I bought an extra domain for our internal network.
$COMPANY_SHORT_FORM.network
Works really well and wie no longer have the issue of deploying root certs in devices.
Should you use Let's Encrypt for internal hostnames?
121–130 of 198 posts
Re: Should you use Let's Encrypt for internal hostnames?
#122I run my own internal CA.
Would not recommend to anyone that they use publicly-valid letsencrypt certs for internal hostnames, since certificate issuance transparency logs are public and will expose all of the hostnames of your internal infrastructure.
Re: Should you use Let's Encrypt for internal hostnames?
#123DNS names are public by nature. Split horizon, private roots, private CAs etc are a sign you are trying to bend things backwards. Just don't use sensitive DNS names.
disagree on that - it's entirely possible to have an openssl private root CA and private DNS that doesn't talk to the internet at all and exists in RFC1918 IP space with no gateway or route to the outside world. not just a matter of ACLs on things like DNS servers but those same servers/VMs not even having interfaces that have any way to get traffic to a global routing table.
split horizon I agree is risky.
Re: Should you use Let's Encrypt for internal hostnames?
#124This 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...
Re: Should you use Let's Encrypt for internal hostnames?
#125I will never understand the obsession people have with hiding their private server names. If 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, yo…
One of the examples given wasn't a server name, it was leaking potentially confidential information via the domain olympics-campaign.staging.example.org - in many environments its fine if people know project names, but NDAs are a thing, and you could end up in hot water if you accidentally leak a partnership between two companies before it's been announced.
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 world.
Re: Should you use Let's Encrypt for internal hostnames?
#126Several 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…
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- and homelab-level certificate woes. I'd really like to hear from a domain expert on how feasible it would be to automate for free public certs, ACME-style.
Re: Should you use Let's Encrypt for internal hostnames?
#127you 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 you're making your own root cert, you should use name constraints and block the issuance to certain DNS names.
https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
https://wiki.mozilla.org/CA:NameConstraints
Although... I have no idea if browsers/applications/openssl/etc actually verify this - but they should.
(Disclaimer I work at LE)
Re: Should you use Let's Encrypt for internal hostnames?
#128I'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
No post body was provided.
Re: Should you use Let's Encrypt for internal hostnames?
#129This 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
Chrome is giving me certificate errors. NET::ERR_CERT_DATE_INVALID
Re: Should you use Let's Encrypt for internal hostnames?
#130Earlier quoted context omitted.
When multiple CSRs [and thus multiple private keys] are involved you end up with multiple wildcard certificates. There is no sharing, technically speaking, but obviously the hostnames in all the wildcards are the same. However, that doesn't really buy you much in terms of security as any one of those wildcards can be used in an active network attack against any matching service if compromised. That is, unless you're…
They also say the "duplicate" "wildcards" have different SANs. Their whole narrative makes no technical sense, but presumably the situation is that they've technically got a very limited understanding of what they're doing and the people selling the product have understandably limited enthusiasm for trying to educate suckers who are buying a product. What's the line from Margin Call? Sold to willing buyers at the cur…
Sorry? I'm not sure why you're calling me a sucker, but the wildcard certificates that we purchase from DigiCert can be reissued as many times as we want using separate CSRs, and, yes, with different SANs. DigiCert calls this a "duplicate", but yes, obviously it is technically a new certificate. What is the problem with that?