8 ms·

The article doesn't discuss this; what are the advantages to using Let's Encrypt for internal services over deploying internally signed certificates? Are there

The article doesn't discuss this; what are the advantages to using Let's Encrypt for internal services over deploying internally signed certificates? Are there any disadvantages to using Let's Encrypt? The rate limits alone seem to be a potential danger if they need to reissue new certificates for their 65,000 servers.

mholt 8y ago
The convenience of not having to manage your own CA (doing so is complex and nuanced).
- wereHamster 8y ago
  If you use your own CA you have to make sure all your apps trust it. With the public CAs that's not a problem because all the standard libraries usually trust them, and often 'apt-get install ca-certificates' is all you need to do.
- mjlee 8y ago
  If you are going to manage your CA and don't have an expert available, you could do much worse than https://www.vaultproject.io/docs/secrets/pki/index.html https://www.vaultproject.io/docs/secrets/pki/index.html Even if you do have an expert available, it's a sound choice.
Ajedi32 8y ago
The obvious advantage is that you don't need to deploy your root cert on client devices, or manage your own PKI. Reissuing certificates shouldn't be a problem since Let's Encrypt has a rate limit exception for renewals, though if I were managing 65,000 servers I'd be a little hesitant to put that kind of burden on Let's Encrypt's infrastructure without contacting them first, just as a matter of courtesy.
- binwiederhier 8y ago
  We didn't just contact them before regarding a rate limit increase, we are also a silver sponsor and pay/donate yearly. See https://letsencrypt.org/sponsors/ https://letsencrypt.org/sponsors/
throwawaycert 8y ago
Let's Encrypt specifically does not rate limit renewals. See the renewal exemption in the 6th paragraph of [0]. A "renewal" is any certificate that would count as a duplicate – that is, using the same set of names as another valid certificate. It doesn't count the keys. So you can always reissue existing certs. [0] https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/
- schoen 8y ago
  Also, since last week, recent renewals won't count against your new issuance rate limits. https://community.letsencrypt.org/t/rate-limits-fixing-certs-per-name-rate-limit-order-of-operations-gotcha/88189 https://community.letsencrypt.org/t/rate-limits-fixing-certs...
mmalone 8y ago
The disadvantages are: it’s less secure — you’re trusting (many) third parties with your security and relying on the security of DNS it’s less flexible — you can’t sign certificates with internal names (e.g., *.cluster.local) and certs must be for 90 days, etc it’s kind of hacky — you have to work around rate limits and whatnot because Let’s Encrypt wasn’t designed for this use case The advantage is it’s easier. But that’s arguable. What the article describes isn’t easy. Using something like cfssl (https://github.com/cloudflare/cfssl https://github.com/cloudflare/cfssl) or vault (https://github.com/hashicorp/vault https://github.com/hashicorp/vault) or step certificates (https://github.com/smallstep/certificates https://github.com/smallstep/certificates) (which I work on) is probably easier and definitely better for internal services.
- ec109685 8y ago
  Why do you think trusting third parties is less secure than operating your own pki infrastructure?
  - therein 8y ago
    Because we are introducing a third party into a situation that didn't require a third party.
    - mmalone 8y ago
      And if you just rely on the default trust stores you’re actually introducing over 100 third parties, some of which are known to be controlled by (or at least work with) the NSA, China, etc.
      - ec109685 8y ago
        With certificate pinning, that is not a high risk.
        mmalone 8y ago
        If you’re talking about services that you’re accessing via a browser, true. If you actually do pinning (properly). For service-to-service stuff and APIs the number of TLS clients that respect pinning is approximately zero. Either way, the other problems remain, and running an internal PKI is really pretty easy.
cmroanirgo 8y ago
There is the alternate way for internal networks to use a self signed cert authority (registered with each machine), and then use that to sign a machine's individual cert. All other devices that are signed using the CA are accepted. Nothing is leaked using this method. I remember seeing a good tut on this once... but can't find it atm.
- ec109685 8y ago
  Athenz operators in this manner: https://github.com/yahoo/athenz/blob/master/README.md https://github.com/yahoo/athenz/blob/master/README.md

mholt 8y ago

The convenience of not having to manage your own CA (doing so is complex and nuanced).

wereHamster 8y ago
If you use your own CA you have to make sure all your apps trust it. With the public CAs that's not a problem because all the standard libraries usually trust them, and often 'apt-get install ca-certificates' is all you need to do.
mjlee 8y ago
If you are going to manage your CA and don't have an expert available, you could do much worse than https://www.vaultproject.io/docs/secrets/pki/index.html https://www.vaultproject.io/docs/secrets/pki/index.html Even if you do have an expert available, it's a sound choice.

Ajedi32 8y ago

The obvious advantage is that you don't need to deploy your root cert on client devices, or manage your own PKI. Reissuing certificates shouldn't be a problem since Let's Encrypt has a rate limit exception for renewals, though if I were managing 65,000 servers I'd be a little hesitant to put that kind of burden on Let's Encrypt's infrastructure without contacting them first, just as a matter of courtesy.

binwiederhier 8y ago
We didn't just contact them before regarding a rate limit increase, we are also a silver sponsor and pay/donate yearly. See https://letsencrypt.org/sponsors/ https://letsencrypt.org/sponsors/

throwawaycert 8y ago

Let's Encrypt specifically does not rate limit renewals. See the renewal exemption in the 6th paragraph of [0]. A "renewal" is any certificate that would count as a duplicate – that is, using the same set of names as another valid certificate. It doesn't count the keys. So you can always reissue existing certs. [0] https://letsencrypt.org/docs/rate-limits/ https://letsencrypt.org/docs/rate-limits/

schoen 8y ago
Also, since last week, recent renewals won't count against your new issuance rate limits. https://community.letsencrypt.org/t/rate-limits-fixing-certs-per-name-rate-limit-order-of-operations-gotcha/88189 https://community.letsencrypt.org/t/rate-limits-fixing-certs...

mmalone 8y ago

The disadvantages are: it’s less secure — you’re trusting (many) third parties with your security and relying on the security of DNS it’s less flexible — you can’t sign certificates with internal names (e.g., *.cluster.local) and certs must be for 90 days, etc it’s kind of hacky — you have to work around rate limits and whatnot because Let’s Encrypt wasn’t designed for this use case The advantage is it’s easier. But that’s arguable. What the article describes isn’t easy. Using something like cfssl (https://github.com/cloudflare/cfssl https://github.com/cloudflare/cfssl) or vault (https://github.com/hashicorp/vault https://github.com/hashicorp/vault) or step certificates (https://github.com/smallstep/certificates https://github.com/smallstep/certificates) (which I work on) is probably easier and definitely better for internal services.

ec109685 8y ago
Why do you think trusting third parties is less secure than operating your own pki infrastructure?
- therein 8y ago
  Because we are introducing a third party into a situation that didn't require a third party.
  - mmalone 8y ago
    And if you just rely on the default trust stores you’re actually introducing over 100 third parties, some of which are known to be controlled by (or at least work with) the NSA, China, etc.
    - ec109685 8y ago
      With certificate pinning, that is not a high risk.
      - mmalone 8y ago
        If you’re talking about services that you’re accessing via a browser, true. If you actually do pinning (properly). For service-to-service stuff and APIs the number of TLS clients that respect pinning is approximately zero. Either way, the other problems remain, and running an internal PKI is really pretty easy.

cmroanirgo 8y ago

There is the alternate way for internal networks to use a self signed cert authority (registered with each machine), and then use that to sign a machine's individual cert. All other devices that are signed using the CA are accepted. Nothing is leaked using this method. I remember seeing a good tut on this once... but can't find it atm.

ec109685 8y ago
Athenz operators in this manner: https://github.com/yahoo/athenz/blob/master/README.md https://github.com/yahoo/athenz/blob/master/README.md