# Let's Encrypt ends certificate expiration reminder emails

> Let's Encrypt ended expiration reminder emails on 2025-06-04, announced on 2025-01-22. It recommends automated renewal plus independent monitoring.

Source: https://ssl.sh/news/lets-encrypt-ends-expiration-emails/
Last updated: 2026-11-10

Let's Encrypt stopped sending expiration reminder emails on 4 June 2025. For years, the address attached to an [ACME](https://ssl.sh/glossary/acme/) account received a warning when a certificate was close to expiry and had not been renewed. The CA announced the change on 22 January 2025 and recommends that subscribers rely on automated renewal and a separate monitoring service instead.

## What happened

Let's Encrypt gave three reasons for ending the reminders: most subscribers now renew automatically, the service cost money to run, and not keeping email addresses is better for subscriber privacy. The emails had been a safety net for failed or forgotten renewals; none were sent after 4 June 2025.

It is one of several changes that push subscribers toward full automation. Let's Encrypt also [shut down OCSP](https://ssl.sh/news/lets-encrypt-ends-ocsp/) in 2025, and certificate lifetimes across the industry are shrinking: the [200-day limit](https://ssl.sh/news/200-day-certificate-limit-in-effect/) is in force and Let's Encrypt is moving to [45-day certificates](https://ssl.sh/news/lets-encrypt-45-day-certificates/). With shorter lifetimes, renewal has to be continuous and automatic, and an email a few weeks before expiry becomes less meaningful.

## Who is affected

Anyone whose renewal depended on a person reading the email now needs another safeguard:

- **People who treated the email as the renewal trigger**, for example anyone who obtained a certificate with `certbot certonly --manual` and added DNS TXT records by hand.
- **Teams whose automation can fail silently**: a broken cron job or systemd timer, an expired DNS API key, a firewall rule that now blocks [HTTP-01](https://ssl.sh/glossary/http-01/), a disk that filled up. Previously the email often caught these failures; now only monitoring will.
- **Setups where renewal succeeds but the web server keeps serving the old certificate** because nobody reloads it. Expiry emails never caught this case, and file-based checks miss it too.

When a certificate does expire, visitors see errors such as [NET::ERR_CERT_DATE_INVALID](https://ssl.sh/errors/net-err-cert-date-invalid/) in Chrome or [SEC_ERROR_EXPIRED_CERTIFICATE](https://ssl.sh/errors/sec-error-expired-certificate/) in Firefox.

## What you should do

Replace the emails with your own expiry check against the live site. First confirm that renewal is scheduled and works:

```bash
systemctl list-timers | grep -i certbot
sudo certbot renew --dry-run
```

Then add an independent check against the live endpoint. A minimal script you can run from cron:

```bash
#!/bin/sh
# Alert if the certificate served by example.com expires within 14 days
if ! echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
    | openssl x509 -noout -checkend 1209600 >/dev/null; then
  echo "Certificate for example.com expires within 14 days" \
    | mail -s "TLS expiry warning" admin@example.com
fi
```

For more than a handful of hosts, use the [bulk SSL checker](https://ssl.sh/tools/bulk-ssl-checker/); for a single site, the [SSL checker](https://ssl.sh/tools/ssl-checker/). Searching [Certificate Transparency logs](https://ssl.sh/tools/ct-search/) also reveals certificates for your domains that nobody remembers issuing. The [renewal automation guide](https://ssl.sh/learn/automate-certificate-renewal/) covers [certificate renewal](https://ssl.sh/glossary/certificate-renewal/) setups for common servers.