Note: Clients may address at least some of these, though not the distributed coordination related ones.
See Also: EFF: A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation
Note that putting your full DNS API credentials on your web server significantly increases the impact if that web server is hacked. Best practice is to use more narrowly scoped API credentials, or perform DNS validation from a separate server and automatically copy certificates to your web server.
The best DNS APIs provide a way for you to automatically check whether an update is fully propagated. If your DNS provider doesn’t have this, you just have to configure your client to wait long enough (often as much as an hour) to ensure the update is propagated before triggering validation.
However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.
See Also: Ending Support for Expiration Notification Emails coming into effect June 4, 2025
We recommend that you rely on your ACME client to automatically renew your certificates, and only use these expiry notices as a warning to check on your automation.
If your certificate is already renewed, we won’t send an expiry notice. We consider a certificate to be renewed if there is a newer certificate with the exact same set of names, regardless of which account created it. 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.
The email body has a link to unsubscribe from future notices. If you hit that link, you won’t get any expiration notices for the next year.
Note that your unsubscribe is only valid for one year, so you will have to renew it every year.
There’s not yet a way for us to efficiently re-subscribe you if you unsubscribe.
Let’s Encrypt is run by a small team and relies on automation to keep costs down. That being the case, we are not able to offer direct support to our subscribers.
We ask that ACME clients perform routine renewals at random times to avoid spikes in traffic at set times of the day, such as exactly midnight UTC, or the first second of each hour or minute. When the service is too busy, clients will be asked to try again later, so randomizing renewal times can help avoid unnecessary retries.
You should make sure you have the ability to easily update all services that use Let’s Encrypt.
You will also want a way to keep your TLS configuration up-to-date as new attacks are found on cipher suites or protocol versions.-
However, for most larger hosting providers we recommend using a single account and guarding the corresponding account key well. This makes it easier to identify certificates belonging to the same entity, easier to keep contact information up-to-date, and easier to provide rate limits adjustments if needed.)
However, if you have infrastructure that may repeatedly create new frontends for the same website, those frontends should first try to use a certificate and private key from durable storage, and only issue a new one if no certificate is available, or all existing certificates are expired.
This type of problem isn’t unique to rate limits, though. If Let’s Encrypt is unavailable for any reason when you need to bring up your frontends, you would have the same problem.
Additionally, when using the dns-01 challenge, make sure to clean up old TXT records so the response to Let’s Encrypt’s query doesn’t get too big.
Related to the above two points, it may make sense, if you have a lot of frontends, to use a smaller subset of servers to manage issuance.
Our recommendation is to serve a dual-cert config, offering an RSA certificate by default, and a (much smaller) ECDSA certificate to those clients that indicate support.
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.
You should implement graceful retry logic in your issuing services using an exponential backoff pattern, maxing out at once per day per certificate.
you and your new customer should use the DNS-01 validation method to issue a certificate before the customer switches over DNS for their site.
The CNAME method means even if it takes your new customer a month to make the needed changes to their DNS, you can get things up and running as soon as they do.
Another reason to prefer the CNAME method over having new customers directly provision their TXT records is to support the best practice of periodically rotating your ACME account key. Because the digest value used for DNS-01 validation is computed based on your current ACME account key, it will change whenever you rotate your account key.
If the customer has left behind a CNAMEd _acme-challenge subdomain that points at you, you should contact that and remind them to delete it.
Similarly, if a customer sets up the CNAME and you issue a certificate on their behalf, but they never point their A records at your servers, you should not reissue new certificates indefinitely without further intervention from the customer.
Renewals coordinated by ARI offer the unique benefit of being exempt from all rate limits. Clients that support ARI periodically check with Let’s Encrypt servers to determine if your existing certificate should be renewed. When the optimal renewal window is reached the client requests a new order explicitly indicating the certificate it replaces. If the new order includes at least one hostname matching the certificate it intends to replace and the certificate has not been previously replaced using ARI, the order will not be subject to any rate limits.
If you are a large hosting provider or organization working on a Let’s Encrypt integration, we have a rate limiting form that can be used to request higher rate limits. It takes a few weeks to process requests, so this form is not suitable if you just need to reset a rate limit faster than it resets on its own.
When a certificate is no longer safe to use, you should revoke it.
If you originally issued the certificate, and you still have control of the account you used to issue it, you can revoke it using your account credentials.
If someone issued a certificate after compromising your host or your DNS, you’ll want to revoke that certificate once you regain control. In order to revoke the certificate, Let’s Encrypt will need to ensure that you control the domain names in that certificate (otherwise people could revoke each other’s certificates without permission)!
Note that most ACME clients combine validation and issuance, so the only way to ask for validations is to attempt issuance. You can then revoke the resulting certificate if you don’t want it, or simply destroy the private key.
Once you’ve validated control of all the domain names in the certificate you want to revoke, you can download the certificate from crt.sh, then proceed to revoke the certificate as if you had issued it:
If you did not originally issue the certificate, but you have a copy of the corresponding private key, you can revoke by using that private key to sign the revocation request.