Certificate Chains Explained: Why 'Untrusted' Errors Actually Happen

Few website errors create as much confusion as:

Your connection is not private

NET::ERR_CERT_AUTHORITY_INVALID

Certificate not trusted

SSL certificate verification failed

Website owners often respond with:

But we have an SSL certificate installed.

The problem is that having a certificate is only part of the story.

Modern browsers don’t 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.

Understanding certificate chains explains why these errors occur and why they can sometimes appear even when a certificate looks perfectly valid.

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.

The structure typically looks like:

Root CA
     ↓
Intermediate CA
     ↓
Website Certificate

The root key can remain highly protected while intermediates perform day-to-day certificate issuance.

Understanding the Three Main Certificate Types

Root Certificates

Root certificates sit at the top of the trust hierarchy.

Examples include certificates issued by organisations such as:

• :contentReference[oaicite:0]{index=0}
• :contentReference[oaicite:1]{index=1}
• :contentReference[oaicite:2]{index=2}

Operating systems and browsers include trusted root certificates by default.

When a browser trusts a root certificate, it trusts certificates 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
• Allow certificate authorities to rotate issuing infrastructure

A certificate authority may operate multiple intermediates simultaneously.

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.

Step 1: Receive the Website Certificate

The server provides its certificate.

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 this situation:

Website Certificate

The website certificate is installed.

The intermediate certificate is missing.

The browser receives:

Website Certificate

but cannot verify:

Website Certificate
      ↓
Intermediate CA

The chain cannot be completed.

Trust fails.

The browser displays an error.

This problem is surprisingly common after certificate renewals or server migrations.

The Most Common “Untrusted” Certificate Errors

Missing Intermediate Certificates

The server fails to provide the required intermediate certificate.

This is one of the most common causes of certificate trust failures.

Self-Signed Certificates

A self-signed certificate signs itself.

Website Certificate
      ↓
Website Certificate

There is no trusted authority involved.

Browsers typically reject these certificates unless explicitly configured to trust them.

Expired Certificates

Every certificate has an expiration date.

When that date passes, the certificate becomes invalid.

Certificate Expired

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.

Validation fails.

Revoked Certificates

Certificate authorities can revoke certificates that should no longer be trusted.

Examples include:

• Compromised keys
• Fraudulent issuance
• Security incidents

Browsers may reject revoked certificates.

Why Browsers Trust Some Certificates Automatically

Browsers maintain a list of trusted root certificates.

This list is often called the:

Root Trust Store

Operating systems and browsers periodically update these trusted roots.

Examples include:

• Windows Certificate Store
• macOS Keychain
• Mozilla Root Program
• Android Trust Store

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.

Their chain may look like:

Internal Root CA
        ↓
Internal Intermediate
        ↓
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 why internal development environments often produce certificate errors.

Understanding Cross-Signed Certificates

Certificate chains can become even more complicated.

Sometimes a certificate authority wants compatibility with older devices.

One solution is cross-signing.

A simplified example:

Root A
     ↓
Intermediate

and

Root B
     ↓
Intermediate

The same intermediate may chain back to multiple trusted roots.

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.

In Chrome:

Padlock Icon
     ↓
Connection Secure
     ↓
Certificate Information

You can typically view:

• Website certificate
• Intermediate certificates
• Root certificate
• Expiration dates
• Issuing authority

This information is often the fastest way to diagnose trust problems.

Common Troubleshooting Steps

When a certificate trust error occurs, check:

Is the Certificate Expired?

Verify validity dates.

Is the Hostname Correct?

Ensure the certificate matches the domain being accessed.

Are Intermediate Certificates Installed?

Confirm the server is providing the complete chain.

Is the Root Trusted?

Verify the root exists in the operating system or browser trust store.

Has the Certificate Been Revoked?

Check revocation status if applicable.

These checks resolve the majority of certificate trust issues.

Why HTTPS Alone Doesn’t Guarantee Trust

Many people assume:

HTTPS = Trusted

This is not always true.

A website can:

• Use HTTPS
• Encrypt traffic
• Still fail certificate validation

Encryption and trust are related but separate concepts.

HTTPS provides encryption.

Certificate chains establish trust.

Both are required for a secure browser connection.

Real-World Example

Imagine a website installs a new certificate after renewal.

The administrator uploads:

website.crt

but forgets:

intermediate.crt

The site appears to work on some devices.

Other users receive:

Certificate Not Trusted

The website certificate itself is valid.

The chain is incomplete.

Browsers cannot verify trust back to a trusted root.

The result is an “untrusted” error despite HTTPS being enabled.

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. Website certificates inherit that trust through a chain of intermediate certificates that link them back to a trusted root.

Most certificate trust errors occur 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 yet still appear untrusted to visitors.