←back to thread

Should you use Let's Encrypt for internal hostnames?

(shkspr.mobi)
238 points edent | 4 comments | 05 Jan 22 12:42 UTC | HN request time: 0.751s | source
Show context
filleokus ◴[05 Jan 22 14:29 UTC] No.29809350[source]▶
Sadly, the answer is probably no (for the information leakage mentioned in the article).

But having an internal (even ACME API-supporting) CA is no walk in the park either. If you can swallow the trade off and design with publicly-known hostnames, I would highly recommend it.

There’s always some annoying device/software/framework requiring their own little config dance to insert the root cert. Like outbound-proxy configuration, but almost worse.

I don’t even want to imagine what would happen if/when the root key needs to be rotated due to some catastrophic HSM problem.

replies(1): >>29809894 #
michaelt ◴[05 Jan 22 15:11 UTC] No.29809894[source]▶
> Sadly, the answer is probably no (for the information leakage mentioned in the article).

Eh, even in large organisations of expert IT users, the internal CA ends up training users to ignore certificate warnings.

Sure, maybe the certificate is set up right on officially issued laptops - but the moment someone starts a container, or launches a virtual machine, or uses some weird tool with its own certificate store, or has a project that needs a raspberry pi, or the boss gets himself an ipad? They'll start seeing certificate errors.

IMHO the risks created by users learning to ignore warnings are much greater than the risks from some outsider knowing that nexus.example.com exists.

replies(1): >>29810159 #
flatiron ◴[05 Jan 22 15:30 UTC] No.29810159[source]▶
If you have a large organization your containers are based off the orgs containers which has the CA in it. Same with VMs, Java, .Net, etc.
replies(1): >>29810790 #
1. infogulch ◴[05 Jan 22 16:12 UTC] No.29810790[source]▶
Maintaining golden container/vm images with root cert customizations is a pretty complex task that needs constant maintenance and customizations for new runtimes. Also this does nothing for unofficial devices (byo laptops, byod smartphones, ceo's ipad, guest laptops).
replies(2): >>29811313 #>>29812373 #
2. Spivak ◴[05 Jan 22 16:44 UTC] No.29811313[source]▶
Hard disagree on that one. For 99% of your software it’s stuck the cert in your distro’s trust store and use the result as your base VM / container templates. Adding to the Java trust store is a 10 line script and never needs to be touched again. It’s not that it’s completely trivial but it’s so much less complex than every other thing your infra team does.

Random BYO devices I can understand but in your cloud / datacenter it’s so easy just because you control everything.

3. throw0101a ◴[05 Jan 22 17:51 UTC] No.29812373[source]▶
> Maintaining golden container/vm images […]

I was under the impression that 'golden images' aren't generally encouraged as a Best Practice™ nowadays. The general momentum seems to me to be use a vendor-default install image (partitioning however you want), and then go in with a configuration management system once it's on the network.

Basically: you keep your config 'recipes' up-to-date, not your image(s).

replies(1): >>29857003 #
4. flatiron ◴[08 Jan 22 22:15 UTC] No.29857003[source]▶
at least at apple the dockerfile for their images were < 50 lines. Like super tweaks on the AL2 image. Every 60 days you need to pull it in. So you are right they just keep it up-to-date and keep it to the vendor images as well.