Hello there (:
I know the really basics. I also installed caddy and use it as service, running a little test site… all fine.
But I want caddy to be my reverse proxy from outside (www) to my inside network. So when I browse for cloud.domain.tld I want to reach my intern server A with nextcloud running on it. www.domain.tld goes to server B with wordpress installed.
Caddy tries to get Certs for all the (sub)domains, but it can’t solve the challenge. That’s right, I know why. But I don’t know how I can tell caddy that caddy should do it on caddy’s own server.
Is this best practise, to use caddy as reverse proxy which handle the ssl certs? Some services I use don’t support SSL, so I would like to have a SSL connection till caddy, and the intern traffic can be unencrypted.
I hope my problem is understandable. I think I just need an example.
What you want to do is squarely within Caddy’s wheelhouse. It’s very good at it and very easy to get running in this manner. One of my own servers in fact reverse-proxies both Nextcloud and WordPress, incidentally.
Two main things need to happen for Caddy to solve an ACME challenge:
DNS for the domain in question needs to resolve to the Caddy host’s external IP address.
The Caddy host must accept connections on ports 80 and 443 and Caddy must be able to bind these ports.
Those are the first, most common hurdles for people getting Caddy running. If they’re both set up properly, you’ll need to get Caddy’s process output when it fails to complete the challenge; that will help tell us what went wrong.
Absolutely. I’d even wager that this exact use case (reverse proxy to non-SSL-capable - or even fully SSL-capable apps, for the purpose of serving multiple apps off one machine) is one of, if not the single most common usage of Caddy.
I use it extensively for this purpose. I have five Caddy servers around the internet, each serving four or more different sites, probably 80% of which are reverse-proxied applications running inside the private network.
I don’t get it, it’s still not working and I’m trying since 4-5 days.
So let us only have a look at nextcloud.
I installed nextcloud like in the nextcloud wiki on a debian container (lxc). It runs great when I redirect Port 80 and 443 directly to the nextcloud container (10.0.0.5). I’m using self-signed certificates.
Then I redirect port 80 and 443 to my caddy container (10.0.0.3) and caddy says to my webbrowser:
Yeah, I know cloud.foo.bar, go to https://10.0.0.3!
That internal IP is in my webbrowser addressbar.
My Caddyfile look like this:
cloud.foo.bar {
proxy / 10.0.0.5 {
transparent
websocket
}
}
I also played with the proxy-line (https://10.0.0.5, 10.0.0.5:443 or 10.0.0.5:80 etc.).
I also tryed different devices and always cleared cache.
I’m thinking of using nginx again as reverse proxy… it’s pretty dump to play around with all that config stuff, but I know it good and it works. I hope I did a mistake and can use caddy (to safe some time in future).
BTW: Thank you very very much for all your effort @Whitestrake <3
