4 ms·

The Great SSL Certificate Panic

22 points by chillax 1y ago

necovek 1y ago
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).
- merb 1y ago
  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-challenge 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.
  - necovek 1y ago
    That's neat, I might do that to limit the damage a bit!
- znpy 1y ago
  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.
  - necovek 1y ago
    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).
    - merb 1y ago
      > 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 1y ago
        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?).
    - znpy 1y ago
      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/ https://letsencrypt.org/docs/client-options/ EDIT: i see in the certbot manpage (https://manpages.ubuntu.com/manpages/bionic/en/man1/certbot.1.html 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-and-post-validation-hooks 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...

22 points by chillax 1y ago

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

merb 1y ago
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-challenge 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.
- necovek 1y ago
  That's neat, I might do that to limit the damage a bit!
znpy 1y ago
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.
- necovek 1y ago
  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).
  - merb 1y ago
    > 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 1y ago
      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?).
  - znpy 1y ago
    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/ https://letsencrypt.org/docs/client-options/ EDIT: i see in the certbot manpage (https://manpages.ubuntu.com/manpages/bionic/en/man1/certbot.1.html 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-and-post-validation-hooks 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...