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 [edit: 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. 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.
To help people test their clients ahead of the deprecation date, we’re going to disable the TLS-SNI-01 method in staging on 2019-01-22 (this Tuesday). Once that’s live we’ll post an update here, and you’ll be able to run certbot renew --dry-run, which will do a test against staging. If the dry run succeeds, you’ll know that you’re ready for the deprecation date.
Update: As of now, the staging environment has TLS-SNI fully disabled. We’ve also disabled the “reuse valid authorizations” feature in staging for the next 30 days. This will ensure that each staging dry run issuance does a fresh validation, so you can be confident that if validation in the staging environment succeeds, your client is working correctly.
Also, we’re changing the final end-of-life date for TLS-SNI in production to March 13, 2019. This will give more people time to update. We’re going to use the original February 13 date as the beginning of a brownout period: We will disable TLS-SNI validation in production on February 13, then re-enable it a week later. We may choose additional brownout periods before the final deprecation.
The goal of the brownout periods is to catch the attention of people who may have missed the notification emails. Not every certificate will necessarily renew during that window, but hopefully enough it will increase the number of people who notice and can update ahead of the deadline.
The brownout window has begun: as of ~2019-02-13 23:30 UTC, TLS-SNI-01 is disabled in production. We plan to leave it disabled for a week, then re-enable it on February 20. We will disable it finally on March 13th.
As any FYI: due to a Boulder bug, authorizations created before March 13th that are still pending can still be validated using the TLS-SNI method. Our pending authorizations expire after 7 days, so we are going to let these authorization objects age out of the system. That means that between March 13th and March 20th we will still be doing a very small number of TLS-SNI validations, but it is not something that a client can specifically opt into.