Free and open Certificate Authority (CA) Let’s Encrypt on Tuesday disabled TLS-SNI-01 validation after learning that users could abuse it to obtain certificates for domains they do not own.

The issue was found to have been created by the use of the ACME TLS-SNI-01 challenge type for domains on a shared hosting infrastructure. Discovered by Frans Rosén of Detectify, the bug could be abused for malicious purposes, which sparked Let’s Encrypt to disable TLS-SNI-01 validation entirely.

The issue doesn’t appear to be related to the certificate authority itself, but to a combination of factors. However, it is centered on the manner in which the ACME server (the CA) validates a domain name’s IP address as part of ACME protocol’s TLS-SNI-01 challenge.

As part of the process, a random token is generated. The ACME client uses it to create a self-signed certificate with an invalid hostname (.acme.invalid) and configures the web server on the domain name to serve the certificate, after which it looks up the domain name’s IP address, initiates a TLS connection, and sends the specific invalid hostname, awaiting to receive a self-signed certificate containing that hostname as response.

When that happens, “the ACME client is considered to be in control of the domain name, and will be allowed to issue certificates for it,” Josh Aas, Internet Security Research Group (ISRG) Executive Director, explains.

However, when more users are hosted on the same IP address, which happens with large hosting providers, and these users also have the ability to upload certificates for arbitrary names without proving domain control, the assumptions behind TLS-SNI are broken and an attack is possible.

Thus, if an attacker controls a website hosted at the same shared hosting IP address as a legitimate site, the attacker can run an ACME client to get a TLS-SNI-01 challenge, and obtain an illegal certificate for the legitimate website.

The attacker would simply install their .acme.invalid certificate on the hosting provider, which will serve it to the ACME server when it looks up the legitimate website. Next, the ACME server will consider the attacker’s ACME client as being authorized to issue certificates for the legitimate website, and the attack is successful.

“This issue only affects domain names that use hosting providers with the above combination of properties. It is independent of whether the hosting provider itself acts as an ACME client. It applies equally to TLS-SNI-02,” Aas explains.

Let’s Encrypt disabled TLS-SNI-01 immediately after becoming aware of the issue, but plans on restoring the service as soon as possible, given that a large number of people and organizations use the TLS-SNI-01 challenge type to get certificates. However, they won’t enable it until they consider it sufficiently secure.

“At this time, we believe that the issue can be addressed by having certain services providers implement stronger controls for domains hosted on their infrastructure. We have been in touch with the providers we know to be affected, and mitigations will start being deployed for their systems shortly,” Aas notes.

Let’s Encrypt is also working on creating a list of vulnerable providers and associated IP addresses and to re-enable the TLS-SNI-01 challenge type with vulnerable providers blocked from using it.

Related: Let's Encrypt Wildcard Certificates a 'Boon' for Cybercriminals, Expert Says

Related: Let's Encrypt Issues 15,000 Fraudulent "PayPal" Certificates Used for Cybercrime