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