I’m wondering if this issue is going to affect us on Virtualmin:
Does anyone know the details of how the module is requesting certificates within Virtualmin?
to summarize from the posting:
In the ACME protocol’s TLS-SNI-01 challenge, the ACME server (the CA) validates a domain name by generating a random token and communicating it to the ACME client. The ACME client uses that token to create a self-signed certificate with a specific, invalid hostname (for example, 773c7d.13445a.acme.invalid), and configures the web server on the domain name being validated to serve that certificate. The ACME server then looks up the domain name’s IP address, initiates a TLS connection, and sends the specific .acme.invalid hostname in the SNI extension. If the response is a self-signed certificate containing that hostname, the ACME client is considered to be in control of the domain name, and will be allowed to issue certificates for it.
However, Frans noticed that at least two large hosting providers combine two properties that together violate the assumptions behind TLS-SNI:
Many users are hosted on the same IP address, and Users have the ability to upload certificates for arbitrary names without proving domain control.
When both are true of a hosting provider, an attack is possible…
Shortly after the issue was reported, we disabled TLS-SNI-01 in Let’s Encrypt. However, a large number of people and organizations use the TLS-SNI-01 challenge type to get certificates. It’s important that we restore service if possible, though we will only do so if we’re confident that the TLS-SNI-01 challenge type is sufficiently secure.