I've recently rebuilt a bunch of servers and (due to DNS provider issues) obtained new certificates on new accounts. Now I'm getting reminder messages about the out-of-use certificates. The problem is that I can't be sure they're about the out-of-use certificates, since they only mention the certificates by domain name. It would save me checking labour if the mails would provide a bit more identifying information, such as:
the date of issuance of the certificate
the certificate fingerprint
That would allow me to be sure which certificates the messages are for just by looking at the message.
It would be nice to have the account ID visible too.
We have been in a rather complex transition with server migration that includes warm backups, and did not want to revoke the old certificates.
Also, my suggestion is about a reminder message, which is at least partly to help people who are dealing with mistakes, or things that have slipped through the cracks. Such as people who forget to revoke and need to know about lost servers. (I haven't lost any of ours yet!)
My suggestion is to save the time of others who are in a similar situation with many servers in complex relationships.
I support your request 100 percent @rptb1 ; moreover, this should be a fairly simple and easy to apply change - just modifying the existing email template.
If a certificate was issued with the same exact set of names as the original certificate, then that should count as a "renewal" and so you wouldn't get an email, regardless of whether it was from a different server or different ACME account. (At least that's my understanding.) Is it that you replaced the certificates with slightly different sets of domain names? If so, it's really hard for Let's Encrypt to know whether the original set of names is also a certificate which is supposed to be renewed as well.
I certainly agree that there are a lot of improvements that could be made to the reminder emails. (And sometimes I think that it would be more helpful to everyone if they just stopped trying to do them altogether.) Just trying to explain the current logic and where Let's Encrypt is coming from.
Part of the transition involved reorganising the way names were attached to certificates, splitting some virtual servers, etc. I have no expectation that Let's Encrypt can deduce what we're up to!
In the meantime, you could search the transparency logs for certs that match the names in the email. And, which are due to expire in 20 days (or 7 if second email).
One search tool is crt.sh although note that on its result page it does not show every name in the SANs list only the ones that match your search criteria. You need to click the ID to see all the names in the cert. Also, by default you see both the Precert and the Leaf so use Advanced options to Deduplicate.
Another good tool is Let's Debug Cert Search but this only shows history of Let's Encrypt certs. The advantage is it shows all the names in the SANs list in a nice format. (Aside: today something seems wrong with it display caching so need to click Search twice for fresh results. I'll report that to dev). (Update: the amazing dev of that tool already fixed the display double-click issue)
With millions of certificates being processed per week and this suggestion having already been made nearly as many times, rest assured that it's not a simple change.
While I agree revocation is unnecessary when replacing a server, I don't think that I'd go so far as to call it a waste. If the now-unused certificates are revoked with reason "superseded", then it makes it clear that the old certificates are no longer in use and nobody should trust them or be using them anymore. (And, Let's Encrypt won't send reminder emails for them, which arguably is a different kind of "waste".)
The draft ACME Renewal Information specification includes a method for a client to indicate to a CA that a certificate has been replaced (and thus doesn't need reminder emails) without indicating that it should be revoked (with all the additional signing/processing/etc. that entails). That's probably really the right solution for this sort of thing, but we're probably still some ways off from Let's Encrypt doing anything with that endpoint (Last I checked it accepted the request and then just didn't do anything with it) and from popular ACME clients implementing it. So until that happens, revoking may be a reasonable way of dealing with it. (Though certainly anyone who doesn't revoke when replacing a server isn't doing anything "wrong".)
I can't find the thread at the moment. But I also recall someone from LE Staff explicitly stating that revoking certs as superseded is a perfectly acceptable practice.
Arguably, this could even be a decent ACME client feature to automatically revoke an old cert on renewal if the new cert contains different SANs than the previous one. The client is really the only non-human process that could have the context to make that decision. But it would be a very client-specific implementation.
It requires an extra round of OCSP signing. And thus wasting resources if that wasn't necessary. Resources that could have gone into signing a certificate
Sure, I'm just comparing that to the waste of a few emails, when the complexity and cost of the email system was recently highlighted as a big pain point for Let's Encrypt. I'm not saying revoking is great, or even needed at all. I'm just saying that doing so, for a one-off server replacement, isn't that big a deal. Just like issuing a one-off certificate for a test server that's only going to be around for a couple weeks isn't that big a deal. It's the revoking regularly that isn't needed, or the wasting certificates regularly (like forcing renewals every day), which are things that polite users of Let's Encrypt's resources would want to avoid.
This is a long-standing request, with people begging for more information on these emails for many many years (Certificate ID, Account ID, etc).
ISRG/LetsEncrypt have been very clear about a few things, also for many years:
Their email system is already too expensive, and they don't have resources to update/manage/change it. @petercooperjr highlighted a recent 2023 post about this, but I think you'll see this going back to 2016 and even earlier.
These emails are a courtesy and a failsafe. On a proper system, you should never receive them.
This is definitely aggravating when you're doing a system migration or server switch. Please keep in mind that you're requesting a feature that would only improve the system for less than 2% of users, while their engineers and developers are already spread pretty thin on critical systems and improvements that will benefit 100% of users.
