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

71–80 of 198 posts

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

#71

Post by reincarnate0x14 »

binwiederhier wrote: post #66

My company uses Let's Encrypt extensively for many thousands of customers edge devices which live in their own LAN. As long as the hostnames are random or at least not too telling there's pretty much nothing that you're leaking. Except for the internal IP address (10.x, 192.x,) and how many servers you have. If you can live with that then it's perfectly fine. I wrote about it a few years ago: https://blog.heckel.io/2…

If you have split DNS you're not even leaking internal addresses, the public name record just has to exist.

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

#72

Post by prashnts »

tzs wrote: post #49
ChrisMarshallNY wrote: post #21

This is an interesting topic, for me. I write iOS apps, and iOS requires that all internet communications be done with HTTPS. It is possible to use self-signed certs, but you need to do a bit of work on the software, to validate and approve them. I don't like doing that, as I consider it a potential security vector (you are constantly reading about development code that is compiled into release product, and subsequen…

> I write iOS apps, and iOS requires that all internet communications be done with HTTPS What if the app is on the same network as the server? I've got a Denon A/V receiver that has an HTTP interface and the Denon iOS app is able to talk to it. I've watched this via a packet sniffer and it definitely is using plain HTTP.

Yeah same with a couple of apps I use, WLED, and HomeAssistant both work on HTTP.

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

#73

Post by silvestrov »

YPPH wrote: post #56
tomc1985 wrote: post #53

Why not just be your own signing authority for internal domains? You can propagate your toplevel public cert with most enterprise network provisioning tools.

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.

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

#74

Post by egberts1 »

rocqua wrote: post #64
Hamuko wrote: post #34

Earlier quoted context omitted.

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

Besides, if I can change your DNS, I can change your HTTP responses as well. So control over DNS already lets me get a lets-encrypt cert for you anyway. Though it is slightly easier to notice if someone changes your DNS to point to a different server than if someone adds a TXT record. I say slightly because if I change your DNS to point at my server I can just proxy requests to your old server so everything still loo…

How often do one monitor their zone files and its updates?

Would you be able to catch new subdomains being created under your watch?

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

#75

Post by reincarnate0x14 »

tomc1985 wrote: post #53

Why not just be your own signing authority for internal domains? You can propagate your toplevel public cert with most enterprise network provisioning tools.

Not only is running your own CA a pain, there is also minimal support for restricting CA scope validity, so anyone that needs to communicate with you effectively ends up trusting your CA for anything and everything. For most anyone except your own trusting partners or coworkers that's a complete non-starter.

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

#77

Post by tedivm »

This is one area where I think AWS does a huge disservice by making their Private CA so expensive ($400 a month + cost of certificates). This ends up pushing people to use public domains instead of private ones, or relying on other solutions outside of AWS. If the cloud companies would make it as easy to get private certificates as public ones you wouldn't see as many issues like this.

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

#78

Post by dspillett »

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.

My method is manual-ish¹. One VM is in charge of getting the wildcard certificates. Other than answering DNS requests for validation and SSH it has no public face.

Each other machine regularly picks up the current outputs from there via SFTP weekly and restarts what-ever services. I'm not running anything that I need near-perfect availability on ATM, so it is no more complex than that. If wanting to avoid unnecessary service restarts check the for changes and only do that part if needed, and/or use services that can be told top reload certs without a restart.

This does mean I'm using the same key on every host. If you want to be (or are required to be) more paranoid than that then this method won't work for you unmodified and perhaps you want per-name keys and certs instead of a wildcard anyway. For extra carefulness you might even separate the DNS service and certificate store onto different hosts.

Not sure how you'd do it with unifi kit, my hosts are all things I can run shell scripts from cron on running services like nginx, Apache, Zimbra, … that I can configure and restart via script.

[1] “manual” because each host has its own script doing the job, “ish” because once configured I don't need to do anything further myself

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

#79

Post by Spivak »

YPPH wrote: post #68
justin_oaks wrote: post #65

Earlier quoted context omitted.

How do you define "properly"? What are some of the things someone can do wrong that Let's Encrypt does correctly?

Root certificate stored on offline HSM and intermediates on secure infrastructure. FIPS compliance. (Relatively) reliable revocation services. [See note 0] The result is security of issuance, that is near complete confidence that certificates will only be used for controlled domains (not necessary if you want to MITM of course). Also, ACME is generally easier and more reliable than other certificate rollover processe…

I mean sure but an org doesn’t really need that much security. If you’re not taking that much care with your API keys and db passwords then you probably don’t need it for certs either. Keep your root CA offline and in an air gapped backup, issue team specific intermediates with med length and keep your endpoint certs short.

You need as much security on your CA as the accounts in your org with the authority to replace them with your provisioning tools.

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

#80

Post by Spivak »

infogulch wrote: post #57
flatiron wrote: post #36

Earlier quoted context omitted.

If you have a large organization your containers are based off the orgs containers which has the CA in it. Same with VMs, Java, .Net, etc.

Maintaining golden container/vm images with root cert customizations is a pretty complex task that needs constant maintenance and customizations for new runtimes. Also this does nothing for unofficial devices (byo laptops, byod smartphones, ceo's ipad, guest laptops).

Hard disagree on that one. For 99% of your software it’s stuck the cert in your distro’s trust store and use the result as your base VM / container templates. Adding to the Java trust store is a 10 line script and never needs to be touched again. It’s not that it’s completely trivial but it’s so much less complex than every other thing your infra team does.

Random BYO devices I can understand but in your cloud / datacenter it’s so easy just because you control everything.

Post reply on HN