I believe the mechanism described here would run afoul of the present baseline requirements, but could be brought into line with the BRs merely by validating control over the base domain.tld that wildcard is being requested for. Current BR method #6 specifies that control over a given FQDN demonstrated by website change is sufficient validation for all FQDNs ending with the validated label, thus appropriate to use in validation for wildcards.
Despite the BRs clarity on that matter, that mechanism leaves much to desire. There’s no strong logical reason to presume the administrator of example.com <http://example.com/> should be entitled to a certificate covering billing.example.com <http://billing.example.com/> or *.example.com <http://example.com/>. Additional security enhancement as described in this method in which additional random labels are added to the base domain — for domain names unknown to the applicant until time of the validation request would seem to illustrate broad-sweeping control over the validated main label + 1 level beyond. Perhaps validate the base domain over which validation is requested plus 3 random labels beyond? I will say that just as with TLS-SNI-0x, there were certainly surprises in the initial deployment of http-01 that led to changes (only validate over port 80 initially because of esoterica in shared hosting environments, etc.) Those kinds of issues suggest that any kind of validation over HTTP — and especially contemplating new or enhanced privilege in HTTP validations — should entail some sort of study of actual real-world deployment behaviors in a wide plurality of environments which exist on the web today. I’m not sure how best to define or architect that, but it’s clear that significant real world behavior in deployment of HTTP and HTTPS services deviated from the expectations and assumptions of the group in previous validation method work. > On Jan 24, 2018, at 3:42 PM, Hugo Leisink <[email protected]> wrote: > > Hi, > > While implementing ACMEv2 for Let's Encrypt, I noticed that wildcard > certificates can only be obtained via dns-01. Because it's not possible > for me to do that automatically, I proposed them a way to do it via > http-01. After they said that 'it might work', they told me to contact > you about this. > > My idea is that when a client requests a wildcard certificate > (*.domain.tld), the CA server offers a challenge and requests that > challenge via HTTP while using a random hostname (<long random > string>.domain.tld). Because only a webserver with a website configured > for *.domain.tld and with a properly configured DNS can respond to this > challenge, it's enough proof that the request for a wildcard certificate > is valid. Perhaps the CA server can do multiple requests with a new > randomly chosen hostname for more proof. After all, they will all end up > at the same website. > > The discussion about this at the Let's Encrypt forum can be found here: > https://community.letsencrypt.org/t/wildcard-certificates-via-http-01/51223 > > I really like to hear your thoughts about this. > > Kind regards, > Hugo Leisink > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
