We’re a managed hosting provider and are processing the new requirements to use webroot authentication and I am wondering if there is anyway to get a list of domains/certificates associated with an email address.
We’re not otherwise keeping any inventory of LE certificates, and have been using a central email to track renewal failures when the auto renewal cron doesn’t work – we expect to be seeing dozens / hundreds in the coming weeks and I wanted to know if we there was anyway to generate a list of domains to get ahead of the issue.
There isn’t any way to retrieve a list of domains/certificates, either per email or per ACME account key.
If you have a list of domains you host and know a little SQL, you could query the crt.sh database for any certificates that are less than 30 days away from expiration.
In the future, it would be better to track failures when they happen client-side so you can deal with them ASAP. The e-mails don’t really contain any actionable information other than which domains to grep your logs for.
The emails alert us when a certificate approaches expiration because of a failure to renewal or some other reason, and this is currently about the only method we will be alerted to which domains are using certificates that need to be updated to the new method.
We of course track httpd failures and can spot check individual domain https failures but it’s not feasible nor desirable to test every ssl certificate that is deployed in our IP space.
I assume lets encrypt retains a database of email addresses and can return a list of domains associated to it, how else are they sending out emails from firstname.lastname@example.org? I understand if it’s not publicly available or even not available on request.
Perhaps you did not understand my question. Also it is far, very far, from ideal to wait for a failure before taking action, that is essentially the worst option.
Is there a way I can make a feature request for such a list?
@Patches is correct, we don’t have an automated way to look up certificates by email address or account URL. However, I assume you’re automatically renewing all your certificates every 60 days, right? What is the mechanism you use to determine which certificates need to be renewed? Does that mechanism allow you to list all the certificates you need test validation for?
Good on you for getting out ahead of the issue and testing revalidation early; thank you!
We’re a centos 6 environment and have followed the provided documentation. We’re running a daily cron that attempts to renew LE certificates, example cron:
12 5,17 * * * /sbin/certbot-auto renew --quiet
We use the same email for all new domains when we generate a LE certificate, and that been alerting us if some issue occurs that prevents the renewal from processing. We receive emails from email@example.com that alert us if a certificate is about to expire.
Thank you for the information jsha, it will be helpful when we audit for certificates.
Unfortunately we have installed LE certs across multiple systems, and which systems out of the many we maintain is not tracked.
I’ve been looking for announcements, but when will the courtesy renewal of existing TLS-SNI certificates come to an end?
Regarding firstname.lastname@example.org, would it be possible to develop a feature that does a dbquery for all certificates associated to an email and return that list to the email address? Could I write such a pull request, would that go here: https://github.com/certbot/certbot or some other place? Or is that not possible, is email@example.com outside the scope of certbot, but being used by it?
Thank you for taking the time to reply, much appreciated, and a big thank you developing letsencrypt, an increasingly vital service in a world where browser vendors have decided https everywhere is necessary.
The Let's Encrypt team have not yet decided on a sunset date for TLS-SNI-01.
This would be a feature of Boulder, the Let's Encrypt server software:
Certbot is client software (one of many) that connects to the Let's Encrypt servers running Boulder. Usually code has to be added to it as well in order to take advantage of new features added to the server, though this might not be necessary in this case.
Before starting work on a new feature in software as complicated as Boulder, it's best to open an issue in their tracker to discuss whether they would accept a patch for it and the best way to implement it.