Intermediate Certificate

When you visit a website and see a padlock icon in the browser, behind it lies a system of digital IDs. These IDs are called certificates. They prove that you are really connected to the genuine site and not to a fake one. However, your browser doesn’t trust a certificate blindly — it checks who issued it. Behind this lies a chain: at the very top stands what’s called a root certificate authority, an organization that browsers and operating systems fundamentally trust. Directly beneath it sits the intermediate certificate. It acts as the link between this root authority and the certificates that websites receive day in, day out.

Why the root authority doesn’t simply issue certificates directly

The root certificate authority is the most valuable link in the entire chain. Its private key — the file it uses to sign new certificates — requires extreme protection. Many operators store this key on computers that are physically disconnected from the internet and kept in secured facilities.

If this key were used to issue thousands of certificates every day, the risk would be enormous. If the key were stolen or compromised, every certificate ever issued worldwide would have to be revoked. That would be a disaster. This is why the root authority remains largely offline and dormant — it signs almost exclusively intermediate certificates. These then handle the day-to-day business.

Another advantage: if an intermediate certificate is compromised, it can be revoked individually. The root authority and all other intermediate certificates remain unaffected. The damage stays contained.

How the browser verifies the chain of trust

When your browser visits a website, it receives that site’s certificate. It then asks: who signed this certificate? The answer is: an intermediate certificate authority. The browser then checks whether it recognizes that intermediate certificate or can verify it as well. It climbs up the chain until it reaches a root certificate listed in its own set of trusted authorities. This process is called chain validation.

Most websites therefore don’t just send their own certificate, but the entire chain at once — including the intermediate certificate(s). If a link is missing, the verification fails. The browser then displays a security warning, even though the actual certificate might technically be correct. In practice, this problem occurs surprisingly often because server administrators forget the intermediate certificates or configure them incorrectly.

There can also be several intermediate certificates in sequence, so the chain doesn’t necessarily have just three levels. Each level signs the next, until the chain ends at the root certificate.

Where intermediate certificates become visible in everyday life

Whenever a browser displays a certificate warning, a problem with an intermediate certificate is often the cause. The error message “incomplete certificate chain” or “unknown issuer” almost always points to this. Anyone who, as a student or developer, has ever run their own website with HTTPS knows the situation: their own certificate is correctly set up, but the browser still complains — because the intermediate certificate is missing on the server.

The term comes up in security news whenever a certificate authority gets hacked. In 2011, the provider DigiNotar was compromised. Attackers issued fraudulent intermediate certificates and were able to intercept traffic undetected. The incident led to DigiNotar being removed from all trust lists and becoming insolvent within a few months. It shows just how much power can reside in a single intermediate certificate.

Companies also use intermediate certificates internally: they run their own small certificate authority for their corporate network, issue intermediate certificates under it, and then distribute certificates to internal servers and services. This works because the company’s own root authority is registered as trusted on all company devices.