fuzzthekingoftrees 10 Posted April 29, 2017 Share Posted April 29, 2017 I couldn't get this to work using your method or mine. In the end I told certmgr to import from the letsencrypt website certmgr -ssl -v -m https://letsencrypt.org/certificates/ Which sorted it out nicely. Although the certificate path that is shown in openssl s_client is not the same for my windows and linux servers, they do now both work with the Amazon Fire TV. Link to comment Share on other sites More sharing options...
ebr 14939 Posted April 29, 2017 Share Posted April 29, 2017 Nice investigation guys. Well Done! If one of you could write up a solution for others in the Linux forum, we'd really appreciate it. Thanks. Link to comment Share on other sites More sharing options...
adam1010 19 Posted April 29, 2017 Share Posted April 29, 2017 (edited) @fuzzthekingoftrees I could NOT get your method to work. I cleared my certmgr store and then used "certmgr -ssl -v -m https://letsencrypt.org/certificates/" --- however, that domain is not using the same intermediate as the actual Let's Encrypt certificates. For some reason it did include the (incorrect) intermediate in the response, so SSL Labs indicated that the chain wasn't complete (and the Fire TV Stick stopped working). (I tried "sudo certmgr -ssl -v -m https://helloworld.letsencrypt.org/" since that domain appears to be using a Let's Encrypt issued cert with the DST X3 intermediate -- however, certmgr just spit out error messages) When I cleared my certmgr store again and then used "sudo certmgr -add -c -v -m CA emby.pfx" I was able to restore connectivity to the Fire TV. However, if I tried to then remove my leaf certificate (leaving just the intermediate), Mono stopped providing the full chain! So at least for me, the actual Let's Encrypt leaf cert + the intermediate DST X3 had to be in my certmgr store in order for the proper chain to be included. I plan to just add that certmgr .pfx import command to the end of the renewal script to make sure the store always contains the current leaf + intermediate. Edited April 29, 2017 by adam1010 Link to comment Share on other sites More sharing options...
fuzzthekingoftrees 10 Posted April 29, 2017 Share Posted April 29, 2017 I've looked over this all again because like you say https://letsencrypt.org uses different certificates so it shouldn't work. What I found is that I need to have two certificates in my CA store. One should be the Let's Encrypt intermediate signed by DST Root CA X3 Serial Number: 08A7EC850B6A7385530100004241010A Issuer Name: O=Digital Signature Trust Co., CN=DST Root CA X3 Subject Name: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3 Valid From: 17/03/2016 16:40:46 Valid Until: 17/03/2021 16:40:46 Unique Hash: 3E1A1A0F6C53F3E97A492D57084B5B9807059EE057AB1505876FD83FDA3DB838 The other one doesn't seem to matter at all. To test I imported the certs from google.com then deleted them until I have just the above and the Google Internet Authority G2 certificate issued by GeoTrust. With those two certificates emby serves a correct chain. If I remove the Google cert, it stops working. Added in one cert from facebook.com and it starts working again. The only criteria for the second certificate is that it must be SHA256. If it's a SHA1 then it doesn't work. Also any additional certificates I add to the store get sent as part of the chain even though they're unrelated Certificate chain 0 s:/CN=my.emby.domain.cert.com i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 2 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 Secure Server CA - G4 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 3 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA Link to comment Share on other sites More sharing options...
adam1010 19 Posted June 29, 2017 Share Posted June 29, 2017 I had to renew my Let's Encrypt cert for the first time today and ran into even more issues. I spent a good hour trying to get the "DST X3" intermediate certificate to be provided in the chain. Luckily the post from @@fuzzthekingoftrees about using *any* random certificate got it working for me. I first cleared my certificate store, then imported my emby.pfx, removed the leaf certificate, and then imported a random certificate (Facebook.com) and that got it working. We really should make sure the Mono guys know about this bug with certmgr -- I've posted my commands below in case I need them again for the next renewal! sudo certmgr -list -c -m CA sudo certmgr -del -c -v -m CA [hash] sudo certmgr -add -c -v -m CA emby.pfx sudo certmgr -del -c -v -m CA [hash_leaf_cert] sudo certmgr -ssl -m https://www.facebook.com sudo service emby-server restart 1 Link to comment Share on other sites More sharing options...
adrianwi 238 Posted September 25, 2017 Share Posted September 25, 2017 I've just stumbled upon this thread, as I've encountered the same problem today trying to get my Mum's Firestick connected to my new emby server. Whilst I understood some of the threads on the first page, you lost me somewhere down the 2nd I'm also running, FreeBSD, although suspect some of the commands are transferable. If someone could list out the steps after creating the letsencrypt certificate .pem files I would be most grateful? Thanks Link to comment Share on other sites More sharing options...
adam1010 19 Posted September 26, 2017 Share Posted September 26, 2017 @adrianwi The gist is this: Once you've obtained the certificate you can set it in Emby server configuration and it'll serve it up to clients. However, in my case and many others, Emby doesn't correctly include the "intermediate certificates" (ie the certificate chain) along with your Let's Encrypt "LE" cert (essentially the LE cert was issued by someone, called a "certificate authority", and that entity's certificate was in turn issued by a different CA, and so on -- in order for some browsers, in particular the Fire TV to accept your LE cert as valid, it needs you to tell it who all of the CAs are in your chain, and include all those intermediate CAs along with the LE certificate you were issued). To determine if these intermediate CA certificates are being included by Emby you can use that openssl method mentioned above or use ssllabs.com/ssltest -- if you determined that the intermediate certificates are missing then you can look to see if Emby is using a certificate manager (like it does on Ubuntu, with Mono) -- in that case you may be able to load your LE certificate into the manager (as well as into Emby Server directly), and then when Emby serves a page then the certificate manager *may* correctly send the entire certificate chain and not just the final/leaf Let's Encrypt cert. In my case I had to goof around with the certificate manager a bit (it's quite buggy on Ubuntu). Hope that helps! Link to comment Share on other sites More sharing options...
adrianwi 238 Posted September 26, 2017 Share Posted September 26, 2017 Kind of! Thanks for the explanation, and I've found a workaround using a reverse proxy to handle to SSL handshake. Maybe I'll come back to this at some point, but for now my Mum's Firestick can connect securely Link to comment Share on other sites More sharing options...
mastrmind11 717 Posted September 26, 2017 Share Posted September 26, 2017 Just set up nginx and reverse proxy in. Way simpler than all of this cert hacking, and has many other uses besides Emby. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now