Expiration notices for expanded certificates

I have one server that I keep adding additional virtualhosts and services too. Accordingly, I keep adding additional domains or subdomains to the certificate (from what I understand, I can't use separate certificates with name-based virtual hosts). Every time I do, a few months later I'll get an expiration notice for the previous certificate (minus the most recently added domain). I understand that this is expected. The documentation says "If you’ve issued a new certificate that adds or removes a name relative to your old certificate, you will get expiration email about your old certificate." My question is, why, and is there anything I can do to avoid this? Every time it happens it freaks me out and eats up time with me trying to ensure that my auto-renewals haven't broken, and I'm worried that this could eventually become a boy-who-cried-wolf situation where I get so used to ignoring it, that I miss an actually important notification. Why can't Let's Encrypt know not to notify about superseded certificates? Or if there's a legitimate reason why you might still care about the old certificate, an option to opt-out for the seemingly more likely case that I don't care. Would revoking the old certificate before requesting the new expanded one solve this problem, or is there some reason why doing that would be a bad idea?

1 Like

Hi @sparkyb and welcome to the LE community forum :slight_smile:

Because they are two separate certificates.
A human sees... I requested to "renew" those 12 names with these 15 names.
A computer see... Give me a cert for these 15 names... (no match found... must NOT be a renewal).
Yes, you can do something about it.
But you would first have to overcome the:

Why can't you do that?

You really should have a more robust system of informing you when your (one and only cert) is close to expiry. Relying on an email from LE is far from the ideal coverage for such an event.

You need to find a quicker way of checking what is in use before even going down that road.
[there are plenty of simply ways of checking one cert]

^ I think I covered that ^
[short answer: LE has no way of knowing where the two certs are even being used]

BAD IDEA.
Revoking a cert wastes resources - even more than issuing a cert.
Please don't do that without just cause (like when a private key has been compromised).

In summation: Why don't we work on "updating" your system to handle SNI instead?
[then you can issue individualized certs and be notified only when one is actually nearing expiry]

1 Like

I'd second this suggestion. Using SNI and having multiple specific certificates is generally better than stuffing domains into one cert (that's limited and if this is a business it also exposes your list of clients).

1 Like

First of all, thanks for the recommendation about SNI. I knew there was a way to identify a host before SSL handshake so that name-based virtual hosting could work with separate certificates, but for some reason I was under the impression that it was not very widely supported or not recommended. I just looked into it again and it seems much more reasonable of a solution than I had previously thought. Perhaps there was another reason I'm not remembering why I didn't do that initially that I'll rediscover when I actually convert my configs to use this method, but for now that sounds like a good plan.

While that will mostly solve my problem, I still think it would be a worthwhile feature for there to be a way to automatically or manual unsubscribe from nuisance expiration notices for certificates that are not being used anymore (for any reason).

It seems like revocation would do it, but I've seen several postings that it is a bad idea if it isn't actually compromised. That advice would be better if it came with an explanation of why revoking a cert is "wasteful". My guess is that it has something to do with cluttering CRLs? I don't know whether a revoked certificate pollutes that list forever, but it seems like it should only need to stay there until the certificate would be expired anyway, which in the case of Let's Encrypt certificates isn't very long, so it seems like it shouldn't be as big a problem as people make it out to be.

But ok, I get that what I'm suggesting is still a misuse of revocation whether it is actually problematic or not. I don't really need to revoke the certificate. I don't really care that it is still valid since I know that I'm in complete control of it and I don't intend to ever use it again. That's why I think there should be a separate certbot command for just letting the Let's Encrypt servers know that I intend to stop using a particular cert and don't plan to renew it again. That way they don't have to do all the work of revoking it, just forget about it and don't issue expiration notices. In fact, certbot already sort of has such a command, certbot delete. I realize there might be reasons why you could want to delete a certificate from a machine and stop its auto-renewal and might want to still be notified about expiration, but it might be nice to have an option for certbot delete to also tell the server that the certificate is being deleted and you shouldn't expect it to be renewed. That way, even if Let's Encrypt does send an expiration notice, it can be worded differently as a reminder that you opted to let it expire instead of saying "Please make sure to renew your certificate" for one you may not remember you decided not to renew intentionally. Also, if I forget to use such a flag to certbot delete, it would be nice to have a similar link in the notification email that let's me opt out of further notifications for just that one cert.

And as for doing this when expanding a certificate, certbot could send the same request to the server to "delete" the old certificate as I'm proposing for certbot delete (with an explicit flag, of course). You say that the server can't tell that the request to issue a new cert with more domains is a replacement and not just a new cert, but my point was that certbot does know this because I identify the cert being replaced with --cert-name. So while it may not be sending enough info the server for it to know at the moment, it seems like it would be possible to add that information that certbot does know to the API so that this feature would be possible. If there's a better place for this feature request, so be it.

1 Like

I think that's an "all-or-nothing" subscription... So you can't pick and choose which emails to receive.

On the subject of revocations, I think it goes beyond the 90 day expiry.
Because that private key may no longer be allowed to get a new cert (ever); So it has to be "remembered" somewhere... for ever! - LOL

Now that seems like a reasonable request.
If certbot can detect the change, it should be able to relay that info to LE.
Please give me a new cert for "these names"... and by the way, it will be replacing this one: "Cert ID".

certbot delete doesn't do anything outside your own server. So, LE wouldn't know about the deletion.