30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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.
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 :)
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:
Hope this helps!
Thanks for the amazing response!