Live data from Hacker News

Should you use Let's Encrypt for internal hostnames?

shkspr.mobi

51–60 of 198 posts

Re: Should you use Let's Encrypt for internal hostnames?

#52
post #41

you should not use wildcards or letsencrypt for internal authentication as its insecure for a few reasons. 0. implicit reliance on a network internet connection means any loss of ACME to the letsencrypt CA makes renewal of the cert or OCSP problematic. if the internet goes down, so does much of the intranet nonreliant upon it. 1. wildcard certs make setting up an attack on the network easier. you no longer need an is…

It seems like the easiest self-managed alternative is several orders of magnitude more complicated, though. Managing a local CA is trivial in a homelab, but pushing self-signed certs to every machine and service that needs them quickly grows quite complex as you need to manage more of them and they grow more heterogeneous. Every stinking system has a different CA management tool with different quirks and different permissions models, and the technological complexity can pale in comparison to the organizational complexity of getting access to the systems in the first place. If you even can: especially in the case of services, they might Just Not Work with private CAs, and now inventing a proxy service is part of your private-CA-induced workload. On top of that, if you want to do a comparably good job of certificate rotation and expiry notification to letsencrypt, you're going to need infrastructure to make it happen.

Is there a tool that solves (some of) this that I just don't know about?

I've seen big companies do it manually, but it's a full time job, sometimes multiple full time jobs, and the result still has more steady-state problems (e.g. people leaving and certs expiring without notification) than letsencrypt.

Re: Should you use Let's Encrypt for internal hostnames?

#54
post #44
post #41

you should not use wildcards or letsencrypt for internal authentication as its insecure for a few reasons. 0. implicit reliance on a network internet connection means any loss of ACME to the letsencrypt CA makes renewal of the cert or OCSP problematic. if the internet goes down, so does much of the intranet nonreliant upon it. 1. wildcard certs make setting up an attack on the network easier. you no longer need an is…

1. Renewal is scripted to try every day for 30 days in advance with most common utilities. If lets encrypt and all other acme hosts are down for 30 days, I think you have bigger issues. 2. If you can't secure a wildcard cert, how does the same problem not apply to a root CA cert, which could also then do things like sign google.com certs that your internal users trust, which feels strictly worse. (I know there are ce…

If an organisation I work for requires me to trust their CA, that trust will go into a VM where the only things allowed to run are internal to the org. This will hamper my productivity, but only for a short time until my notice period runs out, at which point I will be working for another, saner organisation.

Re: Should you use Let's Encrypt for internal hostnames?

#56

Why not just be your own signing authority for internal domains? You can propagate your toplevel public cert with most enterprise network provisioning tools.

Running your own PKI is fairly straightforward, particularly with tools like cfssl at your disposal.

But running your own PKI properly is quite hard.

Let's Encrypt gives you top tier PKI management for $0.

Re: Should you use Let's Encrypt for internal hostnames?

#57

Earlier quoted context omitted.

> 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, o…

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.

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

Re: Should you use Let's Encrypt for internal hostnames?

#58
post #23

Earlier quoted context omitted.

I don't know how LE does it, but at least with DigiCert (and I assume other commercial CAs), servers sharing the same wildcard cert don't have to share a private key. You generate a separate CSR from each server, and then request a duplicate copy of the wildcard cert using that CSR. That way they can have different SANs as well.

Wildcard certs are (only?) issued from DNS-01 challenges. As long as the requester can satisfy the DNS challenge ACME doesn't care about key uniqueness.

With Digicert, you do a different API call “duplicate certificate” to avoid buying another cert unnecessarily.

I would consider it to be a best practice to keep unique keys as an SOP as it discourages bad behaviors, like keeping private keys accessible on file servers or even mail.

Re: Should you use Let's Encrypt for internal hostnames?

#59

Is it that hard to setup an internal CA? I have no idea what I'm doing, and I managed one for years until we moved offices and ditched our LAN.

The hard part is getting the root certificate in the trust store on every device in your organization.

Worse, it is often not the trust store on every device. It is often multiple trust stores on a device.

The OS might have one. Each browser might have its own. For a developer, each language they use might need separate configuration to get its libraries to use the certificate.

Post reply on HN