reg: question about SSL server cert verification

[Jakob Bohm]

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. So, during the SSL handshake, 
> when the server sends its certificate, will the SSL client first 
> checks the `Issuer`'s `CN` field from the x509 SSL certificate that it 
> received for example, and compares against all the `CN`s of all the 
> certificates stored `/etc/ssl/certs` of that client and if it matches 
> any one of them, next it checks the signature of the received 
> certificate by parsing the public key from that CA cert located in 
> `/etc/ssl/certs/someCA.crt` and performers the decryption and checks 
> the signature of the received certificate and if the signature 
> matches, the browser accepts the certificate since it just verified 
> that it's signed by the CA which is located in `/etc/ssl/certs` and 
> uses that cert? Is this how the SSL client verifies the certificate 
> when it receives a server's certificate during the handshake process? 
> If not, It'd be really helpful if someone could explain me how it's 
> exactly done.
>
>
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.

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.

The big complications are:

1. The server owner may have configured the "wrong" list and
clients may or may not work around that.

2. Not all clients trust the same exact list of root CAs,
hence the invention of "cross-signed roots", which are
intermediary certificates with the same name and public
key as a not-known-everywhere root, but signed by an
already-known-everywhere root.

3. Not all clients react the same way when the server
includes a cross certificate in the list.  Some recognize
the cross as the same as a root they trust and declare
success without having to trust the (possibly old)
compatibility root, others check only the compatibility
root and get confused when that old root dies.

4. Some quality checkers (looking at you QualSys) object
strongly to the server including the root itself in its
list, because the root is supposed to be on all the clients
that trust it.  But experienced human client users can
actually use an included root to make informed decisions
about trust errors.

OpenSSL documentation tends to bury its handling of all
this way too deep inside the programmer documentation
rather than explaining things clearly in the end user
documentation.

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