How does a client know an SSL cert has been signed by a CA if the client doesn't have the CA's public key?

Question

I'm still learning how SSL/TSL works, so apologies if this question is very basic.

I understand that the server offers the client its SSL certificate, which contains the signature of a CA. I also understand that the client will usually have a list of certificate authorities it trusts. But what if the SSL certificate is signed by a CA that the client is not aware of? How will the client validate the certificate then?

Answer 1

When the client is verifying a certificate, there are three possibilities:

• The certificate is signed by a CA that the client already trusts (and for which it knows the public key). In this case the client treats the certificate as valid.
• The certificate is signed by a CA about which the client has no knowledge at all. In this case the client treats the certificate as invalid (and the browser will likely display a warning message instead of loading the page).
• The certificate is signed by a CA that the client doesn't know, but which has a certificate that is signed by a CA that the client does know. (In this case the server must usually send both its own certificate, and the certificate of the CA - called the "intermediate CA" - that signed its certificate). Since the intermediate CA's certificate is signed by a CA that the client already trusts, it knows can trust it, and since the server's certificate is signed by the intermediate CA, the client knows it can trust it too.

Note that CA certificates are "special" - just because you have a certificate signed by a trusted CA, that doesn't mean you can then sign other certificates and have clients trust them - unless your certificate is marked as being valid for signing other certificates.

Answer 2

It doesn't. It will be treated just as if it were an invalid certificate.

For example, anyone can self-sign a certificate, essentially acting as a CA for yourself - but such are not trusted by browsers, so users get warnings to that effect.

Answer 3

There are a few good answers to this one already, but I feel I should add, just for completeness, that the full chain doesn't always need to be presented to the client.

For our example of how this works, here's a certificate chain with FOUR(!) certificates, including the root and end-entity (note I'm not recommending such a design):

As a note you can get this properties page on any windows machine by double-clicking on a .cer format certificate file in file explorer and selecting 'certification path'

When a client visits the website, there are two ways this chain can be verified. The website can present the website, issuer and policy* certificates to the client directly. Alternatively, some clients can chase up extended properties on the certificates that provide an address to download the next certificate in the chain.

At least for Microsoft certificate clients, this certificate extension is called "Authority Information Access" (AIA), is similarly formatted to the CDP (CRL distribution point) field, and can be used to determine where the next certificate in the chain is located. You can see it on the 'details' tab of the same window that has the certification path, as below:

More info on CDP's and AIA's here.

So in this example, here's how the client verification works for a scenario where the whole chain isn't presented up front:

1. A client visits website.com over https and is presented the 'Website' certificate.
2. The client verifies this is not a trusted root and is not self-signed. Finding an AIA for the 'Issuer' certificate, it downloads this certificate and verifies the public key of this certificate signed the 'Website' certificate.
3. The client verifies that the 'Issuer' certificate is not a trusted root and is not self-signed. Finding an AIA for the 'Policy' certificate, it downloads this certificate and verifies the public key of this certificate signed the 'Issuer' certificate.
4. The client verifies that the 'Policy' certificate is not a trusted root and is not self-signed. However, it finds that the issuer of this certificate is one of the trusted roots and verifies the public key of the root certificate signed the 'Policy' certificate.

For each certificate in the chain, CDP's are checked for Certificate Revocation Lists (CRL's), to ensure there are no revocations.

If the client at any point had found a trusted certificate, the 'Website' certificate has been verified as issued by a trusted root and non-revoked. Other checks (like validity period) may still result in the certificate being invalid.

If at any point the client found a self-signed, non-trusted certificate, the 'Website' certificate has not been verified as issued by a trusted root. Normally the client will pop up a warning at this point.

Yes, this means you could potentially have a trusted certificate that was not self-signed, but it's not a common scenario.

*If the client trusts the root, it should have a copy of the root certificate already - it needs to have been manually added to the list of trusted root authorities! (this is also why some root CA's are still SHA1 and that's not a problem). HOWEVER, some websites will still present the root certificate, because some software will expect a full chain including the redundant root. Expect this kind of nonsensicalness often whenever you're dealing with software that interfaces with certificates.

Addendum - How Roots Get Trusted

While I mentioned roots being manually trusted, most of the time your trusted root certificates are going to be distributed to your machine by non-manual mechanisms, often bundled into every version of the software and/or distributed with automatic updates. Here's a list of common methods and policies for major website-interfacing certificate-using software:

1. Microsoft Trusted Root Certificate Program Updates

   You can get the latest certificate package here.

2. Active Directory Domain-based distribution (note the linked article also covers the method to manually add a trusted root to a local windows computer.)

The above methods both update the Windows OS certificate store which is used by multiple applications including IE and Edge.

3. Mozilla Root Store Policy
4. Root Certificate Policy - The Chromium Projects (incl. google chrome)

Both Mozilla and Chrome are capable of trusting certificates independently from the OS (effectively maintaining their own trusted root stores), and also subscribing to the OS trusted root store, depending on settings configured in the application and the specific OS.

Trusted CA's in app-specific root stores will be added and removed based on the auspices of their trusted root program.