4

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:

-----BEGIN CERTIFICATE-----
MIIHhzCCBW+gAwIBAgIBLTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEW
MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg
Q2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDYwOTE3MTk0NjM3WhcNMzYwOTE3MTk0NjM2WjB9
MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi
U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3Rh
cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggIiMA0GCSqGSIb3DQEBAQUA
A4ICDwAwggIKAoICAQDBiNsJvGxGfHiflXu1M5DycmLWwTYgIiRezul38kMKogZk
pMyONvg45iPwbm2xPN1yo4UcodM9tDMr0y+v/uqwQVlntsQGfQqedIXWeUyAN3rf
OQVSWff0G0ZDpNKFhdLDcfN1YjS6LIp/Ho/u7TTQEceWzVI9ujPW3U3eCztKS5/C
Ji/6tRYccjV3yjxd5srhJosaNnZcAdt0FCX+7bWgiA/deMotHweXMAEtcnn6RtYT
Kqi5pquDSR3l8u/d5AGOGAqPY1MWhWKpDhk6zLVmpsJrdAfkK+F2PrRt2PZE4XNi
HzvEvqBTViVsUQn3qqvKv3b9bZvzndu/PWa8DFaqr5hIlTpL36dYUNk4dalb6kMM
Av+Z6+hsTXBbKWWc3apdzK8BMewM69KN6Oqce+Zu9ydmDBpI125C4z/eIT574Q1w
+2OqqGwaVLRcJXrJosmLFqa7LH4XXgVNWG4SHQHuEhANxjJ/GP/89PrNbpHoNkm+
Gkhpi8KWTRoSsmkXwQqQ1vp5Iki/untp+HDH+no32NgN0nZPV/+Qt+OR0t3vwmC3
Zzrd/qqc8NSLf3Iizsafl7b4r4qgEKjZ+xjGtrVcUjyJthkqcwEKDwOzEmDyei+B
26Nu/yYwl/WL3YlXtq09s68rxbd2AvCl1iuahhQqcvbjM4xdCUsT37uMdBNSSwID
AQABo4ICEDCCAgwwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYD
VR0OBBYEFE4L7xqkQFulF2mHMMo0aEPQQa7yMB8GA1UdIwQYMBaAFE4L7xqkQFul
F2mHMMo0aEPQQa7yMIIBWgYDVR0gBIIBUTCCAU0wggFJBgsrBgEEAYG1NwEBATCC
ATgwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5w
ZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVk
aWF0ZS5wZGYwgc8GCCsGAQUFBwICMIHCMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0
YXJ0Q29tKSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUg
c2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMDgG
CWCGSAGG+EIBDQQrFilTdGFydENvbSBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTANBgkqhkiG9w0BAQsFAAOCAgEAjo/n3JR5fPGFf59Jb2vKXfuM/gTF
wWLRfUKKvFO3lANmMD+x5wqnUCBVJX92ehQN6wQOQOY+2IirByeDqXWmN3PH/UvS
Ta0XQMhGvjt/UfzDtgUx3M2FIk5xt/JxXrAaxrqTi3iSSoX4eA+D/i+tLPfkpLst
0OcNOrg+zvZ49q5HJMqjNTbOx8aHmNrs++myziebiMMEofYLWWivydsQD032ZGNc
pRJvkrKTlMeIFw6Ttn5ii5B/q06f/ON1FE8qMt9bDeD1e5MNq6HPh+GlBEXoPBKl
CcWw0bdT82AUuoVpaiF8H3VhFyAXe2w7QSlc4axa0c2Mm+tgHRns9+Ww2vl5GKVF
P0lDV9LdJNUso/2RjSe15esUBppMeyG7Oq0wBhjA2MFrLH9ZXF2RsXAiV+uKa0hK
1Q8p7MZAwC+ITGgBF3f0JBlPvfrhsiAhS90a2Cl9qrjeVOwhVYBsHvUwyKMQ5bLm
KhQxw4UtjJixhlpPiVktucf3HMiKf8CdBUrmQk9io20ppB+Fq9vlgcitKj1MXVuE
JnHEhV5xJMqlG2zYYdMa4FTbzrqpMrUi9nNBCV24F10OD5mQ1kfabwo6YigUZ4LZ
8dCAWZvLMdibD4x3TrVoivJs9iQOLWxwxXPR3hTQcY+203sC9uO41Alua551hDnm
fyWl8kgAwKQB2j8=
-----END CERTIFICATE-----
6

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.

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.