[necovek]

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).

[znpy]

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...

[necovek]

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.

[znpy]

> ACME protocol does not help there: certbot needs to update my DNS zone (has my full API keys)

there's your problem

> I admit to not have bothered to restrict it too much

and there is your solution

[necovek]

You literally responded to a post stating:

> Not trivially without inventing my own tools

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?

[merb]

> 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

[necovek]

I agree it's not going to be too bad, but I am not convinced it's going to be better either — that's what this thread is about :)

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?).