This just in via email from email@example.com. More information is available here: https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811
Cloud provider vulnerability causes Let’s Encrypt to disable SNI domain validation
A major issue with some cloud providers allowed the unauthorized issuance of Let’s Encrypt certificates. Although the issue clearly lies with the cloud providers, Let’s Encrypt nevertheless has decided to disable the corresponding validation method.
Frans Rosén discovered that he could use the SNI validation method from the ACME protocol (https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/) to issue certificates for domains hosted on certain cloud providers. He explicitly mentions Heroku and Amazon CloudFront.
TL;DR: I was able to issue SSL certificates I was not supposed to be able to. AWS CloudFront and Heroku were among the affected. The issue was in the specification of ACME TLS-SNI-01 in combination with shared hosting providers. To be clear, Let’s Encrypt only followed the specification, they did nothing wrong here. Quite the opposite I would say.
The core of the issue is that these providers allow users to upload certificates that the system will serve automatically to TLS requests with the corresponding server name. The ACME SNI validation method uses temporary certificates that end with .acme.invalid.
After the issue was reported, Let’s Encrypt almost immediately disabled the TLS-SNI-01 validation method. Let’s Encrypt subsequently decided that, with a few exceptions, it will stay disabled. The newer TLS-SNI-02 method is vulnerable as well. A new TLS-SNI-03 method that considers this problem is being developed, but for the time being users should switch to either the HTTP or the DNS validation method.