Yeah, that’s ultra annoying. If wildcards can’t be automated easily for everyone, then what’s the point? I’ve got a server sitting behind a firewall where the only verification option is DNS, which, in turn, requires using a VPN to access. I’ve been looking forward to wildcard support only to find that it only works with DNS auth, which doesn’t improve the existing situation one bit. Also, DNS records are subject to TTL and I have to wait for hours for our corporate DNS to propagate changes (meanwhile people get upset if I forgot to renew in time). There’s no API for DNS when VPN is part of the equation. This non-feature is ill-conceived.
All of this nonsense is why we need DNSSEC DANE TLSA right now. Almost no one’s DNS host has support for auto-renew and whenever you are talking about corporate networks, the situation is even worse. And securely distributing new private keys when regenerating a wildcart cert is a pain too, but a problem that would be far more manageable if DNS wasn’t the only available auth mechanism. The TXT record should specify an immutable web authority for renewal authorization. That way DNS doesn’t have to change every renewal and can point wherever in needs to point. If DNS is compromised, then that’s on the owner, not Let’s Encrypt. What was the point of registering an email address with Let’s Encrypt when using certbot if you won’t actually use it for its intended purpose (i.e. notifying the owner about certificate issuance issues)?
I don’t trust ANY public CA (including Let’s Encrypt). Public CAs are broken by design. As such, I care only about the lock icon working NOT actual security because SSL/TLS security as it stands is a joke. I’ll trust SSL/TLS when DANE TLSA finally gets implemented everywhere such that I can run my own private CA publicly and permanently get rid of all public CAs from my browser and OS trust store once and for all.
Wasn't it part of the initial announcement (of upcoming wildcard support) that it would only work with DNS validation? Ah yes, here it is, from eight months ago:
I agree that it should be possible to give a permanent authorization.
Also once/if CAA account-uri is implemented, it should be possible to safely permanently delegate the _acme-challenge records to a third-party "acme-dns" service as well, bypassing all the problems with DNS hosting.
Yes, today it is shit and frustrating, but I think there are multiple ways that this will be satisfactorily solved in the future.
Let's Encrypt's internal resolvers have a tiny maximum TTL, so that's not an issue. Let's Encrypt can't do anything about the authoritative DNS servers being extremely slow to deploy updates, though.
Can you delegate a subdomain -- or buy a different domain -- to a DNS provider that works reasonably?
AFAIK, dynamic DNS does not care about the underlying transport.
If you can reach your name servers through whatever tunnel, you can issue dns updates to it - if you configure your zone(s) accordingly.
Furthermore, all but the “immutable web” part is already possible.
Create CNAME records for _acme-challenge.domain.com to a name at a different DNS server that can be controlled via convenient API and then run validations… You only need to dynamically update the other DNS tree with the validations then.
A number of clients already support this, and someone has even written a specialty DNS server for supporting this, though any dynamically updatable DNS server could be used as well…
There is a mechanism that can help a bit with this, which is that you can make a CNAME for _acme-challenge in your zone, pointing to any arbitrary DNS RR in any zone. Then that RR is where the challenge TXT records need to be placed. In that case, you're no longer subject to limitations of the original authoritative DNS server.
Very soon Google Chrome is going to require transparency log inclusion proofs in order to accept certificates, so you can monitor logs (or presumably use other people's services or tools to monitor logs) to detect any misissuance related to your domain. If misissued certificates aren't logged, they won't be accepted by Chrome! Although this is a method of detection rather prevention, misissuance events have been taken extremely seriously by browsers and the overall PKI community and may lead to significant consequences for CAs.
You'll have to lobby browsers about this because they seem to have said that they don't intend to go in this direction, at least for now.
Let's Encrypt in particular was founded by people who are also rather skeptical about the history of the web PKI and who would rather that CAs have less power and discretion rather than more. However, limiting CAs' power has many dimensions and one of those is making sure that we avoid misissuing by limiting the kind of evidence that can be used to justify certificate issuance. For example, there used to be a 3rd validation method for issuing (non-wildcard) certs. This was convenient for users in that it worked particularly well in web application contexts where all URL paths for a virtual host were already routed to some other application. But a researchers discovered a likely scenario in which people would be able to abuse this method in some hosting environments to get certificates for other customers' domains—so we discontinued using that method.
That doesn't mean that the web PKI is good or that it shouldn't be replaced by a better key distribution method. But the limitations on certificate issuance challenge methods are all motivated by making the certificates that Let's Encrypt issues more accurate and trustworthy, generally as a result of explicit threat analysis.