--- title: "Certificate Chain vs Leaf Expiry: What Actually Expires | FourSight" description: "Your leaf certificate isn't the only thing with a notAfter date. How intermediate and root expiries break clients that look nothing like a normal cert expiry." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "Certificate Chain vs Leaf Expiry: What Actually Expires", "description": "Your leaf certificate isn't the only thing with a notAfter date. How intermediate and root expiries break clients that look nothing like a normal cert expiry.", "author": { "@type": "Organization", "name": "FourSight" }, "publisher": { "@type": "Organization", "name": "FourSight" }, "url": "https://foursight.cloud/guides/certificate-chain-vs-leaf-expiry", "mainEntityOfPage": "https://foursight.cloud/guides/certificate-chain-vs-leaf-expiry", "datePublished": "2026-07-14", "dateModified": "2026-07-14", "wordCount": 1600 }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://foursight.cloud/guides" }, { "@type": "ListItem", "position": 3, "name": "Certificate Chain vs Leaf Expiry: What Actually Expires", "item": "https://foursight.cloud/guides/certificate-chain-vs-leaf-expiry" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What's the difference between a leaf certificate and the certificate chain?", "acceptedAnswer": { "@type": "Answer", "text": "The leaf (end-entity) certificate is the one issued for your hostname. The chain is the full sequence your server presents during a TLS handshake: leaf, then one or more CA intermediates linking it to a root certificate in the client's trust store. Every link has its own expiry date, and a broken or expired link fails validation even when your leaf is perfectly valid." } }, { "@type": "Question", "name": "Why does my site work in Chrome but fail in curl or on mobile?", "acceptedAnswer": { "@type": "Answer", "text": "That signature almost always means an incomplete or invalid chain. Desktop browsers cache intermediates and can fetch missing ones (AIA fetching); stricter clients — mobile platforms, HTTP libraries, webhook senders — validate exactly what your server sends. Check that your server is configured with the full-chain file, not the leaf alone." } }, { "@type": "Question", "name": "Can an intermediate certificate expire before my leaf certificate?", "acceptedAnswer": { "@type": "Answer", "text": "It shouldn't when chains are issued correctly — CAs sign leaves with comfortable margin inside the intermediate's validity. But stale intermediate files deployed alongside renewed leaves, pinned intermediates, and CA rotations (like Let's Encrypt's periodic intermediate changes) all create real-world cases where the served chain contains a link that expires first. Chain validation on every check is what catches this." } }, { "@type": "Question", "name": "What happened with DST Root CA X3 in 2021?", "acceptedAnswer": { "@type": "Answer", "text": "The root certificate anchoring Let's Encrypt's original cross-signed trust path expired on September 30, 2021. Modern platforms had long trusted Let's Encrypt's own ISRG root, but old Android versions, outdated OSes, and OpenSSL 1.0.2 clients lost validation — a textbook demonstration that certificates you don't own and can't renew still have expiry dates that affect you." } }, { "@type": "Question", "name": "Should I serve cert.pem or fullchain.pem?", "acceptedAnswer": { "@type": "Answer", "text": "Fullchain, essentially always. Certbot's cert.pem contains only the leaf; fullchain.pem includes the intermediates clients need to build a trust path. Configuring nginx's ssl_certificate (or the equivalent elsewhere) with anything but the full chain is the single most common cause of works-in-some-clients chain failures." } } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) [All Guides](/guides) Reliability & Infrastructure # Certificate Chain vs Leaf Expiry: What Actually Expires Your leaf certificate isn't the only thing with a notAfter date. How intermediate and root expiries break clients that look nothing like a normal cert expiry. 8 min read Guide Published Jul 14, 2026 ## Leaf, Chain, Root: Three Different Expiry Clocks Your leaf certificate — the one issued for your hostname — is not the only certificate in the connection with an expiry date. Every [TLS](/glossary/ssl-tls "Glossary: TLS") handshake presents a chain: the leaf, one or more intermediate certificates that link it to a certificate authority, and ultimately a root certificate that lives in the client's trust store. Each link has its own notAfter timestamp, its own renewal owner, and its own failure mode when it lapses. Leaf expiry is the failure everyone knows: your site breaks for everyone at a precise second. Chain and root expiries are stranger beasts — they break some clients and not others, they're caused by certificates you don't control, and they masquerade as bugs in your customers' code. Understanding which clock ran out is the difference between a five-minute fix and a very confusing day. Related Reading - [→ Feature: SSL certificate monitoring](/features/ssl-monitoring) - [→ Glossary: certificate chain](/glossary/certificate-chain) ## Anatomy of the Chain The three tiers exist so that root certificate private keys — the crown jewels of internet trust — can stay offline in hardware security modules while day-to-day issuance happens with intermediate keys that can be rotated or revoked without replacing what's baked into billions of devices. ### The Leaf (End-Entity) Certificate Issued for your specific hostnames, valid for at most about 200 days for certificates issued since March 2026 (and shrinking — the CA/Browser Forum schedule takes public certificates to roughly 47-day maximums by 2029). This is the certificate your renewal automation manages, the one with your domain in its subject alternative names, and the one whose expiry takes your site down for every client simultaneously. ### Intermediate Certificates Issued by the CA to sign leaf certificates, typically valid for several years. Your server is responsible for sending intermediates during the handshake — clients are not guaranteed to have them. When a CA retires or rotates an intermediate, servers still serving the old one, or clients with odd caching behavior, produce validation failures that look nothing like a normal expiry. [Let's Encrypt](/glossary/lets-encrypt "Glossary: Let's Encrypt")'s periodic intermediate rotations are a recurring source of 'nothing changed on our side' incidents for teams that pinned or hard-coded an intermediate somewhere. ### Root Certificates Self-signed anchors shipped inside operating systems and browsers, valid for decades — which means when one finally expires, the clients affected are precisely the old devices and unpatched systems that never received a trust-store update. You cannot renew a root; you can only ensure your chain builds a path to a root each client actually trusts. ## Case Studies: When the Chain Expired, Not the Leaf Two real incidents show why chain expiry deserves its own monitoring category — in both, millions of perfectly valid leaf certificates became unusable for specific client populations overnight. ### AddTrust External CA Root — May 30, 2020 A widely used Sectigo cross-signing root expired. Modern browsers didn't blink — they trusted the newer root and built an alternate path. But huge numbers of non-browser clients (older OpenSSL 1.0.x and GnuTLS versions, embedded devices, payment terminals, API integrations) validated the expired path and hard-failed. Sites were 'up' in every browser their operators checked while their partners' API calls failed — a support nightmare where every party's dashboard was green. ### DST Root CA X3 — September 30, 2021 The root that gave Let's Encrypt its original cross-signed trust expired, by design and with years of warning. Android devices older than 7.1.1, old iOS/macOS versions, and clients on OpenSSL 1.0.2 lost the trust path. Let's Encrypt engineered a clever long-tail workaround for old Android, but plenty of B2B integrations and legacy fleets still broke that morning. Teams that had inventoried which chains their clients relied on had a quiet day; teams that hadn't spent it re-learning X.509 path building under pressure. ### Monitoring a Commercial SaaS? FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card. [Start Monitoring Free](/auth?signup=true) ## Why Chain Failures Look So Weird Chain problems produce the diagnostic signature that most confuses teams: 'works in Chrome, fails in curl' — or the reverse. The reason is that clients build trust paths differently. Desktop browsers cache intermediates from previous connections and can fetch missing ones on the fly (a mechanism called AIA fetching in Chrome and desktop Safari), so they often paper over a server that forgets to send its intermediate. Stricter clients — most mobile platforms, headless HTTP libraries, older TLS stacks, webhook senders — validate exactly the chain your server presents, and fail if it's incomplete or contains an expired link. So a misconfigured chain doesn't break 'the site'; it breaks a demographic: Android users but not desktop, your Stripe webhooks but not your QA browser, one partner's integration but not another's. If an outage report only affects some client types, suspect the chain before the leaf. ``` # See the FULL chain your server actually sends echo | openssl s_client -servername yourdomain.com \ -connect yourdomain.com:443 -showcerts 2>/dev/null \ | grep -E "s:|i:" # Verify the chain validates against a standard trust store echo | openssl s_client -servername yourdomain.com \ -connect yourdomain.com:443 -verify_return_error 2>&1 \ | grep -E "Verify return code|verify error" # Check EVERY certificate's expiry in the served chain, not just the leaf echo | openssl s_client -servername yourdomain.com \ -connect yourdomain.com:443 -showcerts 2>/dev/null \ | awk '/BEGIN CERT/,/END CERT/' \ | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \ | openssl pkcs7 -print_certs -noout -text | grep "Not After" ``` ## The Configuration Mistake Behind Most Chain Incidents The most common self-inflicted chain failure is embarrassingly simple: configuring the web server with the leaf certificate file instead of the full-chain file. Certbot writes both — cert.pem (leaf only) and fullchain.pem (leaf plus intermediates) — and nginx or HAProxy pointed at the wrong one will pass every desktop-browser test the team runs while failing mobile users and API clients. Close cousins: concatenating certificates in the wrong order for HAProxy's combined PEM format, updating the leaf during a renewal but leaving a stale intermediate file in place, and load balancers that manage chains separately from certificates so the two drift. The rule that prevents all of them: always deploy the full chain as one artifact from one source, and verify from outside — what matters is the chain the internet receives, not the files on disk. ## Monitoring the Chain, Not Just the Countdown A monitoring strategy built only on leaf-expiry countdown misses everything this guide describes. Complete coverage needs three assertions on every check: the leaf's days-to-expiry (the countdown), the completeness and validity of the served chain (would a strict client accept this exact sequence?), and hostname coverage (do the SANs actually cover this domain?). FourSight's SSL monitor performs all three on every check cycle from four regions — chain validation catches the missing-intermediate and expired-intermediate cases within one check of the misconfiguration going live, rather than when the first Android user complains. For belt-and-suspenders on high-stakes estates, add a periodic testssl.sh run in CI for deep configuration analysis; the external monitor covers continuous detection, the scanner covers depth. [See what FourSight's SSL checks validate →](/features/ssl-monitoring) Related Reading - [→ How SSL certificates expire silently: the failure modes](/guides/how-ssl-certificates-expire-silently) - [→ How to audit SSL certificates across your fleet](/guides/auditing-ssl-certificates-across-fleet) ## Frequently Asked Questions ### What's the difference between a leaf certificate and the certificate chain? ### Why does my site work in Chrome but fail in curl or on mobile? ### Can an intermediate certificate expire before my leaf certificate? ### What happened with DST Root CA X3 in 2021? ### Should I serve cert.pem or fullchain.pem? #### Related Guides [What Is Uptime Monitoring? The Complete Guide 12 min ](/guides/what-is-uptime-monitoring)[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[How SSL Certificates Expire Silently: The Failure Modes 8 min ](/guides/how-ssl-certificates-expire-silently) #### Compare FourSight [vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative) 10 free commercial-safe monitors [View Pricing](/pricing) ## Protect Your SaaS Revenue Start monitoring in under 60 seconds. [Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)