> Providing expiration notifications costs Let’s Encrypt tens of thousands of dollars per year, money that we believe can be better spent on other aspects of our infrastructure.
Appreciate the honesty (they had other reasons, too! but emails are a pain and expensive at their scale)
Anyone who can write them a cheque can also set up such a service themselves. All of the certificates are freely available in the CT logs, and every domain must have a reachable email address (or they risk their domain being taken from them). You can probably save a lot of money (and be less liable for violating spam laws) by making the free service opt-in, of course.
LE just isn't interested in maintaining such a service. Sending them money won't make them interested all of the sudden; that money can be spent better on setting up an independent free alternative.
"Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us."
A check to cover the cost of the system would not solve this part of the problem.
Sending single custom emails is much more effort than bulk-mailing a huge list operationally. Sending bulk can be accomplished by uploading a csv of emails to some enail bulk sender versus code to run at the correct time for the correct user... way easier in bulk and way cheaper
This pushed me to automate certificate renewal for all my domains. This is much better than waiting for any kind of notifications, and it was very easy. I think this is a very good decision on their part.
Certificates are still a pain in the butt. One of the most cumbersome aspects of the web.
Especially domain wide certs which need DNS auth.
DNS auth would be okish if it was simply tied to a txt entry in the DNS and valid as long as the txt entry is there. Why does LetsEncrypt expire the cert while the acme DNS entry is still there? Which attack vector does this prevent?
Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?
This makes sense to me. You should never rely on your CA to let you know that a certificate is due to expire soon, you should have your own monitoring in place that actively checks this for you.
I was using this with Certbot for 17 different domains it's a bit sad to see it go. I’m not even sure if I ever relied on the notifications, but just knowing it existed gave some peace of mind.
It's unfortunate to see this go away, but understandable given the costs involved. Another option is to run Caddy as a web server, which provides automatic cert renewal (https://caddyserver.com/docs/automatic-https). If notifications are still important, they also provide an event subscription system (https://github.com/caddyserver/certmagic#events) so you can subscribe to cert-related events, run custom code, trigger event handlers, etc.
This is a smart move. The amount of infrastructure complexity for what's essentially a band-aid for poor automation practices wasn't worth it.
We migrated ~800 domains to LE back in 2019 and initially relied heavily on those expiration emails as a safety net. But honestly, they became more of a crutch than a help. Once we implemented proper monitoring with Prometheus + cert-manager, we haven't had a single cert expire unexpectedly.
The privacy angle is interesting too. I hadn't considered how much PII they were sitting on just for this feature. With GDPR and similar regulations, that's a significant liability for what amounts to "your cron job didn't run" notifications.
For anyone panicking about this: if you're still depending on email notifications for cert renewal in 2025, this is your wake-up call to implement actual monitoring. Even a simple bash script that checks cert expiry dates and posts to a Slack webhook would be more reliable than email notifications.
Curious what their infrastructure costs actually were for this. "Tens of thousands per year" seems low for managing millions of emails, but I guess if it's just queuing jobs to an email service provider, that tracks.
29 comments
[ 2.4 ms ] story [ 53.5 ms ] thread> Providing expiration notifications costs Let’s Encrypt tens of thousands of dollars per year, money that we believe can be better spent on other aspects of our infrastructure.
Appreciate the honesty (they had other reasons, too! but emails are a pain and expensive at their scale)
Pushover is $5 once for personal use, ntfy.sh can be completely self-hostable if you prefer.
I have written a small tool which utilizes pushover for these reasons.
You can receive the notifications on your browser/mobile for free afterwards.
LE just isn't interested in maintaining such a service. Sending them money won't make them interested all of the sudden; that money can be spent better on setting up an independent free alternative.
Its not only the service cost, but as they say, it costs engineering hours, which could be spent elsewhere.
Moreover, SSL cert age check should be something you're looking out for, or letting certbot restart your service for you.
"Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us."
A check to cover the cost of the system would not solve this part of the problem.
Especially domain wide certs which need DNS auth.
DNS auth would be okish if it was simply tied to a txt entry in the DNS and valid as long as the txt entry is there. Why does LetsEncrypt expire the cert while the acme DNS entry is still there? Which attack vector does this prevent?
Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?
https://github.com/jgaa/openvalify
It's a valuable service for the average person to get these emails without having to set up separate monitoring