CloudFlare is a good place for beginners to start. Setting up a reverse proxy can be daunting the first time. Certainly better than no reverse proxy.
That being said, having your own reverse proxy is nice. Better security since the certificates are controlled by your server. Also complex stuff becomes possible.
My traefik uses keys encrypt wild card domains to provide HTTPS for internal LAN only applications (vault warden) while providing external access for other things like seafile.
I also use traefik with authentik for single sign on. Traefik allows me to secure apps like sonarr with single sign on from my authentik setup. So I login once on my browser and I can access many of my apps without any further passwords.
Authentik also allows oAuth so I can use that for seafile, freshrss and immich. Authentik allows jellyfin login with LDAP. (This last paragraph could be setup with CloudFlare as well).
This is the way. My setup is very similar except I only use authentik for Nextcloud. I don’t expose my “arr” services to the Internet so I don’t feel it necessary to put them behind authentik, although I could if I wanted.
Using Duo’s free 10 personal licenses is also great as it can also plug into authentik for MFA through the solution.
The primary reason to put authentik in front of arrs is so I don’t have to keep putting in different password for each when logging in. I disable the authentication for each of them in the app itself and then disable the exposed docker port as well so the only way to access it it via traefik + authentik. It has local access only so isn’t directly exposed to the internet.
10 free accounts on duo is very nice but I hate being locked into things (not self hosted). An open source or self hosted alternative to duo would be great.
I use caddy and it does everything for me, but my limited understanding is that the dns entry for which the certs are requested must point to the ip address at which caddy is listening. So if I have a DNS entry like internal.domain.com which resolves to 10.0.0.123 and caddy is listening on that address I can get a http connection, but not an https connection, because letsencrypt can’t verify that 10.0.0.123 is actually under my control.
*.local.domain.com -> has its own cert but the * can be anything and the same cert can be used for anything in place of the star as many times as you want and therefore doesn’t need to be internet accessible to verify. That way vaultwarden.local.domain.com remains local only.
There is an alternate verification method using an API key to your DNS provider, if it’s a supported one. That method doesn’t need any IP to be assigned (doesn’t care if there are A/AAAA records or where they point because it can verify the domain directly).
deSEC.io is a good example of a good, reputable and free DNS provider that additionally allows you to manage API keys. The catch is that they require you to enable DNSSEC (their mission is similar to Let’s Encrypt, but for DNS).
I see that you want to use the cert for intranet apps btw.
What I did was get two LE wildcard certs, one for *.my.dom and one for *.local.my.dom. Both of them can be obtained and renewed with the API approach without any further care to what they actually point at.
Also, by using wildcards, you don’t give away any of your subdomains. LE requests are public so if you get a cert for a specific subdomain everybody will know about it. local.my.dom will be known but since that’s only used on my LAN it doesn’t matter.
Then what I do for externally exposed apps is to point my.dom to an IP (A record) and either make a wildcard CNAME for everything *.my.dom to my.dom, or explicit subdomain CNAME’s as needed, also to my.dom.
This way you only have one record to update for the IP and everything else will pick it up. I prefer the second approach and I use a cryptic subdomain name (ie. don’t use jellyfin.my.dom) so I cut down on brute force guessing.
The IP points at my router, which forwards 443 (or a different port of you prefer) to a reverse proxy that uses the *.my.dom LE cert. If whatever tries to access the port doesn’t provide the correct full domain name they get an error from the proxy.
For the internal stuff I use dnsmasq which has a feature that will override all DNS resolves for anything ending with .local.my.dom to the LAN IP of the reverse proxy. Which uses the *.local.my.dom LE cert for these ones but otherwise works the same.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
CloudFlare is a good place for beginners to start. Setting up a reverse proxy can be daunting the first time. Certainly better than no reverse proxy.
That being said, having your own reverse proxy is nice. Better security since the certificates are controlled by your server. Also complex stuff becomes possible.
My traefik uses keys encrypt wild card domains to provide HTTPS for internal LAN only applications (vault warden) while providing external access for other things like seafile.
I also use traefik with authentik for single sign on. Traefik allows me to secure apps like sonarr with single sign on from my authentik setup. So I login once on my browser and I can access many of my apps without any further passwords.
Authentik also allows oAuth so I can use that for seafile, freshrss and immich. Authentik allows jellyfin login with LDAP. (This last paragraph could be setup with CloudFlare as well).
This is the way. My setup is very similar except I only use authentik for Nextcloud. I don’t expose my “arr” services to the Internet so I don’t feel it necessary to put them behind authentik, although I could if I wanted.
Using Duo’s free 10 personal licenses is also great as it can also plug into authentik for MFA through the solution.
The primary reason to put authentik in front of arrs is so I don’t have to keep putting in different password for each when logging in. I disable the authentication for each of them in the app itself and then disable the exposed docker port as well so the only way to access it it via traefik + authentik. It has local access only so isn’t directly exposed to the internet.
10 free accounts on duo is very nice but I hate being locked into things (not self hosted). An open source or self hosted alternative to duo would be great.
How do you get certs for internal applications?
I use caddy and it does everything for me, but my limited understanding is that the dns entry for which the certs are requested must point to the ip address at which caddy is listening. So if I have a DNS entry like internal.domain.com which resolves to 10.0.0.123 and caddy is listening on that address I can get a http connection, but not an https connection, because letsencrypt can’t verify that 10.0.0.123 is actually under my control.
You are completely correct…for normal certs. Internal domains require a wild card cert with DNS challenge.
This video explains how to set it up with traefik
https://youtu.be/liV3c9m_OX8
I’d bet caddy can do something similar.
Basically you have:
There is an alternate verification method using an API key to your DNS provider, if it’s a supported one. That method doesn’t need any IP to be assigned (doesn’t care if there are A/AAAA records or where they point because it can verify the domain directly).
deSEC.io is a good example of a good, reputable and free DNS provider that additionally allows you to manage API keys. The catch is that they require you to enable DNSSEC (their mission is similar to Let’s Encrypt, but for DNS).
Thanks, good to know. I’ll see if can set that up.
I see that you want to use the cert for intranet apps btw.
What I did was get two LE wildcard certs, one for *.my.dom and one for *.local.my.dom. Both of them can be obtained and renewed with the API approach without any further care to what they actually point at.
Also, by using wildcards, you don’t give away any of your subdomains. LE requests are public so if you get a cert for a specific subdomain everybody will know about it. local.my.dom will be known but since that’s only used on my LAN it doesn’t matter.
Then what I do for externally exposed apps is to point my.dom to an IP (A record) and either make a wildcard CNAME for everything *.my.dom to my.dom, or explicit subdomain CNAME’s as needed, also to my.dom.
This way you only have one record to update for the IP and everything else will pick it up. I prefer the second approach and I use a cryptic subdomain name (ie. don’t use jellyfin.my.dom) so I cut down on brute force guessing.
The IP points at my router, which forwards 443 (or a different port of you prefer) to a reverse proxy that uses the *.my.dom LE cert. If whatever tries to access the port doesn’t provide the correct full domain name they get an error from the proxy.
For the internal stuff I use dnsmasq which has a feature that will override all DNS resolves for anything ending with .local.my.dom to the LAN IP of the reverse proxy. Which uses the *.local.my.dom LE cert for these ones but otherwise works the same.