Is it possible to have the public key fingerprint, or some other unique identification of the affected certificate, on the automatic expiry email?
If a new certificate has been issued with a similar subset of names I get quite alarmed by the automatic expiry emails for the old ones. Checking the expiry date of the current cert doesn’t always reassure that the other cert is being incorrectly expired. It would be useful if the specific certificate was identified.
It seems like using the public key thumbprint should be safe and easy as it’s public anyway and so wouldn’t leak any account details.
That would work for me. Technically serial numbers don’t need to be unique if they changed the issuer cert at some point in the future, but very unlikely to collide on an individual account.
Why not add both fingerprint and serial? Both public and useful.
The public key thumbprint is not unique either. Some clients do reuse the same certificate key across renewals, even if Certbot does not (without --reuse-key, anyway).
The current FQDN list + expiry date is enough to identify the certificate, but I agree that it is not very friendly and that too many users get surprised by it.
I think instead, a fix like https://github.com/letsencrypt/boulder/issues/4702 would be a better long-term solution. Simply not sending any email unless there is a reduction in domain coverage, and being much more clear about which domains have lost coverage.
I have the scenario where I have multiple certs for https with names which overlap with names which are being used for SMTP TLS in a different cert. Some of the http certs may have less names than they used to as they now have their own SNI cert or separate server, but some of those may still need to be on the SMTP cert (and visa-versa ;)). So I can’t instantly identify the cert from the names and expiry on the email in a way that doesn’t initially freak me out.
I also sometimes manually renew a cert then copy it during a server move as a stop gap and then issue a new one on the new server, so renewal dates can be same day withe same names and new server cron is untested…
https://github.com/letsencrypt/boulder/issues/4702 is a good idea, but doesn’t work with multiple certs with the same names and unknown expiries. I might represent an edge case, but won’t be alone given the number of users.
In terms of a simple all around solution eliminating extant names as per #4702 may require a more complicated separate database batch job to implement, whereas one would have thought that the certificate properties, such as serial and/or fingerprint, would be readily accessible to the current email batch and so more trivially implemented and perhaps get done more quickly. The latter would also help in my scenario.
For me, if I have a unique id on the email that can make a script with openssl to quickly scan for then I’d be happy. If it turns up duplicate serials or thumbprints then that’s easier to investigate than having to check all subject alt names on multiple certs to see what I’m dealing with. If --reuse-key is used I should still be finding the worrisome one. I think we are looking at a very low probability of collision anyway, versus insufficient information to disambiguate certs currently.
I hope for security letsencrypt wouldn’t have a hash or anything other than key size on the private key, so would have to be public cert info for this. So I don’t think you could use a finger print of the whole cert/key. Is hashing the other key meta data to produce another fingerprint not likely to have the same probability of collision as the finger print itself?
There’s probably more entropy in the fingerprint than serial to avoid collision, but yes the serial “should” be unique. Why not both though, in small at the bottom of the email?
True, the expiry mailer can't be all things to all people. You can't guess whether a certificate matters or not without actually getting in the user's head.
If it comes down to a choice, I think that the mailer should cater to the most common use cases. The "I got an incorrect expiry reminder for a certificate which I expanded" is a daily thread here.
I rely on monitoring every SSL endpoint rather than looking at the emails. There's no room for interpretation that way because you only watch the certificates actually in-use.
I think doing exactly that is fairly common. Certificate fingerprints are a thing, which are just a hash over the entire DER-encoded certificate.
Your browser shows it in its certificate UI, and OpenSSL exposes it as well:
Boulder stores and queries the fingerprint already, so I don't think it'd be a big burden on them to change the email template to include a serial and/or fingerprint, if they wanted to.
I just don't really rate this method of monitoring. Look at the dates on your real endpoints, not the dates of possibly stale and unused certificates in some remote database. The advice on the expiration email page suggests as much:
If you check the certificate currently running on your website, and it shows the correct date, no further action is needed.
That said, if the mailer isn't going to get a major facelift any time soon, including the serial gets my vote. Things might be a bit tricky if there's multiple duplicative certificates expiring, though.
The big issue is that most people coming to LE for personal or SME sites don’t have the kind of infrastructure to monitor all of that; if they’re security conscious at all, they log in every week or three to run updates, or when an email about a critical patch or expiration is going to happen. I know this confused the hell out of me when I first started with LE, and I think one of my first posts was about it.
That said, I’d vote for a link to the FAQ to set up automated renewal to be put in the email. Fingerprint or serial would also be very helpful, but for the same reasons above, might not be as helpful as you’d expect to people who only monitor their certs on an ad-hoc basis.
I do not think that people who has a lot of certificates with partially overlapping domains at different places should rely on certificate renewal e-mail notification. It is preferable to have an automation in place for the renewal itself. Maybe an extra script, which sends notification if the expiry date is nearer than it supposed to be already renewed?
Another possible option is to fingerprint the modulus of the Certificate. The modulus is shared with the PrivateKey, so it won't work for people who recycle the PrivateKey – but almost every client is set to rotate the PrivateKey.
In our installs, and my client, I track the modulus fingerprint of the PrivateKey and Certificate. I just find it a much easier way to search for data sometimes.
A fingerprint of the public key should also include the public exponent e. In any case, modulus only really makes sense for RSA keys. So let’s better talk about public key fingerprints, they are at least standardized.
SMTP is potentially transmitted in the clear, I think you’d have to risk assess sending any non public information in the email and I don’t think we need to; the fingerprint and serial are already public in the cert. I’m really not worried about possible duplicate SHA256 fingerprints as it is still going to identify which key to look at in that unlikely scenario, it will be better than the current situation. Serial looks to be unique in db and is already read into an array in the code for the debug log and is shorter…
I have third party monitoring on my endpoints and a script that scans all certs on the filesystem, but if I get an email indicating a certificate with one of my client’s domains name on it is going to lapse I have a duty of care to check it’s all good. Newer users using shared hosting control panels may have more trouble identifying what’s going on, although whether any further detail on the email would help them is uncertain.
It would be nice to have the email be the best for all users though, I thought sticking the extra details down at the bottom wouldn’t hurt.
We recommend renewing certificates automatically when they have a third of their
total lifetime left. For Let's Encrypt's current 90-day certificates, that means
renewing 30 days before expiration. See Integration Guide - Let's Encrypt for details.
This para isn't in the github repo and so I'm not sure who has control to customise this?
The integration guide link doesn't really point someone straight at the FAQ which seems like a good idea.
Would it work for you If the email clearly stated at the top a which domains that would no longer be covered or a statement indicating they are all present on another cert (in addition to the complete list further down)?
If I did a patch to add the dates, thumbprints and serials of the affected certificates right at the end of the email would anyone be interested in reviewing it on github in anticipation of a pull request?
