Certificate Chains Explained: Why 'Untrusted' Errors Actually Happen
Learn how SSL certificate chains work, what root and intermediate certificates do, and why browsers display certificate trust errors even when a website has HTTPS enabled.
Few website errors create as much confusion as “Your connection is not private,” NET::ERR_CERT_AUTHORITY_INVALID, “Certificate not trusted,” or “SSL certificate verification failed.” Website owners often respond with some version of “but we have an SSL certificate installed.” The problem is that having a certificate is only part of the story.
Modern browsers do not simply check whether a certificate exists. They verify whether that certificate can be traced through a trusted chain of certificates all the way back to a trusted authority. When that chain breaks, browsers stop trusting the connection, even if the certificate itself looks perfectly valid.
Understanding certificate chains explains why these errors occur and why they can appear even on sites that seem to be configured correctly.
What Is a Certificate Chain?
A certificate chain is a sequence of digital certificates that establishes trust between a website and a trusted Certificate Authority (CA). Instead of trusting every website directly, browsers trust a small number of certificate authorities. Those authorities issue certificates to other authorities, which eventually issue certificates to websites.
A simplified chain looks like this:
Website Certificate
↓
Intermediate Certificate
↓
Root Certificate
If the browser can successfully verify every link in the chain, the connection is trusted. If any link is missing or invalid, trust breaks down.
Why Certificate Chains Exist
At first glance, certificate chains may seem unnecessarily complicated. Why not simply let the root authority sign every website certificate directly? The answer is security. Root certificates are among the most sensitive cryptographic assets in existence. If a root certificate’s private key were compromised, every certificate issued by that authority could potentially become untrustworthy.
To reduce this risk, root authorities rarely issue certificates directly. Instead they create intermediate certificate authorities, so the structure typically looks like:
Root CA
↓
Intermediate CA
↓
Website Certificate
This way, the root key can remain highly protected while intermediates handle day to day certificate issuance. This is a similar principle to how sensitive cryptographic material is handled elsewhere in security, such as the key strength trade offs covered in AES-128 versus AES-256.
Understanding the Three Main Certificate Types
Root Certificates
Root certificates sit at the top of the trust hierarchy. Examples of well known root certificate authorities include DigiCert, Let’s Encrypt, and GlobalSign. Operating systems and browsers include trusted root certificates by default, so when a browser trusts a root certificate, it trusts every certificate issued through that authority’s chain.
Intermediate Certificates
Intermediate certificates sit between the root and the website. Their purpose is to reduce risk, improve operational flexibility, and allow certificate authorities to rotate issuing infrastructure without touching the root. A certificate authority may operate multiple intermediates at the same time.
Server Certificates
These are the certificates installed on websites. When visiting https://example.com, the server presents its certificate to the browser. This certificate identifies the domain and enables encrypted communication.
How Certificate Validation Works
When a browser connects to a website, it performs several checks in sequence.
Step 1: Receive the Website Certificate
The server provides its certificate for example.com.
Step 2: Verify the Signature
The browser checks which certificate signed it:
example.com
↓
Intermediate CA
Step 3: Verify the Intermediate
The browser verifies the intermediate certificate:
Intermediate CA
↓
Root CA
Step 4: Verify Root Trust
The browser checks whether the root certificate exists in its trusted certificate store:
Trusted Root Store
If every step succeeds, the connection is trusted.
What Happens When a Chain Is Missing?
One of the most common causes of trust errors is an incomplete certificate chain. Consider a situation where the website certificate is installed but the intermediate certificate is missing. The browser receives the website certificate, but it cannot verify the link between the website certificate and the intermediate CA. The chain cannot be completed, trust fails, and the browser displays an error. This problem is surprisingly common after certificate renewals or server migrations, since it is easy to install the new website certificate and forget the accompanying intermediate.
The Most Common “Untrusted” Certificate Errors
For the formal rules certificate authorities follow, see the CA/Browser Forum baseline requirements.
Missing Intermediate Certificates
The server fails to provide the required intermediate certificate. This is one of the most common causes of certificate trust failures in practice.
Self-Signed Certificates
A self-signed certificate signs itself rather than being signed by a separate authority. There is no trusted authority involved, so browsers typically reject these certificates unless they have been explicitly configured to trust them.
Expired Certificates
Every certificate has an expiration date. When that date passes, the certificate becomes invalid and trust immediately fails.
Wrong Hostname
The certificate was issued for example.com, but the user visits api.example.com. The certificate no longer matches the hostname the browser is trying to reach, so validation fails.
Revoked Certificates
Certificate authorities can revoke certificates that should no longer be trusted, for reasons including compromised keys, fraudulent issuance, and security incidents. Browsers may reject revoked certificates outright.
Why Browsers Trust Some Certificates Automatically
Browsers maintain a list of trusted root certificates, often called the root trust store. Operating systems and browsers periodically update these trusted roots, and the major stores include the Windows Certificate Store, macOS Keychain, the Mozilla Root Program, and the Android Trust Store. For the policy that governs how certificates get added to one of these stores, see Mozilla’s certificate policy. When a certificate chain ends at one of these trusted roots, the browser accepts the connection.
Why Internal Company Certificates Often Cause Problems
Many organisations create their own internal certificate authorities, with a chain that might look like an internal root CA issuing to an internal intermediate, which in turn issues to an internal website. The problem is that public browsers do not automatically trust internal roots. Unless the organisation installs the root certificate on employee devices, browsers will display trust warnings. This is exactly why internal development environments so often produce certificate errors even when everything is configured correctly on the server side.
Understanding Cross-Signed Certificates
Certificate chains can become more complicated when a certificate authority wants compatibility with older devices. One solution is cross-signing, where the same intermediate certificate is signed by two different roots, say Root A and Root B. This allows older devices to continue trusting certificates even after ecosystem changes. The widely publicised transition involving Let’s Encrypt and older Android devices is a well known example of this technique.
How to Inspect a Certificate Chain
Most browsers allow you to inspect certificate information directly. In Chrome, clicking the padlock icon, then “Connection is secure,” then “Certificate is valid” will show you the website certificate, intermediate certificates, root certificate, expiration dates, and issuing authority. This information is often the fastest way to diagnose a trust problem.
Common Troubleshooting Steps
When a certificate trust error occurs, work through these checks in order.
Is the certificate expired? Verify the validity dates on the certificate.
Is the hostname correct? Ensure the certificate matches the exact domain being accessed, including any subdomain.
Are intermediate certificates installed? Confirm the server is providing the complete chain, not just the website certificate.
Is the root trusted? Verify the root exists in the operating system or browser trust store being used.
Has the certificate been revoked? Check revocation status if the other checks come back clean.
These five checks resolve the majority of certificate trust issues.
Why HTTPS Alone Does Not Guarantee Trust
Many people assume that HTTPS means trusted, but this is not always true. A website can use HTTPS, encrypt its traffic, and still fail certificate validation. Encryption and trust are related but separate concepts. HTTPS provides encryption. Certificate chains establish trust. Both are required for a genuinely secure browser connection.
Real-World Example
A website installs a new certificate after renewal. The administrator uploads website.crt but forgets intermediate.crt. The site appears to work fine on some devices, while other users receive a “Certificate Not Trusted” error. The website certificate itself is valid, but the chain is incomplete, so browsers cannot verify trust back to a trusted root. The result is an untrusted error despite HTTPS being enabled and the certificate itself being genuine.
Frequently Asked Questions
What is a certificate chain? A certificate chain is the sequence of certificates, from a website certificate through one or more intermediate certificates up to a trusted root certificate, that a browser uses to verify a site can be trusted.
Why does my site say the certificate is not trusted even though I installed one? This almost always means the chain is incomplete. The website certificate is present, but the intermediate certificate the browser needs to link it to a trusted root has not been installed on the server.
How do I fix a certificate not trusted error? Check whether the certificate has expired, confirm the hostname matches exactly, make sure the server is sending the full chain including intermediates, and verify the root authority is one your browser or operating system already trusts.
What is the difference between a root and an intermediate certificate? A root certificate is issued by a trusted certificate authority and sits at the top of the trust hierarchy. An intermediate certificate is issued by that root and used to sign website certificates, which keeps the root’s private key isolated and reduces risk if an intermediate is ever compromised.
Why do internal company websites show certificate warnings? Internal certificate authorities are not part of the public root trust store that browsers ship with by default. Unless an organisation manually installs its internal root certificate on employee devices, browsers will treat sites signed by that internal CA as untrusted.
Conclusion
Certificate chains are the foundation of trust on the modern internet. Rather than trusting every website individually, browsers trust a small number of root certificate authorities, and website certificates inherit that trust through a chain of intermediate certificates linking them back to a trusted root.
Most certificate trust errors happen because that chain cannot be verified. Missing intermediates, expired certificates, hostname mismatches, self-signed certificates, and untrusted roots can all break the chain and trigger browser warnings. Understanding how certificate chains work makes it much easier to diagnose SSL and TLS problems, and explains why a website can have a certificate installed and still appear untrusted to visitors.
Written by the Workshelve team, who write practical explainers on data integrity, networking, and developer tooling.