Post date: Apr 08, 2016 7:3:58 PM
I found an interesting x509 certificate scenario this week. We sent our public certificate to a client along with intermediate and root CA certificates. They were to install the intermediate and root certificates as trusted CA, then they would be able to trust our client certificate as long as it was signed / chained to the CA certificates.
What was interesting, is that when our customer viewed the certificate, they saw a different certification path than what we sent. This was surprising to both parties. See below, both certification paths are valid.
Chain 1 - What we see and sent to client:
client.crt info
Subject: CN=<redacted> Key ID:E8:BA:60:26:6F:96:99:DE:85:DC:6B:3A:5C:F5:00:A1:55:B3:A2:FF
Issuer: CN=Trusted Secure Certificate Authority 5 Key ID:F2:BB:55:EE:FC:8F:CF:D0:3F:14:68:1A:95:7E:79:0E:AB:17:30:F4
Validity Not Before: Mar 23 00:00:00 2016 GMT Not After : Mar 23 23:59:59 2019 GMT
TrustedSecureCertificateAuthority5.crt info
Subject: CN=Trusted Secure Certificate Authority 5 Key ID:F2:BB:55:EE:FC:8F:CF:D0:3F:14:68:1A:95:7E:79:0E:AB:17:30:F4
Issuer: CN=USERTrust RSA Certification Authority Key ID:53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB
Validity Not Before: Sep 10 00:00:00 2014 GMT Not After : Sep 9 23:59:59 2024 GMT
USERTrustRSAAddTrustCA.crt info
Subject: CN=USERTrust RSA Certification Authority Key ID:53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB
Issuer: CN=AddTrust External CA Root Key ID:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
Validity Not Before: May 30 10:48:38 2000 GMT Not After : May 30 10:48:38 2020 GMT
AddTrustExternalCARoot.crt info
Subject: CN=AddTrust External CA Root Key ID:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
Issuer: CN=AddTrust External CA Root Key ID:AD:BD:98:7A:34:B4:26:F7:FA:C4:26:54:EF:03:BD:E0:24:CB:54:1A
Validity Not Before: May 30 10:48:38 2000 GMT Not After : May 30 10:48:38 2020 GMT
Chain 2 - What the client sees as certification path for our client cert.
client.crt info
Subject: CN=<redacted> Key ID:E8:BA:60:26:6F:96:99:DE:85:DC:6B:3A:5C:F5:00:A1:55:B3:A2:FF
Issuer: CN=Trusted Secure Certificate Authority 5 Key ID:F2:BB:55:EE:FC:8F:CF:D0:3F:14:68:1A:95:7E:79:0E:AB:17:30:F4
Validity Not Before: Mar 23 00:00:00 2016 GMT Not After : Mar 23 23:59:59 2019 GMT
TrustedSecureCertificateAuthority5.crt info
Subject: CN=Trusted Secure Certificate Authority 5 Key ID:F2:BB:55:EE:FC:8F:CF:D0:3F:14:68:1A:95:7E:79:0E:AB:17:30:F4
Issuer: CN=USERTrust RSA Certification Authority Key ID:53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB
Validity Not Before: Sep 10 00:00:00 2014 GMT Not After : Sep 9 23:59:59 2024 GMT
USERTrustRSACertificationAuthority.crt info
Subject: CN=USERTrust RSA Certification Authority Key ID:53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB
Issuer: CN=USERTrust RSA Certification Authority Key ID:53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB
Validity Not Before: Feb 1 00:00:00 2010 GMT Not After : Jan 18 23:59:59 2038 GMT
You can see, the main difference in the two paths, is the "USERTrust RSA Certification Authority". In our chain, it is signed by a root certificate; in the customer's chain, it is a self signed certificate that terminates the chain.
How can this be? Well, each certificate in the chain is linked to the signing certificate by issuer subject and issuer private key (check out https://en.wikipedia.org/wiki/X.509#Certificate_chains_and_cross-certification for more technical description). The CA can create more than one certificate with the same private key and subject. In this case, they did just that. One is self signed and the other is signed by another root CA.
Why would they do that? One possibility is that the CA is relatively new. They would have their root certificate signed by an already established CA in order to be recognized as valid by browsers until their self signed certificate is distributed to browser and OS trust stores.