reg: question about SSL server cert verification

[Jakob Bohm]

On 2021-06-18 16:23, Michael Wojcik wrote:

>> 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...
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