Certificate Chain checking

Question

I have a very specific question.

A client verifies a server by taking the certificate and checking specific values and that the digital signature of the intermediate CA is correct (according to the public key stored on the clients computer).

• Option A: Does the client not make sure that the intermediate CA signature (signed by the root CA) is valid, and that the root digital signature (self signed by the root CA) correlates with the public key stored on the computer?

OR

• Option B: Does the client see that the digital signature of the server is correct and therefore uses the information stored in the certificate store to make up the rest of the chain (i.e. if Certificate B was used to sign the server certificate then my certificate store says that certificate A was used to sign certificate B and therefore I will show that as the rest of the chain)

I understand that the entire chain is installed on the server, but does the client use all certificates?

This was sparked by my general interest and I experienced a case where the intermediate certificate was not installed properly and Google Chrome and Internet Explorer accepted it but Firefox 4.0 did not.

I hope I made my question as clear as possible.

I have taken out some of the other steps used in SSL validation on purpose as not to confuse the question.

Note: There was an invisible image associated with this question which I discovered when editing:

Answer 1

The server will provide its own certificate, and optionally (but recommended) all intermediate CA certs in the chain (aka the CA bundle). It need not provide the root CA cert of the chain, and the client should disregard that cert if provided in the bundle anyway, see this question for more details on that. Since the complete bundle is quite possibly unneeded overhead, the client can state it has a cached copies of one or more certs (RFC7924) to reduce connection setup.

The point of validation is that the client should be able to verify the entire chain up to a trusted root, so it must have a copy of the root already, and must have or obtain all intermediates.

If the client is missing intermediate CA certs it can trust those provided by the server as long as they are verifiable, it can then fill in any missing pieces using its local copies of CA certs. This is the method used for intermediate CA cert updates, so that clients can update easily (there is no widely deployed X.509 certificate fetching or publishing system analogous to PGP key servers). There can be zero, one, or many intermediate certificates in a chain.

Each certificate has only the identifying details of its immediate issuer/parent (i.e. not the entire chain) – this is recorded in the Issuer DN field, and more usefully in the AKID field (AKID/SKID PDF). The readable Issuer name may not uniquely identify a specific cert (it does not record the specific serial number). The SKID (Subject Key Identifier) is effectively a thumbprint of a certificate, and the AKID (Authority Key Identifier) is the thumbprint of its issuer, this works like a singly-linked list from the end cert (ideally) up to a trusted root (though older certificates often lack those fields, so the DNs are used instead).

• Starting with the server provided chain (if present) the client should work down the list, it may add intermediate certificates it is missing to its store, if they are valid.
• Then, the client should trace back up from the servers certificate, usually using the AKID field to locate the specific issuer (parent) certificate, verify, and work up until it gets to a trusted self-signed root.

The terms associated with this process are Certification Path Building and Certification Path Validation. There is no single "right way" to do it. A robust client will check from end to end, browsers typically offers a bypass (with sternly worded warnings), and on some systems you can limit the depth from the end certificate to check as an optimisation.

(Validity checking includes signature/hash, date range, CRL, OCSP, pinning etc. and possibly DANE.)

This overlaps with both of your options, plus self-updating of intermediate CA certs.

Answer 2

The chain of trust is verified by starting at the server certificate and verifying signatures until a trusted root is found. So the site certificate's signature is verified against the public certificate of the intermediate CA. The intermediate CA however is not trusted, so the Intermediate CA's public certificate's signature is validated against the Root CA's public certificate. Since the signature is valid (and there are no revocation list entries saying it shouldn't be valid anymore), the intermediate CA (and thus the server's Certificate) inherit trust from the trusted root certificate.

The process can continue for as many generations of the hierarchy is necessary until a trusted certificate is reached. If the server's certificate had manually been added to the trusted certificates repository on the local machine for example, the Intermediate CA's signature would never have been verified since it is unnecessary to get Trust.

Answer 3

Normally, Server does not send all certificate chains by default. It depends on how server is configured and whether or not all its certificate chains are included into keystore of the web server.

To acheive this on Openssl Server client setup, one has to concatenate all its intermediate with its own certificate. The certificates should be in the order of its own certificate at the beginning and intermediate certificate which signed this in the next and so on(One can ignore concatenating Root CA since it exists on the client). And use the same certificate chain list with SSL_CTX_use_certificate_chain_file on the Server side. Now on client, it is enough to have just a Root CA certificate to verify this certificate chain.

There is another approach which is converse to this. Server just sends its own certificate (which is signed by Intermediate cert and Intermediate by Root CA) in the SSL handshake. Here, client needs to have both Intermediate and Root CA certs to verify the full chain. Client concatenates Intermediate and Root CA in the order of Root CA at beginning followed by an Intermediate cert and so on. (One can ignore concatenating server certificate in this list). Client can use SSL_CTX_use_certificate_file API and include this concatenated file to verify the Server Certificate.