Love the service. It’s a great boon to the web at large.
I like the reminder emails about certificate expiration, but I was wondering if a tweak is possible? Could the notifier not send out emails when the expiring certificate has been replaced by a expanded (extra domains added) certificate that is still valid?
Let’s say I get a cert for www.foo.com. I use it for a while, and then expand the cert to add mail.foo.com. I now have one cert for www.foo.com and mail.foo.com. I will get an expiration email about the original www.foo.com cert, even though the new cert is still valid.
Thanks for the help and keep up the good work.
There is no method to tell which certificate is relevant for you from the CA’s point of view. If you are sure your certificate has been renewed correctly, just ignore the notification e-mails.
See Ability to silence email notifications for a particular cert for another thread on that.
1 Like
Thanks for the reply.
When processing the certificate expansion, wouldn’t it be possible to flag the previous cert as “superceded” and not issue email notifications for those certificates?
Currently the protocol that Let’s Encrypt uses doesn’t have a mechanism to assert relationships between certificates.
@jsha, have we discussed this before? Do you think it would be useful to have a way to assert that a certificate request is related to a previous one (e.g., an intent to replace an old certificate) for expiry warning purposes? Or is it impractical for the CA to attempt to keep track of this?
I understand it’s not currently implemented.
Should I open this discussion here, or is this a certbot/ACME issue? I’m unsure if this would be something letsencrypt should track, or code that should be in certbot, or if the best place to address this is the ACME spec.
If this is the wrong forum, I apologize and will head to the correct place.
I think it would be an ACME issue, at least in part.
The approach I’ve been wanting to take is to change this mechanism from warning about certificates to warning about domain names that will soon expire from all certificates. So if you expand a certificate there would be no warning, and if you remove a name from a certificate, you would get a warning only about that name. However, this needs some engineering work, and isn’t a priority at the moment. If someone here would like to work on it, I’d be glad to walk you through the code.
2 Likes
So this would change the expiration check to per domain from pet certificate?
Yes, though it would also group by account and by day, so you would not get a hojillion emails if you had a lot of domains expiring. 
I think this is a great idea. Any way I can help?
Are you proficient in Go? If so, I can show you what needs to change in the code. There’s an indexing optimization we’d probably need to get done first.
Proficient would be a very, very large stretch. I’m only comfortable in C. I’ll leave it to those with applicable skills instead of learning a language while updating a live repo!
Agree with everything that has been said, but would like to note that the release of wildcards seems like it might amplify this problem further.
In our client we opted not to attach an email to the ACME account registrations and to handle renewal emails ourselves, but it would have been great to not do this to have some templating ability for the Let’s Encrypt emails, on a per-account/ & certificate level:
- Unique instance ID nominated by the ACME client
- Allows ACME provider to suppress irrelevant emails, as mentioned
- Allows user to directly reference that particular certificate in their client
- Short description of the “location” (server hostname, ACME user-agent, link to client docs perhaps)
- Avoid user confusion which is often only solveable by comparing installed cert’s notAfter side-by-side with the email and trying to guess/remember what you/some other person did to get setup in the first place.
Granted, email templating may raise some phishing concerns, since the emails are not double-opt-in.
Not to complicate things, but this may also be more difficult than I first thought.
- Get cert for www.foo.com - www Cert expires in 90 day
- One month later expand cert to include www.foo.com and mail.foo.com - www expires in 60, new www & mail in 90
- One month later move www server to different host
a. get www cert on new host
b. issue mail-only cert on old host.
You’re left with a www cert that expires in 30 days, a combined www & mail cert 60 days from expiration and two brand-new certs, separately for www and mail.
How would the notification process go? Certificate expansion would know the www & mail cert (2) supercede the original www cert (1), but the new www cert (3a) would have no ties to the 2nd certificate, because the shrunk mail issuance (3b) would be issued to different machines.
The more I think about it, this seems like a rabbit hole. There exist many different things to keep track of, and wildcard certificates are coming January. Once that rolls around, one needs only:
# deploy-hook.sh
scp "/etc/letsencrypt/live/foo.com/*" otherhost:"/etc/letsencrypt/live/foo.com"
It may still be useful to get into this, but I’m unsure the effort is worth the result. My issue will be resolved once wildcards are issued.
As mentioned in the other thread, revoking a cert will silence all notifications about it. Perhaps a simple --revokeOldOnSuccess switch for certbot would neatly solve the problem for anyone who uses certbot with a supported server (like Apache or nginx), or with a post-hook that can return success or failure. In other cases, print a warning telling the user to revoke the old certificate manually once the new one is installed.
Doesn’t certbot’s revoke command require the certificate to revoke? I’m not sure, but isn’t that certificate overwritten upon renewal/expansion? Or does it keep old copies lying around?
If not, is there a way to tell certbot to keep the old certificate? Barring that, one could copy the old cert to a temp directory in a pre hook, and revoke it in the deploy hook.
/etc/letsencrypt stores a full archive of all past certificates (and CSRs).
OK so a hook to revoke cert n-1 upon renew would be all that is required, or a certbot option as previously mentioned. Ill add revocation to my deploy hook.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.