It’s relevant, you can ask for certificates even it’s not for public usage.
Question is more "Why LE refuse issuing certs for HTTPS only system not able to use other challenge than http-01 ? ». DNS or SNI challenge require more dependencies and system invasion to be usable in production :
dns-01 : access to DNS server, no DNSSec enabled domain…
tls-sni-01: custom/customized httpd, fake vhost routing to the issuing machine…
and then, not everybody can be able to use them.
http-01 require no more (at least for HTTPS usage certs) than your already-in-usage httpd and your issuing machine is already OK to be join by LE backend (already serving necessary vhost and with correct routing from HA/reverse proxies eventually present, DNS already correct…).
In other words, http-01 is the only challenge you can be sure you can use if you already be able to deploy certs. Other challenges require things you have maybe no control.
Refusing to issue certs for HTTPS only domain is refusing to issue cert to people who can’t use other challenges.
You insist that http-01 is easier, but I’m telling you it isn’t for such a service at all. I understand probably most web servers you’ve encountered defaulted to serving up files from the local filesystem. Put something in a directory named .well-known/acme-challenge/ and Bob is your uncle, right? But our server doesn’t do anything like that. For it to serve up an http-01 challenge answer is no easier than to pass tls-sni-01.
The answer to your question (“Why LE refuse…”) is that in ACME testing they found many hosted HTTPS servers which would serve site A’s contents when asked for site B. This meant if http-01 was enabled for HTTPS then the owner of site A could impersonate site B as far as ACME is concerned, obtaining a valid certificate for site B even though they had no entitlement to such a certificate.
Undoubtedly these servers shouldn’t be set up that way, but they are. We can’t write security software for a world we wish we have, only for the world we do have. So http-01 isn’t safe against HTTPS servers.
Likewise, outside of ACME it was contemplated that surely an ordinary web server would never respond to a request for a well-known URL with a chosen string in it, with that exact string. For example, when asked for .well-known/pki-verification/47sd84f92kd03 why would it say “47sd84f92kd03” ? But in fact lots of them do, as a result of primitive SEO seeing and suchlike so the Baseline Requirements had to be tightened up to make it clear that’s not enough verification.
That exactly my point !
LE MUST allow maximum possibilities for cert issuing. If an infra can’t use DNS or SNI (it’s not lazyness but real technical no-go, like DNSSec), it must be able to use HTTP. As you have the possibility to use SNI because HTTP is not available to you…
I think that's a misconception. You cannot expect a project to take on the burden of supporting every imaginable scenario, especially if it has (like in this case) security implications for everyone else. Keeping things as simple as possible is an important concept in security. Let's Encrypt supports challenge types that work on port 80, port 443 and via DNS. TLS-SNI-01 is supported by apache and nginx (experimentally) as well as HAProxy (as @mcgurrin mentioned). Support for other web server software is just a matter of demand and someone implementing it, there's no technical reason it couldn't work.
You're asking this project to take on the burden of supporting a challenge type that poses a security risk to certain users because it's inconvenient for you to use any of the existing challenge types. I don't think that's reasonable.
We have seen previously potential subscribers who were frustrated because their free webhosting didn't include the ability to put files in .well-known/ so they couldn't pass http-01 for that reason. Under your "maximum issuance" approach doubtless you would let them put the response somewhere else?
We have seen people who couldn't figure out how to change the MIME type response to match what is required by ACME and so struggled with http-01 for that reason. Presumably again you would just remove this rule so that they can more easily get their certificate ?
As pfg has written "maximum possibilities for cert issuing" cannot be the rule at the expense of practical security. You could change your DNS arrangements to make dns-01 practical, you could choose a server that can pass tls-sni-01 but you've chosen instead to insist that http-01 requirements should be weakened. Any fix to cope with the "bad default HTTPS" behaviour we see in the wild is going to require the same sort of features as tls-sni-01, which already exists, so it's redundant.
I can’t, because of DNSSec with offline master. I can’t because no way to use customized not official build of httpd. I won’t weaken all my infra just because of cert issuing.
I just insist on the fact why HTTPS is not possible on HTTP-01 : very bad sys admin behaviour which must be eradicated from the Earth if even existing.
Even in HTTP-01 HTTP-only, multi-tenant infra is as weak as HTTPS HTTP-01, because infra sys admin can issue the cert he want for any tenants. And this is a real fact, not an alledged possibility of MitM by one of the other tenant. This is even a feature for all multi-tenant providers deploying Let’s Encrypt on the behalf of their customers.
Rejecting HTTPS because of very bad admin behaviour (and infra weak by default), it’s also refusing issuing cert for people with very high security usage (HTTPS only, HPKP, DNSSec, offline/air-gaped signing DNSSec master…) that should be the default security level today for most of parts.
Let’s Encrypt is in fact no more than all the others CA. Just a yet another plain old root CA, prefering supporting bad behaviour than taking action to enforce security or at least level-up the existing.
I’m thinking to go back to my plain old root CA, never be a problem to use all my security stack with them.
I wish you good luck getting this done. Once you've eradicated this widespread practice, I suggest coming back to the ACME draft group and saying you've fixed this problem and they can re-consider http-01 over HTTPS.
Or perhaps you expect everybody else to eradicate it for your convenience?
Let's Encrypt doesn't refuse to issue you a certificate any more than anybody else, you just have to prove your control and you're unwilling to do that, except, for some reason, by a means that some people are trivially able to spoof on other domains. If you weren't so vehemently in favour of bunker mentality security (air-gapped DNSSEC? really?) I'd be suspicious that you were trying to get this loosened so you could spoof people.
It is a bit weird to say you think Let's Encrypt is "supporting bad behaviour" by requiring a higher standard you can't meet any more and then to say you'll go back to paying a commercial CA that doesn't have such standards. What DV method were you using with your CA prior to Let's Encrypt? Email validation?
I personally don’t care about DV or EV validation, CA must die for DV and trust in general but I still need them to issue certs because DANE (and specially DANE-EE and DANE-TA) is currently implemented nowhere.
And HTTPS-DV problem reported on IETF ACME list was not a real problem if HPKP/DANE was deployed (mitm cert will be rejected).
@Osiris in theory there could be situatons where people have misconfigured default vhosts on HTTP. But that’s usually a very obvious and blatant, because most folks tend to test their domains over HTTP. The HTTPS situation is much more common because it can be an unintended side-effect of trying to enable HTTPS for a subset of the domains that a server answers over HTTP.