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).
> Also, note that once everyone is "forced" to switch to automation, many will be doing it wrong just the same
tbf I think that is fine, overall the outcome after a while is still better than the current system.
of course our industrial revolution also did not everything correct, but now in 202x I think the world is way better than before.
the same happening now with social media, of course not everything there is correct, especially misinformation. but the world still got closer through social media
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).
that's what cert-manager does, for example. certificates are stored in kubernetes secrets.
that being said, the ACME spec is fairly simple, writing your own tool shouldn't be much of an hassle.
see https://letsencrypt.org/docs/client-options/
EDIT: i see in the certbot manpage (https://manpages.ubuntu.com/manpages/bionic/en/man1/certbot....) that there's an hook (--deploy-hook DEPLOY_HOOK / https://eff-certbot.readthedocs.io/en/latest/using.html#pre-...) that's called after issuing. You can use that to scp/upload/post certificates to some other location.
As usual, if only one had read the fine manual...
> Also, note that once everyone is "forced" to switch to automation, many will be doing it wrong just the same
tbf I think that is fine, overall the outcome after a while is still better than the current system. of course our industrial revolution also did not everything correct, but now in 202x I think the world is way better than before.
the same happening now with social media, of course not everything there is correct, especially misinformation. but the world still got closer through social media