Problem with R3 expired

I think i resolved the problem:
https://emby.media/community/index.php?/topic/102125-lets-encrypt-expired-intermediate-and-dotnet-caching/
I did:
sudo rm /var/lib/emby/.dotnet/corefx/cryptography/x509stores/ca/*.pfx
sudo service emby-server restart

Now it's the good Certificate #2

Anyway, thanks very much for your help.

3 Likes

What so what can users with Win 7 or Yosemite do other than update their system?
This Letsencrypt issue has caused numerous problems.

neobie, I've posted about this already, I included a link in one of my posts.

It is a known that Windows Server (at least the current versions, I can't tell you about 2008R2) will re-verify the certificate chain sometime within a few hours after being rebooted. If it finds an expired certificate it will delete that cached chain and rebuild it and update it's cache. So all you needed to do if you were hosting ANY web server on windows server that used the internal certificate chain was reboot the server after 9/30/21

If you are using some antique version of Windows Server, or you have pressed a Windows Pro system into use as a server, you might need to go into mmc and delete the expired DST certificate out of the windows certificate store then reboot.

You also can force this at the command line by doing a

certutil -urlcache * delete

that does the CRL and OCSP cache to just do the CRL cache

certutil -urlcache crl delete

That will trigger windows to rebuild the trust chain. ti also works under win7

The problem under windows is with windows programs (like firefox/thunderbird) that insist they know how to manage certificates better than Windows and have their own cert store. With those whether they Do It Right appears to be version-dependent with the old versions doing it -wrong-

With Linux you are on your own. That's why the advice for stubborn cases has been to delete the LE certificate and get a fresh one.

It seems under Linux there's a lot of people out there who renew ONLY the cert and don't bother with also replacing the fullchain.pem file at renewal time, thinking that since "fullchain.pem never changes I don't need to do that one".

We don't know exactly what they are doing, maybe they are using a home-grown script or doing it manually. certbot only has plugins for a few webservers out there the rest of the servers that use certificates they have to use their own scripts.

In addition to that many clients get very pissy about the order the cert chain is presented - if you are presenting the intermediate cert chain at all. I believe some servers out there will dynamically reorder the certs to the proper order if they are backwards in the *.pem file others won't, which adds to the fun. Some clients will also check the chain backwards and forwards when they get out-of-order intermediate certs from a server, others won't.

The safest rule of thumb to accommodate everybody is to:

always present all intermediate certs in the chain and for extra good measure present the root cert also

Make sure the certs are in the proper order

Test your server with one of the testing sites that displays the order it got the certs and whether they are valid

Never assume your clients have current root CA certs. If you must do that then buy a $1000 a year Verisign cert that was signed by a root CA created back in the dark ages and will be accepted all the way back to windows 3.1 ...LOL Otherwise ALWAYS provide a help document somewhere that explains the importance of having current and up to date software to browse your website.

The fact you even ask about win7 well you are already in the mud hopefully you are ONLY asking because you have to support knuckle-dragging clients who won't give up their win7 until they pry it from their cold, dead fingers and not for server purposes!!!!!

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.