On 2021-06-18 16:23, Michael Wojcik wrote:
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Jakob
Bohm via openssl-users
Sent: Friday, 18 June, 2021 07:10
To: openssl-users@xxxxxxxxxxx
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...
Those checks would presumably happen after chain building,
verifying that signatures, dates, key usage and other constraints
are correct.
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.)
Actually, I have heard of nothing at all proposing the use of
SANs on CA certificates or their use in chain building. Hence
why I refer only to matching the complete DN and/or matching
the "key identifier" field.
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.
However it is something that should be documented in OpenSSL
documents such as the "verify(1ssl)" manpage, but somehow isn't.
For example, some versions of that manpage fail to specify which
name restrictions are checked, which are ignored, and which ones
fail even if they shouldn't.
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.
Revocation checks would also be part of the post-chain-building
checks.
My advice, for someone who wants to understand the certificate-validation process in TLS, is:
[Snipped: List of academic texts for those who want to implement their own X.509 code]
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
