Certificate Chains — Understanding the Path to Trust

Learn how certificate chains are structured, validated, configured, and diagnosed.

CertOneDec 7, 20195 min read

How do browsers validate HTTPS certificates, and why do some sites appear untrusted? A certificate chain establishes a path from the server certificate to a trusted root. This guide explains its structure, validation, and common problems.

1. What is a certificate chain?

A certificate chain, or certification path, is a sequence linking an end-entity certificate to a root CA. Each issuer's signature connects one certificate to the next, ending at a trusted anchor.

1. Core concepts

Trust in public key infrastructure is hierarchical:

Root CA: the top-level authority, typically represented by a self-signed root in a client trust store.

Intermediate CA: an authority certified by a root or another intermediate, used to issue other certificates.

End-entity certificate: the server certificate issued by an intermediate or root CA and installed on the web server.

2. Why use a chain?

Security separation: root private keys are highly sensitive. Issuing through intermediates limits routine exposure of the root key and reduces the consequences of an issuing-key compromise.

Flexible administration: separate intermediates can serve different purposes or regions and be managed or revoked independently.

Established practice: most public CAs issue through intermediates.

2. Chain structure

1. Components

A typical chain contains:

Server certificate:

Issued by an intermediate CA
Contains the server public key and domain names
Installed on the web server

Intermediate CA certificates:

Certified by a root or another intermediate
Used to issue server certificates
A chain may include one or more intermediates

Root CA certificate:

Typically self-signed
Distributed through operating-system and browser trust stores
They anchor the trust chain

2. Chain examples

Root CA certificate
    ↓
Intermediate CA certificate
    ↓
Server certificate

Historical Let's Encrypt example (not a current deployment chain):

DST Root CA X3 (root CA)
    ↓
Let's Encrypt Authority X3 (intermediate CA)
    ↓
example.com (server certificate)

Multiple intermediates:

Root CA certificate
    ↓
Intermediate CA 1
    ↓
Intermediate CA 2
    ↓
Server certificate

3. Chain validation

1. Browser validation process

When a browser connects over HTTPS, it performs checks such as:

Step 1: Receive the server certificate

The server sends its certificate during the TLS handshake
It should also send the necessary intermediate certificates

Step 2: Build a chain

Identify the server certificate's issuer
Locate available intermediate certificates in local stores or caches
Use intermediates supplied by the server
Continue building toward a trusted root

Step 3: Validate the chain

Verify certificate signatures
Check validity periods
Check Key Usage and Extended Key Usage restrictions
Apply revocation checks according to client policy

Step 4: Confirm root trust

Verify that the path anchors in the client's trust store
Validation fails if no trusted anchor can be found

Step 5: Check the hostname

Confirm that the certificate covers the requested hostname
Apply SAN and wildcard matching rules

2. Key checks

Signature validation:

Each certificate is signed by its issuer's private key
The issuer's public key verifies the signature
An invalid signature prevents path validation

Validity periods:

Certificates in the validated path must meet validity requirements
An expired certificate can invalidate the path

Permitted uses:

Inspect Key Usage and Extended Key Usage
Confirm suitability for TLS server authentication

Revocation:

Check available CRL or OCSP status according to client policy
A revoked certificate causes validation to fail when detected and enforced

4. Common chain problems

1. Incomplete certificate chain

Symptoms:

The browser reports an untrusted certificate or NET::ERR_CERT_AUTHORITY_INVALID
The server sends only the leaf certificate

Causes:

Intermediate certificates are missing from the server configuration
The browser cannot build a path to a trusted root

Resolution:

Configure the server to send the complete intermediate chain
In NGINX, point ssl_certificate to a full-chain file
In Apache, configure the chain using the directives supported by your version

2. Missing intermediate certificates

Symptoms:

Some browsers connect successfully while others fail
Mobile devices may report certificate errors

Causes:

Clients may have different trust stores and caches
A client may not already have the required intermediate

Resolution:

Send the leaf certificate and every required intermediate
Use an online tool to check chain completeness

3. Untrusted root

Symptoms:

Browsers report that the certificate is untrusted
Validation fails at the root trust check

Causes:

The root is absent from the client's trust store
The certificate is self-signed or issued by an untrusted CA

Resolution:

Use a certificate from a trusted CA for public websites
For a private PKI, distribute the intended trust anchor securely to managed clients

4. Incorrect chain order

Symptoms:

Chain validation fails
Certificates appear in the wrong order in the file

Causes:

Order the chain from the server certificate through its intermediates toward the root
Incorrect order can cause validation or server-loading failures

Resolution:

Verify the certificate order in the file
Normally omit the root; the client must already trust it

5. Configure the chain

1. NGINX configuration

Full-chain file:

server {
    listen 443 ssl;
    server_name example.com;
    
    # Include the server certificate followed by intermediate certificates.
    ssl_certificate /path/to/fullchain.pem;
    ssl_certificate_key /path/to/privkey.pem;
    
    # Add the remaining TLS settings here.
}

File format:

-----BEGIN CERTIFICATE-----
[Server certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Intermediate certificate contents]
-----END CERTIFICATE-----

2. Apache configuration

Using SSLCertificateChainFile on versions that require it:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    
    # Server certificate
    SSLCertificateFile /path/to/cert.pem
    # Private key
    SSLCertificateKeyFile /path/to/privkey.pem
    # Intermediate chain
    SSLCertificateChainFile /path/to/chain.pem
</VirtualHost>

Or use a full-chain file on supported versions:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    
    # Full-chain certificate file
    SSLCertificateFile /path/to/fullchain.pem
    SSLCertificateKeyFile /path/to/privkey.pem
</VirtualHost>

3. Other servers

IIS：

Import the complete required chain into the certificate manager
Include the server certificate and all intermediates

Tomcat：

Import the server certificate and intermediates into the keystore
Serve the complete certificate chain

6. Inspect the chain

1. Online tools

SSL Labs SSL Test：

Visit https://www.ssllabs.com/ssltest/
Enter the domain and inspect chain details
Check for missing intermediates

Certificate Chain Checker：

Use a certificate-chain inspection tool
Verify chain completeness

2. Command-line checks

OpenSSL:

# View certificate details.
openssl x509 -in cert.pem -text -noout

# Verify the certificate chain.
openssl verify -CAfile chain.pem cert.pem

# Display the server-supplied chain.
openssl s_client -connect example.com:443 -showcerts

curl:

# Display the server-supplied chain.
curl -vI https://example.com 2>&1 | grep -i "certificate chain"

3. Browser inspection

Chrome/Edge：

Open the connection security information in the address bar
Open the certificate viewer
Open the certification path tab
Inspect the chain

Firefox：

Open the connection security information in the address bar
Open Connection secure → More information
Click View certificate
Inspect the certificate hierarchy

7. Chain management practices

1. Server configuration

✅ Serve the complete required chain
✅ Use a file containing the leaf and intermediate certificates
✅ Check chain completeness regularly
✅ Test across browsers and devices

2. Certificate management

✅ Retain the full-chain file
✅ Verify certificate order
✅ Update the chain when replacing the certificate
✅ Back up the chain file

3. Monitoring and testing

✅ Inspect the chain regularly with TLS tools
✅ Monitor certificate expiration
✅ Test validation in different client environments
✅ Set certificate expiration reminders

Conclusion

Certificate chains connect server identities to trusted roots. Understanding their structure and validation is essential to reliable TLS deployment.

Missing intermediates are a common cause of trust errors. Serve the complete required chain and verify it regularly with independent TLS testing tools.

Whatever web server you use, configure the chain correctly so clients can build a valid path to a trusted root.

1. What is a certificate chain?​

1. Core concepts​

2. Why use a chain?​

2. Chain structure​

1. Components​

2. Chain examples​

3. Chain validation​

1. Browser validation process​

2. Key checks​

4. Common chain problems​

1. Incomplete certificate chain​

2. Missing intermediate certificates​

3. Untrusted root​

4. Incorrect chain order​

5. Configure the chain​

1. NGINX configuration​

2. Apache configuration​

3. Other servers​

6. Inspect the chain​

1. Online tools​

2. Command-line checks​

3. Browser inspection​

7. Chain management practices​

1. Server configuration​

2. Certificate management​

3. Monitoring and testing​

Conclusion​

1. What is a certificate chain?

1. Core concepts

2. Why use a chain?

2. Chain structure

1. Components

2. Chain examples

3. Chain validation

1. Browser validation process

2. Key checks

4. Common chain problems

1. Incomplete certificate chain

2. Missing intermediate certificates

3. Untrusted root

4. Incorrect chain order

5. Configure the chain

1. NGINX configuration

2. Apache configuration

3. Other servers

6. Inspect the chain

1. Online tools

2. Command-line checks

3. Browser inspection

7. Chain management practices

1. Server configuration

2. Certificate management

3. Monitoring and testing

Conclusion