The Great SSL Certificate Panic(redmonk.com) |
The Great SSL Certificate Panic(redmonk.com) |
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).
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.
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?).
> 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?