Why you're always at least two steps down your HTTPS certificate chain

Many web developers have heard the term 'certificate chain' before. You might have set up an 'intermediate' certificate on your server before - and maybe wondered why you needed to do that. But that's about it.

Understanding certificate chains can help you answer:

• Why your site is always at least the third entry of the chain
• Why your browser trusts - or doesn't trust - the certificate for your web site.
• Why the top level certificates are trusted
• Why intermediate certificates are necessary

...and a whole bunch more.

An HTTPS certificate matches a public key to a domain, and in the case of EV certs, to a verified real-world identity. Your browser can encrypt requests (like reading articles on the Washington Post or sending my credit card details to a pizza company) using a session key that is created using that public key. The only person who can read those requests is the company that has the matching private key, eg, the Washington Post, or the pizza company.

But why does my browser trust certificates? How do we know that the site you're reading this on is actually certsimple.com or for CertSimple Limited [UK], and not someone else?

The browser verifies the certificate because it's signed by another certificate. That certificate is signed by another certificate, and so on, until you reach the top. You might have seen this in your browser before:

This is the 'certificate chain'.

The top level, or 'root' certificates are normally trusted because they came with your OS or browser: see the chart below:

When your browser visits an HTTPS website, it checks the signatures of that site's certificate, and then checks the parent certificate. It keeps checking certificates until it hits the root certificate, stored in whatever trust store you're using.

If we get all the way to a root cert in the trust store, and:

• The signatures in the chain are correct
• The intermediary certificates are known (because the website provided them or because the trust store already included them)
• The root certificate was in the trust store
• Everything else is correct (eg, the key hasn't expired, the domain in the certificate matches the site your browser is visiting, pinning rules aren't violated, etc.)

...then the certificate is seen as correct and you'll be able to connect to the website securely.

If not - say you were setting up HTTPS on localhost and didn't add the key to your trust store, or your certificate expired - your browser displays an angry-looking message complaining about an untrusted key.

At this point we know the certificate is trusted by a CA. But why does your device trust the CAs?

The standard in how they confirm identity are in the Baseline Requirements and Extended Validation Guidelines. They're audited periodically for how they do that, as well as how they handle their private keys, generate new certs, design their network and a bunch of other things. But it's an excellent question, and worth paying attention to in its own right, so we're going to write another article on that shortly.

Why do we need intermediary certificates? Why can't websites just be signed by a root certificate directly?

Having a website certificate signed directly by a root certificate is explicitly banned in the Baseline Requirements. Here's why:

• To sign new child certificates, the private key for the parent certificate must be kept online. Keeping things online makes them vulnerable.
• If websites were signed directly by the root, then a compromise of that root private key would compromise all the certs signed by that root certificate.

So instead:

• Root private keys are kept disconnected
• Each root has a number of intermediaries
• The intermediaries are used to sign new certs.

The intermediaries shard risk: a compromise of an intermediary private key would be bad, but would limit damage to the certificates signed by that specific intermediary.

Every so often, the root is periodically loaded into memory to create new intermediates as part of a key ceremony. That's why intermediate certs are usually many years younger than root certs.

Yes.

As trust stores get updated over time, they include new intermediates - Windows Update, Mac OS fixes, new iOS and Android versions, etc all include certificate updates. Current evergreen browsers on maintained operating systems often work perfectly without intermediates.

But older devices - and there's a lot of old versions of Android out there (and, for Java people, even more out of date JVMs) - may not have newer intermediates: if you want these customers to be able to access your site you'll need to install the intermediary on your web server.

While sites are always at least the third entry in the chain, they can also be further down - you might see something like:

Why the long chain? Short answer: market dynamics! New CAs can't be trusted in every device overnight, since all the existing devices won't have the new CA in their root stores. Instead, a new CA will pay an old CA (someone who's trusted on every device - including the device you're reading this on) to become an intermediary CA, ie, have their new root signed by the more established CA.

Over time the longer chains are typically replaced with shorter ones as the new CA key is added to trust stores in OS and browser updates.

So there you go: how certificate chains work, why intermediaries exist, and why you should install them.