Not able to access Jellyfin remotely with HTTPS Caddy as reverse proxy

1. Caddy version (2.1.4):

2. How I run Caddy: ./caddy run

a. System environment: Windows 10 Pro

b. Command:

./caddy run

d. My complete Caddyfile or JSON config:

{
    cert_issuer zerossl 868e8687dbef746f8058e26048e1d50f
    http_port 8647
    https_port 7468
}

https://jellyfin.invalidparameter.net

reverse_proxy localhost:8096

3. The problem I’m having:

Was using Caddy as a reverse proxy until Windows updated a few days ago. From what I’ve found it looks to be an update to their Windows Update service that has bound port 443 to that service, and there doesn’t seem to be anything I can do to change that. I no longer am able access Jellyfin remotely via HTTPS.

4. Error messages and/or full log output:

PS C:\Caddy> ./caddy run
2021/06/13 21:49:56.292 ←[34mINFO←[0m using adjacent Caddyfile
2021/06/13 21:49:56.293 ←[33mWARN←[0m input is not formatted with ‘caddy fmt’ {“adapter”: “caddyfile”, “file”: “Caddyfile”, “line”: 2}
2021/06/13 21:49:56.302 ←[34mINFO←[0m admin admin endpoint started {“address”: “tcp/localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”, “[::1]:2019”, “127.0.0.1:2019”]}
2021/06/13 21:49:56.303 ←[34mINFO←[0m tls.cache.maintenance started background certificate maintenance {“cache”: “0xc000339ce0”}
2021/06/13 21:49:56.303 ←[34mINFO←[0m http server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {“server_name”: “srv0”, “https_port”: 7468}
2021/06/13 21:49:56.303 ←[34mINFO←[0m http enabling automatic HTTP->HTTPS redirects {“server_name”: “srv0”}
2021/06/13 21:49:56.304 ←[34mINFO←[0m tls cleaning storage unit {“description”: “FileStorage:C:\Users\Mike\AppData\Roaming\Caddy”}
2021/06/13 21:49:56.304 ←[34mINFO←[0m tls finished cleaning storage units
2021/06/13 21:49:56.304 ←[34mINFO←[0m http enabling automatic TLS certificate management {"domains": ["jellyfin.invalidparameter.net"]}
2021/06/13 21:49:56.305 ←[34mINFO←[0m autosaved config (load with --resume flag) {“file”: “C:\Users\Mike\AppData\Roaming\Caddy\autosave.json”}
2021/06/13 21:49:56.306 ←[34mINFO←[0m serving initial configuration
2021/06/13 21:49:56.313 ←[34mINFO←[0m tls.obtain acquiring lock {“identifier”: “jellyfin.invalidparameter.net”}
2021/06/13 16:49:56 [INFO][FileStorage:C:\Users\Mike\AppData\Roaming\Caddy] Lock for ‘issue_cert_jellyfin.invalidparameter.net’ is stale (created: 2021-06-13 00:17:11.7983559 -0500 CDT, last update: 2021-06-13 00:18:01.9189797 -0500 CDT); removing then retrying: C:\Users\Mike\AppData\Roaming\Caddy\locks\issue_cert_jellyfin.invalidparameter.net.lock
2021/06/13 21:49:56.316 ←[34mINFO←[0m tls.obtain lock acquired {“identifier”: “jellyfin.invalidparameter.net”}
2021/06/13 21:49:56.335 ←[34mINFO←[0m tls.issuance.acme waiting on internal rate limiter {“identifiers”: [“jellyfin.invalidparameter.net”]}
2021/06/13 21:49:56.335 ←[34mINFO←[0m tls.issuance.acme done waiting on internal rate limiter {“identifiers”: ["jellyfin.invalidparameter.net"]}
2021/06/13 21:49:57.012 ←[34mINFO←[0m tls.issuance.acme.acme_client trying to solve challenge {“identifier”: “jellyfin.invalidparameter.net”, “challenge_type”: “http-01”, “ca”: “https://acme.zerossl.com/v2/DV90”}’’’

5. What I already tried:

I’m very new to this so sorry if I’ve missed something simple.

I’ve tried changing the port numbers for HTTP and HTTPs, and am using the zerossl API key. I did generate certificates from zerossl, but I’m unsure how to properly set them up to work with Caddy.

I have both ports forwarded to my computer that Caddy and jellyfin are on.

I’m really at a loss on how to fix this now.

I’m confused. That version doesn’t exist (see Tags · caddyserver/caddy · GitHub) did you mean v2.4.1?

I find that surprising. What’s your evidence? Windows should not be running anything on ports 80/443. Make sure you don’t have any rogue software installed taking those ports.

Ports 80 and 443 must be used by Caddy for the HTTP and/or TLS-ALPN challenges to work. ACME CAs only attempt to connect to servers on those ports to verify the challenge.

If you cannot use those ports, then you’ll need to use the DNS challenge, which does not have a port limitation, but is more complicated to configure:

Yes, I did mean version 2.4.1. My mistake thanks for catching it.

So far my evidence is windows updates that came through when I stepped away and when I’m came back I wasn’t able to access remotely like I could 30 mons prior. I removed all that came through that day and the only one I couldn’t remove servicing stack 10.0.19041.1022. There is more info that I can dig through now that it’s been a few days since it was pushed through.

I scanned ports with the netsh commands and nothing that I could find linked back to any software, but I will go through and delete what I can to see if that helps.

I will hopefully try the dns challenge tomorrow after work if I have no luck with other options and will report back.

Thank you for your help.

After a lot of searching and digging I found that for some reason ports 80 and 443 had been bound to the ‘default site’ in the IIS Manager. It’s odd because I don’t remember ever setting anything up in there and it doesn’t show that anything was, but at least the issue is resolved now.

2 Likes

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