If you somewhat want to avoid this, get a wildcard certificate (LE supports them: https://community.letsencrypt.org/t/acme-v2-production-envir...
Then all they know is the main domain, and you can somewhat hide in obscurity.
If you somewhat want to avoid this, get a wildcard certificate (LE supports them: https://community.letsencrypt.org/t/acme-v2-production-envir...
Then all they know is the main domain, and you can somewhat hide in obscurity.
Yep, but this comes with a tradeoff: all of your services now have a valid key/cert for your whole domain, significantly increasing the blast radius if one service is compromised.
Not a problem if you have the cert on a shared load balancer, not on the services directly.
This is what we do for development containers/hosts - put them behind *.dev.example.com, allows us to hide most testing instances using a shared load balancer. And with a single wildcard CNAME, No info is leaked in CT logs or DNS. Said LB is firewalled, but why pay for extra traffic that's just going to be blocked?
Is it technically possible to obtain a wildcard cert from LetsEncrypt, but then use OpenSSL / X.509 tooling to derive a restricted cert/key to be deployed on servers, which only works for specific domains under the wildcard?
No
Unfortunately they are a bit extra bothersome to automate (depending on your DNS provider/setup) because of the DNS CNAME-method validation requirement.
Yep, but next year they intend to launch an alternative DNS challenge which doesn't require changing DNS records with every renewal. Instead you'll create a persistent TXT record containing a public key, and then any ACME client which has the private key can keep requesting new certs forever.
https://letsencrypt.org/2025/12/02/from-90-to-45#making-auto...
Oh, sweet! I didn't know about this. I have no need of wildcard certs, but this will greatly simplify the process of issuing certificates for internal services behind my local firewall. No need to maintain an acme-dns server; just configure the ACME client, set the DNS record and you're done? Very nice.
Great to hear, one less API keys needed for the DNS records.
If you are using a non-standard DNS provider that doesn’t have integration with certbot or cert-manager or whatever you are using, it is pretty easy to set up an acme-dns server to handle it
https://github.com/joohoi/acme-dns
also you can use https://github.com/krtab/agnos if you don't have any api access
I hadn't heard of Agnos before, interesting alternative to ACME-DNS.
Looking at the README, is the idea that the certificates get generated on the DNS server itself? Not by the ACME client on each machine that needs a certificate? That seems like a confusing design choice to me. How do you get the certificate back to the web server that actually needs it? Or is the idea that you'd have a single server which acts as both the DNS server and the web server?
When I set up a wildcard cert for my homelab services it was easy to have Cloudflare give me an API token to do the DNS validation for LE.
Correct, that's what I did with caddy, which is now periodically renewing my wildcard certificate through a DNS-01 challenge.
May I know does Caddy automatically update with apt if you built custom Caddy binaries for the DNS provider plugin?
Also, may I know which DNS provider you went with? The GitHub issues pages with some of the DNS provider plugins seems to suggest some are more frequently maintained, while some less so.