I'm wondering if this issue is going to affect us on Virtualmin: https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and...
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.
Also interested in this!
If using this script or parts out of this example updated from that still problem could arise but don't know wich virtualmin uses https://community.letsencrypt.org/t/help-test-certbot-apache-and-nginx-f...
we strongly encourage people to move to HTTP or DNS validation rather than attempt to get on the TLS-SNI-01 whitelist.
For most people using the TLS-SNI validation method, moving to the HTTP validation method will be the easiest path forward.
But the http could have some probs ... when using certbot for example
plugin may not succeed in using HTTP-01 Challenges on webserversWe have arrived at the conclusion that we cannot generally re-enable TLS-SNI validation. There are simply too many vulnerable shared hosting and infrastructure services that violate the assumptions behind TLS-SNI validation. We will be executing the following plan to mitigate impact and entirely sunset the TLS-SNI-01 and TLS-SNI-02 validation methods.FWIW, there doesn't seem to be an impact on Virtualmin -- I had no trouble creating a new Let's Encrypt cert for a new domain.
I guess I don't understand how Virtualmin does Let's Encrypt cert requests, but as long as it works, I guess I don't care either!