Lets Encrypt expired intermediate and dotnet caching

[swroger 6]

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

 

[Luke 42078]

Hi that's great, thanks for sharing.

[Q-Droid 989]

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

[Painkiller88 248]

how to do this on a non docker linux server?

 

thanks

[Q-Droid 989]

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.

 

[jant90 15]

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:

 

[neik 873]

Thanks a lot, that did the trick.

[alucryd 315]

@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.

[DoUEvenComputer 1]

Thanks! Spent a few hours trying to figure this one out and this fixed my problem.

[smiley1 2]

thanks! It's work for me to.

[nickbmx2100 2]

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

[nickbmx2100 2]

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

 

[TuXFire 1]

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

[jdotero 7]

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.)  

[Luke 42078]

Let us know how you get on. Thanks.

[jdotero 7]

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.

 

[Luke 42078]

Thanks for the feedback.

[K22R8CT 25]

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?

 

[Luke 42078]

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. 

[somy 25]

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!

[AylesburyStreet 0]

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.

[weble 19]

@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

[jjspierx 11]

For QNAP users:

/share/CACHEDEV1_DATA/homes/admin/.dotnet/corefx/cryptography/x509stores/ca