risenbysin 1 Posted October 9, 2021 Posted October 9, 2021 Hello all, having a bit of a weird issue with refreshing metadata using the fanart.tv service. I'm not exactly sure when this issue began, but I noticed it after adding some newly archived 4k rips of some movies I recently bought over the past several days. If I tail the log, when attempting to manually refresh a movie (in this case Ant-Man) I notice the following: 2021-10-09 12:16:13.733 Error HttpClient: Error getting response from https://webservice.fanart.tv/v3/movies/102899?api_key=xxxxxxx Then shortly followed by: System.Net.Http.HttpRequestException: System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. And a number of other errors. (log attached) Is there anything I can to to remedy this on my end or is this a fanart.tv issue that I just need to wait for them to resolve? My emby media server is running on Debian 11 if that helps any. I also noted the following post on the FreeBSD forum from a couple of days ago that seems similar - Thanks for any assistance you can offer. embyserver.txt
Q-Droid 989 Posted October 10, 2021 Posted October 10, 2021 The Fanart site is using Let's Encrypt certs and those have caused some problems recently. I'm not entirely sure how dotnet makes use of the user level x509store (CurrentUser\My), as a server or also as a client. I would look in ~emby/.dotnet/corefx/cryptography/x509stores/ca to see what, if any, .pfx files are there. If emby is not the host user running your server the sub that name - ~user. Remove the .pfx files in that directory and restart the Emby server. If running emby in Docker the location might be different, /tmp in the container.
risenbysin 1 Posted October 10, 2021 Author Posted October 10, 2021 15 hours ago, Q-Droid said: The Fanart site is using Let's Encrypt certs and those have caused some problems recently. I'm not entirely sure how dotnet makes use of the user level x509store (CurrentUser\My), as a server or also as a client. I would look in ~emby/.dotnet/corefx/cryptography/x509stores/ca to see what, if any, .pfx files are there. If emby is not the host user running your server the sub that name - ~user. Remove the .pfx files in that directory and restart the Emby server. If running emby in Docker the location might be different, /tmp in the container. Forgot to mention, tried this as well from reading a different thread. No such luck. Still receiving the same error for fanart.tv. I also did notice that fanart uses Let's Encrypt certs as well, figured it might be one of those wait and see things after a few more days. Thanks for the tip though!
Q-Droid 989 Posted October 10, 2021 Posted October 10, 2021 Can you connect to the same Fanart URL from the command line on the same Emby host, using curl or wget?
risenbysin 1 Posted October 10, 2021 Author Posted October 10, 2021 2 hours ago, Q-Droid said: Can you connect to the same Fanart URL from the command line on the same Emby host, using curl or wget? Yes, I am able to. Using both wget and curl. I forget the syntax to display the page with wget, but I do download a text file of the contents of the site with wget and with curl, the site comes up fine just like in my browser.
risenbysin 1 Posted October 10, 2021 Author Posted October 10, 2021 Well here's an odd one... Just for the heck of it, I updated to the beta (4.7.0.13) and then proceeded to try and refresh the Ant-Man folder again and everything worked as intended. Highly doubtful it was something in the beta that fixed it, but maybe a reinstall might have reset something? Anyway, guess this particular issue is closed for now. At least I get to test and report on the beta now For now, the server is busy refreshing the metadata for the new rips I uploaded. Thanks for the assistance @Q-Droid!
Q-Droid 989 Posted October 10, 2021 Posted October 10, 2021 Yeah, that is odd but good it's working with the beta release. I was thinking you might need to update the ca-bundle which the beta probably did. The devs can confirm if there were code changes in the beta related to secure connections and crypto. I run the stable release and had no problems with outbound connections.
dml33 25 Posted October 10, 2021 Posted October 10, 2021 8 minutes ago, Q-Droid said: Yeah, that is odd but good it's working with the beta release. I was thinking you might need to update the ca-bundle which the beta probably did. The devs can confirm if there were code changes in the beta related to secure connections and crypto. I run the stable release and had no problems with outbound connections. Hi. I am having similar issues with FreeBSD and certificate validities. The problem appeared one day with the stable 4.6.4.0, and, following some instructions in the forum, I installed latest beta 4.7.0.13, but it was the same. Could you give me any hint? Thanks!
risenbysin 1 Posted October 10, 2021 Author Posted October 10, 2021 1 hour ago, Q-Droid said: Yeah, that is odd but good it's working with the beta release. I was thinking you might need to update the ca-bundle which the beta probably did. The devs can confirm if there were code changes in the beta related to secure connections and crypto. I run the stable release and had no problems with outbound connections. Hmmm, an interesting recommendation. How would I update emby's ca-bundle? Or do you mean the ca-bundle mono (or it is .net now) uses? I'd be interested to know how to do that just for knowledge's sake.
Q-Droid 989 Posted October 10, 2021 Posted October 10, 2021 FreeBSD uses mono, right? Yeah, that's another possible twist. Emby uses the Mozilla ca-bundle (https://curl.se/ca/cacert.pem) and mono has utilities to also update its trust store using the same. What I do not know is which would make a difference, if at all. Then on some platforms the system CA should be kept current though in most cases the OS updates take care of that one. This could also come down to code but I don't think so because if that were the case there would be hundreds in here reporting issues. I don't use FreeBSD and don't have access to one to even check or verify these. Maybe I should spin up a VM to see.
Q-Droid 989 Posted October 10, 2021 Posted October 10, 2021 (edited) 13 hours ago, risenbysin said: Hmmm, an interesting recommendation. How would I update emby's ca-bundle? Or do you mean the ca-bundle mono (or it is .net now) uses? I'd be interested to know how to do that just for knowledge's sake. The Emby software installation (/opt/emby-server/etc/ssl/certs?) is the ca-bundle location. Maintained by the curl project, extracted from Mozilla then converted to PEM format (https://curl.se/ca/cacert.pem) but as far as I know only gets updated locally by Emby with package releases. Should be able to download a new version of the bundle to manually replace the current one, saving a backup copy just in case... Mono and .Net Core are in use depending on platform. And as I posted above may also need updates to the trust store where it exists. These are things I would try, not necessarily recommending them...swim at your own risk... Edited for clarity. Edited October 11, 2021 by Q-Droid
dml33 25 Posted October 11, 2021 Posted October 11, 2021 Hi. Currently, there are 3 mono versions in FreeBSD: - mono 5.10: the traditional version. Emby works, but there are problems accessing fanart.tv (CERTIFICATE_VERIFY_FAILED) - mono 5.20: Emby works, but there are problems accessing fanart.tv (CERTIFICATE_VERIFY_FAILED) - mono 6.8: Emby works, but cannot connect to anything... Regarding X509 Certificates, I have found the following dll: /usr/local/lib/emby-server/system/System.Security.Cryptography.X509Certificates.dll In fact, the error stack involves it: at Mono.Net.Security.MobileAuthenticatedStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x0000d] in <b3922b7d60404fa9ae645f1fb97f5b6b>:0 So, it seems it is embedded in Emby.
Q-Droid 989 Posted October 11, 2021 Posted October 11, 2021 Yes, the part that's failing is related to cryptography and certificate validation. That there's code used to handle cryptography for secure connections doesn't mean the trust and keys are embedded in the code. The functions (code) are separate from the data (keys/certs/trust). I'm not saying that the code couldn't be modified to handle the failure or provide specific details along with the error. But right now this is a fairly isolated problem most likely related to the certs used by the sites and the trust stores used by Emby.
Luke 42078 Posted October 12, 2021 Posted October 12, 2021 17 hours ago, dml33 said: Hi. Currently, there are 3 mono versions in FreeBSD: - mono 5.10: the traditional version. Emby works, but there are problems accessing fanart.tv (CERTIFICATE_VERIFY_FAILED) - mono 5.20: Emby works, but there are problems accessing fanart.tv (CERTIFICATE_VERIFY_FAILED) - mono 6.8: Emby works, but cannot connect to anything... Regarding X509 Certificates, I have found the following dll: /usr/local/lib/emby-server/system/System.Security.Cryptography.X509Certificates.dll In fact, the error stack involves it: at Mono.Net.Security.MobileAuthenticatedStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x0000d] in <b3922b7d60404fa9ae645f1fb97f5b6b>:0 So, it seems it is embedded in Emby. Hi, let's continue in your topic in the FreeBSD section: Thanks.
dml33 25 Posted October 12, 2021 Posted October 12, 2021 Sorry, it's the same problem, and it has been solved in Linux in this threat. I was just looking for ideas from people who knows about it, in order to solve it in FreeBSD as well, which has been quite more complex. Anyway, solved (for now)!
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