There is no need for being nasty, especially when you are wrong.
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.
Also implying that people will do even worse than I do, and thus reduce security posture — I am exactly aware of where the security boundaries are being broken needlessly (and I am accepting this risk), but many won't be. Which this is the whole point of, right?
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.