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?

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.

| improve this answer | |
  • Found that this would essentially do with I wanted: openssl verify -show_chain -untrusted intermediate-cert.pem leaf-cert.pem – oligofren Oct 22 at 7:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.