17
submitted 1 year ago by root@lemmy.world to c/selfhosted@lemmy.world

So, I have a few services (Jellyfin, Home Assistant, etc) that I am running, and have been acessing via their IP's and port numbers.

Recently, I started using NGINX so that I could setup entries in my Pi Hole, and access my services via some made up hostname (jellyfin.home, homeassistant.home, etc).

This is working great, but I also own a few domains, and thought of adding an SSL cert to them as well, which I have seen several tutorials on and it seems straight forward.

My questions:

  • Will there be any issues running SSL certs if all of my internal service are inward facing, with no WAN access? My understanding is that when I try to go to jellyfin.mydomainname.com, it will do the DNS lookup, which will point to a local address for NGINX on my network, which the requesting device will then point to and get the IP of the actual server.

  • Are there risks of anything being exposed externally if I use an actual CA for my cert? My main goal is to keep my home setup off of the internet.

top 25 comments
sorted by: hot top controversial new old
[-] phi@lemmy.world 13 points 1 year ago

i have a similar setup at home. the way i did it was using certbot and dns verification. i pointed my domain's NSs to digitalocean's NS and then i downloaded the certbot-digitalocean-dns plugin, created an API key for DO and stored it somewhere and then certbot took care of everything else. nothing is exposed to the internet

[-] pacocascadero@lemmy.world 8 points 1 year ago

This is the way for services not exposed to the internet. Thera are multiple DNS providers supported (I use Cloudflare personally). At the other hand if the service is published to the internet HTTP validation is very simple to configure as well. I have stopped using Nginx as a reverse proxy and use Traefik for conteinerised services or Caddy for the rest. Both proxies support ACME protocol out of the box.

[-] root@lemmy.world 2 points 1 year ago

Very nice! And you don't have to worry about adding the cert to each device that wants to use the service, right? Since this isn't a self hosted CA.

[-] phi@lemmy.world 4 points 1 year ago

exactly. that was the main thing i wanted to avoid. i also have nginx-proxy-manager in front of all my apps which also automates some things (like requesting new certs or renewing them when the time comes)

[-] jason@sh.itjust.works 0 points 1 year ago

Here’s a script to do it with several different DNS providers: https://github.com/acmesh-official/acme.sh I personally set the renew as a weekly cronjob and never have to think about it.

[-] root@lemmy.world 1 points 1 year ago

Ooo, very nice! If I use that script, can I generate certificates for a made up domain within my network (eg *.homelab), or do I need to use a domain I actually own?

[-] jason@sh.itjust.works 2 points 1 year ago

It would have to be a domain you actually own

[-] root@lemmy.world 1 points 1 year ago

Got it, thank you!

[-] Omripresent@leddit.social 5 points 1 year ago

Shouldn't be any risk if it's all local.

For an internal domain you'll need to set up your own internal CA to sign certs for your fqdns. The risk comes from any mishandling of that new CA since you'll need to install it as a trusted root on all of your devices and if someone gets a hold of it nothing would stop them from creating a MITM attack for let's say yourbank.com

If you have the CA's key under lock then you should be good.

[-] pacocascadero@lemmy.world 5 points 1 year ago

Don’t use internal domain, use standard domain + split DNS instead. Much simpler to handle certificates for internal services with ACME protocol.

[-] preciouspupp@sopuli.xyz 2 points 1 year ago

Yes, use a split horizont setup.

[-] root@lemmy.world 2 points 1 year ago

Gotcha. Yeah I read about doing a self-hosted CA, but then I have to add the cert to every device that needs access to the service, which I don't think the family would be thrilled about. I was going to use the cert generator in NGINX and use the key from my actual domain. This way I don't need to add the certs manually.

My only worry is exposing something accidentally, but if my firewall rules prevent any outside access from my services (Jellyfin, Nginx, Homelab, etc) and the only thing with internet is the device accessing it (a laptop or TV), then I think I should be ok..

[-] Omripresent@leddit.social 1 points 1 year ago

If you have a domain you own that's the way to go, I went by your .home naming assuming that's what you're using. Since .home can't be registered similar to .local, LetsEncrypt wouldn't be an option.

I have a split DNS setup on my end so a service like jellyfin would resolve only internally since I want to limit it, but others would be both public and internal.

[-] dan@upvote.au 1 points 1 year ago

For an internal domain you’ll need to set up your own internal CA

No real need to run your own CA. As long as you have an actual domain name, you can use Let's Encrypt with DNS challenges to get certificates for internal servers.

[-] Aurailious@beehaw.org 5 points 1 year ago

If you use Let's Encrypt, or any public CA, all of your domains and certificates will be public. You can use a wildcard to avoid revealing subdomains. There is a website that you can use to search what is available, but I don't remember what it is.

I suspect there aren't any serious risks to having that information revealed. The only real reason would be privacy against which services you are using on that domain.

[-] phi@lemmy.world 4 points 1 year ago

yeah true but if the DNS records aren't actually pointing anywhere then there's no real threat no? because everything stays in the internal network

[-] DrJenkem@lemmy.blugatch.tube 1 points 1 year ago

For the most part yeah. Unless you don't want people to know you're hosting a particular thing for whatever reason.

[-] Aurailious@beehaw.org 1 points 1 year ago

You have to use a public DNS registrar, and that DNS record has to point to your public IP if you want to automate to a public CA. All of my subdomains are in my local DNS server though and I use a wilcard for them. So no one externally can go to jellyfin.mydomain.com, but they could go to www.mydomain.com to my IP, but that doesn't forward on my router either.

But also only automated scrappers are going to look for my domain too and they are going to be blocked in the same way automated scrappers for residential IPs are blocked. I could be wrong, but I don't think there are ways to bypass security with knowing the domain name tied to an IP.

[-] DrJenkem@lemmy.blugatch.tube 3 points 1 year ago* (last edited 1 year ago)

This is probably the site you're thinking of - https://crt.sh/

[-] preciouspupp@sopuli.xyz 3 points 1 year ago

People can see what domains you use with TLS, but that could be OK: https://letsencrypt.org/docs/ct-logs/

[-] DrJenkem@lemmy.blugatch.tube 4 points 1 year ago

You can use a wildcard cert to avoid leaking subdomains.

[-] BlackXanthus@lemmy.world 3 points 1 year ago

Have you looked at something like :

https://letsencrypt.org/

It offers a free CA for self-hosted stuff. It does TLS certs, and others. It's very useful for avoiding the high fees

[-] root@lemmy.world 3 points 1 year ago

I have heard of this, but I think if you self-host a CA, you have to add the cert to every device that wants access to the service right? For example, I'd have to add it to my TV if my TV connects to Jellyfin, to my laptop if my laptop needs access to Home Assistant, etc. I'm not sure my family would like that XD

[-] Katrina 2 points 1 year ago

Lets encrypt certificates are trusted by everything I've tried.

[-] ehleks@lemmy.javant.xyz 2 points 1 year ago

You can use duckdns.org to create a subdomain, set the domain name to your local IP and then use let’s encrypt DNS challenge to issue a trusted certificate

load more comments
view more: next ›
this post was submitted on 14 Jun 2023
17 points (100.0% liked)

Selfhosted

40360 readers
306 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS