Earlier quoted context omitted.
> 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-...
Should you use Let's Encrypt for internal hostnames?
101–110 of 198 posts
Re: Should you use Let's Encrypt for internal hostnames?
#102This 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.
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.
That is, unless you're using some sort of public key pinning, but that's very rare to find today and works only in a custom application or something that supports DNSSEC/DANE.
Re: Should you use Let's Encrypt for internal hostnames?
#103Another nuisance is that unencrypted port 80 must be open to the outside world to do the acme negotiation (LE servers must be able to talk to your acme client running at the subdomain that wants a cert). They also intentionally don't publish a list of IPs that LetsEncrypt might be coming from [1]. So opening firewall ports on machines that are specifically internal hosts has to be a part of any renewal scripts that r…
Only true if you're using HTTP validation. Use DNS validation instead and this isn't an issue.
[1] https://community.letsencrypt.org/t/whitelisting-le-ip-addre... [2] https://community.letsencrypt.org/t/whitelist-hostnames-for-... [3]https://community.letsencrypt.org/t/letsencrypt-ip-addresses...
Re: Should you use Let's Encrypt for internal hostnames?
#104If somebody gets any access to your local network, there are plenty of ways to enumerate them, and if they can't get access, what's the big deal?
I get that you may want to obfuscate your infrastructure details, but leaking infrastructure details on your server names is quite a red flag. It should really not happen. (Instead, you should care about the many, many ways people can enumerate your infrastructure details without looking at server names.)
Re: Should you use Let's Encrypt for internal hostnames?
#105Another nuisance is that unencrypted port 80 must be open to the outside world to do the acme negotiation (LE servers must be able to talk to your acme client running at the subdomain that wants a cert). They also intentionally don't publish a list of IPs that LetsEncrypt might be coming from [1]. So opening firewall ports on machines that are specifically internal hosts has to be a part of any renewal scripts that r…
But it is possible to have initial certificates without opening anything: https://gruchalski.com/posts/2021-06-04-letsencrypt-certific... From there, it’s possible to use HTTPS negotiation.
Re: Should you use Let's Encrypt for internal hostnames?
#106We 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…
Having an internal CA is a lot of work, if you want to do it properly and not just for some testing. It is still rather hard to setup HTTPS properly without resorting to running a lot of infrastructure (DNS/ VPN or some kind of public server), that you wouldn't need otherwise.
Re: Should you use Let's Encrypt for internal hostnames?
#107you 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 pe…
There's a company called Venafi that makes a product that lives in this space. It tries to auto-inventory certs in your environment and facilitates automatic certificate creation and provisioning.
From what I hear, it's not perfect (or at least, it wasn't as of a few years ago); yeah, some apps do wonky things with cert stores, so auto-provisioning doesn't always work, but it was pretty reliable for most major flavors of web server. And discovery was hard to tune properly to get good results. But once you have a working inventory, lifecycle management gets easier.
I think it's just one of those things where, if you're at the point where you're doing this, you have to accept that it will be at least one person's full-time job, and if you can't accept that... well, I hope you can accept random outages due to cert expiration.
Re: Should you use Let's Encrypt for internal hostnames?
#108Re: Should you use Let's Encrypt for internal hostnames?
#109Earlier quoted context omitted.
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.
I don't go that extreme - my employer is free to install their own root CA on devices they own and supply. I understand some startups are a bit more "Go get your own computer". I think if they paid for it, it's still their device, but once you pay for it out of your own cash, yeah, mdm or root certs are a no go.
I should note that I'm a contractor and I always bring my own tools, which includes the computer. That said, I still prefer to use my own device where I can. It's got the tools I use, configured how I like them, and I'm very familiar with all its quirks which means I have less context switching.
I have worked for clients with tighter regulation controls where I was required to use designated devices for certain tasks but that's been pretty much all of it.
I would rather not have to carry 2 computers around just because an organisation can't trust me to use my own computer, despite having hired me for a substantial amount of money to operate their production infrastructure.
Re: Should you use Let's Encrypt for internal hostnames?
#110Earlier 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…
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.