Blog
Let's Encrypt Stopped Expiry Email Reminders: SSL Certificate Expiration Email Isn't Enough
August 16, 2026
For more than a decade, operators who got their certificates from Let's Encrypt could relax a little: if a certificate was about to expire, the certificate authority would send an email reminder, and you had a window to renew before the site went dark. In June 2025, that changed. Let's Encrypt stopped sending expiration notification emails, and thousands of deployments quietly lost the one automated safety net they relied on. If you still depend on an ssl certificate expiration email to remind you to renew, this article explains what happened, how to check your own certificates, and why a reactive expiry reminder was never a substitute for continuous monitoring.
What Actually Changed in June 2025
In January 2025 the CA announced that it would stop sending expiration notification emails, and the change took effect on June 4, 2025. The reasoning was straightforward — the CA issues hundreds of millions of certificates, and reminder emails only reach a fraction of subscribers. For a program that size, email is neither a reliable nor a scalable operational channel. The decision moved the responsibility for catching expiring certificates back onto the operator.
The practical consequence is easy to underestimate: there are a lot of long-running Let's Encrypt integrations that were configured once and never touched again. A cron job that ran certbot renew nightly and fired an email on failure was, for years, the entire monitoring strategy for many small sites. Those sites are now flying without a net, because the expiration email is no longer coming.
How to Check Your Certificates Yourself
If you manage certificates with certbot or another ACME client, the renewal process itself is unchanged — renewals are still automated, and the ACME protocol still works exactly as before. What changed is the warning system around it. You can and should verify your certificate expiry yourself:
- Inspect the live certificate:
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -datesshows exactly when the served certificate expires. - Check renewal logs:
certbot renew --dry-runexercises the full renewal path and reports whether it would succeed. - Watch for silent failures: a renewal can fail for reasons that don't touch your server at all — a DNS record that stopped resolving, an HTTP-01 challenge blocked by a firewall, or an outbound port 80 rule that changed during a routine firewall update.
- Never trust memory: expiry dates drift. A 90-day certificate issued on a Monday expires on a Monday — and the day your calendar lookup fails is usually the day it lapses.
Why a Pure Expiry Reminder Was Never Enough
Even when expiration emails were still being sent, they answered exactly one question: is this certificate about to expire? That is the narrowest possible view of certificate health, and it misses most of the events that actually hurt production systems:
- Renewal failures: the certificate expired because the automatic renewal silently failed. An expiry reminder tells you the certificate is about to lapse; it does not tell you that the renewal pipeline broke and will fail again next cycle.
- Unauthorized issuance: if an attacker compromises your hosting account or your domain verification path, they can mint a certificate for your domain before you do anything wrong. This is exactly how phishing infrastructure is built — certificates issued by an unrecognized CA for your domain are a strong signal of compromise, and no expiry reminder will ever fire for them.
- Unexpected replacement: a certificate that changed issuer or SANs without a deployment on your side usually means someone else controls your configuration.
- TLS health beyond expiry: chain validation failures, hostname mismatches, or a certificate that expired and was replaced by an invalid one leave the site broken even though the expiry event itself was handled.
Expiry is just one state in a lifecycle full of failure modes. An ssl certificate expiration emailtells you about a single point in time; monitoring tells you about the entire lifecycle — including the renewal that is supposed to happen before that point is reached.
Monitoring Certificate Transparency Logs
Certificate Transparency (CT) is a public, append-only ledger of every certificate issued by publicly trusted certificate authorities. Because every CA must submit every certificate it issues, CT logs are the only independent, third-party record of what certificates exist for your domain — the one signal that doesn't depend on your own infrastructure being honest or healthy. Watching CT logs catches:
- New certificates issued for your domain by an unrecognized CA — a leading indicator of phishing or account compromise, often days before the phishing site goes live.
- Certificates issued outside your expected renewal schedule, which indicates a broken or hijacked renewal flow.
- Missing renewals — when your own certificate is about to expire and no replacement appears in the logs, you know the automated pipeline failed before browsers start warning your users.
Combined with direct TLS checks, CT monitoring turns certificate management from a calendar problem into an early-warning system: you are alerted the moment a certificate is issued, not only when the current one lapses.
What to Set Up Instead
The replacement for the discontinued expiry email is not a better email — it is continuous monitoring that covers the certificate lifecycle end to end:
- Expiry monitoring: daily checks of the served certificate's expiry date, issuer, SANs, and chain, with alerts at configurable lead times (60, 30, 14, 7, 1 days before expiry).
- Certificate change monitoring: an alert whenever the certificate for your domain is issued, replaced, or renewed — so a silent renewal failure or an unauthorized issuance surfaces immediately instead of at expiry.
- CT log monitoring: watching public transparency logs for new certificates on your domain, catching unauthorized issuance and phishing certs.
- Alerts where you already work: email, Slack, Discord, Microsoft Teams, Telegram, DingTalk, Feishu, PagerDuty, or a generic webhook, so the notification lands in the tool your team actually watches.
Checking Any Certificate Right Now
You don't need an account to check a certificate. Certack's public API lets you inspect the live TLS state of any domain in a single request:
Check SSL/TLS status with the Certack API
bashcurl https://app.certack.com/api/public/check-ssl?domain=example.com
{
"valid": true,
"issuer": "Let's Encrypt",
"expires_at": "2026-11-15T00:00:00.000Z",
"days_remaining": 91,
"protocol_version": "TLSv1.3",
"cipher_name": "TLS_AES_256_GCM_SHA384",
"hsts": {
"enabled": true,
"max_age": 31536000,
"include_sub_domains": true,
"preload": true
}
}The Free Tier Is Enough to Start
With the safety net of CA emails gone, the minimum viable setup is expiry plus change detection on every certificate you run. Certack's free plan monitors two sites and includes SSL/TLS, DNS, domain, and CT log checks with dashboard alerts — no credit card required. That covers a personal blog, a side project, and a staging environment today, and it scales to paid plans with five or twenty sites when your fleet grows.
Conclusion
Let's Encrypt's decision to stop sending expiration notification emails closed a chapter in which certificate authorities doubled as your monitoring team. That model was never reliable at CA scale, and now it is gone entirely. The replacement is not another email — it is continuous monitoring of expiry dates, certificate changes, and CT logs, with alerts routed to the channels your team actually reads. The free tier is the fastest way to verify: add your domain, and you'll know about every certificate issued for it — and every expiry — before your users do. Start monitoring for free.