March 13, 2019: End-of-Life for All TLS-SNI-01 Validation Support

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.

Update 2019-01-23: If you are using Certbot, read these step-by-step instructions.

Upcoming TLS-SNI Deprecation in Certbot
Issue to renew?
What's the status on TLS-SNI-01 challenge
Nginx certbot switch back to tls-sni-01
Strong credibility of a vulnerability with TLS-SNI
"Your Let’s Encrypt client used ACME TLS-SNI-01..." Which one?
Your Let’s Encrypt client used ACME TLS-SNI-01 domain validation to issue a certificate in the past 60 days
Unable to auto renew certificates
Action required: Let's Encrypt certificate renewals
New letsencrypt auto-renewal is trying to us port 80 rather than 443
Errors on renewing using apache plugin. Need to move from TLS-SNI-01?
Your Let’s Encrypt client used ACME TLS-SNI-01
At my wits end, this simply doesnt work. SITE IS DOWN
Cannot renew my certificate
Synology TLS-SNI-01 End of Life Email?
How to renew for Dynamic DNS host with no port 80?
Certbot renewal failed
Auto-certbot renew failure with message about firewall
Letsencrypt-auto not working any more
Timeout during connect (likely firewall problem)
The server offers no ACME challenge that is configured for this MD. The server offered 'dns-01 tls-alpn-01 http-01' and available for this MD are: 'tls-sni-01
Acme challenges over HTTPS
TLS-SNI-01 validation is reaching end-of-life
Failed Authorization - Received 2 cerficate(s)
Apache becomes unresponsive when running certbot
Renew not work anymore
Strange renewal failure
Certbot failed to restart apache
"Error getting validation data"
Attempting to renew cert produced an unexpected error: The nginx plugin is not working; there may be problems with your existing configuration. The error was: NoInstallationError(). Skipping
Unable to auto renew certificates
Unable to find virtual host listening on port 80
Letsencrypt-auto not working any more
Haproxy / tls / renew not working
Automatically remove certificate if renewal fails
Wrong subjectAlternativeName with certbot dns-01 challenge
Certificate renewal fails
Problem with renewal of certificates
Acme client, certbot and very poor/confusing instructions
"Your Let’s Encrypt client used ACME TLS-SNI-01..." Which one?
Action required: Let's Encrypt certificate renewals
Concerns about: disable the “reuse valid authorizations”
The key authorization file from the server did not match this challenge
Action required: Let's Encrypt certificate renewals
TLS-SNI-01 website test
Timeout during connect (likely firewall problem)
DNS/CAA Error During Automatic Renewal
TLS-SNI-01 validation is reaching end-of-life
IMPORTANT: What you need to know about TLS-SNI validation issues
Please help the Certbot and Ubuntu teams with testing
SOLVED: renew dry-run error when no http:80 port available
The client lacks sufficient authorization :: Invalid response from

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.

We’re planning to send out a second round of notification emails with the updated information tomorrow.


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.


The brownout period is now over. TLS-SNI-01 is re-enabled in production. It will be disabled finally on March 13th.


TLS-SNI-01 is now completely disabled in production.


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.

1 Like