Is it still hard to do wildcard certs with them? That is one of the reasons I don't use let's encrypt.
lego \
--email="info@example.com" \
--accept-tos \
--path="./ssl" \
--domains="*.example.com" \
--dns="route53"
Personally, I would not want to do that.
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.)
"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!"
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).
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.
I could get around it by hosting split dns, but that’s quite messy
Even on those that are reachable I’d have to carve out port 80 and forward it somewhere else to do the cert generation.
Another option would be dynamic server names - where the host part contains a lot of information (or no info)
https://gafjsisi.slashdot.org I suspect has never been loaded before today. It seems to work from my phone so I assume it’s a wildcard cert
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.
This was one of the reasons for me switching to Cloudflare DNS, although many other providers should work too.
Compromising a web-server will thus not compromise my DNS.
It’s just a basic setup with dehydrated[1], some bash scripts for deployment and cron though.
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 ...
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.
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.
That and I've not played with doing that myself yet, so while I know it is possible I can't talk about it authoritatively.