What Does the Certificate Chain Show?

Understanding Certificate Chains and Trust

A certificate chain (or certification path) is a sequence of certificates that establishes trust from your server's certificate back to a trusted root certificate authority. The chain proves that a trusted authority has verified that the certificate belongs to the domain and that the private key holder is legitimate. Understanding certificate chains is essential for diagnosing SSL/TLS issues and ensuring your site's certificates are properly configured.

The Three-Level Certificate Chain

A typical certificate chain consists of three levels:

Level 1: End-Entity Certificate (Leaf Certificate) This is your domain's certificate:

• Issued to: yourdomain.com
• Contains: Your domain name, public key, validity dates
• Issued by: Intermediate CA
• Used for: Encrypting traffic to your website

Level 2: Intermediate Certificate This is the bridge between your certificate and the root:

• Issued to: Intermediate Certificate Authority (e.g., "Sectigo RSA Organization Validation Secure Server CA")
• Contains: The intermediate CA's public key
• Issued by: Root CA
• Used for: Validating your certificate
• Typically provided by: Your certificate authority

Level 3: Root Certificate This is the trust anchor:

• Issued to: Root Certificate Authority (e.g., "AddTrust External CA Root")
• Contains: The root CA's public key
• Issued by: Itself (self-signed)
• Used for: Establishing trust
• Pre-installed in: Every operating system and browser

How Certificate Chain Validation Works

When a browser connects to your HTTPS site:

1. Server sends certificate chain - The server sends three certificates in order
2. Browser verifies leaf certificate - Checks that the domain matches and the certificate isn't expired
3. Browser verifies leaf signature - Uses the intermediate's public key to verify that the intermediate signed the leaf certificate
4. Browser verifies intermediate - Checks that the intermediate's signature is valid
5. Browser finds root in trust store - Looks up the root certificate in its pre-installed trust store
6. Trust established - If the root is found and all signatures are valid, the chain is trusted

If any link in this chain breaks, the connection fails or shows warnings.

Real-World Example Chain

Leaf Certificate (your domain)
├─ Signed by: Intermediate CA
│  └─ Contains issuer: "Intermediate CA Name"
│
Intermediate Certificate
├─ Signed by: Root CA
│  └─ Contains issuer: "Root CA Name"
│
Root Certificate
├─ Self-signed
│  └─ Contains issuer: "Root CA Name"
└─ Pre-installed in browsers/OS

A real example from a major website might look like:

Certificate for: example.com
├─ Common Name: example.com
├─ Issued by: DigiCert SHA2 Secure Server CA
├─ Valid: 2024-01-01 to 2025-01-01

Intermediate: DigiCert SHA2 Secure Server CA
├─ Issued by: DigiCert Global Root CA
├─ Valid: 2013-03-05 to 2028-03-04

Root: DigiCert Global Root CA
├─ Self-signed
├─ Valid: 2006-11-28 to 2031-11-28
└─ Pre-installed in all browsers

What Each Certificate in the Chain Contains

Your Certificate (Leaf)

• Subject: Your domain name
• Subject Alternative Names: example.com, www.example.com, etc.
• Public Key: Used to verify signatures from you
• Validity Period: When the certificate is valid
• Issuer: Which CA signed it
• Certificate Serial Number: Unique identifier
• Signature: The intermediate CA's signature proving they issued it

Intermediate Certificate

• Subject: Intermediate CA name
• Public Key: Used to verify signatures from the intermediate
• Issuer: The root CA
• Extensions: Key usage, constraints, etc.
• Signature: Root CA's signature

Root Certificate

• Subject: Root CA name (same as issuer, because it's self-signed)
• Public Key: Used to verify intermediate's signature
• Issuer: Itself
• Validity: Usually 20-30 year validity
• Signature: Self-signed

Why Intermediate Certificates Exist

You might wonder why there's an intermediate level. Why not just have every certificate signed directly by the root?

Root Key Security - Root keys must be kept in secure, offline storage. If a root key is compromised, the entire system collapses. By using intermediates, the root stays offline.

Risk Isolation - If an intermediate CA is compromised, you can revoke it without affecting the root's other intermediates.

Scalability - One root can support many intermediates, allowing CAs to issue millions of certificates.

Key Rollover - CAs can retire old roots and introduce new ones by having intermediates signed by new roots.

Certificate Chain Issues

Common certificate chain problems include:

Missing Intermediate Certificate

If you don't configure your server to send the intermediate certificate, browsers must fetch it themselves. This causes:

• Slower connections (extra HTTP requests)
• Connections may fail on some networks
• SSL checker will report "incomplete chain"

Solution: Configure your server to send the complete chain:

For Nginx:

ssl_certificate /path/to/certificate.pem;  # Should contain: leaf + intermediate

For Apache:

SSLCertificateFile /path/to/certificate.pem
SSLCertificateChainFile /path/to/intermediate.pem

Expired Certificate

Any certificate in the chain (leaf, intermediate, or root) can expire:

• If the leaf expires: New certificate needed
• If the intermediate expires: CA must issue new certificate, but usually automatic
• If the root expires: This is rare and browsers usually don't fail immediately

Self-Signed Certificates

A certificate signed by itself (not by a CA):

• Not in trust stores
• Browsers show warnings
• Used for internal testing only, not production

Wrong Issuer

If a certificate's issuer doesn't match the signer, the chain is broken.

Checking Your Certificate Chain

SSL Checker displays your certificate chain:

1. Look at "Certificate Chain" section
2. Identify all three levels
3. Check validity dates (ensure none are expired)
4. Verify issuer names match expected CAs
5. Note any warnings (incomplete chain, weak algorithms, etc.)

A healthy certificate chain shows:

• Three certificates (leaf, intermediate, root)
• All within validity periods
• Proper issuer-subject relationships
• Recognized root CA

Advanced Chain Topics

Chain of Trust The chain of trust is verified cryptographically:

• Root's public key signs intermediate's certificate
• Intermediate's public key signs your certificate
• Breaking any signature breaks the chain

Multiple Intermediates Some CAs use multiple levels:

Leaf ← Intermediate 1 ← Intermediate 2 ← Root

This is valid and works the same way, just with more levels.

Cross-Signed Certificates A certificate can be signed by multiple authorities:

Leaf signed by:
├─ Old Root (deprecated)
└─ New Root (current)

Browsers can follow either path, providing compatibility during root transitions.

Online Certificate Status Protocol (OCSP) Some browsers verify certificate revocation by asking the CA if a certificate has been revoked. The chain confirms you're talking to a legitimate CA.

Certificate Chain Security Implications

Chain Compromise - If any certificate in the chain (except the root) is compromised, all certificates below it are suspect. The intermediate is particularly critical because it signs your certificate.

Root Compromise - If a root is compromised, every certificate it's issued (directly or indirectly) is suspect. This is catastrophic and has happened historically (Comodo, DigiCert, VeriSign breaches).

Chain Revocation - A compromised intermediate or leaf certificate can be revoked through the chain. Browsers check revocation status before trusting certificates.

Best Practices for Certificate Chains

1. Always include the complete chain - Configure your server to send leaf + intermediate
2. Monitor expiration dates - All certificates, especially intermediates
3. Use reputable CAs - Established authorities with good security practices
4. Verify chain with SSL Checker - Regularly check your configuration
5. Update root certificates - Keep your OS/browser's root store current
6. Plan for key rotation - Have a process for transitioning to new intermediates/roots
7. Test thoroughly - Before deploying new certificates, test the complete chain

Conclusion: Certificate Chains Establish Digital Trust

Certificate chains are the foundation of HTTPS security. They create an unbroken cryptographic chain of trust from your server's certificate back to authorities pre-installed in every browser. Understanding what each certificate in the chain does, why intermediates exist, and how to troubleshoot chain issues is essential for maintaining secure HTTPS. The certificate chain is not just a technical detail—it's the mechanism that proves your website is who it claims to be.