They now support wildcards, but in order to verify you are authorised to get a wildcard certificate you need to be able to pass the DNS challenge. Unfortunately there simply isn't another universal, trust-less (and automatable) way of verifying that someone owns a domain -- other than DNS.
However, because the DNS check doesn't require writing to the webroot, you could run this on any server you like and then distribute the certificate to your edge nodes (meaning your edge nodes don't need to have access to write to your DNS). Some clients even have scripting hooks which could make this significantly easier.
(I assumed the "store my cloudflare API keys on my web host" aspect was your main concern with this method -- not necessarily who wrote the client because there are plenty of other clients.)
From the Caddy release announcement that supports wildcards[1]:
"This release introduces support for wildcard certificates, a new offering from Let's Encrypt. Getting a wildcard certificate requires enabling the DNS challenge. Fortunately, that is extremely simple with Caddy, and it works with over 20 different providers!"
In this case the third-party software implements a public protocol, comes with a full source written in a very readable language and is sufficiently small to permit a casual review.
It's not trivial but it's not that hard. In my case I modified AcmeeSharp to handle acmeev2 with a custom script.
The problem I found is that you need a DNS provider that not only has an API, but also has a fairly predictable propagation of DNS changes. I noticed through trial & error that contrary to the specs, let's encrypt doesn't wait and retry if it doesn't find the right DNS entries when it validates the DNS authorization request, instead it just fails the whole thing. Which means that you need to be pretty certain the change has propagated before you tell let's encrypt to complete the authorization. In my case I am using OVH, which has two tiers of service, a regular DNS which is fairly predictable, and a "Anycast DNS" offering which I found to be very hard to get let's encrypt to work with.
Also a rookie mistake to avoid: “* .domain.com” doesn’t cover “domain.com”. So you kind of need to get two authorizations, one for “* .domain.com” and one for “domain.com” and then get a cerficate that covers both (if that’s your need).
Is there still a valid use-case for wildcard certificates when using Lets Encrypt? AFAIK wildcards were used for financial reasons and laziness (since the traditional method of acquiring a cert was cumbersome), but with LE none of those arguments make sense.
Why not just fetch a different cert for every subdomain you use? It's also better security practice as this allows you to use different key per subdomain and the possibility to revoke bad or unused certs.
Also, if you own a very big amount of subdomains (say > 100), you want to minimize the number of certificates you want to manage/renew for easier maintenance and renewal.
I don't agree on this one. The whole point of the ACME protocol is that it allows for automated certificate management. Thus, it shouldn't matter if you manage 1 of 10000 subdomains, because you should automate it anyway.
Also, if for some reason the automated process fails, I'd rather have one subdomain go down, than all of them.
> If you have a lot of subdomains, you may want to combine them into a single certificate, up to a limit of 100 Names per Certificate. Combined with the above limit, that means you can issue certificates containing up to 5,000 unique subdomains per week.
Unfortunately CloudFlare doesn’t provide limited-scope API keys so every server requesting certs needs your global API key which is the keys-to-the-kingdom...so be careful.
You can also CNAME your _acme-challenge record to another zone and perform the updates on the target zone, avoiding overprivileging your webserver.
https://github.com/joohoi/acme-dns is a server implementation of that, and a number of popular clients support it. Or if you don't want to run acme-dns, some ACME clients support an "alias" mode that essentially does the same thing using generic DNS CNAMEing.
Annoyed that Route53 IAM still doesn't let you limit the record label ...
No need for individual servers, let alone public ones, to have your DNS API key.
Have a separate machine that isn't publicly addressable generate the keys and request the certificates, and then push them out to where they need to be. You don't even need to give that box privileged access to the places the certificates need to be, if you arrange things right. Only one box then needs your API key.
That separate machine doesn't need the private keys.
Depending on your scenario it may well make more sense for the DNS privileged machine not to know the keys, and be given Certificate Signing Requests (CSRs) for the certificates it's to go get from Let's Encrypt. Most good ACME clients will accept a CSR you provide as an alternative to making their own keys or using a private key you generated.
A CSR is a signed document like a certificate, but instead of being signed by a CA (Let's Encrypt) to certify something, they're signed by "you" (ie using your private key) to prove you know the key and you want a certificate with these names on it.
Under the hood the ACME protocol always uses CSRs, but since tools to make them are often clumsy and nasty clients tend to follow Certbot (the reference client) in defaulting to making their own CSR without you needing to know about it, a client can do this because it knows your private keys. By providing your own CSRs you don't need the box speaking ACME to know your private keys.
Let's Encrypt doesn't care if you provide the same CSR repeatedly for renewals, unless your private key is known to them because somebody leaked it, in which case subsequent requests for a certificate will fail, which is what you want since that key is now compromised and you need to replace it. You should rotate keys anyway, but can do so at a pace which is appropriate to your risk factors e.g. once a year is fine for most people, and not dictated by the rate at which Let's Encrypt renewals happen.
It's not that hard, I've written a fairly short bash script that automatically issues all of the wildcard certs I use with the correct credentials (and switches to normal HTTP verification when a wildcard isn't requested).