Https on local lan only!? reddit / selfhosted ---------------------------------------------------------------------- I_want_pudim · 2023-11-03 20:43 Hi there, Whenever I search HTTPS on lan I find videos telling or articles telling me about configuring external services so I can access my local machine by an external domain name through the internet, install some proxy, have a dedicated ip and so on. But I don't want that, without exposing anything, and without even going to the internet, is it not possible to access my local machines through https? Like https://10.0.0.1:8080 My only option is really going online? Thanks! ---------------------------------------------------------------------- webtroter · 2023-11-03 20:50 self-signed certificates is what you want. ---------------------------------------------------------------------- thekrautboy · 2023-11-03 21:26 Basically identical post: https://www.reddit.com/r/selfhosted/comments /17n4p1w/obtaining_valid_ssl_certs_for_internal_network/ ---------------------------------------------------------------------- clintkev251 · 2023-11-03 21:35 You can still use a reverse proxy and (if you own a domain) letsencrypt for certificates without exposing anything to the internet. If you don't own a domain you'll need to use self-signed certificates and these will not be trusted by default by any of your devices, you'd need to modify the truststore for all of your devices to have them trust your CA ---------------------------------------------------------------------- Point-Connect · 2023-11-03 21:35 Checkout this video from Wolfgang's channel, everything is free https://youtu.be/qlcVx-k-02E?si=SPKIg62tV4DUT-XS I don't expose any of my stuff to the Internet but use adguard home for my dns, added a rewrite for my duckdns.org domain (you can put an internal IP address as the return address of duckdns) to my server which hosts nginx reverse proxy manager which then picks up the request and sends to along to whatever internal service I'm trying access, SSL and all. So for example, say I want to get to jellyfin, I go to jellyfin.MyDomain.duckdns.org. adguard home sees *.duckdns.org and forwards it along to my internal servers IP where nginx reverse proxy manager sees jellyfin.MyDomain.duckdns.com. I tell it to forward all that traffic to 192.168.1.XX:YYYY and to use the wildcard SSL certificate we got in the video. This isn't accessible outside of my home network, im a network g novice to say the least and I was able to get it all working im an afternoon ---------------------------------------------------------------------- I_want_pudim · 2023-11-03 21:41 Thanks, I'll check it out and try it, looks promising. ---------------------------------------------------------------------- Ursa_Solaris · 2023-11-03 21:46 Let's separate and break down some concepts here. This will be wordy because I'm assuming as little preknown info as possible, so my apologies ahead of time if I cover things you already know. HTTPS doesn't require going online. It's just a method for websites to provide encryption to secure any data sent back and forth. You don't have to do *anything* external to make HTTPS work at a basic level; many things even do it out of the box with "self-signed certificates". HTTPS happens by the server having two parts of a certificate pair, the private half and the public half. The private half is secret and never leaves the server, the public half is sent to anybody who asks. Both of these certificates are linked; messages sent with the public half can only be read using the private half, and vise versa. You can open up Windows powershell or a Linux terminal and just make these certificates. There's plenty of basic guides online to make self-signed certificates using `openssl` commands, and they will work fine, especially on a LAN. The only issue is that you'll get a warning when you connect; your certificates aren't *trusted*. However, this presents a problem: how do you know that the certificate you just got from Facebook is *actually* from Facebook, and not some person sitting in the middle, reading all of your traffic and re- encrypting it so you don't notice, pretending to be Facebook in order to steal your passwords? We need a way to establish trust remotely, but we can't trust anything we download. The answer: Your computer and web browser is pre-loaded with the public half of many "root certificates" from various organizations called Certificate Authorities. These certificates are used to sign other certificates issued to websites with an unforgeable digital signature, which ensures that the certificate is known to be valid and was issued to the real owner of the website it's assigned to. This is why going to Facebook doesn't prompt that window complaining it's insecure. Facebook sends you a certificate signed by a higher authority, you verify the signature against your preloaded root certificates, and now we've established *trust*. There's no known way to forge the signature, and it's impossible for anybody to listen in or tamper with it because they lack the private certificate. The reason why people tell you to buy a domain is because the easiest way to get trusted certificates is to buy a domain name and use Lets Encrypt to create certificates. You don't actually have to expose anything to the internet in doing this; it's perfectly valid to do this solely for internal use. The root cert for Lets Encrypt is trusted everywhere, so all you have to do is get a cert from them and it automatically works. The alternative to gain trust entirely on your own is creating your own root certificate, using that to sign certificates, and then manually installing the root on every device that needs to access the websites. We do this at my workplace for our internal tools. It's a bit bothersome and more advanced work. I do recommend just spending the ~$30/yr on a domain just to save the headache, at least starting out. If you are working entirely internally, you don't *need* trust though. The chances of somebody hacking into your private network and performing a man-in-the-middle attack on you are extraordinarily low. Simply accept the untrusted connection the first time, and that should be that. The reason why people tell you to use a reverse proxy is twofold; one, it gives you a single point you have to apply the certificate instead of many. You can route all of your websites through it using a single certificate. Two, you can route the default https port (443) to any other port automatically, so you don't need to append `:12345` to an address. And third, using docker you can route to other docker containers without ever exposing them directly; this gives you a single point of control for much more advanced stuff like authentication, IP filtering, etc. You don't need a dedicated IP at all; if you do expose stuff externally, you simply need something regularly updating that IP. If you are only working internally, your external IP address is entirely immaterial; you don't even need an internet connection. If you have any questions at all, feel free to ask! ---------------------------------------------------------------------- sk1nT7 · 2023-11-03 23:19 Reverse proxy + valid domain name + ACME DNS challenge. No need to expose anything to the Interner or configure port forwardings. ---------------------------------------------------------------------- I_want_pudim · 2023-11-04 07:16 Thanks for the through explanation, you gave me a lot of material to study but I was able to understand many things already. And your presumption was right! Although I'm "from It", servers and networks are totally alien to me. Thanks! ---------------------------------------------------------------------- Ursa_Solaris · 2023-11-04 16:25 Hey no worries man, I am literally the only person in my IT department that understands this stuff. Server maintenance and security are a very specialized skillset. Not even our network guys know this stuff very well, even though this is very directly related to networking. ---------------------------------------------------------------------- miscUser2134 · 2023-11-04 18:45 Generate a Certificate Authority, and then generate a certificate signed by that Certificate Authority -- many projects available on GitHub to do this. Then install the Certificate Authority on your device (Windows, Mac or phone) and then install the Certificate on whatever service you are running. I use this to SSL all .lan on my network. If you are looking to run SSL for a service running on your computer for development or short-term reasons, then using Ngrok is a far easier solution. ---------------------------------------------------------------------- niagapahc · 2023-11-05 07:55 Check out Caddy. It's a reverse proxy that can generate and manage self-signed certificates for IPs and local domains automatically. I've found it much easier than doing everything manually, and everything is done locally. There's also a feature in some routers that lets you resolve configured URLs to an internal IP, although I forgot what it's called. You don't need a domain name to do this. That would make it so you can use say, https://server/ which would resolve to https://10.0.0.1