37

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?

jwodder
  • 166
  • 1
  • 6
User314159
  • 481
  • 1
  • 4
  • 6

3 Answers3

75

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.

psmears
  • 900
  • 7
  • 9
  • 9
    To be specific your certificate needs the `X509v3 Basic Constraints: CA:TRUE` inside it or the `'X509v3 Key Usage: Certificate Sign, CRL Sign' property`. – LvB Aug 21 '17 at 10:31
  • @LvB: Yeah, I was trying not to go to deeply into the technical details :) – psmears Aug 21 '17 at 10:35
  • which is why I just added as a comment and upvoted your awnser ;) – LvB Aug 21 '17 at 11:44
  • 9
    Ah - so *that's* what all this malarky about "intermediate" certificates and the certificate "chain" is for, then! And why when I don't follow my CA's instructions to include intermediate certificates when configuring my webserver, *some* clients can connect successfully and others show certificate errors. As a dumb web developer who has always just mindlessly and uncomprehendingly followed the instructions I was given when setting up SSL, reading this answer has left me suddenly enlightened. – Mark Amery Aug 21 '17 at 19:33
  • 1
    @Mark And the reason for those intermediate certificates is that you need the private key of your CA certificate if you want to create/sign new certificates. Since root certificates are generally valid for a long time (some devices that rely on them just can't easily be updated) it's best to minimize their exposure. If an intermediate certificate is leaked you can revoke it via its root CA, then create a new intermediate certificate and use that to sign new certificates. If a root CA is leaked you have a much bigger problem on your hands, since you cannot revoke it automatically. – Voo Aug 21 '17 at 20:29
  • (In practice I'd hope that every CA has the private keys of their root CAs in cold storage somewhere with stringent security requirements for the very rare use cases where you need it to actually create new intermediate certs). – Voo Aug 21 '17 at 20:33
  • @Voo : Usually (?always?) buried inside a hardware security module and needing multiple smartcards to be presented to enable the use of the root key. – Martin Bonner supports Monica Aug 22 '17 at 09:44
  • There's a 4th scenario that's kind of like scenario #3 except not quite. Windows automatically downloads missing root certificates, and (I assume) verifies them against Microsoft's own root certificate. So it's neither already trusted by the client nor sent by the server. – user541686 Aug 22 '17 at 12:46
27

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.

Numeron
  • 2,485
  • 3
  • 15
  • 19
8

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):

enter image description here

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:

enter image description here

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.

  1. Mozilla Root Store Policy
  2. 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.

Bruno
  • 303
  • 1
  • 5