> 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.
A thousand helpful new fremium startups nominating themselves to send email to the overall domain admin email of record when CT indicates an upcoming expiration is hardly the same thing as the ACME server sending an email to the actual email sent at the time of registration.
"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.
Because companies are for profit usually and any donation they make reduces that profit. That's why open source projects that can offer service contracts, have a easier time getting money from the buisness world, because this is something bookkeeping people understand in the corporate language.
Do you have some links to their financial reports for last years? I'd love to see that.
> Why not?
Because I believe it is "sickening" expressing how "sickening (...) it is that large companies don't support open source/free initiative" when discussing one of the projects that do global-scale operations purely on corporate and personal donations. Somehow Let's Encrypt themself don't express that sickening in their blogs and websites. They do thank their sponsors, though.
Hey, I was actually in this position at work a few years ago, when I set up a couple of internal (monitoring stuff) servers for my own use. I used Let's Encrypt, because I use them (for free) at home (media server), and know how it works.
I wanted to throw them some (of work's) cash, and... the only two options were "Sponsor", and "Donate". Sponsorship was, uh, wrong for my use-case: it starts at some multiple-thousands of dollars. Donating would be the obviously correct choice, but putting something marked "donation" onto a corporate card would occasion a... Weird conversation, in which "you could have got this for free, but you're choosing to send them money?" would likely have been raised. I went with free, and was sad about it.
Yes, corporate expectations and affordances around FOSS should change - and, I probably could have persuaded my employer that a few dollars a month for Let's Encrypt was the Right Thing To Do, so I'm a little bit of a coward - but LE would make it so much easier if there was a Send Us Money option that looks like a fee for service, rather than a donation. (Maybe being a 501c(3) precludes that? I don't know.)
There's the "Corporate doesn't understand FOSS" problem, but there's also a "FOSS doesn't speak Corporatese" obstacle there, too.
In the end I sent LE $20, or something, of my own money (I've had years of trouble-free use on my media server, and should have before), but they'd have had $5 / month of work's cash for years if they'd made that easier to do.
They are (Internet Security Research Group) a non-profit, so maybe it would be hard to provide official services like you describe?
I still can't find proper data on their financials, but at least below report (page 42) says only 10% of their revenue is donations. And 48% out of total spending is LE.
I'm really not sure if that kind of organization can simply sell services like that. I'm guessing IRS doesn't care of that CC statement was official or not :)
Exactly this. Don't look at the renewal proces, look at its output. It'll work for all certificate sources and catch other potential errors too (eg the webserver reporting success but not presenting the new certificate)
That'll work too. The idea was to put your own infra in place if you really need that, and it's not very hard to do it, even with completely self-hosted stack.
I imagine this is best left to third parties like the recommended service linked in the post. I assume that there's also a whole deluge of other services that have similar offerings.
at least for iOS there are no costs associated with using Apple Push Notification Service (APNS) but depending on the way you use it you either need to pay for the infrastructure that sends your notifications to Apple or for a service like OneSignal which does that for you. Not sure what the volume of LE is but I am pretty sure it's a smart move to focus on their core "business" (providing certificates) and let other handle expiration notifications.
A free account for sending emails would not have changed the decision because it doesn't solve this:
"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."
Now there is no contact information associated with issuance records.
That’s how CT works. They can’t not publish end-entity certificates to CT logs.
(But also, even if they could avoid this somehow: the entire point of a public CA is to publish end entity certificates. The “I want a public certificate while keeping a subdomain secret” model was never particularly coherent.)
The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well.
I dont need cert transparency either. I just needed encryption... Which a self-signed would be fine. But the internet powers that be deem self-signed as 'evil'. And more webtech requires SSL (like you, websockets). Can't even use it locally without SSL.
Paying $x00 for a SSL from some commercial vendor is laughable these days, unless you need a code cert or a onioncert.
> The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well.
Not really: we learned a hard lesson decades ago that encryption isn’t especially meaningful unless you know who you’re encrypting to. Self-signed certificates are the classic “your communications are secure, but you’re talking with satan” example.
As others have said: if you want to keep a specific subdomain label out of CT, you can issue a wildcard certificate instead. But the Web PKI as a whole is correct in not letting you do encrypted communication with a service without having some established notion of that service’s identity.
Get a wildcard for the apex domain/higher-level subdomain, the "secret" subdomain will be covered implicitly.
If you don't want the certificate to be in the CT logs, your only options are a private CA or things like CF Origin certificate, depending on how the domain is intended to be accessed.
It's not the end user that "needs" CT, it is a mechanism to ensure no shady CA can misissue a certificate without being caught. Requirements like that are written in blood (see Symantec).
> For those who would like to continue receiving expiration notifications, we recommend using a third party service such as Red Sift Certificates Lite (formerly Hardenize). Red Sift’s monitoring service providing expiration emails is free of charge for up to 250 certificates. More monitoring options can be found here.
I don't think this is nearly as effective of a solution. It stops working if the script is crashing before hitting the notification, it doesn't work if you break your email setup (which for an email that almost never sends is likely to go unnoticed forever) it also fails if you accidentally stop running a script or remove the certificate from your config entirely.
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 do agree with you, and setting up your own monitoring is key. I have that.
Yet it was still valuable to find those that fell through the cracks. At work, the emails prevented a couple of outages by expired cert, because a dev that left was renewing them by hand and we only found out when they left and the catch-all started to bubble them up to support.
Things fall through the cracks, or people are in a pinch and just forget to add the cert to the in-house monitoring system. The emails were a wonderful failsafe.
I wish I could just query LE to tell me all existing certain where the account is under my domain name. Extremely helpful to assemble a SBOM.
As a hobbyist without a lot of time for sysadmin, it would be nice if basic email monitoring was a standard package (apt install letsencrypt-monitors or something).
Just use certbot. It automatically sets up a scheduled task to renew your SSL/TLS certificates in the background, typically using a systemd timer that runs twice a day. I do not know why people using LetsEncrypt would not set up certbot along with it, that is how I do it. Some nginx config + certbot.
Maybe the situation's improved, but I found certbot from system package managers would diverge from latest version, sometimes significantly, like support for DNS challenge APIs breaking. I switched to ‘acme.sh’ for most machines and haven't looked back. It no longer has Let's Encrypt as its default issuer, but you can set it back to LE with one config command.
You can get pretty close to this by (1) setting up certbot and (2) configuring your system to actually send emails if cron jobs fail.
I can see the use in a tool that will scan all certificates configured in local web servers and monitors for close expiration dates, though. Not just Let's Encrypt, but also any other ACME accounts and certificate directories you may need. The biggest challenge would probably be dealing with encrypted certificate files, and after that getting email set up correctly. Nobody seems to have made it because it's so easy to script or add to a pre-existing monitoring system, so this could be a fun open source project. You probably can't use the letsencrypt brand name, though.
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.
I've missed expired certificates because of a configuration issue that broke the certbot automation. Granted, I could've read the certbot journalctl output, but 99.9% of the time that's a waste of time. Not like there was anything mission-critical on there.
Revoking certificates and expiring certificates tackle two different security issues.
You revoke a certificate when you believe that it might have been compromised. Expiring certificates helps protect you when you've unknowingly been compromised.
So let's say that one of your employees accidentally pushed a private key for one of your certificates up to GitHub and you notice it. That's when you should immediately rotate that certificate and revoking the old one.
Now let's say that the same thing happened but you didn't notice. That's where the certificate expiring comes into play. For a Lets Encrypt certificate there's currently going to be a maximum of 90 days where someone could find that private key and work out a way to exploit it, after that period the certificate would have expired and no longer be being used.
They are slowly reducing the period that certificates are valid for, not to the degree of milliseconds, but certainly to the point that renewing them will need to be automated.
One reason is Agility. Natural turnover due to expiration puts a reasonable maximum on the time needed to make any improvement that's not a flag day (a flag day is a situation where everybody in the ecosystem, so for today's Web that's billions of people, co-ordinates).
Improvements can be changes to cryptographic algorithms, like "Don't use SHA-1" or to the nuances of the certificate document like "Don't use this X509 feature" or to the CA infrastructure like "Don't issue certificates for names which don't exist".
Shortened certificate lifetimes improve agility by bringing forward that horizon. We can say "Stop doing X by August" tomorrow, and by Christmas 2026 there are no trusted end entity certificates which relied on X. A few years ago that took 3-5 years, at the turn of the century it was more than a decade and we repeatedly paid a price for that.
Can't remove a certificate from the revocation lists until it's expired, leading to boundless growth of those lists.
Risk of private keys/certificates from old backup media being leaked (remembering the adobe password leak...) and then suddenly coming back online and working until someone figures out how to revoke them
revoking certs does not work. it is so bad that the end result is that by 2029 certificates will not be allowed to be valid longer than 47 days: https://news.ycombinator.com/item?id=43693900
At a minimum I consider it like an automatic "garbage collection" mechanism that prevents dead and abandoned things to remain "valid forever".
It also helps with things such as change of ownership so after a certain period of time you can have the peace of mind that certs potentially issued by the previous owners are not lingering around as active (I understand things such as revoking and pinning can help with this too but It's nice to have a plain time based expiry too).
Let's say you buy a domain name from someone. Do you really want the previous owner of the domain to own a certificate for your website until the end of time? Sure you can get it revoked but certificate expiration ensures that it will expire even if it doesn't get revoked. That's a vital part of the security model.
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?
> Why does LetsEncrypt expire the cert while the acme DNS entry is still there?
That's like saying "why does the government expire my passport/driver's license when I haven't changed my name". That's not how it works; the document is stamped valid for a specific amount of time, and you get a new document with a new expiration time when you renew it.
The certificate from LE will expire automatically 90 days after it was provided, that's why you need to renew it before the 90 days are up.
If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers. It used to be that you needed to pay a company to generate a certificate for you every year, now you just get the option to have a free one every 90 days.
> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs
An ACME challenge file on a web server proves that you control a specific server at a specific domain, so you get a certificate for a specific domain.
A DNS entry proves you control the entire domain, so you (can) get a certificate for the domain.
By uploading a file to tekmol.freewebhost.com, you haven't proven that you control either .freewebhost.com or .tekmol.freewebhost.com. You have just proven that you control tekmol.freewebhost.com.
> If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers. It used to be that you needed to pay a company to generate a certificate for you every year, now you just get the option to have a free one every 90 days.
I took the easier route and let Cloudflare generate and handle certs for my domains. I’m on the free tier. I secure traffic between them and my host with an origin cert. By default those are valid for 15 years.
I know CF is frequently criticised around here, but wanted to mention it as an option.
That works too, of course. You don't even need a specific certificate or even an open port by leveraging Cloudflare tunnels, which means you can host your website on a local server behind three layers of NAT if you had to.
And it's not just Cloudflare; there are plenty of other redirect-everything-through-a-CDN hosts available. If you don't mind giving Cloudflare control of your website (and barring visitors from countries like India where CGNAT makes everyone fill out CAPTCHAs every page load), this approach will take care of just about everything.
I’ve been impressed with how much I get on the free tier (my sites are small). With the DDoS protections, rate limit, WAF rules, and Turnstile, it feels like I can keep a significant amount of abusive traffic from reaching my host. It’s a pretty compelling tradeoff for me, anyway.
You now have described the status quo in length. But you have not touched on why it is supposed to make sense. You have not provided attack vectors for the easier alternatives.
By uploading a file to tekmol.freewebhost.com,
you haven't proven that you control either
.freewebhost.com
Who said that putting a file on a subdomain should grant you a cert on the domain? Putting it on domain.com/.well-known/acme-challenge/ should.
They attempted to indicate wildcards there, but HN ate them. That should say "you haven't proven that you control either *.freewebhost.com or *.tekmol.freewebhost.com".
Now, I can definitely see there being a system where the owner of the root domain (eg, freewebhost.com) can set up something in their own .well-known directory that specifies that any subdomains can only declare certs for that specific subdomain, rather than being able to claim a wildcard, and then we can allow certs that sign wildcards in cases where such a limiter is not in place.
In any case, this would only solve the DNS auth hurdle, not the overall expiration hurdle.
> That's like saying "why does the government expire my passport/driver's license when I haven't changed my name". That's not how it works; the document is stamped valid for a specific amount of time, and you get a new document with a new expiration time when you renew it.
Because certificate lifetimes need to be determined when they’re issued. They aren’t dynamic and so can’t be changed in response to whether an acme challenge file exists.
The government expires your driver's license because they want to charge you for a renewal. You can tell that this is the only reason because it's the only thing they want in order to give you a new one. They do nothing to confirm that you still know how to drive.
But Let's Encrypt doesn't charge anything. All they want is to confirm that you still control the domain. So why doesn't "the DNS record they had you add to begin with is still there" satisfy that requirement and allow you to repeatedly renew the certificate until it stops being there?
Tie the DNS challenge to the public key in the certificate. Then as long as it hasn't changed you can update the certificate without giving the update process modify access to the DNS server.
Most governments primarily don’t want stolen identity documents circulating without any time bounds, especially given that they often get used improperly these days (e.g. by allowing a photo/scan of somebody’s ID to constitute “authentication” without comparing the photo to a real person, which is a bizarre notion that’s getting more and more common).
Passports and license renewals are often for periods in the nature of 10 years. Is that meaningfully different from the self-invalidation already implied by an ID that claims you're 144 years old? The mean time between mass data breaches is certainly already less than the existing renewal interval.
Meanwhile how does a stolen scan of an identity document become invalidated by requiring a renewal? The new document is identical and even contains the same ID number. The only difference is the date which anyone could trivially alter with a computer. For that matter the only thing they need from the stolen ID is the name and number, so even if you completely redesign the layout of the ID, someone with the old one can recreate a scan of the new layout using only the information on the old stolen one.
The problem here is not that you need IDs to expire, it's that you need fools to stop trying to rely on a computer image of an ID to authenticate anything.
> The new document is identical and even contains the same ID number.
Quite a few IDs contain a 2D barcode, and I believe at least some of these contain some offline-validateable signature over the basic data of the document, including the expiry date. That's not as trivial to forge.
On top of that, document expiry does help a bit with people trying to use a lost/stolen ID of somebody they happen to look similar to, adds a forcing function to make people eventually upgrade to newer/more secure document standards etc.
> Quite a few IDs contain a 2D barcode, and I believe at least some of these contain some offline-validateable signature over the basic data of the document, including the expiry date. That's not as trivial to forge.
Most government IDs don't have that, and it's still not clear what good it would be doing when data breaches happen on much shorter timescales than ID expirations. Who cares if they stop being able to use the ID after 10 years, when they can use them for 10 years and there will be another breach providing them with a new batch of IDs to use in a matter of days rather than years?
> On top of that, document expiry does help a bit with people trying to use a lost/stolen ID of somebody they happen to look similar to
That seems like an extremely narrow advantage. If they just need some ID that looks like them then they can just get another one from the batch of fresh ones. If they need the ID of a specific person, the government still isn't authenticating renewals, so wouldn't they just use the existing stolen ID and pay for a renewal in that case, in which case we're back the only thing happening being the government extracts money?
Or no, in that case it's worse, because then they can submit a fresh picture of themselves to renew the ID which has someone else's name on it.
> adds a forcing function to make people eventually upgrade to newer/more secure document standards etc.
Which you already have because everybody eventually dies.
Regarding "the DNS record they had you add to begin with is still there", it generally isn't. Part of the automation process for certbot using the DNS-01 challenge is the removal of the DNS record, following successful validation of said record. In any complex DNS environment, leaving TXT records around just increases the debris.
It's the Let's Encrypt people who make certbot, so that's just an implementation detail, and the premise here anyway is that you would be doing it manually (once) because the inconvenience to be avoided is when certbot can't update the DNS records automatically.
No, it's not the LetsEncrypt people who make certbot. Certbot is an EFF project, managed by separate people. Additionally, most of the DNS implementations will require the use of a specific plug-in/library for your selected DNS platform, and those, also, are developed separately.
Let's Encrypt was an EFF project to begin with. They're still the same people.
The DNS plugins only matter if you're trying to automate updating the DNS entry. The whole point is that you could have certbot spit out a DNS TXT record for the user to manually add to their DNS once, e.g. which contains the public key fingerprint of the certificate they want Let's Encrypt to renew on an ongoing basis, and then certbot would be able to renew the certificate as long as the DNS record remains in place.
No, LetsEncrypt was not an EFF project to begin with. Look, it works how it's documented to work. If you wish it worked some other way, to solve your particular suggested workflow, you're likely free to fork it and make it work that way.
Certificates have a static expiry date by design - it's not "LetsEncrypt expiring the cert". There is no way to avoid expiring a cert if the DNS entry is still there - all you can do is make it easier to renew the cert. That means it must be automated, in which case it doesn't matter if you need to re-create a DNS entry.
In my experience, it takes a little effort to set things up the first time, but from then on it just works.
I think the parent commenter would be satisfied if they could authorize their DNS by creating a DNS challenge entry one time, and then continue to renew their certificate as long as that entry still existed.
And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so.
That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.
> many of the simpler DNS tools -...- do not support API control
That's on the DNS provider in my opinion. They can, if they want to, make things easy and automatic for their customers, but they choose not to. There's a whole list of provider-specific plugins (https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...) with many more unofficial ones available (https://pypi.org/search/?q=certbot-dns-*). Generic ones, like the DirectAdmin one, will work for many web hosts that don't have their own APIs.
If you like to stick with whatever domain provider you picked and still want to use Let's Encrypt DNS validation, you can create a CNAME to another domain on a domain provider that does have API control. For instance, you could grab one of those free webhosting domains (rjst01.weirdfreewebhostthatputsadsinyourhtml.biz) with DirectAdmin access, create a TXT record there, and CNAME the real domain to that free web host. Janky, but it'll let you keep using the bespoke, API-less registrar.
I imagine you could set up a small DNS service offering this kind of DNS access for a modest fee ($1 per year?) just to host API-controllable CNAME DNS validation records. Then again, most of the time the people picking weird, browser-only domain registrars do so because it allows them to save a buck, so unless it's free the service will probably not see much use.
> 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?
An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added.
> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?
Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.
Of course - but that requires the owner to know they were attacked, know the attacker added a TXT verification, potentially overcome fear of deleting it breaking something unexpected, etc.
If the owner does not find out that someone got control of their DNS server, the attacker can do anything with the domain anyhow. Including issuing certs.
Yes, but once that access is revoked, that is enough to be certain that the attacker can no longer issue certs. With your proposal, I would then have to audit my TXT records and delete only attacker-created records.
(Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)
> Certificates are still a pain in the butt. One of the most cumbersome aspects of the web.
They will likely always be a pain and many aspects of Web security are cumbersome. It is simply a reflection of the fact that the Web, like e-mail, was not designed to be secure in the first place, being used in organisations where you can rely on trust. As a result the security stuff is just bolted on and often only in response to the previous solution failing. The previous layers stick around like zombie flesh until they are unceremoniously deprecated and cut away a decade later. A new system designed from scratch would be less cumbersome.
Since my DNS provider(IONOS) has an API and there is a plugin for my Webserver (caddy), DNS certificates were completely painless, even for *.<my domain>.
The solutions exist, depensa on the providers and your client.
It still helps sometimes. I was changing some settings on the server and messed up the automatic renewal. Getting an email from them saved me a lot of issues.
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.
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.
I strongly recommend building affirmative detection. A script which checks everything is OK and either tells everybody "Yeah, everything is OK" or "Here are the problems" means when, inevitably, that script doesn't fire, you don't get the false impression everything is OK.
All "silent success" detection systems will also silently fail and so they're worse than useless in my experience.
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.
Write a lambda in some cloud provider framework and run it every 1 hour to 24 hours and if it finds expired certificate, it will use webhooks to send you a message on Slack or Gotify or whatever.
Or you can just periodically renew the certificate on server using Task Scheduler + win-acme or Cron and certbot.
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
> 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 mailing list. Is still retaining emails somewhere. Doesn’t matter if it’s stored in a text file on a usb drive in a vault. It’s still retaining an email list.
I think the key part is what you didn't emphasize: "connected with issuance records." A list of email addresses is just a list of email addresses. A list of email addresses with domains over which the recipient has control is far more interesting data.
Is it truly much more difficult? At worst you could batch them by week and registered email, a one-liner can generate the list of destinations, and then you send that to your newsletter-sender-service and call the email "your cert is expiring next week".
You are talking of a volume of around 600 000 000 domains (based on a plot on their website) that try to renew at best after 8 weeks. And that's just default profile, there are 160h certs profiles now [0].
You think they will ever send nearly as much as (at least) 75 million newsletter mails weekly? Sendgrid's highest value in their pricing slider is 1,25 mil a week.
It is easy to think something like this is easy until you attempt to do it.
Are you really questioning a free SSL Certificate system when it says something is too complex and not worth it?
If you ever set up a free SSL before LetsEncrypt, you'd know they're amazing and you can trust them not to lie to you, especially about this where they've outlined the reasons clearly.
One could say it expired.
> 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)
tens of thousands of dollars? that's it? No one can just write them a check? switchgear costs more than that!
If someone were to hand them a check, with that $10,000, they would like to do something other than send reminder emails
That's the point
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.
A thousand helpful new fremium startups nominating themselves to send email to the overall domain admin email of record when CT indicates an upcoming expiration is hardly the same thing as the ACME server sending an email to the actual email sent at the time of registration.
It's not just about the money:
"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.
Aure, but that only covers a year or so. Its an extra operating expense that might or might not cause them to cut other things to fund.
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.
Not sure why, but many large companies that rely heavily on any open source/free initiative don’t donate. It’s sickening tbh
"Not sure why"
Because companies are for profit usually and any donation they make reduces that profit. That's why open source projects that can offer service contracts, have a easier time getting money from the buisness world, because this is something bookkeeping people understand in the corporate language.
Why discuss it here? Let's Encrypt has a shitload of corporate sponsorship. Look at their main page.
Why not? The sponsorship they get is far from enough. For such a significant CA, it should be a lot more than that
Do you have some links to their financial reports for last years? I'd love to see that.
> Why not?
Because I believe it is "sickening" expressing how "sickening (...) it is that large companies don't support open source/free initiative" when discussing one of the projects that do global-scale operations purely on corporate and personal donations. Somehow Let's Encrypt themself don't express that sickening in their blogs and websites. They do thank their sponsors, though.
Hey, I was actually in this position at work a few years ago, when I set up a couple of internal (monitoring stuff) servers for my own use. I used Let's Encrypt, because I use them (for free) at home (media server), and know how it works.
I wanted to throw them some (of work's) cash, and... the only two options were "Sponsor", and "Donate". Sponsorship was, uh, wrong for my use-case: it starts at some multiple-thousands of dollars. Donating would be the obviously correct choice, but putting something marked "donation" onto a corporate card would occasion a... Weird conversation, in which "you could have got this for free, but you're choosing to send them money?" would likely have been raised. I went with free, and was sad about it.
Yes, corporate expectations and affordances around FOSS should change - and, I probably could have persuaded my employer that a few dollars a month for Let's Encrypt was the Right Thing To Do, so I'm a little bit of a coward - but LE would make it so much easier if there was a Send Us Money option that looks like a fee for service, rather than a donation. (Maybe being a 501c(3) precludes that? I don't know.)
There's the "Corporate doesn't understand FOSS" problem, but there's also a "FOSS doesn't speak Corporatese" obstacle there, too.
In the end I sent LE $20, or something, of my own money (I've had years of trouble-free use on my media server, and should have before), but they'd have had $5 / month of work's cash for years if they'd made that easier to do.
There is a video here where FOSS donations confuses an accountant:
https://www.youtube.com/watch?v=VTY-lQ3S1gw
You could instead frame it as a payment for your dependency on the future existence of the FOSS you are using for free.
They are (Internet Security Research Group) a non-profit, so maybe it would be hard to provide official services like you describe?
I still can't find proper data on their financials, but at least below report (page 42) says only 10% of their revenue is donations. And 48% out of total spending is LE.
https://www.isrg.org/documents/2024-ISRG-Annual-Report.pdf
It may not even have to be an official service, just something that shows up on a CC statement as something other than a "donation".
Or hey maybe they could charge for these expiration notifications.
I'm really not sure if that kind of organization can simply sell services like that. I'm guessing IRS doesn't care of that CC statement was official or not :)
can you?
They should just build a mobile app for the purpose of receiving these notifications. Make the app $2.99. Turn the expense into a profit. /s
As an other option, you install a cron job on your server, and send push notifications via pushover or ntfy.sh whenever it fails to renew.
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.
Or just a cronjob that fetches the tls certs and look at the expiration date and then send a mail or X.
So it's even work if you don't have control about the le client.
Exactly this. Don't look at the renewal proces, look at its output. It'll work for all certificate sources and catch other potential errors too (eg the webserver reporting success but not presenting the new certificate)
That'll work too. The idea was to put your own infra in place if you really need that, and it's not very hard to do it, even with completely self-hosted stack.
I imagine this is best left to third parties like the recommended service linked in the post. I assume that there's also a whole deluge of other services that have similar offerings.
what's the cost of sending notifications via mobile app? cheaper than email?
Mobile app? Now they need to develop that, keep up to date with OS version changes, and far far worse, support end users and their bugs?
And worse of all, worry about Apple and Google's arbitrary rejections?
This seems far more costly than email. Just having one dev keeping those apps going, is likely 20x or more than their email costs per year.
at least for iOS there are no costs associated with using Apple Push Notification Service (APNS) but depending on the way you use it you either need to pay for the infrastructure that sends your notifications to Apple or for a service like OneSignal which does that for you. Not sure what the volume of LE is but I am pretty sure it's a smart move to focus on their core "business" (providing certificates) and let other handle expiration notifications.
that's quite a good idea..
A company like Postmark should have just given them a free account on the condition they mentioned them at the bottom of emails or something
It's a valuable service for the average person to get these emails without having to set up separate monitoring
A free account for sending emails would not have changed the decision because it doesn't solve this:
"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."
Now there is no contact information associated with issuance records.
It didn't need to be a requirement
Neither is sending emails :)
Yeah, but nobody said it was a requirement
But it was obviously valuable enough for them to be doing it for over a decade
I remember it being helpful to me personally when I was using LE when it first came out
If they're that worried about having some random email associated, then perhaps they shouldn't also publish all certs they cut for domains?
https://crt.sh/
Publishing all SSL certs for domains is kind of worse than some random email.
That’s how CT works. They can’t not publish end-entity certificates to CT logs.
(But also, even if they could avoid this somehow: the entire point of a public CA is to publish end entity certificates. The “I want a public certificate while keeping a subdomain secret” model was never particularly coherent.)
The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well.
I dont need cert transparency either. I just needed encryption... Which a self-signed would be fine. But the internet powers that be deem self-signed as 'evil'. And more webtech requires SSL (like you, websockets). Can't even use it locally without SSL.
Paying $x00 for a SSL from some commercial vendor is laughable these days, unless you need a code cert or a onioncert.
> The "I want basic encryption for this subdomain but not announce it to the world" seems rather sane as well.
Not really: we learned a hard lesson decades ago that encryption isn’t especially meaningful unless you know who you’re encrypting to. Self-signed certificates are the classic “your communications are secure, but you’re talking with satan” example.
As others have said: if you want to keep a specific subdomain label out of CT, you can issue a wildcard certificate instead. But the Web PKI as a whole is correct in not letting you do encrypted communication with a service without having some established notion of that service’s identity.
Get a wildcard for the apex domain/higher-level subdomain, the "secret" subdomain will be covered implicitly.
If you don't want the certificate to be in the CT logs, your only options are a private CA or things like CF Origin certificate, depending on how the domain is intended to be accessed.
It's not the end user that "needs" CT, it is a mechanism to ensure no shady CA can misissue a certificate without being caught. Requirements like that are written in blood (see Symantec).
> I just needed encryption... Which a self-signed would be fine. But the internet powers that be deem self-signed as 'evil'.
Self-signed certificates don't actually provide useful encryption, since they are trivially MITM-able.
At least there is this:
> For those who would like to continue receiving expiration notifications, we recommend using a third party service such as Red Sift Certificates Lite (formerly Hardenize). Red Sift’s monitoring service providing expiration emails is free of charge for up to 250 certificates. More monitoring options can be found here.
They could just include a local notifier in their scripts, would probably satisfy the majority of users.
I don't think this is nearly as effective of a solution. It stops working if the script is crashing before hitting the notification, it doesn't work if you break your email setup (which for an email that almost never sends is likely to go unnoticed forever) it also fails if you accidentally stop running a script or remove the certificate from your config entirely.
You could have a weekly canary email as well.
Yeah and people could just use rsync instead of Dropbox
Of course, whenever it's possible.
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 do agree with you, and setting up your own monitoring is key. I have that.
Yet it was still valuable to find those that fell through the cracks. At work, the emails prevented a couple of outages by expired cert, because a dev that left was renewing them by hand and we only found out when they left and the catch-all started to bubble them up to support.
Things fall through the cracks, or people are in a pinch and just forget to add the cert to the in-house monitoring system. The emails were a wonderful failsafe.
I wish I could just query LE to tell me all existing certain where the account is under my domain name. Extremely helpful to assemble a SBOM.
As a hobbyist without a lot of time for sysadmin, it would be nice if basic email monitoring was a standard package (apt install letsencrypt-monitors or something).
Just use certbot. It automatically sets up a scheduled task to renew your SSL/TLS certificates in the background, typically using a systemd timer that runs twice a day. I do not know why people using LetsEncrypt would not set up certbot along with it, that is how I do it. Some nginx config + certbot.
Maybe the situation's improved, but I found certbot from system package managers would diverge from latest version, sometimes significantly, like support for DNS challenge APIs breaking. I switched to ‘acme.sh’ for most machines and haven't looked back. It no longer has Let's Encrypt as its default issuer, but you can set it back to LE with one config command.
I was going to mention acme.sh, too. certbot and acme.sh are two popular methods.
That said, I never had issues with certbot on Arch Linux, and I have been using it for a really long time.
Since Arch Linux is bleeding-edge, it does not diverge from latest version. :D
I use certbot, but I don't think it will email me if something goes wrong.
What would go wrong? I have been using LetsEncrypt (with certbot) for a really long time, and it never went wrong. Did it ever happen to you?
You can get pretty close to this by (1) setting up certbot and (2) configuring your system to actually send emails if cron jobs fail.
I can see the use in a tool that will scan all certificates configured in local web servers and monitors for close expiration dates, though. Not just Let's Encrypt, but also any other ACME accounts and certificate directories you may need. The biggest challenge would probably be dealing with encrypted certificate files, and after that getting email set up correctly. Nobody seems to have made it because it's so easy to script or add to a pre-existing monitoring system, so this could be a fun open source project. You probably can't use the letsencrypt brand name, though.
Emails sent from most hosting servers won't actually get to your inbox, unfortunately.
Use one of the myriad uptime monitoring services.
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.
When I received the first warning email about this, I wrote a simple library and cli to validate all my certs for me.
https://github.com/jgaa/openvalify
I just have a cronjob that does:
If you’re automating the check why not automate the renewal directly?
I've missed expired certificates because of a configuration issue that broke the certbot automation. Granted, I could've read the certbot journalctl output, but 99.9% of the time that's a waste of time. Not like there was anything mission-critical on there.
who says they don't have the renewal automated?
> https://github.com/jgaa/openvalify
I don't begrudge people writing a tool to learn, but it should be noted that this wheel has already been invented:
* https://github.com/matteocorti/check_ssl_cert
* https://exchange.nagios.org/directory/Plugins/Security/check...
* https://github.com/narbehaj/ssl-checker
* https://github.com/Matty9191/ssl-cert-check
Is it the right time to rant about the cert expiration as a concept? I understand why certs might be revoked. But expire?
Revoking certificates and expiring certificates tackle two different security issues.
You revoke a certificate when you believe that it might have been compromised. Expiring certificates helps protect you when you've unknowingly been compromised.
So let's say that one of your employees accidentally pushed a private key for one of your certificates up to GitHub and you notice it. That's when you should immediately rotate that certificate and revoking the old one.
Now let's say that the same thing happened but you didn't notice. That's where the certificate expiring comes into play. For a Lets Encrypt certificate there's currently going to be a maximum of 90 days where someone could find that private key and work out a way to exploit it, after that period the certificate would have expired and no longer be being used.
If expiring certificates offer some sort of security shouldn’t they be expiring after milliseconds?
If I had compromised the Bank of America servers a couple of minutes would suffice to collect a ton of password combinations.
They are slowly reducing the period that certificates are valid for, not to the degree of milliseconds, but certainly to the point that renewing them will need to be automated.
One reason is Agility. Natural turnover due to expiration puts a reasonable maximum on the time needed to make any improvement that's not a flag day (a flag day is a situation where everybody in the ecosystem, so for today's Web that's billions of people, co-ordinates).
Improvements can be changes to cryptographic algorithms, like "Don't use SHA-1" or to the nuances of the certificate document like "Don't use this X509 feature" or to the CA infrastructure like "Don't issue certificates for names which don't exist".
Shortened certificate lifetimes improve agility by bringing forward that horizon. We can say "Stop doing X by August" tomorrow, and by Christmas 2026 there are no trusted end entity certificates which relied on X. A few years ago that took 3-5 years, at the turn of the century it was more than a decade and we repeatedly paid a price for that.
Can't remove a certificate from the revocation lists until it's expired, leading to boundless growth of those lists.
Risk of private keys/certificates from old backup media being leaked (remembering the adobe password leak...) and then suddenly coming back online and working until someone figures out how to revoke them
revoking certs does not work. it is so bad that the end result is that by 2029 certificates will not be allowed to be valid longer than 47 days: https://news.ycombinator.com/item?id=43693900
TLS server certificates, that is. It’s perfectly fine for other uses of certificates.
true, but i would guess that revoking certificates doesn't work in general, so this would apply to any situation where revoking is necessary.
That guess is incorrect. Revocations are routine in PKI-based electronic signatures and authentication, and do work there.
At a minimum I consider it like an automatic "garbage collection" mechanism that prevents dead and abandoned things to remain "valid forever".
It also helps with things such as change of ownership so after a certain period of time you can have the peace of mind that certs potentially issued by the previous owners are not lingering around as active (I understand things such as revoking and pinning can help with this too but It's nice to have a plain time based expiry too).
Let's say you buy a domain name from someone. Do you really want the previous owner of the domain to own a certificate for your website until the end of time? Sure you can get it revoked but certificate expiration ensures that it will expire even if it doesn't get revoked. That's a vital part of the security model.
While 90d might be short, 10 years is too long (encryption changes!)
I hope they don't send another 20 emails at random intervals across two months to notify me of this now...
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?
> Why does LetsEncrypt expire the cert while the acme DNS entry is still there?
That's like saying "why does the government expire my passport/driver's license when I haven't changed my name". That's not how it works; the document is stamped valid for a specific amount of time, and you get a new document with a new expiration time when you renew it.
The certificate from LE will expire automatically 90 days after it was provided, that's why you need to renew it before the 90 days are up.
If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers. It used to be that you needed to pay a company to generate a certificate for you every year, now you just get the option to have a free one every 90 days.
> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs
An ACME challenge file on a web server proves that you control a specific server at a specific domain, so you get a certificate for a specific domain.
A DNS entry proves you control the entire domain, so you (can) get a certificate for the domain.
By uploading a file to tekmol.freewebhost.com, you haven't proven that you control either .freewebhost.com or .tekmol.freewebhost.com. You have just proven that you control tekmol.freewebhost.com.
> If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers.
Not for much longer, the maximum lifetime of a public certificate will progressively go down to 47 days by March 2029.
> If you hate setting up automated certificate renewal, you can still get longer-lasting certificates from paid certificate providers. It used to be that you needed to pay a company to generate a certificate for you every year, now you just get the option to have a free one every 90 days.
I took the easier route and let Cloudflare generate and handle certs for my domains. I’m on the free tier. I secure traffic between them and my host with an origin cert. By default those are valid for 15 years.
I know CF is frequently criticised around here, but wanted to mention it as an option.
That works too, of course. You don't even need a specific certificate or even an open port by leveraging Cloudflare tunnels, which means you can host your website on a local server behind three layers of NAT if you had to.
And it's not just Cloudflare; there are plenty of other redirect-everything-through-a-CDN hosts available. If you don't mind giving Cloudflare control of your website (and barring visitors from countries like India where CGNAT makes everyone fill out CAPTCHAs every page load), this approach will take care of just about everything.
Agreed. It’s about priorities and tradeoffs.
I’ve been impressed with how much I get on the free tier (my sites are small). With the DDoS protections, rate limit, WAF rules, and Turnstile, it feels like I can keep a significant amount of abusive traffic from reaching my host. It’s a pretty compelling tradeoff for me, anyway.
You now have described the status quo in length. But you have not touched on why it is supposed to make sense. You have not provided attack vectors for the easier alternatives.
Who said that putting a file on a subdomain should grant you a cert on the domain? Putting it on domain.com/.well-known/acme-challenge/ should.They attempted to indicate wildcards there, but HN ate them. That should say "you haven't proven that you control either *.freewebhost.com or *.tekmol.freewebhost.com".
Now, I can definitely see there being a system where the owner of the root domain (eg, freewebhost.com) can set up something in their own .well-known directory that specifies that any subdomains can only declare certs for that specific subdomain, rather than being able to claim a wildcard, and then we can allow certs that sign wildcards in cases where such a limiter is not in place.
In any case, this would only solve the DNS auth hurdle, not the overall expiration hurdle.
Because certificate lifetimes need to be determined when they’re issued. They aren’t dynamic and so can’t be changed in response to whether an acme challenge file exists.
Passport is a good example. So is bank notes. They expire to add new security features.
Banknotes don't expire.
There’s plenty that have. Just one example: https://en.wikipedia.org/wiki/Military_payment_certificate
Similar schemes have been used in the past as a forcing function against tax evasion or simply to phase out less secure older bills.
Specific notes and coins do, despite the underlying money doesn't.
In practical terms retailers can refuse old ones. In countries I have lived in.
The government expires your driver's license because they want to charge you for a renewal. You can tell that this is the only reason because it's the only thing they want in order to give you a new one. They do nothing to confirm that you still know how to drive.
But Let's Encrypt doesn't charge anything. All they want is to confirm that you still control the domain. So why doesn't "the DNS record they had you add to begin with is still there" satisfy that requirement and allow you to repeatedly renew the certificate until it stops being there?
Tie the DNS challenge to the public key in the certificate. Then as long as it hasn't changed you can update the certificate without giving the update process modify access to the DNS server.
Most governments primarily don’t want stolen identity documents circulating without any time bounds, especially given that they often get used improperly these days (e.g. by allowing a photo/scan of somebody’s ID to constitute “authentication” without comparing the photo to a real person, which is a bizarre notion that’s getting more and more common).
Passports and license renewals are often for periods in the nature of 10 years. Is that meaningfully different from the self-invalidation already implied by an ID that claims you're 144 years old? The mean time between mass data breaches is certainly already less than the existing renewal interval.
Meanwhile how does a stolen scan of an identity document become invalidated by requiring a renewal? The new document is identical and even contains the same ID number. The only difference is the date which anyone could trivially alter with a computer. For that matter the only thing they need from the stolen ID is the name and number, so even if you completely redesign the layout of the ID, someone with the old one can recreate a scan of the new layout using only the information on the old stolen one.
The problem here is not that you need IDs to expire, it's that you need fools to stop trying to rely on a computer image of an ID to authenticate anything.
> The new document is identical and even contains the same ID number.
Quite a few IDs contain a 2D barcode, and I believe at least some of these contain some offline-validateable signature over the basic data of the document, including the expiry date. That's not as trivial to forge.
On top of that, document expiry does help a bit with people trying to use a lost/stolen ID of somebody they happen to look similar to, adds a forcing function to make people eventually upgrade to newer/more secure document standards etc.
> Quite a few IDs contain a 2D barcode, and I believe at least some of these contain some offline-validateable signature over the basic data of the document, including the expiry date. That's not as trivial to forge.
Most government IDs don't have that, and it's still not clear what good it would be doing when data breaches happen on much shorter timescales than ID expirations. Who cares if they stop being able to use the ID after 10 years, when they can use them for 10 years and there will be another breach providing them with a new batch of IDs to use in a matter of days rather than years?
> On top of that, document expiry does help a bit with people trying to use a lost/stolen ID of somebody they happen to look similar to
That seems like an extremely narrow advantage. If they just need some ID that looks like them then they can just get another one from the batch of fresh ones. If they need the ID of a specific person, the government still isn't authenticating renewals, so wouldn't they just use the existing stolen ID and pay for a renewal in that case, in which case we're back the only thing happening being the government extracts money?
Or no, in that case it's worse, because then they can submit a fresh picture of themselves to renew the ID which has someone else's name on it.
> adds a forcing function to make people eventually upgrade to newer/more secure document standards etc.
Which you already have because everybody eventually dies.
Regarding "the DNS record they had you add to begin with is still there", it generally isn't. Part of the automation process for certbot using the DNS-01 challenge is the removal of the DNS record, following successful validation of said record. In any complex DNS environment, leaving TXT records around just increases the debris.
It's the Let's Encrypt people who make certbot, so that's just an implementation detail, and the premise here anyway is that you would be doing it manually (once) because the inconvenience to be avoided is when certbot can't update the DNS records automatically.
No, it's not the LetsEncrypt people who make certbot. Certbot is an EFF project, managed by separate people. Additionally, most of the DNS implementations will require the use of a specific plug-in/library for your selected DNS platform, and those, also, are developed separately.
Let's Encrypt was an EFF project to begin with. They're still the same people.
The DNS plugins only matter if you're trying to automate updating the DNS entry. The whole point is that you could have certbot spit out a DNS TXT record for the user to manually add to their DNS once, e.g. which contains the public key fingerprint of the certificate they want Let's Encrypt to renew on an ongoing basis, and then certbot would be able to renew the certificate as long as the DNS record remains in place.
No, LetsEncrypt was not an EFF project to begin with. Look, it works how it's documented to work. If you wish it worked some other way, to solve your particular suggested workflow, you're likely free to fork it and make it work that way.
Good luck.
Certificates have a static expiry date by design - it's not "LetsEncrypt expiring the cert". There is no way to avoid expiring a cert if the DNS entry is still there - all you can do is make it easier to renew the cert. That means it must be automated, in which case it doesn't matter if you need to re-create a DNS entry.
In my experience, it takes a little effort to set things up the first time, but from then on it just works.
I think the parent commenter would be satisfied if they could authorize their DNS by creating a DNS challenge entry one time, and then continue to renew their certificate as long as that entry still existed.
And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so.
That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.
> many of the simpler DNS tools -...- do not support API control
That's on the DNS provider in my opinion. They can, if they want to, make things easy and automatic for their customers, but they choose not to. There's a whole list of provider-specific plugins (https://eff-certbot.readthedocs.io/en/stable/using.html#dns-...) with many more unofficial ones available (https://pypi.org/search/?q=certbot-dns-*). Generic ones, like the DirectAdmin one, will work for many web hosts that don't have their own APIs.
If you like to stick with whatever domain provider you picked and still want to use Let's Encrypt DNS validation, you can create a CNAME to another domain on a domain provider that does have API control. For instance, you could grab one of those free webhosting domains (rjst01.weirdfreewebhostthatputsadsinyourhtml.biz) with DirectAdmin access, create a TXT record there, and CNAME the real domain to that free web host. Janky, but it'll let you keep using the bespoke, API-less registrar.
I imagine you could set up a small DNS service offering this kind of DNS access for a modest fee ($1 per year?) just to host API-controllable CNAME DNS validation records. Then again, most of the time the people picking weird, browser-only domain registrars do so because it allows them to save a buck, so unless it's free the service will probably not see much use.
> 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?
An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added.
> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?
Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.
> An attacker should not gain the ability to > persistently issue certificates because they > have one-time access to DNS.
They wouldn't. As soon as the owner of the domain removes the TXT entry that ability would be gone.
Of course - but that requires the owner to know they were attacked, know the attacker added a TXT verification, potentially overcome fear of deleting it breaking something unexpected, etc.
If the owner does not find out that someone got control of their DNS server, the attacker can do anything with the domain anyhow. Including issuing certs.
Yes, but once that access is revoked, that is enough to be certain that the attacker can no longer issue certs. With your proposal, I would then have to audit my TXT records and delete only attacker-created records.
(Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)
> Certificates are still a pain in the butt. One of the most cumbersome aspects of the web.
They will likely always be a pain and many aspects of Web security are cumbersome. It is simply a reflection of the fact that the Web, like e-mail, was not designed to be secure in the first place, being used in organisations where you can rely on trust. As a result the security stuff is just bolted on and often only in response to the previous solution failing. The previous layers stick around like zombie flesh until they are unceremoniously deprecated and cut away a decade later. A new system designed from scratch would be less cumbersome.
Since my DNS provider(IONOS) has an API and there is a plugin for my Webserver (caddy), DNS certificates were completely painless, even for *.<my domain>.
The solutions exist, depensa on the providers and your client.
We would be better off if people started using DANE. No centralized authority, you control the keys
DIY monitoring:
I can't believe they didn't end it soon. Majority of the users have automatic renewals in place which makes this completely unnecessary
It still helps sometimes. I was changing some settings on the server and messed up the automatic renewal. Getting an email from them saved me a lot of issues.
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.
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.
These emails were handy to detect when the automation failed.
I strongly recommend building affirmative detection. A script which checks everything is OK and either tells everybody "Yeah, everything is OK" or "Here are the problems" means when, inevitably, that script doesn't fire, you don't get the false impression everything is OK.
All "silent success" detection systems will also silently fail and so they're worse than useless in my experience.
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.
is there a Slack bot for expiry checks?
Write a lambda in some cloud provider framework and run it every 1 hour to 24 hours and if it finds expired certificate, it will use webhooks to send you a message on Slack or Gotify or whatever.
Or you can just periodically renew the certificate on server using Task Scheduler + win-acme or Cron and certbot.
haha, I was asking if somebody build that or recommends good open sourced version of exactly this
[flagged]
Yeah a list of emails is not similar to a db of email/certificate association ...
[flagged]
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
It has nothing to do with complexity.
> 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 mailing list. Is still retaining emails somewhere. Doesn’t matter if it’s stored in a text file on a usb drive in a vault. It’s still retaining an email list.
I think the key part is what you didn't emphasize: "connected with issuance records." A list of email addresses is just a list of email addresses. A list of email addresses with domains over which the recipient has control is far more interesting data.
Irrelevant.
Is it truly much more difficult? At worst you could batch them by week and registered email, a one-liner can generate the list of destinations, and then you send that to your newsletter-sender-service and call the email "your cert is expiring next week".
Of course it's more difficult.
You are talking of a volume of around 600 000 000 domains (based on a plot on their website) that try to renew at best after 8 weeks. And that's just default profile, there are 160h certs profiles now [0].
You think they will ever send nearly as much as (at least) 75 million newsletter mails weekly? Sendgrid's highest value in their pricing slider is 1,25 mil a week.
- [0] https://letsencrypt.org/docs/profiles/
It is easy to think something like this is easy until you attempt to do it.
Are you really questioning a free SSL Certificate system when it says something is too complex and not worth it?
If you ever set up a free SSL before LetsEncrypt, you'd know they're amazing and you can trust them not to lie to you, especially about this where they've outlined the reasons clearly.
will email still be recuired for getting certs?
I don't think it ever was? I never gave my email address to LetsEncrypt but I'm also not using their official client.
Account registration is done by sending a public key to a certain API endpoint. The key will become associated with an account URL that looks like this: https://acme-v02.api.letsencrypt.org/acme/acct/4277968575
As far as I know. No.