Now we have real demand for this, DNS over TLS/HTTPS will not work without
such certificates.
The issue used to be instantly closed following some obscure concerns about
validity of owner validation, which are obviously illegal for all http/ssh/ftp etc. methods.
I see not only no problems with validity, I see that it just will work with no modifications to acme
protocol. So, actually, the last and the most strong argument since 2017 was that it is no needed.
It is needed now.
The consequence of this limitation is to make client software to ignore(!!!) certificate validation,
or to add ugly kludges with static resolution of some names at client side. Well, to pay to digicert.com
like cloudflare.
Automating validating "ownership" of IP addresses is pretty tricky. IPs are now rented by the hour (or even by the second) by the large hosting "cloud" providers, plus there are plenty of IPs that multiple customers share all on one hosting provider's server. I almost think you'd need to add some kind of challenge token to the IP block's whois info, or something like a DNS-01 challenge but in the in-addr.arpa / ip6.arpa zones (which likely brings its own set of complications). Hopefully someone smarter than me can figure out how it will all work.
I'm not overly familiar with DNS-over-TLS/HTTPS (I use the dnscrypt protocol on my home network for now, and when I first heard of DNS-over-HTTPS it sounded like someone accidentally took RFC 3252 seriously though I suppose they do solve some pragmatic problems some people have), but I would think the solution in the meantime (if free IP-address certs aren't coming anytime soon) would be to have clients do something like public key pinning and include the public key along with the IP address to connect to? That's how dnscrypt solves the problem, at least.
FYI dns/tls is de facto standard in Android since 9. And dns/https is standard in google chrome. So, we just have to live with this and deal with this. Apparenlty, most of people use cloudflare dns there, which
uses digicert signed certificate. But it is still not an excuse to ban people who do not want to rely on cloudflare.
And there is no way to modify the procedure there or to use an alternative protocol. Luckily, right now it works when we use DNS name instead. Apparently, it uses usual insecure DNS at initialization, which is apparently is a huge hole which will be eventually fixed.
What's about IP address by the hour, I would avoid to use this as an argument. DNS names by hour
are just a lot easier and wide spreaded since yore. IP address allocation policy always used to be much more strict than one for DNS names. And virtual hosting is not an issue as well. IP altNames are used only by direct refs like https://a.b.c.d/, if such SNI is requested, it is obviously out of scope of virtual hosting by definition.
Earlier versions of the draft included a reverse-DNS challenge type. Within the
working group there were concerns raised about the accuracy of the reverse DNS
zone information that this challenge type relied on. A decision was made to
remove this challenge type from the draft to allow forward progress on the
remaining uncontroversial parts of the draft.
I personally don't think it's a good idea, but consider that e.g. ec2-*.*.compute.amazonaws.com is a blocked certificate domain.
The point being that the problem might be mitigated by policies on specific IP ranges without having to restrict validation methods.
If that's too whack-a-mole, maybe they'll just be OK with issuing certificates anyway, given that certificates are pretty short-lived anyway.
True, but no customer on a shared server should be capable of serving content directly from e.g. http://198.51.100.1/.well-known/acme-challenge/or installing an SSL certificate for https://198.51.100.1/ or responding to TLS-ALPN requests. They should only be able to serve content from domains in their account.
This should be verified in the real world, so we don't have another TLS-SNI on our hands. But as far as I know, that's a safe assumption in cPanel and Plesk.
... to never. I'm not the foremost expert in the area or anything, but isn't the purpose of a DNS A record to enable the lookup of ephemeral IP addresses. Doesn't certifying an IP address completely circumvent the value provided by the Domain Name System. In particular, I'm assuming that SNI goes out the window when certifying IP addresses. I suppose a port could be included if certifying full urls.
most web browser doesn't send SNI when connect to naked IP address, so it will see default host on that ip address.
but if they won't trust cert with IPadress because domain's A record resolve to that address.
so it's only valid in https context when browser connected to https://1.2.3.4
