markdown guide
 

Good question, especially if widened to 'how do I secure services in my local private network?' The article @nektro links to below regarding localhost (letsencrypt.org/docs/certificates-...) provides a lot of good advice while making some assumptions that readers understand how certificates work, so let's recap those assumptions :)

  • Certificates enable encrypted communication, by containing and transporting the public key of an asymmetric key pair, with the private key being held by the service that needs to be encrypted. This is the bit provided by local software (eg: certbot), generating key pairs and building certificates from them to be used by services on the local system (eg: web server).
  • Certificates can also be part of a tree of trust, known as a public key infrastructure (PKI), that assures communicating parties are who they say they are. This is the bit provided by LetsEncrypt, who perform checks against services exposed on the public internet to assure that a claimed domain name is owned by the claimant, before digitally signing the claimants certificate. This signature can be checked by a client system receiving a certificate (eg: web browser) as having been signed by an already trusted entity (aka a trust root), in this case LetsEncrypt. Importantly this only works for public internet domains.

So what can we do for private networks? The LetsEncrypt article has a few suggestions, as does the ASUS article linked by @bgadrian with varying levels of hacky-ness vs. complexity:

  • Use public certificates (ASUS), give your local devices public internet names (and possibly make them accessible from the 'net). This breaks the 'private' bit in the question somewhat, and could be re-phrased as "don't run a private network" - hmmn.
  • Sign your own certificates (aka self-signed), usually at the point where they are generated: LetsEncrypt provide a sample openssl command for this. We get the encryption, but there is no tree of trust for client devices to check, so typically users will have to 'permit' or 'add an exception' to use a service with a self-signed certificate. The LetsEncrypt articles points out another risk here, where the self-signed certificate is manually added to the client as a root of trust to avoid unwanted user interaction, and frequently includes the private key as well as the public one - thus leaking private keys to users. Doh! This also becomes difficult to manage (it doesn't scale well) in larger environments.
  • Run your own certificate authority (aka CA), using freely available software (LetsEncrypt suggest minica), to sign all the certificates you use in your private network, while adding the CA's root certificate as a root of trust to client devices. This becomes more scalable at the cost of running a CA, but packages like minica make this reasonably easy. You typically find the IT services team in larger organisations do this already, including the local CA cert(s) in gold builds of operating systems used by the staff, so they can operate secure internal services (eg: webmail) easily. This is also how my organisation secures the internal networks of deployed products, typically using obviously private domain names like .local.

Hope this helps!

 
 

I'm not really sure how that would work. The router would need to request an address for 192.168.1.1, but the LetsEncrypt servers would require proof that you own that address, but since it's a local address, they can't do a dns lookup, or send an http request to do the veriication.

 

I've since seen here that they aren't able to produce certificates that aren't a part of public DNS. So names like localhost and 192.168.x.x are currently not possible for Let's Encrypt. Do you think they'll add this in the future? Or potentially create "global" certs that any service running on a local network could use?

 

Breaking this down:
Do you think they'll add this in the future

How would you propose that Let's Encrypt validate my ownership of 192.168.1.1? They need to contact that IP address to check I own it - but their 192.168.1.1 doesn't refer to the same machine as mine.
Does that make sense?

Or potentially create "global" certs that any service running on a local network could use
So now, I open 192.168.1.1 in my browser, or let's say 10.45.214.12. I get back a valid Let's Encrypt TLS certificate for that IP. I'm certain that I'm talking to the machine on my LAN, or corporate WAN, with that IP address, right?
Not quite - how do I know someone hasn't rerouted the traffic to a machine they control - say some kind of hacker who already has a foothold in the network.
If Let's Encrypt publicly post private keys and certificates for all the private IP addresses in existence, I can never be sure if I'm talking to the machine I want to talk to, or another machine that happens to have the same private key downloaded from Let's Encrypt!

 

If the attacker is connected to your network, and intercept your traffic then is too late :))

Some routers already have this option asus.com/us/support/FAQ/1034294/

I think that by exposing the router admins to the internet is a bigger threat than not using a secure connection in your LAN.

Classic DEV Post from Aug 26 '18

What are the hardest programming languages you have ever learned?

For me it was C and Haskell and for completely different reasons. Coming from ...

Meghan Denny profile image
22. Local trans witch who uses a staff by night and a keyboard by day.

Hey there reader...

Do you prefer sans serif over serif?

You can change your font preferences in the "misc" section of your settings. ❀️