we're in the process of replacing certificates with SHA1 hash due to Google's move to let them appear less secure in Chrome. The replacement certificates use a different intermediate CA than the ones we're currently using, but the same root CA. During testing we noticed that our SSL clients would fail to validate the chain using the new certificates we don't quite understand why.
Here's the specifics:
Currently the chain the server sends looks like this:
- Root CA, signed by Server CA X from the same authority (came with Server Certificate)
- Intermediate CA 1 (came with Server Certificate)
- Server Certificate
in our SSL clients we trust:
- Root CA, self signed, but same CN and same key (same skid)! (Downloaded from authority; same as Mozilla incorporates in its products)
- Intermediate CA 1 (identical with the one the server sends)
This works with the current certificate chain but only because we trust Intermediate CA 1. If we remove this it fails because Server CA X is not trusted. New certificates obviously don't work then, because they are signed by a different intermediate CA.
Now, from reading RFC 5280, section 6.1, my impression is that our SSL client does not adhere to standards, because from what I've read my understanding of a certificate path validation is this (simplified):
- start with the trust anchor; validate if it's still currently valid (time) etc.
- for the following certificates: check if the CN and key of the previous certificate match with the issuers CN and key of the current certificate (and check pathlen constrains etc...)
- the last certificate must not be a CA certificate
The point is: Our SSL client fails to validate the chain because the root certificate it's configured to use as a trust anchor has a different issuer than the root certificate presented by the server. However, CN and key are identical for both. From my understanding of what I've read in RFC 5280 the SSL client should not care for the issuer of its trust anchor. There are also no policies defined in the certificates inside the chain that would enforce anything like that. However, I don't know if our SSL client may enforce additional policies that would lead to this (not my system).
So my question is: Does our SSL client behave correctly in this scenario or not? And of course: Why?
Thanks in advance
Edit: I know that the server should only send the intermediate CA cert and not the root cert, however, we're using what the authority provided as a cabundle alongside the certificate, which included the root certificate. Moreover, from what I know, the client should disregard the root certificate sent by the server in that case.
Also what's weird is that the client behaves as if it validates the chain from the server certificate down to something it can trust and then stops, whereas the specs say it should validate the chain from the trust anchor up to the server certificate.
Edit2: The different "versions" of the Root CA cert all have the same SKID - they only differ in issuer and serial number (of course).
Also, just came to mind, from the first edit's information it seems the SSL client either needs the root certificate in trust and chain to be identical in its issuer and possibly serial number to accept it.