Running PlexConnect and a web server

1. Caddy version (caddy version):

2. How I run Caddy:

a. System environment:

Ubuntu 20.04 using systemd to run Caddy

b. Command:

I run Caddy through systemctl as installed from “sudo apt install caddy”

sudo systemctl start caddy

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

myDomain.com {
        reverse_proxy 127.0.0.1:8096
}


trailers.apple.com:443 {
        reverse_proxy  192.168.0.58:4433 {
            header_down Host {host}
            header_down X-Real-IP {remote}
        }

        tls /home/alex/PlexConnect/assets/certificates/trailers.pem /home/alex/PlexConnect/assets/certificates/trailers.key
}

trailers.apple.com:80 {
        reverse_proxy 192.168.0.58:8090 {
            header_down Host {host}
            header_down X-Real-IP {remote}
        }
}

3. The problem I’m having:

Hi all, I posted about a year ago with this same issue and then gave up on it. Since then I’ve tried to get this to work again, I’ve made a bit of progress and I think my caddyfile is close.

PlexConnect is a service run on my machine that redirects an app from an old Apple TV 3 to a Plex server. That way you can view a Plex library even though apps aren’t available on the Apple TV. However, because I’m running Caddy on this machine already, the standard PlexConnect ports (80/443) aren’t available. I have confirmed that when disabling Caddy that PlexConnect works as intended.

In the PlexConnect settings I’ve changed both ports to prevent the conflict and tried to update my caddyfile to match.

The PlexConnect documentation does feature an nginx config here I used this as a best guess to try and do the same within Caddy.

It seems to work to a degree as I’m able to load the certificates on the Apple TV, so something works. However I’m unable to view anything when opening the intercepted app, Trailers, and instead get a generic error that it’s unavailable at this time. If I have the machines address as 127.0.0.1 instead of the local IP it will fail and not even load certificates. Again, I think I’m on the right track overall but not quite there.

4. Error messages and/or full log output:

5. What I already tried:

Caddy doesn’t give me any issues but I still don’t think the config is correct, I suspect it has to do with how I’ve configured my headers. I’m a bit of a novice here but did my best based on reading the documentation. Again, I suspect the example nginx config will have the answer.

Initially I had the incorrect path for certs and also had to change permissions on one. Now that’s all done and Caddy will start without issue.

I’ve done my best with headers but I’m definitely not an expert. From looking at the caddy documentation it looks like the X-Forwarded-For and X-Forwarded-Proto from the nginx config can be ignored as caddy does this automatically.

6. Links to relevant resources:

What you probably want is:

        reverse_proxy 192.168.0.58:8090 {
            header_up X-Real-IP {remote_host}
        }

header_down sets headers on the response after having proxied the request, on the way back up the middleware chain. You want header_up to set headers on the request being sent upstream.

Also, you don’t need to override Host because Caddy passes that header through transparently already.

Also since you’re trying to proxy to a server that’s listening for HTTPS requests, you’d probably need to adjust the :443 site block to this:

        reverse_proxy https://192.168.0.58:4433 {
            header_up X-Real-IP {remote_host}
            transport http {
                tls_insecure_skip_verify
            }
        }

This will connect over HTTPS, and ignore any TLS certificate trust issues (which I assume would happen in this case since your Caddy server probably doesn’t trust the certificate being served, if it’s a self-signed cert).

Hi @francislavoie thanks for the suggestions.

I’ve gone ahead and updated my Caddy file based on your recommendation. Again, I’m able to load the cert on to the Apple TV with the new Caddy file so that’s great. However I still have no luck when attempting to open the Trailers app with the same error.

I think you’re correct that the cert is self signed, it’s generated on the machine with this step.

Here’s my current Caddy file, let me know if I’ve misunderstood something you suggested and if this is incorrect.

Not sure if it helps but in addition to the nginx sample, the repo also has an Apache config but this is with a virtual host, it’s here

myDomain.com {
        reverse_proxy 127.0.0.1:8096
}

trailers.apple.com:443 {
        reverse_proxy  192.168.0.58:4433 {
            header_up X-Real-IP {remote_host}
            transport http {
                tls_insecure_skip_verify
            }
        }

        tls /home/alex/PlexConnect/assets/certificates/trailers.pem /home/alex/PlexConnect/assets/certificates/trailers.key
}

trailers.apple.com:80 {
        reverse_proxy 192.168.0.58:8090 {
            header_up X-Real-IP {remote_host}
        }
}

Turn on the debug global option, and check Caddy’s logs. At the top of your Caddyfile:

{
	debug
}

To check your logs:

Thanks francislavoie, here’s a log from restarting Caddy and then loading the certificate to the Apple TV followed by trying to access the Trailers app.

I can see the TLS error at the end of the log, is this because we have the self-signed cert that was generated? Sorry if this is obvious, I’m a novice with this

Sep 01 17:32:31 alexServer caddy[58331]: LANG=en_US.UTF-8
Sep 01 17:32:31 alexServer caddy[58331]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Sep 01 17:32:31 alexServer caddy[58331]: NOTIFY_SOCKET=/run/systemd/notify
Sep 01 17:32:31 alexServer caddy[58331]: HOME=/var/lib/caddy
Sep 01 17:32:31 alexServer caddy[58331]: LOGNAME=caddy
Sep 01 17:32:31 alexServer caddy[58331]: USER=caddy
Sep 01 17:32:31 alexServer caddy[58331]: INVOCATION_ID=0903248ed102402ea765ff3ac94c0120
Sep 01 17:32:31 alexServer caddy[58331]: JOURNAL_STREAM=8:342054
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8448915,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"warn","ts":1630539151.8463073,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":24}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8475595,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8477228,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc0000ca8c0"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"warn","ts":1630539151.8479414,"logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [trailers.apple.com]: no OCSP server specified in certificate"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.847977,"logger":"http","msg":"skipping automatic certificate management because one or more matching certificates are already loaded","domain":"trailers.apple.com","server_name":"srv0"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8479826,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8479924,"logger":"http","msg":"server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server","server_name":"srv1","http_port":80}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"debug","ts":1630539151.8484626,"logger":"http","msg":"starting server loop","address":"[::]:443","http3":false,"tls":true}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"debug","ts":1630539151.8484836,"logger":"http","msg":"starting server loop","address":"[::]:80","http3":false,"tls":false}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8485446,"logger":"tls","msg":"cleaning storage unit","description":"FileStorage:/var/lib/caddy/.local/share/caddy"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8491008,"logger":"tls","msg":"finished cleaning storage units"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.855743,"msg":"autosaved config (load with --resume flag)","file":"/var/lib/caddy/.config/caddy/autosave.json"}
Sep 01 17:32:31 alexServer caddy[58331]: {"level":"info","ts":1630539151.8557827,"msg":"serving initial configuration"}
Sep 01 17:32:31 alexServer systemd[1]: Started Caddy.
Sep 01 17:36:14 alexServer caddy[58331]: {"level":"debug","ts":1630539374.0605168,"logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"192.168.0.58:8090","request":{"remote_addr":"192.168.0.177:49177","proto":"HTTP/1.1","method":"GET","host":"trailers.apple.com","uri":"/trailers.cer","headers":{"X-Forwarded-For":["192.168.0.177"],"X-Forwarded-Proto":["http"],"X-Real-Ip":["192.168.0.177"],"Accept-Encoding":["gzip, deflate"],"User-Agent":["AppleTV/7.7 iOS/8.4.4 AppleTV/7.7 model/AppleTV3,2 build/12H923 (3; dt:12)"],"Accept-Language":["en"],"Accept":["*/*"]}},"headers":{"Content-Type":["text/xml"],"Server":["BaseHTTP/0.3 Python/2.7.18","PlexConnect"],"Date":["Wed, 01 Sep 2021 23:36:14 GMT"]},"status":200}
Sep 01 17:36:28 alexServer caddy[58331]: {"level":"debug","ts":1630539388.0640407,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.0.177:49187: tls: no cipher suite supported by both client and server"}
Sep 01 17:36:28 alexServer caddy[58331]: {"level":"debug","ts":1630539388.1258798,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.0.177:49188: tls: client offered only unsupported versions: [301]"}
Sep 01 17:36:28 alexServer caddy[58331]: {"level":"debug","ts":1630539388.1698606,"logger":"http.stdlib","msg":"http: TLS handshake error from 192.168.0.177:49189: tls: client offered only unsupported versions: []"}

Looks like the client/browser in your Apple TV is probably too old to securely connect to Caddy.

Caddy only supports TLS 1.2 and 1.3 (the last two latest versions) because older TLS versions have known security vulnerabilities.

Thanks, that’s good to know. I’m guessing this means there’s not much else we can do? If the traffic is only from local IPs I’d feel pretty safe with ignoring any issues.

The Caddy documentation does state the min version is TLS 1.2, obviously as you mentioned this makes sense for security reasons.

From Googling around it looks like the Apple TV 3 is on TLS 1.0 due to the Python dependencies.

:man_shrugging:

Caddy might not be the right tool for you, for this.

You could make a custom build of Caddy making a small code change to make it possible to configure Caddy with TLS 1.0 and 1.1, but that’s a headache and will no longer work in the future once Go itself removes support for 1.0 and 1.1 altogether (which is planned).

The world can’t stop making security fixes to software, to allow old devices to continue working, obviously. And Caddy aims to be secure by default and prevent users from shooting themselves in the foot as much as possible.

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