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

171–180 of 198 posts

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

#171

Post by Macha »

aaomidi wrote: post #127
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…

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)

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

I even mentioned that in my post ;)

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

#172

Post by mmalone »

KronisLV wrote: post #169
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…

> Several comments here mention running your own CA. You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/ In comparison, have a look at…

I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress.

We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environments. We've started building out a management UI there, and it does map to the CLI as you've described :).

[1] https://github.com/smallstep/certificates

[2] https://github.com/smallstep/cli

[3] https://smallstep.com/certificate-manager/

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

#173

Post by mmalone »

nickf wrote: post #147
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.

This is not a technical limitation though. It's a policy limitation.

In theory, a name-constrained intermediate for `.example.com` has no more authority and poses no greater risk than a wildcard leaf certificate for `.example.com`. In both cases the private key can be used to authenticate as any subdomain of `example.com`.

But, name constraints are verified by relying parties (the clients and servers that are actually authenticating remote peers using certificates). It's hard to be certain that everything has implemented name constraints properly. This is, ostensibly and as far as I know, the reason CA/Browser forum hasn't allowed name constrained intermediates.

At some point it probably makes sense to just pull the bandaid off.

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

#174

Post by tialaramex »

justusthane wrote: post #130
tialaramex wrote: post #111

Earlier quoted context omitted.

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?

A wildcard is a name consisting of a single asterisk (matching any label) instead of the first label of a DNS name inside an eTLD+1. [Historically some other wildcards existed but they're prohibited today]

But SANs are just names (that's even what it stands for, "Subject Alternative Name" the word alternative is because this is for X.509 which is part of the X.500 directory system, in which names are part of the X.500 hierarchy, while these names are from the Internet's naming systems DNS and IP addresses which could be seen as an alternative to that hierarchy)

So in changing both the names, and the keys, you're just getting a completely different certificate, maybe the pricing is different for you than purchasing more certificates, but these certificates aren't in any technical sense related to the other certificate.

It's a problem to use nomenclature that's completely wrong in a technical discussion like this. If you call the even numbers "prime" you shouldn't be surprised at the reaction when you claim "half the natural numbers are prime" in a thread about number theory.

[Edited to fix eTLD to eTLD+1 obviously we can't have people issuing wildcards directly inside an eTLD]

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

#175

Post by infogulch »

mmalone wrote: post #172
KronisLV wrote: post #169

Earlier quoted context omitted.

> Several comments here mention running your own CA. You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/ In comparison, have a look at…

I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress. We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environment…

GP's post prompted me to look into LE's ACME server implementation, Boulder [1], but it's pretty apparent that Boulder is not suitable for small scale deployments. But the smallstep "certificates" project seems to be a lot more reasonable for this use-case. Thanks for sharing, I'll definitely check it out!

[1]: https://github.com/letsencrypt/boulder

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

#176

Post by chrisweekly »

mojzu wrote: post #154
chrisweekly wrote: post #42

Earlier quoted context omitted.

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

My notes were pretty rough but I've tried putting them into a gist here: https://gist.github.com/mojzu/b093d79e73e7aa302dde8e335945b2... Which covers using step-ca with Caddy to get TLS certs via ACME for subdomains, and protecting internal services using client certificates/mtls I then install Tailscale on the host which is running the docker containers, and configure the firewall so that only other 100.* IP address…

Awesome, thanks!

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

#177

Post by fomine3 »

Hamuko wrote: post #34
dsr_ wrote: post #25

Earlier quoted context omitted.

Right. If you control the DNS, you can point names at any IP address and get appropriate certs for them. Therefore, you must protect your DNS infrastructure.

Isn't the need to protect your DNS infrastructure pretty obvious anyways even when ignoring certificate validation?

Obvious, but tend to be missed on small deployments.

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

#178

Post by tomlx »

KronisLV wrote: post #169
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…

> Several comments here mention running your own CA. You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/ In comparison, have a look at…

I never got why people think using tar is hard. Specify your archive File with f. want to eXtract it? add a x. want to Create it? add a c. Want it to be Verbose while doing that? add a v. if it's gZiped add a z. Granted, j for bzip2, t for listing is less obvious, but with that it's about everything you need for everyday usage and that more than suffices to disarm that bomb.

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

#179

Post by hashimotonomora »

marcosdumay wrote: post #104

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

Security is not boolean. What’s local can be public some day. Everything should be disclosed on a need to know basis.

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

#180

Post by itsjloh »

mmalone wrote: post #172
KronisLV wrote: post #169

Earlier quoted context omitted.

> Several comments here mention running your own CA. You know, i feel like more people wouldn't have a problem with actually doing this if it weren't so challenging and full of sometimes unpleasant CLI commands. To me openssl and similar packages to it feel like comparing the UX of tar vs docker CLIs, where the former is nigh unusable, as humorously explained here: https://xkcd.com/1168/ In comparison, have a look at…

I'm biased because I'm the founder of the company, but you should check out the certificate management toolchain (CA[1] and CLI[2]) we've built at smallstep. A big focus of the project is human-friendliness. It's not perfect (yet) but I think we've made some good progress. We also have a hosted option[3] with a free tier that should work for individuals, homelabs, pre-production, and even small production environment…

I really want to try and deploy smallstep at home but one stumbling block I always hit is deploying the CA (or ideally the mTLS certificate!) to end user devices like phones, laptops etc. Maybe I'm missing something entirely but I think I'd need a full MDM profile or setup for phones/mobile devices. Is this theoretically a lot easier than I'm making it? I'd just need an iPad, iPhone and MacBook.

Apart from that thankyou so much for what you've done and provided for the opensource community. The smallstep toolkit is truly fantastic.

Post reply on HN