Certificate verified using two different paths

Question

StartSSL has an intermediate certificate that they use to sign their EV certificates: sub.class4.server.ca.pem. This certificate's issuer is shown by openssl x509 to be /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority. This matches the certificate they distribute as their root CA: ca.pem.

However, Firefox/Mozilla includes two certificates with that subject. One is the same as the certificate that StartSSL distributes. The other ^{(attached below)} is verifiably different; for instance, the serial number of the former is 1, while the serial number of the latter is 45. Edit: After further research, it turns out that this is the same as the cert that StartSSL distributes as ca-sha2.pem.

If I use openssl verify to check sub.class4.server.ca.pem against ca.pem, it works:

% openssl verify -CAfile ca.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: OK

Interestingly, though, if I check it against the Firefox/Mozilla certificate, it still works:

% openssl verify -CAfile ca-ff.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: OK

Just to make sure something else wasn't getting in there to foul my results, I tried it against a certificate I knew to be the wrong one:

% openssl verify -CAfile ca-wrong.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA
error 20 at 0 depth lookup:unable to get local issuer certificate

That leaves two possibilities: either openssl verify isn't checking the actual signature and relying solely on the Issuer Subject (possibly because I'm using it incorrectly), or somehow this certificate can be verified with two different certificates.

To check the first possibility, I created a self-signed certificate with the same issuer information and used it to verify the intermediate certificate:

% openssl verify -CAfile ca-fake.pem -verbose sub.class4.server.ca.pem
sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA
error 20 at 0 depth lookup:unable to get local issuer certificate

So it seems that openssl verify is not that easily bamboozled.

Then it occurred to me that two different certificates could verify the same child certificate if they used the same RSA key, and I found that the public key modulus reported for the two certs are the same.

Is it concerning at all that StartCom has apparently used the same RSA key for two different certificates? It seems like a bad idea to me, but I'm just an amateur.

For convenience for anyone else looking into this, here's the additional certificate that Firefox has:

score 6 · Accepted Answer · edited Oct 07 '21 at 06:58

As far as X.509 is concerned, there is absolutely no problem in having several certificates with the same public key. The validation process is described in full details here; in a nutshell, it is verified that:

each certificate in the chain is currently valid (with regards to its start and end dates for validity);
the signature on each certificate is correct for the certificate contents and the public key in the issuing CA;
the issuer DN of each certificate matches the subject DN of its issuing CA;
all certificate extensions (certificate policies, name constraints...) are correct.

Having the same public key in two distinct certificates is not a problem. Each certificate asserts a binding between a public key and an identity. If you have ten certificates which assert the same binding, so much the better.

In practice, having several certificates with the same name and key is the normal outcome of renewals. When a certificate expires, you may wish to keep the same key pair for the new certificate.

In your case, the situation is slightly different because the involved certificates are root certificates, i.e. not "real" certificates: they are not issued by a CA; they are convenient vessels for trust anchors. Nevertheless, a comparison of both certificates (with openssl x509 -text -noout -in ca.pem) reveals the reason why there are two (and it is a very poor reason): this is part of a predicted overarching anathema on SHA-1. Indeed, a root certificate is often self-signed (because there is a non-optional field for a signature in the X.509 format), and a signature algorithm begins by a hash function. The "old" certificate (the ca.pem file from StartSSL) declares a signature with SHA-1, while the "new" certificate (from Firefox's entrails) uses a SHA-256 based signature.

Another difference is that the "new" certificate does not include URL for CRL download, which is correct since a root certificate, by definition, cannot be revoked by its issuing CA.

Apart from the serial number, hash algorithm, and URL for CRL download, the two certificates are identical; they contain the same name, public key and validity dates. I think that the blind, systematic, overzealous rejection of SHA-1 is the main drive here. This is a poor reason because:

SHA-1 is not broken yet, in particular for signatures, which work more on preimages than collisions.
The signature on a root certificate is pointless, so it does not matter if the declared hash function is SHA-1, SHA-256, MD5 or FOOBAR42.

I did finally find the source of the second certificate: [Mozilla/NSS bug 751954](https://bugzilla.mozilla.org/show_bug.cgi?id=751954). — wfaulk, Mar 27 '14 at 23:14

Certificate verified using two different paths

1 Answers1

Linked

Related