Mind that I am very noob into self-hosting, reverse proxies and the like
When I saw that Caddy automatically handled the HTTPS thingies I was like “this is my moment then to go into self-hosting”. Caddy seemed so simple.
Turns out… I am suddenly discovering that the connection between the caddy machine and the Home Assistant machine (both in the local network) is non-encrypted. So if another appliance in my local network went rogue… bum, all my info gets leaked… right?
This might sound weird because it might actually be super-duper complicated but… how come in 2025 we still don’t auto-encrypt local comms?
Please be kind. Lot’s of love. Hopefully I’ll dig my way to self-hosting wisdom.
Your choice I don’t encrpt local comms because it is all in machine. Go to proxy and proxy goes to another container but never leaves the machine but don’t see a reason to encrypt. Even HA in a seperate machine what are they going to see.
Yes and no. Usually you do HTTPS termination on the same device, so the traffic doesn’t actually go out onto the network. To sniff it, you’d have to be root on the machine, in which case you’re already compromised.
Depends on what you want. You can have the application have an https certificate which could either be one issued my a globally trusted issuer or could just be a self issued certificate that caddy is configured to trust. And caddy can then add the globally trusted certificates from let’s encrypt or whatever. But that definitely requires extra steps. Just, how secure do you want to be?
If your concern is IoT devices, TVs, and the like sniffing on your local traffic, there are alternatives, and some of them are:
- https from reverse proxy to service.
- VLANs or Different LANs for IoT and your trusted devices (I do this one).
- Internal VPN connection between devices (like WireGuard), so the communication between selected devices is encrypted.
If you want everything on your local lan to have SSL, look into Step CA. Its not completely beginners friendly, but if you’re serious about selfhosting you will manage to set it up :) Caddy works with it also, and their examples are very helpful.
Or simply create your rootCA, IntermediateCA, keys and certifictes with openSSL.
Neither of those are begginer friendly but openSSL is probably a bit easier to get started. There’s a nice book with openSSL (if you are interested I migh look how it’s called) and the last chapter is all about how to create your mini-CA and everthing else to serve your proxy with valid certificates for your homelab.
The reason i chose Step CA over openSSL is because with step CA you can automate certificate renewal without any manual intervention. I don’t know how that would work with openSSL except some heavy scripting?
Yeah thats correct !
I Wouldn’t say heavy though (maybe I see it that way because I got a bit better with bash and the like :p) because you can make use of CRL to revoke your certificates and renew them very easily with your intermediate and ready to use config files.
But yeah, there isn’t any automated way to manage certificates like Smallstep does :)
You mentioned a book though… Now i’m curious ;-)
I’m not familiar with Caddy at all - I use Traefik for a reverse proxy, and my knowledge there isn’t huge either. But I think that your reverse proxy terminates TLS (HTTPS) from the world and then forwards traffic to the appropriate service on your local network using HTTP by default - but if your local service can handle TLS, I think you can configure your reverse proxy to forward the traffic to it using TLS.
Like others are saying, a simple fix to this is to setup the homeassistant machine for https & a self signed cert. Then on the Caddy machine you can configure the https to not verify the origin. That would make the communications more robust, but I think it is still vulnerable to MITM attacks.
Even better: generate a key pair to use for HA, and give the public part to Caddy to use for authenticating the HA server. If HA supports it, you could even generate a client certificate Caddy could use to authenticate against HA.
if you use a simple
reverse_proxy service
it isn’t https. It will make the connection using good old http. If you use
reverse_proxy https://service
or
reverse_proxy service:443
it will be https (443 is the port for https)This does not mean, that any other device can just intercept the packages. It depends on the routing; your router and switches are smart. They know on which cable a device is and only send it to that cable. If anything else is on that cable, they can intercept this message. Any devices not on that cable can’t.
So if you’re like me and have Caddy and HomeAssistant on the same physical server as virtual machines, you realistically shouldn’t have to worry, as the traffic should never leave your server.
There are multiple reasons but the most important one is: You didn’t enable it.
Caddy fully supports https to the reverse proxy targets, though you’d have to get those targets trusted certificates otherwise caddy wouldn’t connect.
The default protocol for backends is http, most of the time this isn’t a problem because:
- The web server runs on the local machine
- The web server runs in containers/vms on the local machine
- or is running in a VM and has a direct virtual connection with the caddy vm
- The connection to the Backend is encrypted with a VPN
- Caddy and the web server are directly connected or connected through an otherwise isolated network
Because https requires certificates that are somewhat difficult to set up for internal servers (and were even harder to get before) the default mostly is just to encrypt on another layer of the stack. Afaik at least.
Good write-up. I also have Caddy with no HTTPS to the back end service, and was just thinking “I should set that up” when I realized…all the services are on the same ProxMox host, so that have direct access via virtualization, and so won’t be in clear text over the network at all (or at least I think so). Thanks!
