1

When manually building a certificate you often do something like this, appending an intermediate certificate to your own (and sometimes the root CA):

# Concatenate intermediate certificate and root certificate
cat ${CERTNAME}.single.pem DigiCertSHA2ExtendedValidationServerCA.pem DigiCertHighAssuranceEVRootCA.pem > ${CERTNAME}.pem

I recently appended an intermediate certificate to a certificate that was issued by another CA, and of course, Chrome warned me that it could not validate the certificate. I wonder how I can know this ahead of time, using for instance openssl or keytool to ensure that I only concatenate certificates to the chain that make sense.

When making a "human readable dump" of an intermediate Buypass certificate I get this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1b:78:1c:6d:5e:34:ce:1f:77
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 Root CA
        Validity
            Not Before: Mar 25 12:17:10 2019 GMT
            Not After : Oct 26 09:16:17 2030 GMT
        Subject: C = NO, O = Buypass AS-983163327, CN = Buypass Class 2 CA 2
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:9c:ab:67:c6:96:4b:0d:0f:91:d2:ec:ca:cc:33:
                    2b:f3:72:fc:0e:7f:b9:4e:84:a9:0f:7d:73:aa:26:
...

(using openssl x509 -in my-cert.pem -noout -text)

The Subject field in this intermediate certificate is the same as the Issuer field in my own certificate, so I guess I could extract this and grep it, but although that will probably be sufficient in 99% of the cases, it does not strike me as correct :) Is there some kind of signature I can use to verify "ancestry" between the two?

oligofren
  • 601
  • 2
  • 8
  • 21
  • You probably should say A right intermediate rather than THE right one. Due to frequent changes in CA businesses many CA's have 'cross' certs from multiple roots and you can validly use any of them. For a well-explained example, see https://letsencrypt.org/certificates/ . – dave_thompson_085 Oct 21 '20 at 18:47
  • 1
    To use openssl to verify a (potential) chain more or less the same as a browser or other client, see https://security.stackexchange.com/questions/163577/should-a-server-or-a-client-be-able-to-verify-a-client-server-certificate-inte and https://stackoverflow.com/questions/29436967/how-to-chain-a-ssl-server-certificate-with-the-intermediate-and-root-ca-certific . To use openssl to choose a chain for you see https://serverfault.com/questions/1011294/how-to-view-certificate-chain-using-openssl . – dave_thompson_085 Oct 21 '20 at 18:57
  • Your answer in the second link more or less answered it for me. The third as well. Voting to close this and redirect people to the third link. – oligofren Oct 22 '20 at 07:38

1 Answers1

2

Yes, there are two extensions which can help you out here. The Subject Key Identifier and the Authority Key Identifier.

The former should be based on the public key of the certificate in which this extension is embedded. The latter should based on the public key which signed the certificate - that is, the CA. RFC 5280 defines alternative methods for generating these values, but the main point is that they should be unique for a certificate.

So, if you have a certificate with an Authority Key Identifier (AKI) of 1234567890abcdef, it will have been signed by a CA whose Subject Key Identifier (SKI) is also 1234567890abcdef. You can use this to trace the chain.

Community
  • 1
garethTheRed
  • 4,009
  • 13
  • 20
  • Found that this would essentially do with I wanted: `openssl verify -show_chain -untrusted intermediate-cert.pem leaf-cert.pem` – oligofren Oct 22 '20 at 07:41