Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you use Let's Encrypt for internal hostnames?

shkspr.mobi

Post reply on HN
Print view View original

41–50 of 198 posts

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

#41

Post by nimbius »

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 issued cert for your malicious service, you just need to find a way to get/use the wildcard. you should know your services and SANs for the certs. these should be periodically audited.

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

#42

Post by chrisweekly »

mojzu wrote: post #35
meepmorp wrote: post #2

I've used https://smallstep.com/docs/step-ca/ as a CA internally, works well.

I've been using it too and it works well, particularly with Caddy to do automatic certificates with ACME where possible Plus all my services go through Tailscale, so although I am leaking internal hostnames via DNS, all those records point to is 100.* addresses

I'm a fan of both Caddy and Tailscale; any chance you have any devnotes to share on your setup?

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

#43

Post by snthd »

Can lets encrypt issue multiple wildcard certs for different subdomains like *.banana.example.com and *.grapefruit.example.com

Then you could give each server a different wildcard cert without exposing the full name to the certificate log: exchange.banana.example.com log4j.grapefruit.com

Ugly, but functional.

Alternatively should the certificate transparency log rules be changed to not include the subdomain? Maybe what matters is that you know that a certificate has been issued for a domain, when, and that you have a fingerprint to blacklist or revoke. Knowing which actual subdomain a certificate is for is very convenient, but is it proportionate?

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

#44

Post by Macha »

nimbius wrote: 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 cert extensions that allow restricting certs to a subdomain, but they're not universally supported and still scoped as wide as a wildcard cert).

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

#45

Post by meepmorp »

mrweasel wrote: post #5
meepmorp wrote: post #2

I've used https://smallstep.com/docs/step-ca/ as a CA internally, works well.

What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.

Yeah, that is the major drawback.

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

#46

Post by dnautics »

mrweasel wrote: post #5
meepmorp wrote: post #2

I've used https://smallstep.com/docs/step-ca/ as a CA internally, works well.

What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.

Out of curiosity, What's the problem with distributing your own root CAs? Is it security? Or is it "just a PITA"?

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

#47

Post by Hamuko »

dnautics wrote: post #46
mrweasel wrote: post #5

Earlier quoted context omitted.

What I'd want is an internal CA, like step-ca, but have the certificates signed by a "real" CA, so I don't have to distribute my own root CA certificate.

Out of curiosity, What's the problem with distributing your own root CAs? Is it security? Or is it "just a PITA"?

Mostly the second.

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

#48

Post by nimbius »

Macha wrote: post #44
nimbius wrote: 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…

OCSP is still a problem, as youll need to either proxy a local ocsp response during outages or disable validation entirely. microservices in an aws partial outage, for example, would suffer here.

a root CA cert is stored in a gemalto or other boutique special HSM. it has an overwhelming security framework to protect it (if its ever online.) security officers to reset pins with separate pins, and an attestation framework to access its functions through 2 or more known agents with privileges separated. even the keyboard connected to the device is cryptographically authenticated against the hardware to which it connects.

commonly your root is even offline, unavailable (locked in a vault) and only comes out for new issuing CA's.

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

#49

Post by tzs »

ChrisMarshallNY wrote: post #21

This is an interesting topic, for me. I write iOS apps, and iOS requires that all internet communications be done with HTTPS. It is possible to use self-signed certs, but you need to do a bit of work on the software, to validate and approve them. I don't like doing that, as I consider it a potential security vector (you are constantly reading about development code that is compiled into release product, and subsequen…

> I write iOS apps, and iOS requires that all internet communications be done with HTTPS

What if the app is on the same network as the server?

I've got a Denon A/V receiver that has an HTTP interface and the Denon iOS app is able to talk to it. I've watched this via a packet sniffer and it definitely is using plain HTTP.

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

#50

Post by willis936 »

mcgeez wrote: post #37

I like the wildcard certificates option, however I have not been able to find an easy solution to distribute those certificates to every host I have internally. Is this usually done manually? is there some equivalent to acme.sh? The kind of hosts I have are OPNSense router, traefik servers, unifi controller etc.

If you have root ssh on each machine you can make rsync cron jobs. Imo it's reasonably secure if you spend the time setting up ssh keys and disabling password auth after.
Post reply on HN