Hacker News Reader

Comment by c00lio | Hacker News Reader

There are tons of reasons to not use an external CA.

First, cost. Any CA that issues unlimited certificates will charge tons of money. Free CAs like letsencrypt do have rate limits that we would frequently hit with autoscaling environments, CI jobs, and such.

Also, CAs require the use of certificate transparency logs. Which will expose your internal infrastructure data to the public. It will, by exposing autoscaling data, also expose financial data (at least in hints), e.g. by showing that last christmas, your scaling peak was far higher.

And external CAs are a security risk because you need to provide firewall exceptions and/or transfer mechanisms for certificates into your internal infrastructure that you would usually want to isolate.

Lastly, an external CA is an availability risk. Should your external CA be unreachable for some reason, you might not be able to run any CI jobs or auto-scale-up your infra.

View on HN

There are tons of reasons to not use an internal CA.

First, cost. You're not just going to slap the root CA onto the network drive and let the developers have at it - you're going to need infrastructure to keep the key safe and handle automated cert provisioning and suchlike - that's going to need people to maintain it. And it'll be an important part of your infrastructure, so you'll need enough experts you can maintain round-the-clock support.

Second, it reduces your security because your users will inevitably learn to ignore certificate errors.

Thirdly, you'll never stop the certificate errors. Oh, you're going to set them up for both Chrome and Firefox and Edge and Safari on Windows, Mac, Linux? Oops, you forgot Android and iPhone. And your CI system. And Java and Docker and Git. And the network printer and the electronics team's network-enabled oscilloscope. Think you've covered everything? Surprise, Slack is distributed in a Snap now, it's generating certificate errors.

Just have your cloud provider take care of it. Not in the cloud? A wildcard cert on your load balancer will get you 99% of the value with 1% of the work.

So I'll route my CI integration tests that test communication from application to database through the loadbalancer? And I'll teach the loadbalancer to talk to itself to talk to the autoscaling web backends it needs to talk to because only the loadbalancer has a valid certificate? Nice brain-knot.

And talking about security risks, wildcard certs are especially dangerous and should be forbidden from ever existing. They just lead to "copy it everywhere"-keys that, sooner or later, will leak. And that won't be revoked or replaced, because of course everything will break at once.

Oh, and the certificate errors will also come with external CAs. Chain too long? Error in some browsers. ECC signature? Error in some browsers. Chain with different paths? Error in some browsers. 4096bit certificate somewhere? Error in some browsers. Two different valid roots? Error in some browsers.

The result is different when comparing to self-signed certificates. For instance, yes you should be careful with your key, but losing it makes your security as bad as when using self-signed certificates. Yes, you might be teaching some of your users to bypass the warnings. Just like when using self-signed certificates.

I think you've entirely misunderstood the discussion here. Your post seems to be about using internal certificates for an externally visible website (although I'm confused about the mention of network printers and Slack--are you thinking this is a MITM certificate? nobody had suggested using an internal CA for those things) but that's not what anyone here was talking about. They're talking about internal use for communication between your own backend services.

Recall the post that started this subthread:

> Having to communicate with outside is kinda overkill if you just want to have container A talking to container B.

The article here is about the same.

#2 and #3 in your post don't apply; we're not talking about browsers or end users at all here. #1 may apply but I think you're overstating it; Active Directory Certificate Services takes care of all that. Remember that you don't have to follow the CA Baseline Requirements as a private CA. It's harder to get rid of an ADCS PKI than to set it up.

> #2 and #3 in your post don't apply; we're not talking about browsers or end users at all here.

Y'all don't have internal tools implemented as webapps? Self-hosted version control servers? Nexus? SonarQube?

Oh, I'll agree that you can outsource all that stuff if you want to - but any business with that philosophy would surely also outsource their certificate provisioning. Especially considering how easy and cheap AWS make it.

> although I'm confused about the mention of network printers and Slack

Do you not want graceful handling of internal URLs when mentioned in slack? Such as previews, image unrolling etc? Do you not need a certificate for the internal file server your scans upload to, and so on?

You're still talking about a completely unrelated use of CAs here. We're talking about how you get two k8s pods to communicate with each other securely, as an alternative to using self-signed certificates and without leaking details of your internal infrastructure to a CT log. Nobody suggested using self-signed certificates for any of the things you're talking about; we are talking about what you should replace your self-signed certificates with. That's what both the article and this thread are about. You're arguing against a point that nobody made. You'd never use a self-signed certificate for a user-facing website or service and nobody suggested that you would. It is specifically the situations where you'd use a self-signed certificate that this subthread is suggesting using an internal CA for instead.

Stated another way, I believe you are saying "don't use internal CAs for things you'd otherwise use public certificates for" but what we're saying is "use internal CAs for things you'd otherwise use self-signed certificates for". I believe both statements are correct but we weren't talking about the first thing at all until you brought it up.

> A wildcard cert on your load balancer will get you 99% of the value with 1% of the work.

The goal is not to make cert errors go away.

The goal is to establish secure connections between parties, with the smallest possible trust boundary and attack surface.

> Free CAs like letsencrypt do have rate limits that we would frequently hit with autoscaling environments, CI jobs, and such.

You're expected to design around that. Deploying should never create a new certificate, those should live in secure storage and get deployed when needed.

The main rate limit also doesn't apply to renewals, so you could potentially issue N*50 domain names on your Nth week using Let's Encrypt.

"Renewals are treated specially: they don’t count against your Certificates per Registered Domain limit." - https://letsencrypt.org/docs/rate-limits/

If you need to issue certificates for new domains at a higher rate, you're very likely a large company that can afford to pay some money for any excess certificates you need. Failing over to ZeroSSL (zerossl.com) on rate limiting should be an easy engineering task since both use the ACME API.

Some more:

- Letsencrypt and friends don't give you whatever purpose certs you would want. I.e File Encryption, Code Signing and friends, individual client certs

ACM is effectively free. Cost is not an issue. None of your data is exposed. This is all FUD.

Certificate Transparency Logs don't exist?

It you are not personally aware of the basis behind a security posture, please avoid denouncing it as FUD. Yout own ignorance, uncertainty, or doubt does not suffice to replace the informed advice of a professional.

I'm sorry but this is simply not true. Certificate Transparency logs ARE (meta?)data which would be exposed. If the certificates were meant to be reached externally, you wouldn't indeed care at all - but if they're for internal flows (e.g. App server to DB, 2 steps behind a balancer and a set of web frontends) you are indeed publishing stuff you would have rather kept private.

Before this (d)evolves into a zero trust, security-by-obscurity discussion - some auditors won't certify you in some edge cases related to this, and you may be operating in a regulated sector where such a certification is necessary. Just because it doesn't impact your use case, doesn't mean this is the case for someone else.

Reply on news.ycombinator.com