On 2018-01-09 we got a report from Frans Rosén of Detectify that one of our three validation methods, TLS-SNI-01, could be used to get certificates for domains you don’t own, if those domains were hosted on software that allowed upload of arbitrary certificates. We immediately disabled TLS-SNI-01. Initially we thought this would be a temporary measure, but we later learned that a lot of hosting software has this issue. We’ve decided that TLS-SNI will remain disabled for most new issuances.
Renewals will continue to work with TLS-SNI, so if you only need to renew certificates, you don’t need to take any immediate action, but you should continue to keep your ACME client software up-to-date.
If you use Certbot in its automatic Nginx or Apache modes, you need to upgrade to version 0.21 in order to issue certificates for new domain names. If you use the
letsencrypt command, you are using packages provided by your operating system vendor, which are often slow to update. If this is the case, you should probably switch to
certbot-auto, which provides the latest version of Certbot on a variety of operating systems. Also note: If you block port 80 on your web server, upgrading to the latest Certbot will not fix your problem, because it switches to the HTTP-01 validation method, which uses port 80. I recommend opening port 80 and redirecting HTTP traffic to HTTPS.
The long-term plan is to remove TLS-SNI-01 and TLS-SNI-02 (which has the same problem) from the ACME spec. The IETF ACME group is working to develop a followup TLS-SNI-03 validation method (aka challenge) that solves the problem. You can participate via the mailing list. It will take significant time to standardize and implement TLS-SNI-03, so you should plan on using HTTP-01 or DNS-01 in the meantime. If you have good automation for your DNS servers, DNS-01 is a good option for two reasons: It works well even when you have multiple frontend servers, and future support for wildcard issuance will require DNS-01 validation.
Relevant previous posts: