SOLVED: SSL Handshake Failed on Fire TV

[Linseed9747]

Hi everyone,

I've been running jellyfin from a docker compose file on an ubuntu server with several Fire TV sticks (both locally and remotely) for over six months with no issue. Renewed my Jellyfin domain's godaddy wildcard ssl certificate. The service connects using a built-in reverse proxy on a Synology NAS. Nearly two dozen other services are working as usual using that same reverse proxy server after the certificate update.  I ran the domain on ssllabs.com and the certificate received an A+ rating. The server is configured to accept both TLS 1.2 and 1.3 versions. The jellyfin service runs perfectly fine on other tested devices, including computer web browsers and apple iphone & ipad as well as the firetv web browser itself. Testing the FireTV using the local http protocol works fine, but this is not satisfactory given the I have remote users. Rebooted the FireTV several times, even deleted the app and reinstalled to no avail.  Let me know if you need any additional information or have any suggestions on further troubleshooting.

Application version
0.16.11

Device information
Fire TV Stick 4K Max and other versions as well

Android version
Fire OS

Jellyfin server version
10.9.6

[TheDreadPirate]

Did any of the cert authorities change in your cert? Does FireOS trust your cert? Are you providing the full trust chain in your reverse proxy config?

[Linseed9747]

Did any of the cert authorities change in your cert?  Does FireOS trust your cert?  Are you providing the full trust chain in your reverse proxy config?

For full transparency, I only understand your questions enough to get myself in trouble.  Also, my cert provider makes the process fairly point-and-click at this point; that, in and of itself, is making me less competent to answer your questions, but I will give it a go.

1) Did any of the cert authorities change in your cert?

I believe so (assuming I understand your question).  I deleted the old expired certificate from my server to make sure nothing was attempting to use it when I started troubleshooting this issue.  So I don't know how to go back and compare, but I did have the impression at the time that the CA changed.  I believed I saved the old certificate somewhere if you need me to go back an look at it.  But to be honest I may be misunderstanding what you are asking lol

2) Does FireOS trust your cert?

When inputting the server url on Fire TV Stick jellyfin app, receiving a handshake error.  All tested Fire Sticks had previously been working properly, so I assume the answer is no, Fire OS does not trust the cert?  Again, I may be misunderstanding your question but I do know the other services I run using this wildcard certificate are working properly.

3) Are you providing the full trust chain in your reverse proxy config?

I am using a Synology NAS stock reverse proxy.  I remember reading at some point that Synology may be using a version of NGINX at the core, but Synology doesn't expose a lot for me to look at.  When I was prompted, I did add the private key, certificate, and intermediate certificate.  Is this what you are asking?

I'm willing to be putty in your hand if you're willing to help mold me

[Linseed9747]

ssllabs.com/ssltest

Handshake Simulation
Android 4.4.2 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Android 5.0.0 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Android 6.0 RSA 4096 (SHA256)  TLS 1.2 > http/1.1  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Android 7.0 RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Android 8.0 RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Android 8.1 -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Android 9.0 -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
BingPreview Jan 2015 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Chrome 49 / XP SP3 RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Chrome 69 / Win 7  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Chrome 70 / Win 10 -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Chrome 80 / Win 10  R -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Firefox 31.3.0 ESR / Win 7 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Firefox 47 / Win 7  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Firefox 49 / XP SP3 RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Firefox 62 / Win 7  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Firefox 73 / Win 10  R -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Googlebot Feb 2018 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
IE 11 / Win 7  R Server sent fatal alert: handshake_failure
IE 11 / Win 8.1  R Server sent fatal alert: handshake_failure
IE 11 / Win Phone 8.1  R Server sent fatal alert: handshake_failure
IE 11 / Win Phone 8.1 Update  R Server sent fatal alert: handshake_failure
IE 11 / Win 10  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Edge 15 / Win 10  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Edge 16 / Win 10  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Edge 18 / Win 10  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
Edge 13 / Win Phone 10  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Java 8u161 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Java 11.0.3 -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH secp256r1  FS
Java 12.0.1 -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH secp256r1  FS
OpenSSL 1.0.1l  R RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
OpenSSL 1.0.2s  R RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
OpenSSL 1.1.0k  R RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH x25519  FS
OpenSSL 1.1.1c  R -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Safari 6 / iOS 6.0.1 Server sent fatal alert: handshake_failure
Safari 7 / iOS 7.1  R Server sent fatal alert: handshake_failure
Safari 7 / OS X 10.9  R Server sent fatal alert: handshake_failure
Safari 8 / iOS 8.4  R Server sent fatal alert: handshake_failure
Safari 8 / OS X 10.10  R Server sent fatal alert: handshake_failure
Safari 9 / iOS 9  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Safari 9 / OS X 10.11  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Safari 10 / iOS 10  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Safari 10 / OS X 10.12  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Safari 12.1.2 / MacOS 10.14.6 Beta  R -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Safari 12.1.1 / iOS 12.3.1  R -  TLS 1.3 TLS_AES_256_GCM_SHA384   ECDH x25519  FS
Apple ATS 9 / iOS 9  R RSA 4096 (SHA256)  TLS 1.2 > h2  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
Yahoo Slurp Jan 2015 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS
YandexBot Jan 2015 RSA 4096 (SHA256)  TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   ECDH secp256r1  FS

[TheDreadPirate]

For 3). Can you show me the interface for the Synology reverse proxy? In plain Nginx, I can provide a "full chain" certificate that includes the subject in addition to the intermediate and root certificate instead of just the intermediate/root certificate. As with a lot of handshake errors, not just in jellyfin, they don't tell you what went wrong most of the time.

[Linseed9747]

For 3).  Can you show me the interface for the Synology reverse proxy?  In plain Nginx, I can provide a "full chain" certificate that includes the subject in addition to the intermediate and root certificate instead of just the intermediate/root certificate.  As with a lot of handshake errors, not just in jellyfin, they don't tell you what went wrong most of the time.

https://pasteboard.co/dRT3eO9pB4Ea.jpg

https://pasteboard.co/dRT3eO9pB4Ea.jpg

When I right click, I have an option to 'Export certificate'

Here are the exported file names, let me know if you need me to look at something in them?

cert.pem
chain.pem
privkey.pem
root.pem
short-chain.pem

[Linseed9747]

I did notice the chain.pem only contains one section.  Based upon may reading up on 'full chain certificates', is this suppose to have three sections?  I also noticed the chain.pem and short-chain.pem contain the same data if that offers any helpful information.

[TheDreadPirate]

What are the file sizes?

Code:

-rw-r--r-- 1 root root 1484 Apr 29 17:28 cert1.pem
-rw-r--r-- 1 root root 1826 Apr 29 17:28 chain1.pem
-rw-r--r-- 1 root root 3310 Apr 29 17:28 fullchain1.pem
-rw------- 1 root root  241 Apr 29 17:28 privkey1.pem

Perhaps you can access Nginx on the command line and modify the config manually?

https://www.synoforum.com/resources/syno...-hood.135/

[Linseed9747]

I went ahead and ssh'd into the synology and found the folder containing those PEM files. Here is a list of files contained in that directory:

cert.pem
chain.pem
fullchain.pem
info
privkey.pem
root.pem
short-chain.pem

When I CAT the fullchain.pem, it contains two sections? Thoughts so far?

[TheDreadPirate]

See my last point about modifying the Nginx config manually and providing the fullchain.pem in the Nginx config.