There's been a lot of discussion about this on the IETF ACME mailing list. Essentially, the issue is that certificates don't nominate a specific port, so if you can get a certificate for a hostname you can impersonate any service on it. Thus, any validation method needs to represent not only a single port, but the machine as a whole.
443 is not really ideal for this purpose, but requiring control of it is probably the least worst option, security-wise.
How about requiring control over DNS, like I suggested before?
Put a public key in the DNS, sign the CSR with the corresponding private key, the CA will fetch DNS, verify the signature, and then sign your certificate.
LE lets you get a cert by putting stuff in DNS, but it's generally hard for a program running on your Web server to modify DNS in an automated fashion and this tool focuses on what can be automated on your Web server.
If I could just put a public key in DNS, sign stuff with the corresponding private key, and send the signed request via POST to LE, then they can easily check that I control the DNS, and I can automate it (and never have to change the webserver’s content or DNS).
I've suggested this on the ACME list, actually; allowing people to put their ACME account public keys in DNS, rather than the random-per-transaction challenge specified right now, which is quasi-unusable.
The problem, apparently, is that CA forum rules require that a random challenge be used. Of course this doesn't make much sense in the context of ACME, where you have a private key identifying the user account. But this obstructs the specification of a deterministic challenge for DNS, alas.
443 is not really ideal for this purpose, but requiring control of it is probably the least worst option, security-wise.