Http-01: decouple proof of ownership from A-Record


#1

HTTP-01 requires control over the webserver that the A-Record points to. This may not possible for embedded devices and is not possible for devices not exposed to the internet. It is problematic if A-Record points to more than one address e.g. with geo-based DNS resolution.

DNS-01 requires automatic access to dns which is much more complex than http-01.

It would be great to allow the http-01 challenge to be located on a deticated server. This could be done by using a certain TXT or SRV record that points to a host or URI that should be used for the challenge.

Example:
_letsencrypt-acme-challenge-http-01 IN TXT “http://acme.mydomain.com/acme-challenge

A similar request was proposed at Shouldn't verification via DNS record be a priority?

The advantage of this solution is that it is only a minimal change to http-01 and that it would not influence security of http-01 (an attacker who can change the special TXT record could also change NS or A records, so that won’t make a difference).


#2

Indeed would be very nice as I also use geo latency based DNS for my site’s server cluster too


#3

An HTTP/DNS “hybrid” would indeed increase flexibility for people who don’t want to open DNS for automatic updates but still don’t want to or can’t provide HTTP on the required record.

If this can be done securely, I’m all for it. It would be my favourite method.

Edit: SRV looks like the natural record to use.


#4

Maybe instead of replacing http-01, create another challenge which would be that combination of DNS and HTTP. Maybe call it srv-02?


#5

This is not a replacement for http-01, just an extension. And it’s not a hybrid since dns is not used for challenge, just for resolving (and that’s the intent of dns).

SRV looks better at the first glance. But it can only transport hostname and port, not URI. This forces users to have exactly 1 service per chellenge running (when using URIs, one server can handle challenges for multiple domains).


#6

Well, the only alternative that I see are TXT RRs.


#7

why not just allow posting the allowed LE account public keys (or their hashes) in the DNS?
a lot easier since you then dont need to do anything to verify, coz LE already knows your pubkey and you proved that you have it via API call signatures.


#8

While it’s not available, you should be able to redirect all /.well-known/acme-challenge/* requests to a dedicated server which solves the challenges. It’s really easy, it just doesn’t work if you can’t provide a HTTP service on port 80.


#9

well when working with multiple vhosts it gets annoying once again.


#10

Same if you have geo-dns distributed servers, embedded devices that cannot redirect, webservsers behind a firewall that are not externally reachable, websites on private ip addresses.