1

Does a X.509 Certificate contain some kind of ID that is associated with the Private Key that was used to create the Certificate? So if i had a database of all my Private Key IDs, i could then look at a Certificate Field, that contains the ID and know which Private Key was used. If so, what is the field? And is there ever a case where it may be empty? Or should it always have a value.

1
  • It's really sad thatthere is no key id because we can't store multiple certsand their keys in a single file Commented Jun 27, 2023 at 18:03

3 Answers 3

1

Technically, the only private key used when issuing a certificate is the issuer's, the subject the certificate is issued for only has to provide its public key. But i think you mean the subject's key, and are asking how to create/find an identifier for that.

X.509 certificates as defined in RFC 5280 may identify the subject's key in three ways:

  1. Issuer Distinguished Name plus serial number

  2. Subject Key Identifier

  3. Certificate Fingerprint

Let's look at an example. The certificate provided by Google is instructive because Google is quite diligent in providing this information. You can use your browser to inspect/download the certificate or obtain it with OpenSSL

$ openssl s_client -connect www.google.com:443 | openssl x509 -noout -text

The three identifiers are all present. First, issuer and serial number

Serial Number:
   ec:97:43:fa:9b:c4:a2:19:02:00:00:00:00:7f:d5:01
Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1

This information is mandatory, and the serial number must be unique. Second, the subect key identifier:

X509v3 Subject Key Identifier:
    CA:99:9C:40:40:2E:F4:66:0C:96:AE:2B:DB:2A:B9:C3:0A:9F:03:4D

This is a SHA-1 hash over the public key itself, so this may be the closest thing to what you want. The SKI may be used in place of the issuer/serial number pair in places like S/MIME encrypted email to identify the keys used. In an ideal world, SKI and issuer/serial numbers have the same semantics, but of course in the real world, your mileage may differ.

Additionally, while not defined in the standard, the fingerprint (obtained via openssl x509 -noout -fingerprint) of the certificate (not just the public key) is often used:

SHA1 Fingerprint=C7:02:0E:0A:96:C9:22:79:2E:E5:62:74:AB:5B:65:B6:39:34:D2:D5

This is a hash over the whole certificate.

Which one do you want to use? Well they all have upsides and downsides:

  1. Issuer and serial number are human-readable. The serial number also shows up in places like Certificate Revocation Lists, so it is useful information. But string comparisons on issuer Distinguished Names are notoriously tricky, so many organizations end up writing their own code to do this.

  2. SKI is available right at keypair generation, and its string representation is easily defined, so you don't have these issues. But the first advantage is overstated: you usually generate keypairs right before having a certificate issued anyway, so you rarely have a naked keypair to derive an identifier from. And while SKI should be unique, in practice some organizations reuse private keys, and this may or may not be an issue for you.

  3. Fingerprints are often referred to in the literature as the thing you should look at to establish the authenticity of a certificate. But they are closely tied to the certificate, which, as explained above may or may not bother you.

1

The certificate contains the public key matching the private key. This public key is actually the most important part of the certificate, the rest are just meta data which describe what this public key is for (i.e. owner), if it is valid, who signed it and for what purposes it can be used. The public key is thus always there, i.e. a certificate without key would not make sense.

The public key is all what is needed to find the matching private key when you have multiple private keys to choose from.

6
  • hello, so could you generate a hash of the public key, and compare it to a hash of the private key then? As i wont have access to the private keys, but i can generate a hash or ID or something from them before they are stored away.
    – PixelPaul
    Commented Nov 16, 2020 at 8:22
  • @PixelPaul: One cannot directly compare the public key to the private key but one can extract the public key from the private key. If one then takes the full public key for comparison or just a hash of it does not really matter. Commented Nov 16, 2020 at 8:52
  • OP was asking about the private key used to generate the certificate. In general (excluding root/self-signed certificates), the public key in the certificate is not related to the private key used to sign the certificate.
    – ysdx
    Commented Nov 21, 2020 at 0:17
  • @ysdx: I'm aware of this. I do not claim that the private key matching the public key in the certificate was used to sign the certificate. I'm not sure what part of my answer you interpret this way. Commented Nov 21, 2020 at 3:46
  • 1
    @ysdx: I see what you mean. I understood that the question was asking about the private key associated with the certificates subject (i.e. the one matching the certificates public key) and the other answer interpreted the question in the same way. But you are right in that OP could be interpreted as asking about the private key used for signing too with exactly the same wording since there are actually two keys involved when creating the certificate. Commented Nov 21, 2020 at 9:00
1

A certificate by itself (e.g., in a DER encoded format) does not contain any information pertaining to the private key, other than the public key itself.

However, in Windows a certificate in a certificate store may have what is called a certificate property. More information on how private keys are associated with certificates in Windows using this method is here: https://docs.microsoft.com/en-us/windows/win32/seccrypto/certificate-extended-properties.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .