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 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...
More importantly, you didn't think it through: this is really what I am doing, but this executes a script which needs to have permissions to push certificates to another VM (I do it with passphrase-less SSH), and then needs to have permissions to reconfigure my mail server with those updated certificates as they are on the same domain (using sudo from the unprivileged user) — how this script breaks through security barriers is what's the issue, not running the script.
ACME protocol does not help there: certbot needs tomupdate my DNS zone (has my full API keys), then I need to securely share only the certs (private part too) and nothing else (I admit to not have bothered to restrict it too much), and the target, upon receiving updated certs, needs to reconfigure the mail server to use them. Really, an exploit in certbot (imagine a MITM attack) would get the attacker access to my DNS, and my mail server configuration. Custom stuff could help (eg. I could be pushing cert to a secrets store on one end, and pulling it down on another), but that's more work, and has its own risks.
My point is that I am not doing the most encapsulated thing, and there will be plenty others who do even worse, thus exposing themselves to even worse security risks.
That's what we need to look at to evaluate if a change is more or less secure.
there's your problem
> I admit to not have bothered to restrict it too much
and there is your solution
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
In other words, it is "fine" today too, and nobody has really measured how risky all the CRL issues and such are (how often is this a practical problem?).
