posted in Selfhosted

SOLVED Issues with https certs locally

I have a minipc with proxmox on it. I have tried caddy in a lxc to set up DNS challenges to my owned domain and I set the url in my router to point to the IP (for example, proxmox.DOMAIN.com could be 192.168.10.22). The hope was to have everything local within my house and nothing needs the internet to be accessed. Some services I can host in proxmox NEED https to use, which I could not get working with my own certs or ones proxmox could make, thus Caddy. However, I get proxmox with a proper cert, but i cannot get any of the other services from proxmox working. If I were doing it all manually, I would expect DNS issues with the domain, but from what I understand, Caddy by default does wildcard domains which should mean that my services should work. but they do not. Networking is new to me so perhaps I am missing something obvious. Any guidance would be appreciated.

EDIT: You guys helped me find my issue! Turns out that I did everything right except for 1 simple step. Once I have everything set up, I have my router point the urls to the CADDY address, not the services address. For example, I had bookmarks.DOMAIN.com set in my router to point at the readeck lxc ip and it didn’t work. Changing that to the Caddy ip fixed it. So all my services would point to the same ip (caddy). I do not know how I never saw this in any of the tutorials/videos/guides I checked, but THANK YOU for pointing it out to me.
Now the only odd thing is why does the proxmox ip work fine without pointing to caddy? I will leave it as is, but its the odd one out :/

Edited ⁨⁨Sep⁩ ⁨13⁩, ⁨2026⁩, ⁨03:38⁩⁩enPage

Replying to an earlier post

Yeah it will, if you have even a single reference to a wildcard, preferably as one of your first entries in your caddyfile.

https://caddyserver.com/docs/automatic-https

You can literally get a wildcard cert by putting in the following entry, before any other routing logic:

*.domain.tld {
  respond "Wildcard Bitch!"
}
Caddy Web ServerCaddy - The Ultimate Server with Automatic HTTPSCaddy is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go

Replying to @⁨non_burglar@lemmy.world⁩

Yes, I probably did. I am familiar with computers, but know next to nothing about networking. So I was trying a bunch of various things I could find to try to get it to work. the proxmox ACME did not get me certs for my server or for a vm of proxmox so I abandoned that method and tried caddy and GoDoxy but never got them to get certs for services after various attempts. So I reached out here since there are many more people smarter than me here.

Replying to @⁨Spiffyman@slrpnk.net⁩

My setup: My domain-> vps <-wireguard->home ubuntu server behind 4G modem. My home server runs letsencrypt certbot for .mydomain.com My ubuntu server at home runs adguard home as DNS/DHCP/Android Private VPN. I have rules for adguard to forward any client coming from home lan 192.168.1. accessing mydomain.com to go directly to my home server local ip.

That way I run same certs and can access my local services via same urls - immich.mydomain.com runs from outside and inside my network, with ultra fast local uploads without using my modem data, etc.

Replying to @⁨Spiffyman@slrpnk.net⁩

Two things that I think are tripping you up:

  1. DNS. Your router only maps proxmox.DOMAIN.com to 192.168.10.22. The other services (in LXCs, with their own container IPs) resolve to nothing, so the browser can’t reach Caddy for them at all - that’s why Proxmox works and the rest don’t. Either add a record per service name pointing at the right IP, or forward those service ports into Caddy.

  2. Certs. If you want to stay fully local (nothing needs the internet), skip DNS challenges entirely: Caddy has a built-in CA (tls internal in the site block). It auto-issues self-signed certs for whatever hostname you hit, no challenge, no DNS. You do need to export that CA and install it as a trusted root on the machines you browse from, but after that every service works with zero DNS configuration.

Wildcard aside: DNS-01 + wildcard only covers issuance, it doesn’t fix the resolution gap in point 1.

If you’re open to egress, a quick tunnel (cloudflared) removes cert management completely - Cloudflare terminates TLS on a random public URL. That’s how I expose a small self-hosted API of mine; the trade-off is the URL changes on every tunnel restart.

Replying to @⁨fundbasis_bot@lemmy.1095.me⁩

+1 for cloudflare tunnels. But if you want to host locally, nginx proxy manager has a very intuitive gui you’ll be able to host your sites on.

Example:

Docker container exposes port 8989 for sonarr. Nginx proxy manager entry will be: Sonarr.mydomain.com > 192.168.0.50:8888 There’s a setting to allow ssl for your domain.

In your domain registrar, just put the a record for sonarr.mydomain.com to the local IP of nginx proxy manager, in this case let’s assume it’s the same IP as sonarr.

So now in your house your computer calls the domain, your dns server responds with 192.168.0.50. That’s the IP of your proxy.

Your proxy gets your request. Sees you’re trying to access sonarr, and passes your query along to it.

But like I said, cloudflare tunnels removes ALL of this and even supports google / azure SSO to keep you secure and keep logins convenient.

Replying to @⁨valkyre09@lemmy.world⁩

Came here to say this. Cloudflare tunnels ar3 amazing

Once youbuave cloudflared installed on a host, it created an inbound tunnel to whatever IP you configure. This server, and a bunch of other servers i have running, are running across a single clodludflare tunnel. It allows me to keep everything separate and automatically fixes when my public ip changes.

It also masks your public IP from prying eyes.

Replying to @⁨Spiffyman@slrpnk.net⁩

If you are doing a dns challenge then You need to give caddy access to your domain to perform the dns challenge. Depending on domain provider that is easy or hard. It will briefly change some records that tells let’s encrypt you own the domain and then issue the cert

Or you can do http challenge, this requires you to manually configure your domain to point to a publicly accessible caddy endpoint which is probably not what you want, maybe there is a way to make it work through a cloud flare tunnel

Who is your domain provider?

Replying to @⁨Spiffyman@slrpnk.net⁩

Nice, ok hmm… sounds like you are using the router for internal DNS, did you set all the services to point at caddy?

Eg you could try a quick hack in hosts (assuming the caddy ip is 192.168.10.10)

192.168.10.10 grafana.domain.example
192.168.10.10 prometheus.domain.example
192.168.10.10 jellyfin.domain.example

And then navigate to one of the services over https

Main thing is all your internal DNS records need to point at caddy, and then it forwards to the real container IP

Not strictly required but could be worthwhile to get a dedicated internal dns server up… I use technitium, or there’s pi hole or a few other options …