Shield and SSL

[marpow]

Has anyone successfully got a Let's Encrypt certificate working with the Jellyfin client on the Nvidia Shield Pro? I setup Jellyfin on Debian and have a p12 certificate from Let's Encrypt with the correct hostname working for web browser and iOS client access. When I try from my Shield it says it cannot connect. Is the Shield missing the Let's Encrypt root certificate?

Thank in advance!

[TheDreadPirate]

We strongly recommend NOT using Jellyfin's built in HTTPS functionality. It is deprecated and will be removed entirely in JF 13. We recommend you use a reverse proxy like Caddy or Nginx. It is much more secure and configurable. What is likely happening is that the cert you are using does not include the full certificate chain. Your Shield likely does not explicitly trust the intermediate cert, but the cert you provide does not include the root certificate, which your Shield almost certainly does trust.

Use a reverse proxy for handling https connections (see documentation below). But for LAN client, https is not necessary.

https://jellyfin.org/docs/general/post-i...rse-proxy/

[marpow]

Thanks for the feedback. I was hoping to avoid the overhead of running Jellyfin through a reverse proxy. I have other, lighter weight services going through a Nginx proxy, but those have significantly lower bandwidth utilization. I've transitioned to running almost all services, both remote and local, as encrypted for consistency, particularly anything that passes authentication information.

[TheDreadPirate]

Unless this is a really really low powered system, the overhead from Nginx handling TLS traffic, even for jellyfin, is negligible. All my Jellyfin clients, even clients on my LAN, go through Nginx. When I am monitoring btop, Nginx is so far down the list of processes (sorted by CPU usage), that I have never actually seen it pop up. Nginx is incredibly efficient.

[jo_gurt]

Unless this is a really really low powered system, the overhead from Nginx handling TLS traffic, even for jellyfin, is negligible.  All my Jellyfin clients, even clients on my LAN, go through Nginx.  When I am monitoring btop, Nginx is so far down the list of processes (sorted by CPU usage), that I have never actually seen it pop up.  Nginx is incredibly efficient.

Hi!
I am facing similar issue with LE cert chain on my NV Shield.
Just wondering - is using reverse proxy is somehow helping with it, or this is just a side-note?

[TheDreadPirate]

Unless this is a really really low powered system, the overhead from Nginx handling TLS traffic, even for jellyfin, is negligible.  All my Jellyfin clients, even clients on my LAN, go through Nginx.  When I am monitoring btop, Nginx is so far down the list of processes (sorted by CPU usage), that I have never actually seen it pop up.  Nginx is incredibly efficient.

Hi!
I am facing similar issue with LE cert chain on my NV Shield.
Just wondering - is using reverse proxy is somehow helping with it, or this is just a side-note?

Most people don't realize how complicated a TLS handshake actually is.  There are a lot of things going on to ensure that the connection is secure and valid.  One of those things is ensuring that the certificate the server is presenting to your client device is trusted.  This is done through what's called a "Trust Chain".  Your operating system has a list of trusted "Certificate Authorities" (abbreviated as CA) and your operating system provider will periodically update this list of trusted CA's.  CA's have two levels: Intermediate and Root.  The intermediate CA's typically are the workhorses that generate client certificates that you and I get for our servers, while root CA's generate the certificates only for the Intermediate CA's.

Typically root CA's have a very long validity period (usually over 10 years) while intermediate CAs have much shorter validity periods (usually 3 years).  As part of the TLS handshake process you present both your certificate and the certificate of the intermediate CA that issued your server certificate.  If an intermediate CA is retired and a new intermediate CA is stood up, but your operating system hasn't been updated in months or years, your operating system will not trust server certificates issued by that new intermediate CA.  This is what is happening with you.  Android and, especially, Android TV based clients do not get updated as frequently as Linux, Windows, and Mac devices.  Meaning that Android TV based devices often do not trust certificates issued by newer intermediate CAs.

This is where using a reverse proxy comes to the rescue.  AFAIK, Jellyfin's built-in HTTPS capability (which will be removed in JF13) can only present your server certificate and the intermediate CA certificate.  But reverse proxies can be configured to present the server certificate, the intermediate CA certificate, AND the root CA certificate.  And because of the longevity of root CAs, it is unlikely your device will not trust a root CA.  It would have to be a suuuuuper old device that has not received any updates in a decade.

Now let's circle back to the concept of a "Trust Chain".   Even though your device does not explicitly trust the intermediate CA, because your device trusts the root CA it will implicitly trust the intermediate CA and, therefore, your server certificate.

TLDR; use a got dang reverse proxy for TLS.  

https://letsencrypt.org/certificates/#chains

[jo_gurt]

All reverse proxy and deprecated functionality aside (I started using reverse proxy and I love the idea of it), feels kind of weird that the trust and trust chain depends on who serves the certificate to the end client.
As I understand, it's the client that needs to trust the chain and this is done by storing trusted CAs on client side.
And this is where I get lost - how is it different for the jellyfin client who serves the cert, is it proxy or jellyfin server. Even if server presents full chain, client device still needs to know that the presented CA is good one.
So if LE changed their root CAs and old device, like nvidia shield, does not update root CAs, we do not have a good way out.

[TheDreadPirate]

The client does store trusted certificate authorities. But the OS provider needs to regularly update that. If your device provider hasn't updated the OS in quite some time, it won't have the certificate authorities that have been stood up since the last update in its trust store. Let's Encrypt has several new root and intermediate certificate authorities that were stood up in September 2025. If your device's last OS update was PRIOR to that, it wouldn't have ANY of those certificate authorities in its trust store.

https://letsencrypt.org/certificates/#su...ediate-cas

If you look at the section in the link above, Subordinate Intermediate CAs, you'll notice that in the "Chains" for each of the new Y* Intermediate CA they are signed by both the new root CAs and the older X root CAs because they are trusted by older devices. They know that if new certs were only signed by the new Y intermediate and root CAs, a lot of seldom updated devices wouldn't be able to trust their certs. So they cross sign them with older X CAs so that older devices can establish a chain of trust from the top down.

Now to why this matters with setting up HTTPS in Jellyfin directly and in a reverse proxy. Jellyfin has zero configuration for its HTTPS implementation. You provide it a very specific format of cert and that is it. You can't control what ciphers clients are allowed to use, you can't control which SSL/TLS protocols clients can use, and you can't control what certs to present in the trust chain.

If you have an older device that doesn't trust, for example, Let's Encrypt's YE1 intermediate CA, but that is the only CA cert you present then the client won't trust it. And Jellyfin's HTTPS implementation has no way to change that.

But if your reverse proxy presents the X1 cross signed certificate chain, and your device trusts Let's Encrypt's X1 root CA, then it will trust the entire chain implicitly. This is how Let's Encrypt handles changes in their CA infrastructure, cross signing with older CAs so that older devices can still trust newly issued certificates.