What verification strategy are they using to determine when a wildcard cert can be created? I see the discussion on https://github.com/letsencrypt/acme-spec/issues/64 suggesting that they validate a sampling of randomly-generated subdomains, but it's unclear if that's actually the strategy they're using (and an obvious downside with that strategy is it won't work for a client that wants a wildcard cert for whatever reason but hasn't configured DNS to handle arbitrary subdomains, though you could of course argue that these clients don't actually need wildcard certs).
Currently we're only planning to allow DNS method validation for wildcards. You'll have to validate the base domain via DNS, that's all. No HTTP or file-based validation option.
We decided not to offer HTTP-based (file-based) validation via randomly-generated subdomains for wildcards in part because if you're required to set up random subdomains you're modifying DNS to do that, and if you're already modifying DNS you might as well just use the DNS validation method.
Glad to hear it. So the assumption is that if you control the DNS for example.com then you control the DNS for all subdomains? That seems like a reasonable assumption.
I used to use the DNS challenge for my (few) sites. Unfortunately i'd had many problems so I switched to HTTP. These problems boiled down to:
1. Namecheap's API is rubbish - extremely rate limited so after doing 2 or 3 in an hour it basically stopped working
2. Propagation delays - I don't know if this was provider specific for Namecheap and Gandi, but sometimes lego would just hang waiting for LE to confirm propagation.
HTTP challenge works fine and is far easier if punched into the load balancer rather than relying on each back end.
Note note of these problems are the fault of LE from what I see. I'm going to see if any of the ACME clients support updating Google Cloud DNS which I use now, as their propagation time seems minimal.
Thanks for your work btw in securing the internet.
