Self hosting and HSTS preload domains
from wraith@lemmy.ca to selfhosted@lemmy.world on 15 Apr 18:44
https://lemmy.ca/post/42352731
from wraith@lemmy.ca to selfhosted@lemmy.world on 15 Apr 18:44
https://lemmy.ca/post/42352731
I have a domain that requires HSTS preload. I want to self host a few things using that domain (and subdomains), like nextcloud, pihole, and vaultwarden. How much of an issue is HSTS preload going to be if I do that? Will I need to set up a wildcard cert for everything? Or will it just work™️ because it’s internal or traffic is through a VPN?
I can’t find much about this so any help would be appreciated!
threaded - newest
Give those domains their own let’s encrypt certificate?
Why is your domain HSTS preloaded?
Google is the registry that owns the rights to the TLD. They require all of the domains they control to have HSTS preload enabled.
Then yeah, VPN or not, you’re going to need to enable TLS. What’s the issue with giving your subdomains a certificate?
I am fairly new to self hosting and just wanted to know if this was a big enough deal that I should just get a domain that doesn’t require HSTS preload. It’s one thing to tinker with an IP address on a local network for some unimportant project; it’s just intimidating to try it for real using a domain and hosting my own data.
I’m just a little nervous tbh. Thanks for the help!
Not much to be nervous about, you can’t fuck it up anymore than it already is since the HSTS is preloaded ;) ACME/Let’sEncrypt is pretty easy to setup
Required? That’s quite a commitment. Is this a Cloudflare thing?
All it really means is that you have to advertise some metadata about your max-age and (sub)domains associated with whatever the domain is. If you’re only planning to serve over HTTPS, and you have a bulletproof refresh workflow for your certs, it’s not going to be a huge issue. Clients need to respect HSTS first, so if your clients don’t check, it’ll still function.
If you’re just using internal or VPN traffic, there’s literally no point in using it EXCEPT to satisfy client requirements.
Can you expound a bit more on this requirement btw? Now I’m curious.
Google requires HSTS preload for all of their domains. Charleston Road Registry (their subsidiary), enforces this by adding the TLD to the HSTS preload list.
Here is the Wikipedia link to the TLD. It’s at the bottom.
Yeah, but you’re saying this is going to be used internal to you only, right? No public facing exposure?
I will need it to be available via a VPN or other means, but it’s not going to be any more public-facing than it has to be.
Right, so if it’s going to JUST be available over VPN, you don’t need to use a public TLD, DNS, or HSTS at all. Why use the public TLD with these requirements and expose private IP address space over public DNS if it’s sole purpose isn’t going to be consuming it publicly?
So I should just host it with an IP address instead of using the domain?
I hadn’t thought to do that, at least not for anything other than short lived internal-network-only projects and tests. An IT guy in the company I work for advised me to just get a domain and host with it/subdomains to make it easier to manage if I wanted to host multiple services.
Well, that’s the simplest way in practice, but not usability. Let me explain:
You control the IP address space once you’re connected to your VPN, and you control the various settings that connection makes, including DNS.
You have a network already, and a VPN of some sort, so that means you have a network device that is terminating that VPN. Is that a router you’re familiar with, or a box on your network?
I haven’t set up the VPN yet. I am getting as much info as I can before I start any work. For the sake of this discussion, it would be a box on my network.
Then you just need to run a DNS Forwarder, or something with a DNS forwarding capability. Your router most likely already has this.
DNS is essentially just a request and a response from a service. These can be public or private. A DNS Forwarder on your network will quickly respond if it knows that something is when asked, and return an IP address. If it doesn’t know what it is, it will ask the public services available.
So if you have an internal-only network, a VPN into that network, and a forwarder or other DNS service on that network, you just tell your VPN client of choice to switch to using that DNS instead of public once it connects. It’s a simple setting that every VPN solution supports, and actually makes you MORE secure by not using public DNS servers by default. You can add any record you want to said forwarder, and it will return whatever value you give it for a given domain name.
Here’s a simple workflow as an example:
All contained within your local network and VPN by extension.
No need for public DNS entries or TLDs and HSTS requirements.
Google owns a could of TLDs (.app, .dev, etc) and they preloaded all of them 😒
.
There are specific TLD which are required at the DNS level to be served over HTTPS.
.devis an example. The browser will physically not load a.devdomain over anything but HTTPS.Yeah, I got that, but this is an internal system OP is discussing. DNS forwarder and VPN. Solved.
I use a .dev and it just works with letsencrypt. I don’t do anything special with wildcards, I just let traefik request a cert for every subdomain I use and it works. I use the tls challenge which works on port 443, so I don’t think HSTS or port 80 matters, but I still forwarded port 80 it so I can serve an http->https redirect since stuff like curl and probably other tools might not know about HSTS.
I self-host on a .dev domain. It’s extremely simple with Caddy, as its HTTPS by default. Anything else is kind of a pain in the ass sometimes.
I also know of those who’ve had great success with Lego although I’ve never personally used it.
Yeah I use Lego, works great