I received an e-mail purporting that two names were coming for renewal within 1 day, then within 0 days (i.e. expired).
This is an odd (and new) behaviour as previously there would be a 30 day warning.
In this mail, there were two names listed. But the active cert has 16 names.
My assumption is that the command
./letsencrypt-auto certonly
has generated certs with a variety of names and numerical suffixes (various testing, errors and multiple submissions lead to such a situation). Each one the spawns its own mailer service.
*1 is this assumption correct?
2* a suggestion
If assumption correct, without getting into complicated management rules, at the very least the mail should indicate the certificate name, chain and path. Thus the server admin can verify against nginx/apache configurations.
If I remember correctly, the expiration mailer currently determines whether a certificate has been renewed by checking whether there's a more recent certificate that covers the exact same set of domain names. This would explain why the new certificate with 16 names (which I assume includes those two domains) didn't count. It doesn't explain why you only got a 1-day and 0-day notice (unless it's a spam thing) - I'll do some more thinking on that.
I like the idea of adding something that would identify the certificates uniquely, so that server administrators aren't left wondering which certificate the mail is referring to. It'll probably have to be the serial number, as the server has no way of knowing the path the certificate is stored at (I'm assuming that's what you meant?). It might even be a link to crt.sh, which would show the full details included in the certificate.
It's a bit tricky because one expiration mail could be referring to multiple certificates, but it can be done.
“the server has no way of knowing the path the certificate is stored at (I’m assuming that’s what you meant?)” well, when the cert installs via certonly, it determines a path. Should that not be associated with the mailer routine?
Whatever the solution, my assumption is based on servers with somewhat frequent changes in 3LD changes: the administrator would want to have a quick method for checking.
That's a client functionality, and it's specific to the particular client you're using. Other clients might work completely different, or might not store the certificates in a regular filesystem at all. The CA server shouldn't make any assumptions on that matter.
Incidentally, this partially explains why the interface to certonly changed recently by offering webroot and standalone options… that got me confused a bit as well.
webroot was, to my knowledge not to be used in production; that may have changed. May I suggest that the community digest have leading items that deal with changes like this?
I haven't heard that before - do you know why it's supposed to be bad for production?
I used webroot since it didn't require me to shutdown the webserver (standalone does) and didn't mess with my configurations (the --apache and --nginx plugins do).
Read it in the posts in this community. Naturally Murphy impedes me to find the origin in browser cache and searching hasnot identified it quickly. I may have misread…
It may also have been in a comment during the closed beta, perhaps for one of the earliest clients. No matter, I completely believe that’s the sort of thing that would have been said last year before Let’s Encrypt went public.