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 same interface boundary shows up in contract testing versus integration testing, and RFC 5280 gives that boundary a public reference point.

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:

• DigiCert
• GlobalSign
• Internet Security Research Group (ISRG), the organisation behind Let’s Encrypt

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.

That encryption happens alongside the certificate checks; for more context on the cryptography side, see AES-128 vs AES-256.

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. That is the gap dependency-aware SLAs is concerned with: the code can look correct while CA/Browser Forum Baseline Requirements still defines the contract that matters at runtime.

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

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. This is where timeouts that do not cancel work becomes useful, because Mozilla Root Store Policy makes the expected behavior explicit enough to test.

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. A similar dependency appears in distributed tracing; OpenSSL verify documentation only helps if the system preserves the contract through the full request path.

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.

Why Missing Intermediate Certificates Cause Browser Errors

Many people assume that if a website has a valid SSL certificate installed, browsers can automatically obtain any missing certificates needed to complete the chain.

In practice, this is no longer a safe assumption.

The server is expected to provide both its own certificate and any required intermediate certificates during the TLS handshake.

If the server sends only the website certificate, many modern browsers and operating systems will fail to build a trusted chain, even if the intermediate certificate is publicly available.

This is why incomplete certificate chains often produce trust errors immediately after certificate renewals or server migrations.

---

How Certificate Chains Are Configured on Web Servers

Most web servers require the complete certificate chain to be installed, not just the website certificate.

For Apache and Nginx, this is commonly provided as a combined certificate bundle such as:

fullchain.pem

This file typically contains:

Website Certificate
Intermediate Certificate(s)

The trusted root certificate is not included because browsers and operating systems already maintain their own trusted root stores.

Installing only the website certificate without the intermediate certificates is one of the most common causes of “Certificate Not Trusted” errors.

Because certificate bundles are usually PEM text files, certificate handling also overlaps with encoding basics covered in Base64 vs Hex Encoding.

---

Beyond the Certificate Chain: What Browsers Also Verify

Successfully building a certificate chain is only one part of certificate validation.

Browsers also verify several other security properties before trusting a connection, including:

• Certificate validity dates
• Hostname matching
• Digital signatures
• Key Usage and Extended Key Usage (EKU)
• Revocation status (where supported)
• Acceptable cryptographic algorithms and key sizes

A certificate may have a complete chain yet still fail validation if any of these checks fail.

---

Authority Information Access (AIA)

Certificates often include an extension called Authority Information Access (AIA). Seen from production, mock servers belongs in the same conversation as MDN Transport Layer Security, because both describe promises other systems rely on.

This can provide a URL where the issuing intermediate certificate can be downloaded if it is missing.

Although some operating systems and browsers may use AIA to retrieve missing intermediates, behaviour varies between platforms and network environments.

Because AIA fetching is not guaranteed, web servers should always provide the complete certificate chain during the TLS handshake rather than relying on clients to download missing certificates.

---

Useful Tools for Troubleshooting Certificate Chains

Several tools make it easy to diagnose certificate trust problems.

OpenSSL

The OpenSSL command-line tools can display the complete certificate chain presented by a server.

For example:

openssl s_client -connect example.com:443 -showcerts

This allows you to verify whether intermediate certificates are being sent correctly.

SSL Labs Server Test

Qualys SSL Labs provides a free online service that analyses a server’s TLS configuration, certificate chain, supported protocols, and common security issues.

It is one of the most widely used tools for validating public-facing HTTPS deployments.

Browser Developer Tools

Most modern browsers allow you to inspect the certificate presented by a website.

The certificate viewer can reveal:

• The full certificate chain
• Certificate issuer
• Validity dates
• Subject Alternative Names (SANs)
• Signature algorithm

This information is often enough to identify missing intermediates or hostname mismatches.

---

Learn More

If you want to explore certificate validation in greater depth, these official resources provide detailed guidance:

• Mozilla Root Store Policy
• Let’s Encrypt Chains of Trust
• OpenSSL certificate verification options
• Microsoft Root Certificate Program

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.