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

81–90 of 198 posts

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

#81

Post by throw0101a »

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

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

#82

Post by metafunctor »

meepmorp wrote: post #2

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

This is the correct answer ;)

If you're going to run a serious internal network, you'll need the basic things like NTP, DNS, a CA server, and, yes, some kind of MDM to distribute internal CA certificates to your people. The real PITA is when you don't have these in place.

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

#83

Post by runjake »

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.

This would be called an "Intermediate CA" to those for whom this is unclear.

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

#84

Post by throw0101a »

filleokus wrote: post #9
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.

The dream would truly be an internal CA backed by a publicly trusted subordinate cert (limited to the domain you control). But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.

> But afaik that can’t happen until the Name Constraint Extension is enforced by “all” clients.

For those curious about this extension, see RFC 5280 § 4.2.1.10:

* https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10

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

#85

Post by Macha »

nimbius wrote: post #48
Macha wrote: post #44

Earlier quoted context omitted.

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 framew…

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

There are many organisations not large enough to justify this setup, for which Lets Encrypt is clearly safer than a custom root CA.

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

#86

Post by cmeacham98 »

silvestrov wrote: post #73
YPPH wrote: post #56

Earlier quoted context omitted.

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.

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.

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

#87

Post by ivanr »

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…

> By the way, EasyRSA still isn't that easy, but it's better than using OpenSSL directly.

The trouble with EasyRSA (and similar tools) is that they make decisions for you and restrict what's possible and how. For example, I would always use name constraints with private roots, for extra security. But you're right about OpenSSL; to use it directly requires a significant time investment to understand enough about PKI.

I tried to address this problem with documentation and templates. Here's a step by step guide for creating a private CA using OpenSSL, including intermediate certificates (enabling the root to be kept offline), revocation, and so on: https://www.feistyduck.com/library/openssl-cookbook/online/c... Every aspect is configurable, and here are the configuration templates: https://github.com/ivanr/bulletproof-tls/tree/master/private...

Doing something like this by hand is a fantastic way to learn more about PKI. I know I enjoyed it very much. It's much easier to handle because you're not starting from scratch.

Others in this thread have mentioned SmallStep's STEP-CA, which comes with ACME support: https://smallstep.com/docs/step-ca/getting-started That's definitely worth considering as well.

EDIT The last time I checked, Google's CA-as-a-service was quite affordable https://cloud.google.com/certificate-authority-service AWS has one too, but there's a high minimum monthly fee. Personally, if the budget allows for it, I would go with multiple roots from both AWS and GCP for redundancy.

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

#88

Post by throw0101a »

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.

> acme.sh

Another shell-based ACME client I like is dehyradted. But for sending certs to remote systems from one central area, perhaps the shell-based GetSSL:

> Obtain SSL certificates from the letsencrypt.org ACME server. Suitable for automating the process on remote servers.

* https://github.com/srvrco/getssl

In general, what you may want to do is configure Ansible/Puppet/etc, and have your ACME client drop the new cert in a particular area and have your configuration management system push things out from there.

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

#89

Post by YPPH »

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

Chrome, Edge, Safari and (god forbid) IE will use system certificate stores.

Firefox was a challenge. But my understanding is that now, on Windows, it will now import enterprise root certificates from the system store automatically.

https://bugzilla.mozilla.org/show_bug.cgi?id=1265113

https://support.mozilla.org/en-US/kb/how-disable-enterprise-...

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

#90

Post by grogenaut »

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

The big-co I work for handles this via some tooling that checks for browsers and sees if the cert is installed, or by having the ca page signed regularly and having people self install. "Your site look wierd, likely you are missing the CA". It's not solved solved but it's mostly solved. The browsers that come with the image on the enterprise release cadence all have the cert. The people adding other browsers are usually devs or technically savvy enough to add a CA.
Post reply on HN