Help Regarding Revers Proxy to port 443 (https) backend servers

Help
1

1. Caddy version (caddy version):

v2.4.6

2. How I run Caddy:

systemd ( as a service) on ubunutu lxc

a. System environment:

Ubuntu 21.04 (GNU/Linux 5.11.22-7-pve x86_64)

b. Command:

curl 172.16.199.119:2020/config/apps/http/servers/srv0/routes/ \
    -X POST \
    -H "Content-Type: application/json" \
    -d @- << EOF
 {  
"@id": "secured.server.ae",
"match": [
                {
                  "host": [
                    "secured.server.ae"
                  ]
                }
              ],
"handle": [
                        {
                          "handler": "reverse_proxy",
                          "upstreams": [
                            {
                              "dial": "192.168.88.31:443"
                            }
                          ]
                        }
                      ]
                   
                }
EOF

c. Service/unit/compose file:

Dont know where to find this !

d. My complete Caddyfile or JSON config:

using API only to configure caddy

3. The problem I’m having:

I am having trouble proxying the host to my backend server that is running a webserver on port 443 (https).

And if I turn off HTTPS on the server and proxy to port 80 i don’t get the page to render correctly nor i can log in to the web app on that server but on my lan its working as it should on port 80.

4. Error messages and/or full log output:

I usually use https://192.168.88.31 to browse it on my lan , but after adding the above config via API i get " Too Many Redirects " if i enable HTTPS only on my server and proxy to port 80,
Or I get a 502 error if i redirect to port 443.

5. What I already tried:

I tried turning off HTTPS on my server and using plain port 80 and doing so I can reach my server but the page doesn’t render correctly and the login does not work, etc.
Then I tried turning on HTTPS again from my server and using port 443 with the server IP in my curl config but it gives 502 error.

Please Help me I have a lot of HTTP servers in LAN that need to be proxied via API!

6. Links to relevant resources:

2

What systemd service are you using? If you’re using the API, you should be using the caddy-api service.

Caddy will try to proxy over HTTP by default. If you need to proxy over HTTPS, you need to tell the proxy’s HTTP transport to enable TLS.

Also, keep in mind that for the TLS handshake to succeed, Caddy needs to trust the upstream server’s TLS certificate.

What does that mean? Are some JS/CSS files not loading? Check Caddy’s logs, it should show you whether the requests are succeeding, or if there’s an error in loading some things.

3

Thank you again for the quick reply sir ,

so in order to do that ill have to send a request that looks like :

curl 172.16.199.119:2020/config/apps/http/servers/srv0/routes/ \
    -X POST \
    -H "Content-Type: application/json" \
    -d @- << EOF
 {  
"@id": "webmin.dom.com",
"match": [
        {
         "host": [
          "webmin.dom.com"
         ]
        }
       ],
       "handle": [
        {
         "handler": "subroute",
         "routes": [
          {
           "handle": [
            {
             "handler": "reverse_proxy",
             "transport": {
              "protocol": "http",
              "tls": {}
             },
             "upstreams": [
              {
               "dial": "192.168.88.20:12321"
              }
             ]
            }
           ]
          }
         ]
        }
       ],
       "terminal": true
      }
EOF

How exactly does that happen according to my above curl request?

Regards,
Ahsan Muhammad

4

Looks about right.

Well, Caddy will use your system’s trust store (list of root Certificate Authority (CA) certificates) to validate that the upstream’s certificate was signed by one of those roots. If it wasn’t (e.g. self signed cert) then you’ll need to configure Caddy to trust the server’s certificate, or disable verification altogether (strongly recommend you don’t do that).

Alternatively, you could just proxy to the upstream over HTTP. Since the upstream app is in your local network, you don’t need to have communication between Caddy and the app (unless you’re running untrusted software in the same network or don’t trust people connected on the network to sniff the communications between Caddy and the app).

Establishing trust for HTTPS between internal services can be a headache, so I suggest to avoid it. And turning off verification is essentially the same as just having the traffic unencrypted, because anyone could perform a man-in-the-middle attack if they can get between Caddy and your upstream app (i.e. insert their own proxy in between them and re-encrypt with their own certificate, since Caddy will ignore trust issues).

1 Like
5

This topic was automatically closed after 30 days. New replies are no longer allowed.