LetsEncrypt – Expiration Notification Service Has Ended

Rationale for Ending Emails

• Commenters highlight the official reasons: cost (“tens of thousands” per year plus engineering time), infrastructure complexity, and the desire to focus on core CA functions.
• The privacy angle is seen as important: sending reminders required retaining millions of email addresses tied to issuance records, which some view as a liability and contrary to LE’s stated values.

Cost, Funding, and Corporate Support

• Some are surprised the service was dropped over what seems like a relatively small amount; others stress that engineering time and privacy, not just dollars, are the real constraints.
• Discussion about donations: large users often don’t contribute, and corporate accounting treats “donations” differently from “fees for service,” making small recurring support harder.
• LE’s nonprofit status may complicate offering paid “services” like notifications, though this remains unclear in the thread.

Alternatives for Renewal Monitoring

• Strong consensus: certificate owners should not rely on their CA for reminders but should implement their own monitoring.
• Suggested options:
  • Cron jobs / scripts checking expiry with OpenSSL or curl and sending email, Slack, or push notifications (Pushover, ntfy.sh, Gotify).
  • Use certbot/acme.sh timers, Nagios-style checkers, or Prometheus + cert-manager.
  • Third-party services like Red Sift Certificates Lite and generic uptime/HTTPS monitors.
  • Caddy with automatic HTTPS and cert events; Cloudflare (including long-lived origin certs).

How Valuable Were the Emails?

• Some say most users already have automatic renewal, so the emails were redundant.
• Others report the emails saved them when automation silently broke or was never set up (e.g., hand-managed certs by a departed developer). They viewed them as a useful last-resort safety net and will miss the extra assurance.

Debate Over Certificate Expiration

• A side thread questions the need for expiration vs. pure revocation.
• Arguments for expiration:
  • Limits lifespan of unknown compromises and leaked keys.
  • Lets revocation lists be pruned.
  • Acts as “garbage collection” for abandoned certs and for ownership changes of domains.
  • Improves ecosystem agility for crypto and policy changes; shorter lifetimes are trending (eventually ~47 days for TLS server certs).
• Skeptics argue the model is conceptually clumsy and, if shorter equals safer, the logic would push toward very short lifetimes.

DNS Validation and Wildcards Frustrations

• Several users find certificates—especially DNS-01 and wildcards—still “a pain.”
• Requests for one-time DNS TXT auth that remains valid as long as the record exists.
• Others counter that one-time DNS or web-server compromise should not grant persistent wildcard issuance, and explain why HTTP vs DNS challenges are scoped differently.
• Some propose DANE or better DNS APIs; others describe workarounds like CNAME-based validation and using providers with ACME plugins.

Overall Sentiment

• Many see the move as sensible, nudging users toward proper automation and reducing privacy/operational burden.
• A smaller but vocal group is disappointed to lose a simple, centralized safety net, especially for small or hobby setups.