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

141–150 of 198 posts

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

#141

Post by paxys »

throw0101a wrote: post #81
justin_oaks wrote: post #62

We have an internal certificate authority for internal domains at my job. We add the root CA certificate to each desktop or server through an endpoint agent that runs on every machine. That agent is used for monitoring, provisioning users, and even running arbitrary commands. The article mentions BYOD (bring your own device) but we don't allow personal devices to connect to internal services, so this isn't an issue f…

> We have an internal certificate authority for internal domains at my job. We add the root CA certificate to each desktop or server through an endpoint agent that runs on every machine. One challenge to this is some software doesn't use the operating system's CA chain by default. A lot of browsers use their own internal one and ignore what the OS does (by default).

It is also troublesome when you have to manage cert loading not just on end devices but ephemeral VMs and containers as well.

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

#142

Post by Ajedi32 »

rusk wrote: post #136

I read somewhere a while ago that LE are working on what’s called “intermediate CA” [0] which would solve the problem. Apparently from a regulatory standpoint there are some questions around abuse that need to be answered before they can go ahead. The basic idea is that you can issue your own certificates based on the LE CA that is already recognised by the browsers. EDIT [0] https://community.letsencrypt.org/t/does-…

We're a long ways away from name-constrained intermediaries being viable from a regulatory and technical perspective. I'd explain, but commenter in a thread linked to the one you posted has a pretty detailed explanation already: https://community.letsencrypt.org/t/sign-me-as-an-intermedia...

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

#143

Post by jopsen »

cmeacham98 wrote: post #86
silvestrov wrote: post #73

Earlier quoted context omitted.

A business case for Let's Encrypt is to support internal hosts which are not visible on the internet (Let's Encrypt can check that) and omit the hostnames from the Certificate Transparency Logs. Let a business pay $100/year for 10 internal hostnames.

I'm fairly certain LE is required to emit signed certificates to CT by the CA/B forum baseline requirements, with no "internal only" exception. In other words, if they do this they will be untrusted in browsers. They could offer this service on a secondary untrusted root if they wanted.

They could augment the CT spec, such that only a hash of the domain needs to be made public.

Would be a great way to found LE :)

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

#144

Post by jopsen »

AtNightWeCode wrote: post #108

A public CA is for having a third-party entity so two different parties do not need to trust each other. So, the answer is no. Why would you even consider this for internal communication?

Installing a root CA on devices is risky.

From the article:

> It means your employees aren't constantly fighting browser warnings when trying to submit stuff internally.

If your employees gets a habit of ignoring certificate warnings then you have much bigger problems than leaking internal domain names.

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

#145

Post by imadethis »

dijit wrote: post #124
imadethis wrote: post #6

This seems like a perfect use case for wild card certs, especially if you have internal sites on a different (sub) domain from your prod servers. Yes, multiple servers have the same private key, but when the alternative is self-signed or no encryption, that is an easy trade off for me.

Please stop advocating for wildcard certificates. http://blog.dijit.sh/please-stop-advocating-wildcard-certifi... http://blog.dijit.sh/follow-up-wildcard-tls-certificates

…that’s why I said to have your LAN on a different domain or subdomain, so it can’t be a valid cert for your prod traffic.

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

#146

Post by marcosdumay »

ttyprintk wrote: post #132
marcosdumay wrote: post #125

Earlier quoted context omitted.

Well, if instead of making a lot of effort in hiding your names you just didn't, you wouldn't use a name like that. Every single person that connects to any of your networks (very likely the sandboxed mobile one too) can find that name. Basically no place hides it internally. There is very little difference between disclosing it to thousands of the people that care the most about you and disclosing it to everybody on…

The other examples are better. Say a never-before-seen name appears, cisco520.internal.foo.bar. Suddenly, a well-formed email appears, “Re: Cisco Support Ticket #7779311” about some additional steps to provision your new appliance. It is trivial to automate that phish by crawling the CT log.

Is this valuable enough to resist every real advancement in network security since the late 00's? Because for each one of them it's certain that people will pop-up making a lot of noise about hidden server names.

It's mostly because of them that DNS is still not reliable. Well, at least this article isn't against certificate transparency, just about how to avoid it.

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

#147

Post by nickf »

infogulch wrote: post #91

Several comments here mention running your own CA. Maybe that could be a signed intermediate CA with the Name Constraint extension [0] (and critical bit?), but one roadblock on this path is that allegedly Apple devices do not support that extension (edit: actually this was fixed! see reply). You there, @ LetsEncrypt? To address the article a recent related discussion, "Analyzing the public hostnames of Tailscale user…

Wish it were as simple - ultimately having a name-constrained and publicly-trusted CA is the same as having any publicly-trusted CA and comes with a ton of wonderful burdens like audits.

You're essentially running a public CA at that point, and that isn't easy.

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

#148

Post by wolrah »

infogulch wrote: post #126
ArchOversight wrote: post #116

Earlier quoted context omitted.

Apple devices support the Name Constraint extension just fine. I've deployed a bunch of internal CA's with Name Constraint and Apple's macOS/iOS/iPadOS block certs that are signed for anything outside of the constraints. As is intended. AFAIK the Apple bug was fixed in macOS 10.13.3 from what I can find online. [1] [1]: https://security.stackexchange.com/questions/95600/are-x-509...

That's great to hear! I'd only heard secondhand, so I updated my comment to reflect this detail. Also I found https://bettertls.com publishes details about which TLS features are supported on different platforms over time, and it appears that the latest test in Dec 2021 shows most platforms support name constraints. With that roadblock evaporated, I think this would be the perfect solution to a lot of organization- a…

I'm happy to see that a big name like Netflix is getting behind this. I've been wishing for better Name Constraints support ever since learning how certificates work. Almost every situation where someone currently uses a wildcard could be done better with a name constrained CA cert.

I would love for this to become as widely supported as wildcards so those who choose to use them could do so easily.

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

#149

Post by stncls »

> But there is a downside. The CT logs are public and can be searched. Firstly, [...]

This bit me recently. I have a certificate for homelab.myname.com, and as any public-facing IP address, I get the expected brute force ssh login attempts for users 'root', 'git', 'admin', etc...

But I was terrified (until I remembered about the public cert) to find attempts for users 'homelab' and 'myname' -- which, being my actual name, actually corresponds to a user.

It's obviously my fault for not thinking this through, and it's not a terrible issue, but thinking I was under a targeted attack was quite the scare!

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

#150

Post by infogulch »

Ajedi32 wrote: post #142
rusk wrote: post #136

I read somewhere a while ago that LE are working on what’s called “intermediate CA” [0] which would solve the problem. Apparently from a regulatory standpoint there are some questions around abuse that need to be answered before they can go ahead. The basic idea is that you can issue your own certificates based on the LE CA that is already recognised by the browsers. EDIT [0] https://community.letsencrypt.org/t/does-…

We're a long ways away from name-constrained intermediaries being viable from a regulatory and technical perspective. I'd explain, but commenter in a thread linked to the one you posted has a pretty detailed explanation already: https://community.letsencrypt.org/t/sign-me-as-an-intermedia...

From that it looks like the main issue is regulatory requirements that force CAs to log all issued certificates via CT (certificate transparency) logs. Given that this is the very thing we're trying to avoid with a private CA ("CT" and "leaking internal hostnames" are functionally synonymous) we seem to be at an impasse at the level of base requirements.

Maybe an IP constraint that restricts certs to only be valid in private IP spaces (10.*, 192.168.1.*, etc)?

Post reply on HN