Validating an SSL certificate chain according to RFC 5280: Am I understanding this correctly?

Question

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):

1. start with the trust anchor; validate if it's still currently valid (time) etc.
2. 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...)
3. 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.

Answer 1

There is X.509, and there is SSL/TLS. TLS expects the server to send an X.509 certificate chain, from which the client will extract the server's public key. Then things diverge:

• In pure X.509, the server should send its certificate for the client to validate; possibly, the server may add an unordered bunch of extra certificates that could prove useful to the client, basically some possibly relevant intermediate CA. The client would still be free to validate the certificate in any way as it sees fit, in particular through arbitrary chain building. This method is demonstrated in, for instance, in CMS (formerly known as "PKCS#7"), in which a signed document (SignedData) references the signer's certificate and optionally includes an unordered set (ASN.1 "SET") of extra certificates.

• In SSL/TLS, things don't go that way. Instead, the server should send the exact chain that is to be used; the server is explicitly allowed to omit the root CA, but that's all. Any client is entitled (at least historically, if not de jure) to reject the server's certificate if the chain does not match this pattern. Of course, any client is allowed to make an effort and try to validate the server's certificate in the X.509 way, with its own path building; but there are SSL client out there that do not make such an effort.

A relevant excerpt of RFC 5246 is in appendix F.1.1:

If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority.

This is the passage that gives SSL clients the "right" to unceremoniously reject server chains that cannot be validated "as is".

In your case, the chain sent by the server is:

    Root-X -> CA1 -> Server

where "Root-X" is "the root signed by Server CA X". The lazy client tries to validate that chain twice:

1. First attempt is based on the assumption that the chain includes the root CA. The client does not find "Root-X" in the list of its own root CA, so this fails.

2. Second attempt is based on the assumption that the chain does not include the root CA. The client scans its root CA for an issuer for Root-X (and that's the critical point). It does not find any, hence failure.

In order to validate the chain sent by your server, the client must be slightly less lazy, and try to find an issuer for CA1 within its own set of trusted CA. This would require a third assumption, namely that the chain sent by the server does include a root CA, but not "the right one".

I suppose that your failing SSL client is a "lazy client" as enunciated above. To make sure, try to connect with Internet Explorer as client; IE, for all its shortcomings, is not lazy when it comes to certificate validation. IE will try to rebuild a chain from the certificates sent by the server, the certificates it has in its own stores, and the certificates it can download. Notably, any certificate may contain a URL pointing to the certificate for its issuer (that's part of the Authority Information Access extension); IE (and, in fact, Windows in general) will gleefully follow such URL and gather intermediate CA (HTTP-only, not HTTPS, to avoid a nasty loop).

If you can thus confirm that the problem is indeed a lazy client, then possible workarounds include the following:

• Change the chain sent by the server so that it includes the self-signed root, or simply ends at CA1.
• Install the "Server CA X" certificate as trusted CA in the clients.
• Modify/configure the client so as not to be lazy.

Of course it is quite possible that your chain is incorrect in some other way, which is difficult to assess without actually seeing the certificates. The path validation algorithm is complex, so there might be another extension that does not please the client (e.g. one certificate might be using a Name Constraints extension on which the SSL client implementation just chokes). Possibly, the client is not lazy, but insists on ascertaining revocation status of all certificates in the path, and some CRL or OCSP responder is out-of-date or unreachable. There are hundreds of ways by which certificate validation may fail.

Answer 2

The provided chain should not include the root, if it does the client must disregard it. A key feature of X.509 trust is that it requires pre-known roots (or trust anchors). This isn't the cause of your problem though. The order is inverted, the server cert should be first, followed by its signer (and its signer etc. if need be), this might cause problems on some platforms, but read on.

Contemporary clients no longer rely on chasing up the chain by DN (i.e. issuer's certificate name). Starting with the AKID of a certificate (Authority key identifier), the parent is the certificate with the matching SKID. The SKID (Subject key identifier) is intended to be a (statistically) unique identifier, typically it's derived from a hash of the public key, but need not be. For the purpose of of verification it's simply an opaque identifier (i.e. verification doesn't recompute it, it only compares the values). It seems most likely the identifiers have changed, though the human readable names have not.

The checking of the chain must start at the server cert, and work toward the root at the "top", this is conventionally "up". This is the same order the chain is presented in. Each cert "knows" only its signer (CN and SKID), nothing else about the hierarchy.

This expands on the verification process a little: Certificate Chain checking, and this gives an example using OpenSSL to reproduce the typical verification process: https://serverfault.com/questions/541262/checking-the-issued-and-expiry-dates-for-the-certificates-involved-a-certificate

Another possible problem is what constitutes the "top", or "trust anchor". Some CAs have a self-signed root certificate (AKID==SKID), some use cross-signed roots (the signing cert belongs to another CA). Where exactly to stop following the chain is a property of the client keystore, typically by virtue of a CA certificate in a specific classification.