Domain Expiry vs SSL Expiry: Two Clocks, Two Very Different Outages

Two things on your website have expiration dates, they sound almost identical, and they are completely unrelated. One is the SSL/TLS certificate — the thing that makes the padlock appear, issued by a CA like Let's Encrypt, typically valid for 90 days. The other is the domain registration — your annual (or multi-year) lease on the name itself from a registrar, governed by ICANN, typically renewed every year. They are billed separately, managed in different dashboards, and enforced by different systems. And people conflate them constantly, usually at the worst possible moment: the site is down, someone says "the SSL expired," and an hour disappears into the wrong dashboard.

Here's the distinction that ends the confusion: an expired certificate still lets the browser reach your server; an expired domain means the browser can't even find it. They are not two severities of the same outage. They are two different outages, and they don't look alike.

What an Expired Certificate Looks Like

When the TLS certificate expires, DNS still resolves, the server still answers on port 443, and the TLS handshake still happens. Everything about the name is fine. What breaks is the last step: the browser validates the certificate, sees the notAfter date is in the past, and refuses to proceed — throwing NET::ERR_CERT_DATE_INVALID behind a full-page "your connection is not private" interstitial. The site is right there; the browser is standing in front of it.

That's why an expired certificate is loud but recoverable. Users see a scary warning, but the moment you renew and deploy the new certificate — often minutes with an automated ACME setup — the warning is gone and nothing was lost. The failure is a validation failure, local to the client's trust check, and it clears the instant the certificate is valid again. (What happens when an SSL certificate expires covers this case in full.)

What an Expired Domain Looks Like

When the domain registration lapses, the failure is earlier and far more total. At or shortly after the expiration date, the registrar stops the domain from working — typically by pulling or parking its authoritative nameservers. Once the authoritative NS stop answering for your zone, every resolver on the internet that looks up your name gets NXDOMAIN — "this name does not exist." The browser can't find an IP to connect to at all, so there's no server to reach, no handshake, no certificate check. You get DNS_PROBE_FINISHED_NXDOMAIN (Chrome) or ERR_NAME_NOT_RESOLVED, not a padlock warning.

And it doesn't stop at the website. The domain is the root of everything attached to the name: email dies too (the MX records vanish with the zone, so inbound mail bounces), any API on a subdomain goes dark, SSO that relies on the domain breaks, and links across the internet rot. An expired certificate is one broken door on a building people can still find. An expired domain removes the building's address from every map at once.

The worst part is the recovery curve, because a domain doesn't just wink back on when you pay. It moves through a lifecycle, and each stage costs more:

• Auto-renew grace period (registrar-dependent, roughly 0–45 days after expiry). Some registrars keep resolving during a short grace window; many park it immediately. You can usually still renew at the normal price — if you notice.
• Redemption period (~30 days). ICANN's recovery window. The domain is gone from DNS and can only be restored by paying a redemption fee that is often $80–$200+ on top of the renewal, through a manual registrar process.
• Pending delete (~5 days). No recovery at any price. You wait for it to drop.
• Dropped. The name returns to the open market — where a drop-catcher or a competitor can register it before you do, and now it's a business problem, not an ops problem.

So the two clocks aren't just different in what they break — they're different in how forgiving they are. Miss the cert by a day and you renew and move on. Miss the domain by a few weeks and you might be paying a redemption fee; miss it by a couple of months and you might not get the name back at all.

Why They Get Confused (and How to Tell Them Apart Instantly)

They get conflated because both are "an HTTPS thing with an expiration date," both are often on autopilot, and both surface as "the site is down." But one look at the error tells you which clock ran out:

The one-command test: dig example.com +short (or nslookup example.com). If it returns an IP address, the domain is fine and you have a certificate (or other server) problem. If it returns nothing / NXDOMAIN, the domain itself is the problem — go to your registrar, not your CA. whois example.com (or an RDAP lookup) shows the registration's expiry date and its status codes directly; a status like redemptionPeriod or pendingDelete in that output is the domain lifecycle telling you exactly where on the curve you are.

How to Watch Both — Before Either Bites

Neither clock should ever surprise you, and the reasons they do are structural:

• Certificate renewal is automated, which is exactly why it fails silently. ACME/Certbot renews in the background, so no human watches it — until the renewal cron breaks (a firewall change blocks the port-80 challenge, a DNS-01 record goes stale, a hook fails) and the first signal anyone gets is the expiry itself. Automation removed the manual step and the manual attention with it. Monitor the certificate's live notAfter from outside, so a stalled renewal is caught with weeks of runway, not at hour zero.

• Domain renewal depends on one email reaching one person. The registrar sends renewal notices to the registrant contact — which is frequently an ex-employee's inbox, a shared alias nobody reads, a role account behind WHOIS privacy, or a card that expired. Auto-renew fails quietly when the card on file declines. The domain is the single most catastrophic thing to lose and the one most likely to be governed by a forgotten email. Monitor the registration expiry date directly instead of trusting that the notice will be seen. Enable auto-renew and verify the payment method, because auto-renew with a dead card is not protection.

• Watch the expiry dates, not just "is the site up right now." A blunt uptime check is green until the exact moment each clock hits zero, at which point it flips to a total outage with no warning. The dates are knowable weeks ahead — for the certificate (notAfter) and for the domain (the registration expiry) — so the useful monitor is the countdown, not the corpse.

An expired certificate and an expired domain are not two flavors of one problem. One is a validation failure at the last step of a connection the client can still make; the other removes the name from the internet and takes the email, the subdomains, and the recoverability with it. Conflating them wastes the scarcest thing you have during an outage — time — sending you to renew a certificate while the actual clock that ran out was the registrar's.

Merlonix watches both clocks from outside your stack: it reads your certificate's live expiry on every check and, separately, tracks the domain's registration expiry and status via RDAP — the registrar-side lifecycle data — so a lapsing registration pages you with weeks of runway instead of dropping your name into a redemption fee. You can check a domain's live certificate, DNS, and registration right now without signing up, watch a certificate's countdown with the free cert watcher, and the free tools hub has the rest. When it is the certificate, the sibling posts cover each way that fails: expiry, name mismatch, incomplete chain, untrusted root, and the handshake failing before any certificate.

Two clocks, two dashboards, two very different worst cases. The certificate gets you a scary warning; the domain gets you a disappearance. Both are knowable weeks ahead of time — which is the whole reason neither one has to be the way you find out.