Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
When we have certs with a bunch of SANs on them, it is common to add or remove one name. This is seen as a "new cert," not a replacement for an existing cert, so we get a LOT of false alarm email notifications.
Subject: Let's Encrypt certificate expiration notice for domain [...]
In the message body it says: "note that this reminder email is still sent if you've obtained a slightly different certificate by adding or removing names. If you've replaced this certificate with a newer one that covers more or fewer names than the list above, you may be able to ignore this message."
Is there any way to fix this? To make letsencrypt aware of the fact that a new cert with more or less names is actually a replacement for a previous cert?
The way things are now, we've had dozens, if not hundreds of false alarm emails about expirations, and zero useful expiration notifications. I'm on the verge of just filtering all letsencrypt email to the garbage.
Well, that domain is not the best example as it is just a wildcard for that domain
One option for multi-SAN certs is to just not do that A better approach is to get a cert with only names that are tightly coupled to each other. For common servers that means getting one cert for each virtual host. This is more efficient when adding/removing domains.
Another option is to use your own monitoring system and ignore these friendly warnings. Since you know all the active domains you could monitor each for trouble. This would catch even more problems such as server misconfigure and such.
Working with VARs such as pantheon and acquia, there are limits to the number of certs we can upload. If there's a maximum of 10 certs possible to be in use, and you have 70 sites served there, you have to put a bunch of names into SAN's on certs. You throw in some wildcards to try to keep the number of names down, but there's nothing you can do. You have to use SANs with multiple names, and as sites come and go, you have to add/remove names.
It sounds like the answer is "ignore letsencrypt email and use your own monitoring system."
The tricky part is that outright unsubscribing will also unsubscribe you to notices that are actually important, such as if your client needs to be upgraded due to an API change, or because one of your certificates needed to be revoked prematurely due to Let's Encrypt making a mistake.
You may be better off with a mail client rule that just automatically deletes the mail with that subject.
Longer-term, there is a proposal called ACME Renewal Information, which would allow your servers to notify Let's Encrypt once it was no longer using a certificate. Let's Encrypt has started implementing the draft, but doesn't yet connect the message that a client was done with a certificate with the mail renewal system.
Another similar option may be actually revoking the old certificate once it's been replaced (with reasonCode superseded), as I'm pretty sure you won't get renewal emails for revoked certificates. That may not be easy to put into your workflow either, though, and is arguably causing more work on Let's Encrypt side to deal with the revocation that is actually necessary.
If that was easily possible, Let's Encrypt would already have implemented it. But it's not easy, if not practically impossible. Not without ACME client feedback, such as with ARI.
If the ACME client isn't able to provide feedback, either using ARI or revoking a cert, the LE servers can only guess.. And nobody gets happy about that.
ARI is the draft "ACME Renewal Information" that I linked to earlier, which is an extension to the ACME protocol to add more information to clients on when a certificate should be renewed, and to inform the server when a certificate has been replaced. It's currently in draft, getting feedback on implementations. All you would need to do upgrade your client (such as certbot) once it gets support for it. But it probably doesn't have support yet, and even if it did Let's Encrypt would also need to update their end to handle not sending renewal reminders once a certificate was marked as replaced.
It's a longer-term solution, not anything you can really use in practice yet to solve this particular problem.
Ok, thank you. I unsubscribed from the renewal emails, and it says the unsubscription will only last a year, so presuming someday ARI or something equivalent exists, it will be a natural transition to the newer stuff.
A better approach is to get a cert with only names that are tightly coupled to each other. For common servers that means getting one cert for each virtual host. This is more efficient when adding/removing domains.