Let’s Encrypt allows subscribers to validate domain control using any one of a few different validation methods. For much of the time Let’s Encrypt has been operating, the options were “DNS-01”, “HTTP-01”, and “TLS-SNI-01”. We recently introduced the “TLS-ALPN-01” method. Today we are announcing that we will end all support for the TLS-SNI-01 validation method on February 13, 2019 [February 13 will be a brownout date. We’ll re-enable TLS-SNI-01 after a week, then disable permanently on March 13].
In January of 2018 we disabled the TLS-SNI-01 domain validation method for most subscribers due to a vulnerability enabled by some shared hosting infrastructure 1.8k. We provided temporary exceptions for renewals and for a small handful of hosting providers in order to smooth the transition to DNS-01 and HTTP-01 validation methods. Most subscribers are now using DNS-01 or HTTP-01.
If you’re still using TLS-SNI-01, please switch to one of the other validation methods as soon as possible. We will also attempt to contact subscribers who are still using TLS-SNI-01, if they provided contact information.
We apologize for any inconvenience but we believe this is the right thing to do for the integrity of the Web PKI.
Update 2019-01-23: If you are using Certbot, read these step-by-step instructions
2018.01.11 Update Regarding ACME TLS-SNI and Shared Hosting Infrastructure
Please see the following information for background information.
The last 48 hours have been a busy time for Let’s Encrypt staff. We’ve been working hard to come up with a plan for ACME TLS-SNI validation that sufficiently protects the integrity of Web PKI while minimizing problems for people and organizations using TLS-SNI validation for HTTPS deployments. We’d like to thank our community and partners for the incredibly helpful input we’ve received.
We have arrived at the conclusion that we cannot generally re-enable TLS-SNI validation. There are simply too many vulnerable shared hosting and infrastructure services that violate the assumptions behind TLS-SNI validation. We will be executing the following plan to mitigate impact and entirely sunset the TLS-SNI-01 and TLS-SNI-02 validation methods.
TLS-SNI Validation Will Remain Disabled For New Accounts
The ACME TLS-SNI-01 validation method will remain disabled permanently for new accounts by default. Since the same problems apply to TLS-SNI-02, TLS-SNI-02 will remain disabled in our upcoming ACMEv2 API endpoint.
Mitigations for Existing TLS-SNI Users
Our recommendation for users is to begin a migration to the HTTP-01 or DNS-01 validation methods. We are working to provide a reasonable amount of migration time for as many users as possible, while maintaining our commitment to security.
We will implement renewal-only validation through TLS-SNI-01, based on account credentials. That is, if a given account has previously issued a certificate with Let’s Encrypt for a domain name we will allow that account to revalidate and reissue using TLS-SNI-01 for that domain name for a limited time (to be determined).
We will maintain a short-to-medium term whitelist based on ACME account IDs and/or stable validation IP address ranges that will allow us to enable TLS-SNI-01 validation for large providers (10k+ active certificates) that are not vulnerable to exploitation. Please understand that since we have limited staff resources to build and maintain this whitelist, we strongly encourage people to move to HTTP or DNS validation rather than attempt to get on the TLS-SNI-01 whitelist.
For most people using the TLS-SNI validation method, moving to the HTTP validation method will be the easiest path forward.
ACME Client Updates
We are working with ACME client developers whose clients rely on TLS-SNI validation to get updates out as quickly as possible. The Certbot client expects to have an update out within the next few days.
ACME Protocol Updates
We will engage with the IETF ACME working group to decide the future of TLS-SNI validation and remediations to the discovered problems.