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
