It creates certs for each FQDN you define, but (unless you make other arrangements) only Caddy uses them.Does this give each reverse proxied service its own cert? Or just caddy?
Two possibilities:If not, how do you access services locally with a valid cert?
As the textbooks of old would say, this is left as an exercise for the reader--mainly because there are so many ways to handle it. The script will install Caddy with the desired DNS plugin, but configuring it is up to you.In the installation, don’t you have to define the token and zone info?
Even within the Caddyfile there is nothing about zone info.
As for HAproxy on pfsense, do I point the dns to the router IP?It creates certs for each FQDN you define, but (unless you make other arrangements) only Caddy uses them.
Two possibilities:
The bottom line in either case is that when you try to browse to ombi.yourdomain on a LAN device, that query hits your Caddy instance, which presents a valid TLS cert, handles the TLS termination, and then proxies the query to whatever other local resource is desired.
- Use local/split-horizon DNS to point those FQDNs to the Caddy jail
- e.g., say Caddy's running on 192.168.100.10, and you're using it to reverse proxy Ombi at 192.168.100.20. Your local DNS should point ombi.yourdomain to 192.168.100.10
- This naturally depends on your being able to configure your local DNS this way; most consumer routers are sufficiently brain-dead that you can't do it there. OPNsense and pfSense both allow it, or you could run a Pi-Hole instance for this purpose instead
- Hairpin NAT
- In this arrangement, there's no unique local DNS; ombi.yourdomain would resolve using public DNS to whatever your public IP is. Your router then turns that around, follows its own port-forwarding rules, and forwards the query to your Caddy jail, which then proxies it as usual.
- Downside here is that not all routers support it. OPNsense handles it well; I wasn't able to make pfSense do it, and I really don't have enough experience with others to say.
Note that I've mentioned both pfSense and OPNsense--if you're using either of those, they support running the reverse proxy directly on the router (you can even run Caddy on OPNsense), and I'd recommend that instead. But if your router doesn't support acting as a reverse proxy, this script and jail give you an alternative.
As the textbooks of old would say, this is left as an exercise for the reader--mainly because there are so many ways to handle it. The script will install Caddy with the desired DNS plugin, but configuring it is up to you.
Certainly the external DNS. For internal DNS, yes, but you'd want hairpin NAT working for that, I think.As for HAproxy on pfsense, do I point the dns to the router IP?
About the Caddyfile, does it use tab or spaces on the lines?Certainly the external DNS. For internal DNS, yes, but you'd want hairpin NAT working for that, I think.
I've been back and forth between pfSense and OPNsense for a while (there's a thread in the OT forum if you're interested), and went back to OPNsense recently--and there's a third-party plugin for Caddy on OPNsense. And even though the only GUI it offers is a checkbox to enable and a text field to enter the Caddyfile (which you have to write yourself), I find it much easier to use that than I did HAProxy on OPNsense, which I found easier to use than HAProxy on pfSense.
It doesn't strictly matter; Caddyfile syntax isn't nearly as demanding as, say, YAML. I use spaces; I'm not sure it prefers one vs. the other.About the Caddyfile, does it use tab or spaces on the lines?
If the point is to do this without external access, HAProxy on pfSense may not be the answer you're looking for--I don't know that it's designed to work in that scenario. But pfSense can get a cert using DNS validation, and HAProxy can use that cert, so it may do the job.Basically I’m looking to do local TLS with trusted certs, (for bitwarden etc) locally, without external access.
Lol. No I am using domains.I'm pretty sure if Caddy's running, it has a cert--it will fall over and die rather than run without one. But if you're browsing by IP rather than by name, you'll get a cert error.
{ # acme_ca https://acme-staging-v02.api.letsencrypt.org/directory email myemail.domain.com } mymain.domain.ca { tls { dns cloudflare longtokenthatisvalid } root * /usr/local/www/html file_server } my.domain.ca { encode gzip reverse_proxy 192.168.1.132 } myother.domain.ca { encode gzip reverse_proxy 192.168.1.133 }
ERR_SSL_PROTOCOL_ERRORAssuming you're browsing to mymain.domain.ca, this ought to work. What exactly is the error you're getting?
I get this error when browsing to any of the domains specified.ERR_SSL_PROTOCOL_ERROR
Yes it seems like its trying to get in via port forward with connection refused.Is that with Chrome? If so, does Firefox show any more detail? You can also check the log file in the jail--I think it's at /var/log/caddy/caddy.log.
Also Im finding that i have to edit the Caddyfile from the caddy jail instead of the apps/caddy directory.Do all of the domains i proxy need to be DNS validated?
As i understand only caddy DNS name needs that.
This is not the zone toke, but the API token.Yes it seems like its trying to get in via port forward with connection refused.
Im not sure, but the token is set up properly to allow DNS validation though...