Solution swroger 6 Posted September 30, 2021 Solution Share Posted September 30, 2021 I thought this might be useful if someone else comes across the same issue. I'm a bit of an edge case since I use docker and I create a pkcs12 cert bundle from certs and keys extracted from traefik, but the issue I had was not related to that. Since Lets Encrypt intermediate expired my emby server has been presenting an expired intermediate, but the `p12` file I'm generating has the correct new intermediate, I narrowed it down to the x509stores in the docker image had cached the intermediates, so since the issuer hadn't actually changed it never refreshed the intermediates and just kept on trucking with the invalid certs. Long story short, if you run docker and have some kind of lets encrypt certificate and you're getting `NET::ERR_CERT_DATE_INVALID` from chrome (Firefox ignores the bad certs, so I think the only affected browser is edge/chrome on macOS) then either remove and recreate the docker container (it uses `/tmp` for home so that will clear it) or docker exec -ti emby-server sh -c 'rm -rf /tmp/.dotnet/corefx/cryptography/x509stores' docker restart emby-server 1 2 3 Link to comment Share on other sites More sharing options...
Luke 37099 Posted September 30, 2021 Share Posted September 30, 2021 Hi that's great, thanks for sharing. Link to comment Share on other sites More sharing options...
Q-Droid 652 Posted September 30, 2021 Share Posted September 30, 2021 (edited) I did the same and it worked for me as well, non-docker installation. I've contacted the devs for their feedback. Edited September 30, 2021 by Q-Droid 1 Link to comment Share on other sites More sharing options...
Painkiller8818 203 Posted September 30, 2021 Share Posted September 30, 2021 how to do this on a non docker linux server? thanks 1 Link to comment Share on other sites More sharing options...
Q-Droid 652 Posted September 30, 2021 Share Posted September 30, 2021 On my host the location is ~emby/.dotnet/corefx/cryptography/x509stores/ca and the pfx files in that directory are the ones to delete. ~emby is usually /var/lib/emby. Link to comment Share on other sites More sharing options...
jant90 15 Posted September 30, 2021 Share Posted September 30, 2021 On my Linux server I found it at: /home/<user>/.dotnet/corefx/cryptography/x509stores/ca I'm running Emby as <user>. Not sure if it will fix the issues mentioned in this thread though: Link to comment Share on other sites More sharing options...
neik 837 Posted September 30, 2021 Share Posted September 30, 2021 Thanks a lot, that did the trick. Link to comment Share on other sites More sharing options...
alucryd 216 Posted September 30, 2021 Share Posted September 30, 2021 @swroger Any idea how often this cache is invalidated? If it's not that often we will need to find a way to automate this task in emby itself. 2 Link to comment Share on other sites More sharing options...
DoUEvenComputer 1 Posted October 1, 2021 Share Posted October 1, 2021 Thanks! Spent a few hours trying to figure this one out and this fixed my problem. Link to comment Share on other sites More sharing options...
smiley1 2 Posted October 3, 2021 Share Posted October 3, 2021 thanks! It's work for me to. Link to comment Share on other sites More sharing options...
nickbmx2100 2 Posted October 3, 2021 Share Posted October 3, 2021 Any ideas where I can find the X509stores directory on an Emby Server installation on Synology via Package Center . I ssh to synology but could not located that directory. /volume1/@appstore/EmbyServer Link to comment Share on other sites More sharing options...
nickbmx2100 2 Posted October 4, 2021 Share Posted October 4, 2021 Just wanted to update thread. I was able to located the X509Stores directory on my EmbyServer instance running on Synology. /volume1/@apphome/EmbyServer/.dotnet/corefx/cryptography/x509stores/ca Once removed pfx and rebooted server updated pfx was loaded and being used. https now works Link to comment Share on other sites More sharing options...
TuXFire 0 Posted October 4, 2021 Share Posted October 4, 2021 On 9/30/2021 at 8:23 PM, Q-Droid said: On my host the location is ~emby/.dotnet/corefx/cryptography/x509stores/ca and the pfx files in that directory are the ones to delete. ~emby is usually /var/lib/emby. I had the same problem. Searched for hours. Thanks Link to comment Share on other sites More sharing options...
jdotero 7 Posted October 4, 2021 Share Posted October 4, 2021 Thanks! Spent many hours trying to figure out what was wrong with some of my certificates. Come to find out, it was the X509Store! This fixed all of my problems with scripts connecting over the https port. Hope it fixes the issues many of my friends have when trying to use Emby connect. Time will tell. (They are all working and none of them are willing to leave work early to see if this fixes their problems.) Link to comment Share on other sites More sharing options...
Luke 37099 Posted October 4, 2021 Share Posted October 4, 2021 Let us know how you get on. Thanks. Link to comment Share on other sites More sharing options...
jdotero 7 Posted October 4, 2021 Share Posted October 4, 2021 Clearing out (deleting) the certificates in the X509 store (on my NAS, located in /home/emby/.dotnet/corefx/cryptography/x509stores/ca) and then rebooting the Emby server, fixed the problem. All users can now connect via Emby Connect. Link to comment Share on other sites More sharing options...
Luke 37099 Posted October 4, 2021 Share Posted October 4, 2021 Thanks for the feedback. Link to comment Share on other sites More sharing options...
K22R8CT 24 Posted October 10, 2021 Share Posted October 10, 2021 Very helpful, thanks. But I wonder why it's necessary. The pfx contains the entire chain so cache should be invalidated whenever it's updated. No? In my case it wasn't despite a fresh pfx. Is this a bug that will show up again in 4 years when the new R3 expires? Link to comment Share on other sites More sharing options...
Luke 37099 Posted October 11, 2021 Share Posted October 11, 2021 17 hours ago, Anon28109 said: Very helpful, thanks. But I wonder why it's necessary. The pfx contains the entire chain so cache should be invalidated whenever it's updated. No? In my case it wasn't despite a fresh pfx. Is this a bug that will show up again in 4 years when the new R3 expires? Unfortunately I don't think we'll be able to predict what will happen four years from now, especially given that several other pieces of software are involved as well. Link to comment Share on other sites More sharing options...
somy 24 Posted October 13, 2021 Share Posted October 13, 2021 On 9/30/2021 at 6:48 PM, Luke said: Hi that's great, thanks for sharing. Hi Luke, do you know what is the path for QNAP QPKG? Thanks! Link to comment Share on other sites More sharing options...
AylesburyStreet 0 Posted October 22, 2021 Share Posted October 22, 2021 On 9/30/2021 at 5:18 PM, swroger said: I thought this might be useful if someone else comes across the same issue. I'm a bit of an edge case since I use docker and I create a pkcs12 cert bundle from certs and keys extracted from traefik, but the issue I had was not related to that. Since Lets Encrypt intermediate expired my emby server has been presenting an expired intermediate, but the `p12` file I'm generating has the correct new intermediate, I narrowed it down to the x509stores in the docker image had cached the intermediates, so since the issuer hadn't actually changed it never refreshed the intermediates and just kept on trucking with the invalid certs. Long story short, if you run docker and have some kind of lets encrypt certificate and you're getting `NET::ERR_CERT_DATE_INVALID` from chrome (Firefox ignores the bad certs, so I think the only affected browser is edge/chrome on macOS) then either remove and recreate the docker container (it uses `/tmp` for home so that will clear it) or docker exec -ti emby-server sh -c 'rm -rf /tmp/.dotnet/corefx/cryptography/x509stores' docker restart emby-server You are a hero - thank you. I run emby on docker and couldn't understand why my android TV refused to connect after I updated the certificate, when the certificate was clearly valid and emby worked fine on iphone/browsers. This fixed it immediately. Link to comment Share on other sites More sharing options...
weble 14 Posted October 30, 2021 Share Posted October 30, 2021 (edited) @swroger this fix worked for my docker container, I could not figure out why some devices worked fine and others were not. THANK YOU!!!! Edited October 30, 2021 by weble Link to comment Share on other sites More sharing options...
jjspierx 11 Posted January 20, 2022 Share Posted January 20, 2022 For QNAP users: /share/CACHEDEV1_DATA/homes/admin/.dotnet/corefx/cryptography/x509stores/ca 1 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