I am not even sure I buy the automation increases security posture claim.
When I was automating my own LetsEncrypt cert updates, I had to effectively expose my DNS API keys to the same runtime environment as the ACME client (I could have created a thinner interface between two compartmentalized services with more effort, true), thus increasing the chances of an exploit in one flowing into the other. And with a bug in certificate automation, your entire domain is open to hijaacking too.
Not to mention that I have to push the same certs to other services running on the same IP (like my self-hosted email), which really works against my encapsulation of every service inside a separate VM (if automated). So an automation exploit and there goes my mail server too (you need to set certs up as a user with sufficient permissions to reconfigure the mail server).
> Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server.
You’re probably doing wrong. You can decouple things if you need to, obtaining certificates and delivering them to the software that will use them can be done by separate systems/services.
Not trivially without inventing my own tools: or are you suggesting this can be done with certbot itself?
Also, note that once everyone is "forced" to switch to automation, many will be doing it wrong just the same (probably even more wrong in that there will be a path from exploiting end services to gain DNS and cert access too).
I am not even sure I buy the automation increases security posture claim.
When I was automating my own LetsEncrypt cert updates, I had to effectively expose my DNS API keys to the same runtime environment as the ACME client (I could have created a thinner interface between two compartmentalized services with more effort, true), thus increasing the chances of an exploit in one flowing into the other. And with a bug in certificate automation, your entire domain is open to hijaacking too.
Not to mention that I have to push the same certs to other services running on the same IP (like my self-hosted email), which really works against my encapsulation of every service inside a separate VM (if automated). So an automation exploit and there goes my mail server too (you need to set certs up as a user with sufficient permissions to reconfigure the mail server).
btw. you can use a different dns server than you're main dns server which exposes the api, via cname redirects/ns records.
https://letsencrypt.org/docs/challenge-types/#dns-01-challen...
> Since Let’s Encrypt follows the DNS standards when looking up TXT records for DNS-01 validation, you can use CNAME records or NS records to delegate answering the challenge to other DNS zones. This can be used to delegate the _acme-challenge subdomain to a validation-specific server or zone. It can also be used if your DNS provider is slow to update, and you want to delegate to a quicker-updating server.
That's neat, I might do that to limit the damage a bit!
You’re probably doing wrong. You can decouple things if you need to, obtaining certificates and delivering them to the software that will use them can be done by separate systems/services.
Not trivially without inventing my own tools: or are you suggesting this can be done with certbot itself?
Also, note that once everyone is "forced" to switch to automation, many will be doing it wrong just the same (probably even more wrong in that there will be a path from exploiting end services to gain DNS and cert access too).