When a browser connects to an HTTPS website, it does not just check that the server has a certificate — it validates the entire certificate chain from the server's certificate up to a trusted root certificate authority. When any link in that chain is broken, users see a scary warning and connections are rejected.
Understanding certificate chains is essential for anyone who manages HTTPS endpoints, configures load balancers, or deploys internal services with custom CAs.
How Certificate Chains Work
A certificate chain (also called a chain of trust) links your server's certificate to a root CA that browsers trust.
A typical chain has three levels:
1. Root CA certificate — Self-signed, stored in the OS/browser trust store. Root CAs are extremely secure and offline most of the time. Examples: DigiCert Global Root G2, ISRG Root X1 (Let's Encrypt's root).
2. Intermediate CA certificate — Signed by the root CA. Intermediate CAs do the actual day-to-day signing of server certificates. Using intermediates limits the exposure of the root private key.
3. Server (leaf) certificate — Signed by the intermediate CA. This is the certificate installed on your web server and presented to clients.
For a connection to succeed, the client must be able to build a path from your server certificate to a trusted root certificate it has in its trust store.
Common Certificate Chain Problems
Missing intermediate certificate
The most common certificate chain error. The server presents only its own certificate and not the intermediate CA certificate. Browsers often cache intermediates, so the site works for some users but not others (especially on mobile or fresh OS installs).
Fix: Configure your server to serve the full chain — server cert + all intermediates. Most certificate providers give you a fullchain.pem file for this purpose.
Expired certificate
Certificates have a notAfter date. Once a certificate expires, browsers reject it. Automated renewal with tools like Certbot and Let's Encrypt prevents this, but manual certificates need calendar reminders.
Wrong domain (SAN mismatch)
Certificates are issued for specific domain names listed in the Subject Alternative Name (SAN) extension. If the hostname in the URL does not match any SAN entry, browsers show a certificate mismatch error.
Wildcards (*.example.com) cover one level of subdomain but not deeper levels (a.b.example.com is not covered by *.example.com).
Untrusted root
Internal services often use certificates signed by a private/internal CA. Clients must have that CA's root certificate installed in their trust store, or connections will fail with an untrusted root error.
Reading a Certificate with the DevHexLab Certificate Chain Viewer
Paste a PEM-encoded certificate or certificate chain into the tool. PEM certificates look like:
-----BEGIN CERTIFICATE----- MIIFazCCA1OgAwIBAgIRAIIQz7DSQONZRGPgu2OCiwAwDQYJKoZIhvcNAQELBQAw ... -----END CERTIFICATE-----
The tool parses and displays:
- Subject — the entity the certificate was issued to (Common Name, Organization)
- Issuer — the CA that signed the certificate
- Valid from / Valid to — the validity period
- Subject Alternative Names — all domains this certificate covers
- Serial number — the unique identifier for this certificate
- Signature algorithm — how the certificate was signed (e.g., sha256WithRSAEncryption)
- Public key info — key type and size
- Extensions — Key Usage, Extended Key Usage, CRL distribution points, OCSP URL
For a chain, each certificate in the chain is shown in order from leaf to root.
Extracting Certificates from a Server
To get a server's certificate chain from the command line:
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -text
Or to get the full chain:
openssl s_client -connect example.com:443 -showcerts 2>/dev/null < /dev/null
Copy the PEM blocks from the output into the Certificate Chain Viewer.
Certificate Expiry Monitoring
Certificate expiry is one of the most avoidable causes of outages. Monitor expiry dates for all production certificates and set alerts at 30 days and 7 days before expiry. Let's Encrypt certificates expire every 90 days by design — automate renewal with Certbot or a similar ACME client.
Conclusion
SSL certificate chain issues are one of the most common causes of HTTPS failures. The DevHexLab Certificate Chain Viewer gives you a fast way to inspect certificate details, verify the chain, and diagnose common problems without reaching for OpenSSL command-line tools.