When you type https://example.com into your browser, invisible magic happens behind the scenes. Your browser doesn't just connect to the server — it validates a chain of trust, confirming that the website's certificate is signed by a trusted Certificate Authority. This chain consists of multiple certificates, each one signing the next. And if there's a break anywhere in this chain, you see a red error screen.
Most engineers understand "SSL is needed for HTTPS." But how exactly does certificate validation work? Why does the browser sometimes say "certificate not trusted" when your certificate is perfectly valid? What's this intermediate certificate you need to add to your server? Let's break it down step by step.
TLS Handshake: The Beginning of Trust
When a browser initiates an HTTPS connection, here's what happens:
1. Browser sends ClientHello with supported TLS versions and ciphers. Server responds with ServerHello, selecting version and cipher.
2. The server sends its certificate (usually along with a chain of intermediate certificates). This is the critical moment: the server must send not just the leaf certificate, but the entire path up to a trusted root.
3. The browser validates the chain: starting with the leaf certificate, it goes up to the root certificate that exists in its trust store. Each certificate is signed by the previous one, creating an unbreakable chain of cryptographic verification.
4. If the chain is valid and the root certificate is present in the browser — the connection is established. If the chain is broken or the root is unknown — you see "SEC_ERROR_UNKNOWN_ISSUER" or similar error.
Trust Chain: Root CA, Intermediate, Leaf
SSL/TLS uses a hierarchical trust model:
Root CA (Root Certificate Authority) — this is the top of the pyramid. GlobalSign, DigiCert, Let's Encrypt Trusted Root — these are root authorities whose certificates are built into every browser, operating system, and mobile phone. The Root CA signs itself (self-signed certificate). Its private key is stored in a secure vault and almost never used to directly sign end-entity certificates.
Intermediate CA (Intermediate Certificate Authority) — this is a certificate signed by root. An intermediate can sign other certificates. This allows the root CA to stay offline, reducing the risk of compromise. Intermediate certificates must be sent with your server certificate.
Leaf certificate (End-entity certificate) — this is your certificate, bound to a domain. It's signed by an intermediate and contains your public keys for encryption. Browsers check this certificate first.
Example certificate chain for example.com:
example.com (Leaf Certificate)
↓ Signed by
Intermediate CA Certificate
↓ Signed by
Root CA Certificate (built into browser)The browser superficially looks at the leaf — but the real validation is deeper: is the leaf's signature valid? Was the signature created with the intermediate's private key? Is the intermediate valid? Was it signed by root? Is root in the browser's trust store? Only if all answers are "yes," is the connection secure.
Why the Intermediate Certificate is Stored Offline
You could imagine a model where the root CA directly signs all end-entity certificates. But that would be a nightmare:
1. The Root CA would need to be online 24/7, ready to sign new certificates. The more online operations — the higher the risk of compromise.
2. If the root key is compromised — the entire trust infrastructure collapses. All browsers will trust fake certificates until they update with a new root.
3. Scaling becomes difficult. The Root CA would need to perform millions of signing operations daily.
That's why intermediate certificates exist. The Root CA stays in cold storage (air-gapped vault), signing intermediates once every few years. The intermediate is online and signs millions of end-entity certificates. If an intermediate is compromised, it can be revoked and a new one issued without touching the root.
Certificate Types: DV, OV, EV
There are three main types of SSL certificates. They differ in the level of verification before issuance:
DV (Domain Validation) — the certificate authority only verifies that you own the domain. Usually through a DNS TXT record or file on the web server. Issued within minutes. Cheap or free (Let's Encrypt, Certbot). From an HTTPS encryption perspective, DV is fully functional — data is encrypted identically. The difference is in trust signaling: the browser doesn't guarantee that a specific company is behind the domain, only that someone owns the domain.
OV (Organization Validation) — the CA verifies the organization's legal existence: company registration, address, contacts. Takes 1-7 days. In older browsers, displayed blue text with the organization name. More expensive than DV ($15-100/year). Often used on corporate sites where it's important to show "this is a real company."
EV (Extended Validation) — the strictest verification. Includes financial audits, registration verification, and legal confirmation. In old browsers, EV certificates showed a green bar in the address bar. Takes 10-30 days. Most expensive ($100-200+/year). Downside: in modern browsers (Chrome 77+), the EV indicator disappeared because users can't visually distinguish DV from EV. Upside: still used for high-tech phishing protection and internal systems.
Important note: DV, OV, and EV all use the same cryptography. The difference is only in the issuance process and trust in the organization. For 99% of websites, DV is sufficient.
How Browsers Validate the Chain
The certificate validation process is classic graph parsing:
1. Chain Retrieval. The browser receives a certificate from the server. If intermediate certificates aren't sent explicitly, the browser tries to find them through Authority Info Access (AIA) requests to an OCSP responder or fetch by URL in the certificate. Mobile clients often can't do this, so an incomplete chain = error.
2. Leaf Certificate Validation. Browser checks: is the certificate not expired? Does the domain in CN or Subject Alternative Names match the requested URL? Is the signature computed correctly using the public key from the issuer certificate (intermediate)?
3. Building the Chain to Root. Then the browser validates the intermediate: is its signature valid? Is it signed by root? Has the intermediate certificate not expired? Are there no revocation status indicators in CRL or OCSP?
4. Root Verification. The browser looks for the root certificate in its trust store. If found — the chain is valid. If not — error "unknown issuer" or "self-signed certificate."
5. Additional Checks. The browser checks Certificate Transparency (CT) logs — every public certificate should be logged in multiple CT logs for auditability. Older browsers skip this, newer ones require it.
Common SSL Errors and What Causes Them
ERR_SSL_PROTOCOL_ERROR — server is not sending valid TLS data. Often: incorrect nginx/Apache configuration, SSL disabled on port 443, or the port is listening to a non-SSL application.
SEC_ERROR_UNKNOWN_ISSUER or CERTIFICATE_VERIFY_FAILED — incomplete chain. Server sent only the leaf certificate without the intermediate. Browser can't find the intermediate and declares "issuer unknown." Solution: add the intermediate certificate to the web server configuration.
NET::ERR_CERT_AUTHORITY_INVALID — root certificate is not in the browser's trust store. Happens with self-signed certificates or homemade CAs. Browsers don't trust them without explicit exception.
SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED — certificate signed with an obsolete algorithm (SHA-1, MD5). Modern browsers reject such certificates. Need to reissue with SHA-256.
NET::ERR_CERT_COMMON_NAME_INVALID — domain doesn't match CN or SAN in the certificate. For example, certificate for api.example.com, but you're connecting to www.example.com. Solution: use a wildcard certificate (*.example.com) or multi-domain certificate (SAN).
NET::ERR_CERT_VALIDITY_TOO_LONG — browsers reject certificates with validity periods longer than 13 months (introduced in 2020). Let's Encrypt issues for 90 days, commercial CAs often for 12 months. If you see this error — reissue.
How to Check Your SSL Chain
The openssl command shows the exact composition of your chain:
openssl s_client -connect example.com:443 -showcertsIn the output you'll see multiple certificates, separated by "-----BEGIN CERTIFICATE-----". Each is part of the chain. Count them:
- 2 certificates (leaf + intermediate) = minimally acceptable
- 3 certificates (leaf + 2 intermediates) = normal for commercial CAs
- 4+ certificates = rare, usually means old intermediate chains
But there's a more convenient way. Open /tools/ssl-checker — enter your domain and you'll see:
- Full certificate chain in the browser
- Details for each: issued to, issued by, issue and expiry dates
- Problem indicators: incomplete chain, expired certificate, wrong domain
Let's Encrypt and Automatic Certificate Management
Let's Encrypt revolutionized SSL by making certificates free and automated. Instead of manually ordering certificates every year, you run Certbot:
Initial Issuance. Certbot proves to Let's Encrypt that you own the domain (through DNS TXT record or HTTP file placement). Let's Encrypt issues a certificate for 90 days along with intermediate certificate chain.
Automatic Renewal. 30 days before expiry, Certbot attempts to renew the certificate. If successful — new certificate is ready, web server reloads with new files, and you notice nothing.
What Can Break. DNS calls don't go through due to firewall rules. ACME client can't connect to Let's Encrypt API. Cron job for renewal is disabled. Web server doesn't restart after renewal. In these cases, the certificate silently expires until you notice the error in the browser.
SSL Monitoring: Why It's Critical
Certificates expire silently. This isn't a database error that triggers an immediate alarm. It's an expected event that you can forget about. And here's what happens:
Day 1 (Expiry). Certificate expires exactly at midnight. Your web server keeps running, the browser keeps connecting (sometimes with hidden warning). You notice nothing.
Day 3. Mobile apps start rejecting the connection. Clients complain the app "crashed." Slack explodes. You grab your laptop and open the browser — it works! This is schizophrenic.
Day 5. Curl won't connect. API clients fail. You finally notice the certificate expired. Now you need to urgently renew or regenerate it.
Day 7. 40% of corporate firewalls don't trust the expired certificate. You have 3 hours of downtime for some regions while you update the certificate and browsers cache the new one.
SSL monitoring is simple: check certificate expiry date daily. If less than 30 days until expiry — send an alert. Notification goes to email, Slack, Telegram — a month before the problem you know to take action.
SSL expiry alerts in AtomPing are configured per-target. For example, for critical APIs — alert 45 days out. For staging — 7 days. And the system checks all your certificates in parallel, so you never miss expiry even if you have 300 domains.
CAA Records and Certificate Pinning
CAA (Certification Authority Authorization) is a DNS record that says: "you're only allowed to issue certificates for this domain to this CA." This is an additional layer of security against compromise.
Example CAA record:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"This says: "Let's Encrypt, only you can issue certificates for example.com." If any other CA tries to issue a certificate for your domain, Let's Encrypt checks the CAA record, sees "not you," and refuses.
CAA is especially important for commercial CAs that use weaker domain validation. With CAA, you guarantee that a certificate can only be issued by an authorized CA, even if an attacker compromises your domain's DNS.
Learn more about DNS and CAA in our article on DNS records.
How to Fix an Incomplete Chain
If you have an "unknown issuer" error:
1. Obtain the intermediate certificate. Your CA (DigiCert, Sectigo, Let's Encrypt) usually provides it on their website in "downloads" or "intermediate certificate" section. Let's Encrypt certificates often come with embedded intermediate when issued.
2. Combine certificates in one file. Order is critical: your leaf first (domain.crt), then intermediate(s), then (optional) root. File is usually called chain.pem or fullchain.pem.
3. Update web server configuration. For nginx: ssl_certificate points to fullchain.pem (contains leaf + intermediates), ssl_certificate_key points to private key. For Apache: SSLCertificateFile = leaf, SSLCertificateChainFile = intermediates.
4. Reload server. New certificates won't take effect without reload.
5. Verify chain. Use openssl s_client or SSL Checker to confirm the chain is now complete and browser sees no errors.
Certificate Type Comparison
| Type | Validation Level | Issuance Time | Cost | Use Case |
|---|---|---|---|---|
| DV | Domain | Minutes | Free - $10 | Most websites |
| OV | Organization | 1-7 days | $20-100 | Corporate sites |
| EV | Extended | 10-30 days | $100-200+ | Finance, high trust |
SSL Chain and Monitoring: Practical Checklist
1. Verify your server sends the complete chain. Use openssl s_client -showcerts or SSL Checker. You should see at least 2 certificates (leaf + intermediate).
2. Make sure the intermediate certificate is added to your web server configuration. For nginx this is usually ssl_certificate file (fullchain.pem), for Apache it's SSLCertificateChainFile.
3. Enable SSL monitoring for all critical domains. Check certificate expiry daily, get alerts 30 days before expiry. SSL expiry alerts are built into all AtomPing plans.
4. Set up automatic renewal. For Let's Encrypt use Certbot with a cron job for monthly renewal attempts. For commercial CAs — set a calendar reminder 45 days out.
5. Add CAA records for your domain. Specify which CA can issue certificates. This protects against unauthorized certificate issuance.
6. Use modern algorithms. SHA-256 or higher. Avoid SHA-1, MD5, which browsers reject.
7. Test on mobile devices. Old iOS and Android versions sometimes can't load intermediate certificates through AIA. Incomplete chains might pass on desktop but fail on mobile.
Conclusion: Trust Is Built on the Chain
The SSL certificate chain is the foundation of the internet. Every time you type https://example.com, your browser performs cryptographic validation of the chain, ensuring the server is who it claims to be. If there's a break in this chain (incomplete chain, expired certificate, wrong domain), the connection is rejected.
As an engineer, you need to know:
1. The chain consists of leaf (your certificate) → intermediates → root (in browser). Server must send the entire chain, not relying on browser fetching intermediates.
2. Three types: DV (fast, free), OV (slower, validates organization), EV (strictest). For most sites DV is enough.
3. Let's Encrypt simplified SSL, but automatic renewal can break. Monitoring 30 days before expiry is minimum insurance.
4. Common errors: incomplete chain (unknown issuer), expired certificate, wrong domain. All fixed in minutes if you know what to look for.
Check your SSL certificate right now on /tools/ssl-checker — enter your domain and see the entire chain, dates, and potential issues. And enable SSL monitoring for your domains so you never miss an expiry.
Related Resources
SSL Checker — check your SSL certificate and chain online. See the complete chain, issue/expiry dates, and common issues.
DNS Record Types Explained — learn about CAA records that bind certificates to domains.
SSL Expiry Alerts — set up automatic notifications 30 days before certificate expiry. Never miss a certificate renewal again.
FAQ
What is an SSL certificate chain?
An SSL certificate chain is a sequence of certificates that establish trust from your website's certificate to a Certificate Authority that browsers recognize. The chain typically includes: a leaf certificate (your website), one or more intermediate certificates, and a root certificate. Browsers validate the entire chain to confirm your certificate is legitimate.
Why do intermediate certificates exist?
Root CA private keys are kept offline in secure vaults for security reasons. Intermediate certificates act as signing authorities, allowing CAs to issue end-entity certificates without exposing the root key. If an intermediate certificate is compromised, the CA can revoke it without affecting the root — but if the root key is compromised, the entire trust system is broken.
What does 'incomplete chain' mean?
An incomplete chain occurs when your server sends only the leaf certificate without the intermediate certificate(s). Browsers usually can fetch the missing intermediate, but some mobile clients and older devices cannot. This causes SSL errors even though your certificate is valid. Always configure your server to send the complete chain.
How can I check if my SSL chain is complete?
Use 'openssl s_client -connect example.com:443' from the command line. Count the number of certificates in the output — you should see at least 2 (leaf + intermediate). Or use an online tool like AtomPing's SSL Checker at /tools/ssl-checker to instantly view your complete chain and identify any issues.
What's the difference between DV, OV, and EV certificates?
DV (Domain Validated) certificates only verify you own the domain — cheapest and fastest. OV (Organization Validated) certificates verify your organization's legal existence — shown in certificate details. EV (Extended Validation) certificates perform the strictest validation and trigger a green bar in old browsers (deprecated in modern browsers). For HTTPS security, all three provide identical encryption — the difference is trust signaling.
Why did my SSL certificate expire if I set up auto-renewal?
Let's Encrypt certificates are valid for 90 days and require renewal before expiry. If auto-renewal failed (due to DNS issues, firewall blocking ACME requests, or cron misconfiguration), your certificate expires without replacement. This is why SSL expiry monitoring is critical — AtomPing monitors certificates and alerts 30 days before expiry, giving you time to fix renewal issues.