[mdhardeman]

But if you're a web post with 10k+ users, what's the problem with the HTTP-01 challenge?

You just allow .well-known/* to be passed on to reflect the challenge responses you've generated for the client, while 301 redirecting everything else to their https:// site.

I'm confused how that would be harder for a web host at that scale?

EDIT: I get people trying to run a server off their cable modem / rtr public IP, and 80 might be taken by something other than the target the port forward for 443 is going to -- and that's a problem for those use cases -- but that kind of concern wouldn't exist in a significant hosting infrastructure.

[merb]

I would say the .well-known/ is actually easier. one could just create a nginx (or somehow in haproxy) backend that will actually load the data to generate the cert from a trusted store. (I mean no user will probably use the .well-known endpoint (hopefully))

after that it could actually just put the cert into that store again and reload all public facing webservers

[will_hughes]

> what's the problem with the HTTP-01 challenge?

Nothing, yet.

But who's to say that another similar bug won't be found in common shared-hosting platforms that forces LE to turn that challenge off too?

[mdhardeman]

True.

Because almost all of the CAs utilize a web control mechanism, with many of them probably having processes not as rigorous as HTTP-01, it is likely that there would be significant backlash and a lengthier migration away from the method for that case.

That said, anyone who can would be well advised to figure out how their DNS based mechanism would work if it were ever needed.

As I and others have pointed out, there are clever and fully supported hacks for validating dns-01 without dynamic control of the full domain zone. (CNAME to another zone for the _acme-challenge labels, NS delegation to refer each _acme-challenge label as an independent zone at a different NS, etc.)