SSL Issues when Configuring Reverse Proxy for accessing docker services, Self Signed Certificates issued

WHOAH That worked!

Thank you SOOO much for all the help! I learned quite a lot!

If you don’t mind; can you perhaps explain how you determined that calibre-web was expecting the header?
Is this a header that would have been present had I hosted this service natively on a VPS, secured with TLS?

One of the links I referenced above (Setup Reverse Proxy · janeczku/calibre-web Wiki · GitHub) had some information about it. Specifically, an nginx config (with the syntax RequestHeader set X-SCHEME https and a short explanation: “The X-Scheme directive is used to preserve the protocol (http/https), it could be hard coded to http or https to force this type of protocol.”)

Whether or not the service is on a VPS doesn’t really matter; the cloud is just someone else’s computer. On a VPS you’d need to configure a web server, most likely, and if the web server on the VPS was Caddy, well… Nothing would be different, in practice.

Alternately if you’re asking if you’d exposed calibre-web directly to the internet, e.g. by giving it a purchased HTTPS certificate - no, you probably wouldn’t have had this problem. It’s part of a class of logical problems that can occur when you introduce a proxy layer. There’s a few oddities that can occur when the client expects one thing and the app expects another, but there’s a web server in between invalidating those expectations. Mostly nowadays though it’s just plug and play, and the benefits of having a server like Caddy handle your HTTPS is just too good to pass up.

2 Likes

Thank you so much for all the help!
You are an excellent teacher.

My day job is being a SaaS product technical support engineer; I troubleshoot everything from endpoint agent installations to back-end service issues all day long. This experience has taught me about as much as anything else!

Just a Quick Summary for the record:

Setup:

  • Caddy as a Reverse proxy for multiple docker services
  • Caddy running as a container service on the same server-host

Issues:

  • Home networking issue; google wifi in dmz+ mode with a PACE U-verse modem

    • ATT set firewall rule opening 443 to the WAP for testing. Unsure whether this could be closed/reconfigured
  • Hosted web application relying on X-Scheme header to persist/force scheme. Automatically downgrading to http, breaking flow.

Fixes:

  • Configuring Caddy to reverse proxy on a nonstandard port
    • forwarded nonstandard port to server; then opened that port to the docker container.
    • specified this port In Caddyfile
  • Added header_up X-scheme https to force the application to maintain https (prevent from downgrading).

Relevant configuration/compose files:
Loosely following this guide:

https://github.com/DoTheEvo/selfhosted-apps-docker/tree/master/caddy_v2
version: "3"
services:

  caddy:
    image: caddy:latest
    container_name: caddy
    hostname: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "8443:8443"
    environment:
      - MY_DOMAIN
    volumes:
      - /home/pi/docker/caddy/.Caddyfile:/etc/caddy/Caddyfile
      - /home/pi/docker/caddy/.data:/data
      - /home/pi/docker/caddy/.config:/config
{
     acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
     email email@gmail.com
}


https://books.website.com:8443 {
        reverse_proxy 192.168.86.249:8083 {
                header_up X-Scheme https
        }
        tls {
                issuer acme {
                        disable_tlsalpn_challenge
                }
        }
}

Now to remove the staging acme_ca and reload Caddy; and I should have a working reverse proxy!

I look forward to learning more about Caddy, and utilizing it in different ways!

Many Thanks @Whitestrake, You are a gentleman and a scholar!

3 Likes

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