1

Given

  • Final X.509 certificate A in PEM format.
  • Access to the certificate store of the server, which encloses all certificates, including singing chain for the certificate A.

OpenSSL shows following attributes of the certificate:

openssl x509 -in second.der -inform DER -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            xx:xx:xx:xx:xx
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: aaa
        Validity
            Not Before: May 14 08:33:31 2019 GMT
            Not After : May 14 04:33:51 2024 GMT
        Subject: bbb

How can I recover the singing chain, thus all certificates which were used to sign the A until the root certificate?

Naive approach to look for the certificates having Subjet: bbb fails, because it also fetches from the store old certificates, which were used to sign previous versions of the current certificate.

Anton Golubev
  • 131
  • 4
  • The `issuer` field tells you the name of the certificate that is one level up in the chain. – mti2935 Jul 11 '22 at 16:52
  • Naive search `issuer` -> `subject` produces dissatisfactory results, because it catches expired or newly added parent certificates, which are present in the store, but not part of the trust chain for the given final certificate. – Anton Golubev Jul 11 '22 at 16:57
  • This is why servers generally serve the entire certificate chain, up to (and sometimes even including) the root certificate. Notwithstanding, modern browsers are smart enough to do what you are describing - in fact, this is how cross-signing is possible, and how browsers are able to overcome expired certificates in the chain (see https://security.stackexchange.com/questions/258190/what-could-cause-classic-err-cert-date-invalid-when-i-can-confirm-no-error-fro/258650#258650 for more info). But, this requires the browser to do some trial-and error using the certs in its store (and elsewhere). – mti2935 Jul 11 '22 at 17:12
  • Did you remove extensions from the display? An X.509 certificate without extensions should be v1 not v3. And as noted some of them are very relevant to chaining. – dave_thompson_085 Jul 14 '22 at 01:57

1 Answers1

3

The Authority Key Identifier (AKI) extension in a certificate points to the signing key, which should be unique to a CA certificate.

From RFC 5280 Section 4.2.1.1:

The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate. This extension is used where an issuer has
multiple signing keys (either due to multiple concurrent key pairs or due to changeover). The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or the issuer name and serial number.

In reality, most CAs use the subject key identifier in the issuer method to generate the AKI. You can work your way up the chain to the Root CA by comparing AKI with the proposed parent CA's Subject Key Identifier (SKI) - if they match, that key signed your target certificate.

This assumes that all the issuers are available to you. In the real world, it is the certificate sender's responsibility to send all the other certificates required to build a chain, less the Root CA certificate, which must already be in your trust-anchor store.

garethTheRed
  • 1,392
  • 7
  • 12
  • Thanks! Exactly that! In CLI it would be `openssl x509 -in ./cert.pem -text` under `X509v3 extensions` shows `X509v3 Subject Key Identifier` and `X509v3 Authority Key Identifier`. You can traverse `Authority key Identifier` -> `Subject Key Identifier` until you reach the certificate marked as `CA:TRUE` – Anton Golubev Jul 12 '22 at 23:34
  • 1
    `openssl s_client` by default shows brief (two-line) form of the (re)ordered and augmented chain passed to the verify callback, but adding `-showcerts` adds the chain/list as received in full PEM form which can be e.g. input (individually) to `openssl x509 -text`. Also in TLS1.3 (now over half of top websites per Qualys) certs are no longer visible to a network trace like wireshark unless you can have your endpoint give it session secrets e.g. Firefox/Chrome SSLKEYLOGFILE. And 8446 weakens the ordering requirement (other than first=leaf) to SHOULD instead of MUST. – dave_thompson_085 Jul 14 '22 at 01:54
  • @dave_thompson_085: Thanks - I never realised `-showcerts` listed the received certs. Every day's a school day :-) – garethTheRed Jul 14 '22 at 05:53
  • @garethTheRed I liked your original answer much more: it was precise and short. Key is - use AKI iteratively to traverse up to the singing chain. Now you've added a lot of assumed context information, which was not in the question. – Anton Golubev Jul 14 '22 at 13:45