Hacker News Reader

Comment by archgoon | Hacker News Reader

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.

View on HN

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.

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/

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) or vault (https://github.com/hashicorp/vault) or step certificates (https://github.com/smallstep/certificates) (which I work on) is probably easier and definitely better for internal services.

Why do you think trusting third parties is less secure than operating your own pki infrastructure?

Because we are introducing a third party into a situation that didn't require a third party.

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.

With certificate pinning, that is not a high risk.

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.

Very few sites use certificate pinning. Chrome dropped support for dynamic certificate pinning. Web based certificate pinning is often recommended against because it's very hard to do right.

Also, using Let's Encrypt doesn't stop you from certificate pinning.

Certificate pinning (HPKP) is browsers is effectively dead, and was never a good idea to begin with.

There are far too many ways to self-DoS accidentally with HPKP. Also, an attacker who briefly gains control of your public DNS or web server can DoS a hostname semi-permanently.

Won't all the client machines already have hundreds of 3rd party CAs (including Let's Encrypt) loaded onto them anyway?

Yea, by default anyways, but that doesn’t mean you need to use/trust them for a particular request. I’m talking mostly about service-to-service traffic fwiw, not browsers.

Installing certs on your own computer is easy. Installing certs on random testing phones? Not so easy. Let's encrypt just works.

>it’s less secure — you’re trusting (many) third parties

You're trusting those third parties regardless of if you use your own PKI, because browsers already trust all those root CAs anyways.

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/

Also, since last week, recent renewals won't count against your new issuance rate limits.

https://community.letsencrypt.org/t/rate-limits-fixing-certs...

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

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.

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

Even if you do have an expert available, it's a sound choice.

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.

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

Reply on news.ycombinator.com