SOLVED: Custom SSL Certificate Issue

[SirRorick]

I have looked through the forum and mostly find information regarding 'self signed' certs or using reverse proxy, but am not seeing much regarding using the "Custom SSL Certificate Path" built into Jellyfin.

I am running 10.10.7 on Windows.
I have combined the Cert, Bundle, and Key from a paid cert from SSLS[.]com and applied the resulting PFX to the jellyfin server.
HTTPS is enabled, and forced using the "Require HTTPS option".

Here is the kicker, it works completely fine for me from browser and android phone app (from outside my network),
but I have family who are also using android (jellyfin phone app with a clean cache) and the domain refuses to connect. From that same phone, they can connect just using the phone browser and going to the domain.
It is not a DNS issue, it is has something to do with the cert. Same phone can connect to HTTP is I disable the requirement for HTTPS (just for testing).

Devices that appear to be affected seem to be some android phones, and most of not all 'google TV' type devices.

Does anyone have any information on this?

please note, setting up a reverse proxy is not the answer I am looking for. I had an NGINX reverse proxy on a RPi4 that applied the cert that worked. Went to cloudflare because I wanted to do away with port forwarding, learned that streaming services is against their TOS, so now I am back to port forwarding and thought, why do I even need the reverse proxy if the jellyfin can apply the cert directly, removing the extra hop and bottleneck from the RPi. (Dream Machine firewall is doing most of the fancy blocking, and I have a custom powershell script reading the jelyfin logs and banning IPS with too many failed attempts just like Fail2Ban.

So I reiterate, I am trying to not go back to the reverse proxy if the Jellyfin server can just do the one function I need. Apply the cert correctly to all users

If anyone wants log data, this is all it gives me from a failing device:
[WRN] [14] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS "REDACTED" error receiving data: "The remote party closed the WebSocket connection without completing the close handshake."
[INF] [14] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "REDACTED" closed

[SirRorick]

In my research, I am seeing this. Is this true, or is GPT full of it?

GPT Response:
"Yes—unfortunately, that’s a known limitation of Jellyfin on Windows. Under the hood, the Windows build uses .NET’s HTTP.sys/HttpListener stack, which—regardless of what you bundle into your PFX—only ever sends the leaf certificate to clients. Intermediate certificates simply aren’t included in the TLS handshake.
A couple of notes:

• There’s discussion in the Jellyfin repo about moving to .NET 7’s HTTP listener (which can include the chain), but Jellyfin’s Windows server still targets an earlier runtime where this isn’t supported.
  
• Practically speaking, until Jellyfin switches to a runtime that includes chain support (or reworks its TLS layer), the only reliable way to serve a full chain is to terminate TLS upstream—e.g. with a reverse proxy or dedicated TLS terminator.
  

So yes—it’s true: Jellyfin on Windows today will not send out your full-chain PFX."

[bitmap]

I would recommend looking into running a reverse proxy. It's on the roadmap to remove Jellyfin's cert handling in favor of the plethora of RP options out there.

[SirRorick]

Good to know, I was not aware this was a feature pending removal. I guess that closes this issue.

Thank you.

[SirRorick]

Moved to caddy for windows and this is proving to be a fine solution moving forward. Please note for anyone who also may run into this, while the cert settings in JF server may be going away, this issue I described above, was because I didn't have UDP included in my port forward for 443. Needs TCP and UDP.

I was having the same issues with Caddy, but found this in the documentation that closed this issue for good.

https://jellyfin.org/docs/general/post-i...oxy/caddy/
"Note: For HTTP/3 support, ensure UDP port 443 is forwarded/opened on your firewall, as HTTP/3 uses UDP."