> From: openssl-users <[email protected]> On Behalf Of Jakob
> Bohm via openssl-users
> Sent: Friday, 18 June, 2021 07:10
> To: [email protected]
> 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
