Last time I considered using it, it was a pia for IIS servers because you have to manually renew every 30 days. Has this changed?
Should you use Let's Encrypt for internal hostnames?
61–70 of 198 posts
Re: Should you use Let's Encrypt for internal hostnames?
#62We 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 for us.
You can use something like EasyRSA to set up an internal certificate authority and generate server certificates signed by that certificate authority. I started using plain old OpenSSL for generating certificates, which EasyRSA uses under the hood, but I would have liked to start by using EasyRSA in the first place.
By the way, EasyRSA still isn't that easy, but it's better than using OpenSSL directly.
Re: Should you use Let's Encrypt for internal hostnames?
#63This 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.
> 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.
That's interesting. I wonder why Apple let that go by. I've had apps rejected, because they wouldn't use HTTPS. Maybe it's OK for a local WiFi connection. Even then, Apple has been fairly strict.
That said, I think that there are ways to register for exceptions.
Re: Should you use Let's Encrypt for internal hostnames?
#64Earlier 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?
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 looks like it works.
Heck, even with most other certificate issuers I can get a cert in similar ways when controlling DNS.
Re: Should you use Let's Encrypt for internal hostnames?
#65Why 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.
How do you define "properly"? What are some of the things someone can do wrong that Let's Encrypt does correctly?
Re: Should you use Let's Encrypt for internal hostnames?
#66My 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/2018/08/05/issuing-lets-encrypt-certi...
Re: Should you use Let's Encrypt for internal hostnames?
#67This 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…
For the project I'm working on currently, I use Charles Proxy's "Map Remote" function to map our UAT server's HTTPS url to my local machines HTTP URL. Also ngrok.com works really well if you need to give other people access to your dev environment.
> I use Charles Proxy's "Map Remote" function to map our UAT server's HTTPS url to my local machines HTTP URL.
This looks really interesting. Thanks! I'll see if I can get away with it.
Re: Should you use Let's Encrypt for internal hostnames?
#68Earlier 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.
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 processes I've seen. I'm not sure if there's in-house PKI tools supporting it?
Depends on your organisation size though. Maybe your in-house PKI is fine, but it's not for everyone!
[Note 0] Revocation is of course a mess. Let's Encrypt isn't without fault either, particularly when used internally, since OCSP responders will need to be accessible from client devices.
Re: Should you use Let's Encrypt for internal hostnames?
#69Earlier 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.
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.
Re: Should you use Let's Encrypt for internal hostnames?
#70This 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.
> perfect use case for wild card certs
I don't like distributing wild card certs as you then have a bigger problem if the cert is leaked.
When the cert is host specific you immediately know where the leak comes from and the scope of the leak is restricted.