SSL Certificate Chain Explained: Intermediate Certificates and How to Fix a Broken Chain

What is the SSL certificate chain?

The SSL certificate chain (also called the chain of trust) is an ordered list of certificates that links your server's identity back to a root certificate authority (CA) that browsers and operating systems already trust. Browsers don't trust your certificate by itself — they trust it because it was signed by an entity they do trust, which was in turn signed by another trusted entity, and so on up the chain.

When a browser opens an HTTPS connection, the server sends its certificate (and should send the intermediate certificates too). The browser then builds a path from the received certificates up to a root CA in its trust store. If the path is complete and every signature validates, the connection proceeds. If a certificate is missing anywhere in the chain, the browser cannot complete the path and displays a security warning.

The three layers of the chain

Why CAs use intermediate certificates

The intermediate CA layer exists primarily for security and operational flexibility. Without it, the root CA key would need to be online to sign every certificate request — a significant risk given the value of a root key. The intermediate layer solves several problems simultaneously:

How browsers validate the chain (RFC 5280 path building)

Certificate path validation is specified in RFC 5280. When a browser receives a TLS certificate, it performs the following check for each certificate in the chain:

1. 1The certificate's digital signature is verified using the public key of its issuer certificate.
2. 2The current date is within the certificate's validity window (Not Before ≤ now ≤ Not After).
3. 3The certificate has not been revoked (checked via CRL, OCSP, or CRLSet depending on the browser).
4. 4The certificate is appropriate for its role: intermediate certificates must have Basic Constraints: CA:TRUE and a matching Key Usage extension.
5. 5The chain terminates at a root CA certificate that is present in the browser's or operating system's built-in trust store.

Every step must pass for every certificate in the chain. A single failure at any level — an expired intermediate, a revoked leaf, a missing intermediate that breaks the path — terminates the validation and produces a browser security warning.

AIA chasing: why Chrome works but mobile clients fail

Each X.509 certificate contains an Authority Information Access (AIA) extension that includes two key URLs:

• CA Issuers: A URL where clients can download the issuer's certificate — i.e., the intermediate CA that signed this certificate.
• OCSP: A URL for checking real-time revocation status (see our OCSP stapling guide for details).

Desktop Chrome and desktop Edge perform AIA chasing: if the server doesn't send an intermediate certificate, these browsers read the AIA extension in your leaf certificate, fetch the missing intermediate from the CA Issuers URL, and complete the chain automatically. This is why a misconfigured server may appear to work perfectly in Chrome while failing for every other client.

What chain errors look like

The error message varies by client, but all of the following indicate a certificate chain problem. (For expiry, name-mismatch, and the other non-chain failures, see our guide to SSL certificate errors.)

How to diagnose a broken chain

The fastest way to check your certificate chain is with OpenSSL'ss_clientcommand. Run this from a machine where Chrome's AIA caching won't confuse the results:

# Connect and show all certificates in the chain
openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null \
  | grep -E "^(subject|issuer)"

A complete chain shows at least two subject/issuer pairs — one for your leaf certificate and one for the intermediate CA:

subject=CN = yourdomain.com
issuer=CN = Sectigo RSA Domain Validation Secure Server CA, ...

subject=CN = Sectigo RSA Domain Validation Secure Server CA, ...
issuer=CN = USERTrust RSA Certification Authority, ...

An incomplete chain shows only one pair — just your leaf certificate:

subject=CN = yourdomain.com
issuer=CN = Sectigo RSA Domain Validation Secure Server CA, ...
# ← intermediate certificate missing — the chain is broken

You can also count certificates directly:

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"
# 1 = incomplete, 2 or 3 = typically complete

Fix the chain on Nginx

Nginx requires the certificate chain to be bundled into a single file that thessl_certificatedirective points to. The file must contain the leaf certificate first, followed by the intermediate certificate(s). Never include the root.

Step 1: Create the fullchain file

# Leaf cert first, then the intermediate(s)
cat yourdomain.crt intermediate.crt > fullchain.pem

# If your CA provided a bundle with multiple intermediates:
cat yourdomain.crt ca-bundle.crt > fullchain.pem

Step 2: Reference fullchain.pem in your server block

server {
    listen 443 ssl http2;
    server_name yourdomain.com;

    # Use the full chain file — NOT just yourdomain.crt
    ssl_certificate     /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/private.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
    ssl_prefer_server_ciphers off;
    ...
}

Step 3: Test and reload

nginx -t              # Validate config — fix any errors before reloading
nginx -s reload       # Reload without dropping connections

Fix the chain on Apache

Apache 2.4.8 and later supports a bundled certificate file via SSLCertificateFile. Older Apache versions required a separate SSLCertificateChainFile directive (which was deprecated in 2.4.8 but still works).

Apache 2.4.8+ (preferred — single bundled file)

# Create fullchain.pem
cat yourdomain.crt intermediate.crt > fullchain.pem

# In your VirtualHost block:
<VirtualHost *:443>
    ServerName yourdomain.com
    SSLEngine on

    # Point to the bundled file — leaf cert + intermediate(s)
    SSLCertificateFile    /etc/apache2/ssl/fullchain.pem
    SSLCertificateKeyFile /etc/apache2/ssl/private.key

    # Optional — improves forward secrecy and TLS 1.3 compatibility
    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    ...
</VirtualHost>

Apache 2.4.7 and earlier (separate chain file)

<VirtualHost *:443>
    SSLCertificateFile      /etc/apache2/ssl/yourdomain.crt
    SSLCertificateKeyFile   /etc/apache2/ssl/private.key
    SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt
    # SSLCertificateChainFile is deprecated in 2.4.8+ but still works
</VirtualHost>

Test and restart

apache2ctl configtest    # or: httpd -t
systemctl reload apache2  # or: systemctl reload httpd

Fix the chain on IIS

IIS on Windows doesn't use a bundled certificate file. Instead, intermediate certificates are stored in the Windows Certificate Store, and IIS automatically includes them during the TLS handshake when they are present in the right store.

Install the intermediate via MMC

1. 1Press Win+R, type mmc, press Enter to open the Microsoft Management Console.
2. 2Go to File → Add/Remove Snap-in → select Certificates → Add → choose Computer account → Local computer → OK.
3. 3In the left pane, expand Certificates (Local Computer) → Intermediate Certification Authorities → Certificates.
4. 4Right-click the Certificates folder → All Tasks → Import.
5. 5Browse to your intermediate certificate file (intermediate.crt or ca-bundle.crt). Complete the wizard.
6. 6Restart IIS: run iisreset in an elevated Command Prompt.

Install via PowerShell

# Import intermediate into the correct store
Import-Certificate -FilePath "C:\ssl\intermediate.crt" `
    -CertStoreLocation Cert:\LocalMachine\CA

# Restart IIS
iisreset

Where to get the intermediate certificate

Your CA should provide the intermediate certificate in your certificate download package. Look for a file named ca-bundle.crt, intermediate.crt, or chain.pem. My-SSL download packages include your leaf certificate, the intermediate bundle, and a pre-built fullchain.pem ready to use directly in Nginx or Apache.

If you don't have the intermediate file, you can retrieve it from the AIA extension embedded in your own certificate:

# Find the CA Issuers URL in your certificate
openssl x509 -in yourdomain.crt -noout -text \
  | grep -A 2 "CA Issuers"
# Example output:
# CA Issuers - URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt

# Download the intermediate from that URL
curl -o intermediate.crt "http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt"

# If the downloaded file is in DER format (binary), convert to PEM:
openssl x509 -inform DER -in intermediate.crt -out intermediate.pem
mv intermediate.pem intermediate.crt

Verify the fix

After restarting your server, run the following checks to confirm the chain is complete:

1. OpenSSL — count certificates

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null \
  | grep -c "BEGIN CERTIFICATE"
# Expected: 2 (leaf + one intermediate) or 3 (leaf + two intermediates)

2. OpenSSL — verify return code

openssl s_client -connect yourdomain.com:443 2>/dev/null \
  | grep "Verify return code"
# Expected: Verify return code: 0 (ok)

3. curl — full chain verification

curl -vI https://yourdomain.com 2>&1 | grep -E "(issuer|subject|SSL)"
# Look for multiple issuer lines — one per certificate in the chain

Frequently asked questions