Let's Encrypt offers three ACME methods which implement 3.2.2.4.6 ("Agreed Upon Change to Website"), 3.2.2.4.7 ("DNS Change") and 3.2.2.4.10 ("TLS Using a Random Number").
Where can I find these details? Sorry if I'm being a bit dense here.
https://cabforum.org/baseline-requirements-documents/
In recent years the BRs are using RFC 3647 structure. This RFC gives an outline for how to write policy documents for PKIX (X.509 Public Key Infrastructure for the Internet) and rather than wrestle with each organisation having its own preferred way to organise much the same information the trend is to require RFC 3647, so you know the stuff about names will be in section 3 for example
The RFC 3647 structure doesn't break down as far as 3.2.2.4 but 3.2.2 is where people explain how they're going to validate organisation names, and so in the Baseline Requirements 3.2.2.4 is where the "Ten Blessed Methods" are described, the authorised means by which public CAs can determine if the name you want a certificate for is really yours.
But it turns out cheap bulk hosting sites, especially using Apache HTTPD often did this because it worked fine by default.
The symptom for ordinary users would be you try to visit https://cat-videos.example/ and it gives a certificate error saying the site has a certificate only for aaa-microwave-repairs.example do you want to continue? If you say "Yes" you get an error page. Eventually you remember it was http://cat-videos.example/ no need for the 's' and that works. Weird but ultimately harmless.
What has happened is the Microwave repairs people paid for working HTTPS, with a valid certificate for their name, the Cat Video people didn't bother. But both set the bulk hosting site as the correct IP address for their servers.
Now, when you connect to that IP address and ask for cat-videos.example using SNI, the remote server should go "Er, no?" and you just get an error. But Apache's default behaviour instead figures you want the default web site and default certificate, which will typically be alphabetically first on that server.
This destroys the security assumptions for tls-sni-01, because "it's safe unless people use cheap bulk hosting" is essentially identical to "it's not safe" and getting Apache to fix things was too late. Bad guys could sign up for a bulk host used by their target for non-TLS sites, and add a bogus site named like aaaaaaa.bad-guys.example and use this to attack the target with tls-sni-01 challenges.
So, the replacement ACME challenge doesn't rely on SNI it uses ALPN instead. Also some people actually tested to check that Apache isn't also dumb enough to go "Um, I don't recognise this ALPN, I guess that means I should press on anyway and cause breakage" which fortunately it is not.
Unless someone successfully preforms a MITM attack on letsencrypt but then all bets are off.
To summarize TFA: lets encrypt is now verifying domain ownership from multiple data centers. The idea being if someone tries to mitm the verification process (through bgp hijacking or whatever) its much harder to do that across the entire internet and go unnoticed then it is to do it on just one network path