reg: question about SSL server cert verification

[Michael Wojcik]

> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Friday, 18 June, 2021 07:10
> To: openssl-users at openssl.org
> Subject: Re: reg: question about SSL server cert verification
>
> On 2021-06-18 06:38, sami0l via openssl-users wrote:
> > I'm curious how exactly an SSL client verifies an SSL server's
> > certificate which is signed by a CA.

> >
> No, here is what really happens:
>
> First the owner of the server (or a program they use) find
> the chain of intermediary certificates which leads from
> their actual certificate to a commonly trusted root
> certificate, Lets say the chain is:
> RootA->CrossB->IntermediaryC->IntermediaryD->EndCertServer.
> This list of certificates is put in a server config file
> and the complete list is sent in each SSL handshake and
> every CMS signed message.

We hope. But, of course, as Jakob says, there are many misconfigured servers.

> Now the client simply works backwards through that list,
> checking if each certificate signed the next one or claims
> to be signed by a certificate in /etc/certs.  This lookup
> is done based on the complete distinguished name, not just
> the CN part of it. At every step, the certificate may be
> referenced by a "key identifier" instead of the
> distinguished name, and some clients will compare that
> instead of the distinguished name.

And there are a whole bunch of other checks: signature, validity dates, key usage, basic constraints...

Also, the correspondence between the peer identity as requested by the client, and as represented by the entity certificate, should not be done using the CN component of the Subject DN (as OP suggested), but by comparing against the Subject Alternative Name extension values. The subject CN should only be used as a last resort; some applications may refuse to allow a CN match and insist on an X.509v3 certificate with a valid SAN.

(Jakob knows all this.)

Certificate chain validation is a very complicated topic. I put together an internal presentation with an overview of it some years back and it was a dozen or more slides, and I only touched on the major points. It's not something that can be covered thoroughly in an email discussion.


> The big complications are:

Numerous. Jakob's list is a good one, but I'm sure we can come up with others. Like, say, the enormous mess which is revocation.

My advice, for someone who wants to understand the certificate-validation process in TLS, is:

1. Start with one or more books that explain TLS at length. I don't know offhand of a single book which covers the protocol in its current form and all of the many, many aspects of using it in an interoperable fashion. My best suggestion would be to read Rescorla's /SSL and TLS/, which is old but provides a foundation, and Ristic's /Bulletproof TLS/, which describes using TLS in practice and has recently been updated.

2. Experiment using tools such as openssl s_client and s_server to ground that understanding.

3. Read RFC 5280, Public Key Infrastructure - X.509 ("PKIX") and the CA/Browser Forum's Basic Requirements.
        PKIX is the standard for using X.509 certificates for a PKI on the Internet; it certainly isn't always followed, but it will give you an idea of what sorts of rules a TLS application is supposed to obey when validating a peer's certificate chain.
        The CA/BF BR is a standard promulgated by and for commercial CAs and browser manufacturers. It doesn't apply to other TLS participants, but again it shows what sorts of rules those prominent ones are *expected* to follow. Other applications, and private CAs (for example, organizational CAs), might or might not follow similar rules. At any rate, it shows how some participants might be picky about things like the Extended Key Usage (EKU) extension for certificates in the chain, or why they might reject a valid certificate because they're imposing tighter requirements (e.g. the maximum difference between the validity dates).

4. Be aware that pretty much all implementations are buggy in one way or another. If you get into this, you can find all sorts of research documenting errors in certificate validation. That's particularly true when you get into more-complex validation graphs, as Jakob wrote regarding cross-signing. If you subscribe to Hanno Bock's /Bulletproof TLS/ newsletter, and/or read some of the back issues, you'll see how often someone identifies some sort of misbehavior in this area.

So I suppose the answer to your original question is "no, no one can explain certificate validation". It's unlikely there's a single person on the planet who has comprehensive knowledge of all the funky corners of X.509 PKI. (Someone - PGN, maybe - wrote a presentation years ago that covered, among other things, some of the many certificate policies published by various national governments. That's just one example of an X.509-related mess that almost no one pays attention to.)

In practice you can learn enough about it to diagnose most certificate-validation problems. But it takes time and effort.

--
Michael Wojcik