nague 5 Posted September 29, 2021 Share Posted September 29, 2021 (edited) Has anyone experience connection issue with Sony TV (Android 8 + SSL + Let's Encrypt )? Starting from tonight, I'm not able to connect emby server from Sony TV with SSL. Others devices are still working fine with SSL. I'm thinking it can be relate to the DST Root CA X3 expiration (https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/). From a tcpdump capture, I can read with wirehark TLSv1.2 Alert "Fatal - Certificate Unknown" from Sony TV. Edited September 29, 2021 by nague Link to comment Share on other sites More sharing options...
nague 5 Posted September 29, 2021 Author Share Posted September 29, 2021 Edit: actually, my Nvidia Shield is also impacted. Link to comment Share on other sites More sharing options...
ebr 14958 Posted September 29, 2021 Share Posted September 29, 2021 Hi. Are you somewhere where it is already Sep 30th? That does seem like too much of a coincidence, however, that doc says that Android devices should still work... Link to comment Share on other sites More sharing options...
nague 5 Posted September 30, 2021 Author Share Posted September 30, 2021 Hi @ebr I thought like you as it was still Sep 29th, but here another clue: at the same time yesturday, Emby for Android (mobile) reported a new DST Root CA X3. I also discovered this morning that Emby for Apple TV is impacted too. Can you rename this topic with something related to Let's Encrypt and Emby for AndroidTV ? Link to comment Share on other sites More sharing options...
neik 838 Posted September 30, 2021 Share Posted September 30, 2021 (edited) Create a new one, I also saw some issues on Android Mobile using Chrome Browser with the cert today, creating a new one solved it. AFAIK Let's Encrypt made some changes today on their infrastructure which might be related to this. Edit: Need to revert what I said, there seem to be still issues with this. Just tried the Emby app for Mobile and it keeps asking me to accept the Let's Encrypt cert. On AndroidTV it's even worse, there I can't get my MiBoxS to connect anymore, it keeps telling me the server might be offline - which it isn't. Edited September 30, 2021 by neik Link to comment Share on other sites More sharing options...
nague 5 Posted September 30, 2021 Author Share Posted September 30, 2021 I forced a certificate renew but the issue is still here on Emby for AndroidTV + AppleTV. Emby for Android Mobile noticed the new certificate and is working fine. Link to comment Share on other sites More sharing options...
neik 838 Posted September 30, 2021 Share Posted September 30, 2021 I don't even get it fixed on Android Mobile, still seeing the message you posted in the screenshot above. I think it is somehow related to the certificates path, in my case the "DST Root CA X3" as parent is missing: The forum of Let's Encrypt looks like this: Interestingly if I use nginx as reverse proxy it does work fine, so I'm wondering if I am doing anything wrong in the conversion from pem to pfx. This is the command I am using: openssl pkcs12 -export -out certificate.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem Any hint is appreciated! Link to comment Share on other sites More sharing options...
nague 5 Posted September 30, 2021 Author Share Posted September 30, 2021 @neik I'm using acme.sh to renew my let's encrypt certificate, and this command to convert to pfx: acme.sh --toPkcs -d <domain> [--password pfx-password] In the meantime, same behavior in my side, Emby for Android Mobile keeps asking me that to accept the certificate, but it's working fine then. Link to comment Share on other sites More sharing options...
Q-Droid 670 Posted September 30, 2021 Share Posted September 30, 2021 I just renewed my cert to test and I think this might be an Emby problem, @Luke. The new full chain from LetsEncrypt includes the ISGR Root X1 cert used in cross signing but Emby is not presenting the full chain depth during the authentication handshake. So the client is trying to complete the chain using the DST Root CA X3. It appears the browsers are able to handle the expired root properly but not the Android clients if the chain cert is missing. subject=/CN=myembycn issuer=/C=US/O=Let's Encrypt/CN=R3 subject=/C=US/O=Let's Encrypt/CN=R3 issuer=/C=US/O=Internet Security Research Group/CN=ISRG Root X1 subject=/C=US/O=Internet Security Research Group/CN=ISRG Root X1 issuer=/O=Digital Signature Trust Co./CN=DST Root CA X3 My cert store has the full chain of three certs but Emby is only presenting two (depth=1). $ openssl s_client -connect myembycn:8920 CONNECTED(00000003) depth=1 C = US, O = Let's Encrypt, CN = R3 verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/CN=myembycn i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- 1 Link to comment Share on other sites More sharing options...
Q-Droid 670 Posted September 30, 2021 Share Posted September 30, 2021 This is weirder than I though and now I'm convinced it's an issue in Emby. The LE R3 cert presented during the handshake IS NOT the LE R3 cert stored in the pfx. Also note that the one from Emby is expired. From Emby: Owner: CN=R3, O=Let's Encrypt, C=US Issuer: CN=DST Root CA X3, O=Digital Signature Trust Co. Serial number: 400175048314a4c8218c84a90c16cddf Valid from: Wed Oct 07 15:21:40 EDT 2020 until: Wed Sep 29 15:21:40 EDT 2021 Certificate fingerprints: MD5: 31:21:28:F5:A0:ED:7B:A5:4B:65:82:92:87:56:BA:83 SHA1: 48:50:4E:97:4C:0D:AC:5B:5C:D4:76:C8:20:22:74:B2:4C:8C:71:72 SHA256: 73:0C:1B:DC:D8:5F:57:CE:5D:C0:BB:A7:33:E5:F1:BA:5A:92:5B:2A:77:1D:64:0A:26:F7:A4:54:22:4D:AD:3B In PFX: Owner: CN=R3, O=Let's Encrypt, C=US Issuer: CN=ISRG Root X1, O=Internet Security Research Group, C=US Serial number: 912b084acf0c18a753f6d62e25a75f5a Valid from: Thu Sep 03 20:00:00 EDT 2020 until: Mon Sep 15 12:00:00 EDT 2025 Certificate fingerprints: MD5: E8:29:E6:5D:7C:43:07:D6:FB:C1:3C:17:9E:03:7A:36 SHA1: A0:53:37:5B:FE:84:E8:B7:48:78:2C:7C:EE:15:82:7A:6A:F5:A4:05 SHA256: 67:AD:D1:16:6B:02:0A:E6:1B:8F:5F:C9:68:13:C0:4C:2A:A5:89:96:07:96:86:55:72:A3:C7:E7:37:61:3D:FD Link to comment Share on other sites More sharing options...
ebr 14958 Posted September 30, 2021 Share Posted September 30, 2021 Moving to general section as this appears to be a global issue. Link to comment Share on other sites More sharing options...
SOz92 7 Posted September 30, 2021 Share Posted September 30, 2021 I have problems too with the certificate in different android devices...I forced renew certificate but nothing solves. Link to comment Share on other sites More sharing options...
jant90 15 Posted September 30, 2021 Share Posted September 30, 2021 Same issue here. Also got the notification in the mobile Android app to accept the new certificate shortly after midnight, after accepting it's working fine again. However I have several friends that can't play anything now. Most are running CoreELEC 9.2.8 (Kodi Leia) and the legacy Emby addon. One friend is running the Android TV app on a Mi Box. My own CoreELEC 19.2 (Kodi Matrix) box is not affected and browsers are fine as well. Who knows what to do? Should we generate the *.pfx differently? Maybe use fullchain.pem instead of chain.pem? Link to comment Share on other sites More sharing options...
nague 5 Posted September 30, 2021 Author Share Posted September 30, 2021 Moving to ZeroSSL might be an option... Link to comment Share on other sites More sharing options...
neik 838 Posted September 30, 2021 Share Posted September 30, 2021 22 minutes ago, jant90 said: Should we generate the *.pfx differently? Maybe use fullchain.pem instead of chain.pem? I tried that -> Same result. Link to comment Share on other sites More sharing options...
Luke 37232 Posted September 30, 2021 Share Posted September 30, 2021 35 minutes ago, jant90 said: Same issue here. Also got the notification in the mobile Android app to accept the new certificate shortly after midnight, after accepting it's working fine again. However I have several friends that can't play anything now. Most are running CoreELEC 9.2.8 (Kodi Leia) and the legacy Emby addon. One friend is running the Android TV app on a Mi Box. My own CoreELEC 19.2 (Kodi Matrix) box is not affected and browsers are fine as well. Who knows what to do? Should we generate the *.pfx differently? Maybe use fullchain.pem instead of chain.pem? HI, the android app has no impact on the Kodi addon, so I would suggest creating a topic in the Kodi section of the community. Thanks. Link to comment Share on other sites More sharing options...
Q-Droid 670 Posted September 30, 2021 Share Posted September 30, 2021 34 minutes ago, Luke said: HI, the android app has no impact on the Kodi addon, so I would suggest creating a topic in the Kodi section of the community. Thanks. @Luke, I tried sending you PM but it's not allowing me. I've PM'd @ebr with some details about this and the .dotnet crypto cache workaround posted in another thread. 1 Link to comment Share on other sites More sharing options...
jant90 15 Posted September 30, 2021 Share Posted September 30, 2021 This is the issue: https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ So unless you can add a new root cert to the problematic devices you're out of luck with Let's Encrypt. It should be possible to add certs to CoreELEC devices for example but with unrooted Android TV devices and TV's you're probably screwed. 1 hour ago, nague said: Moving to ZeroSSL might be an option... Yep, looking into it now as well. It should be possible to use certbot with their ACME server as well but I couldn't find a lot of documentation yet. Hope I can get that to work with Cloudflare DNS challenges. Link to comment Share on other sites More sharing options...
Q-Droid 670 Posted September 30, 2021 Share Posted September 30, 2021 (edited) There is a fix but you would have to find the location on your server as it would be different between platforms. It is a server side fix. Removing the cached certs (pfx) from the directory forces the download of the updated certs. Might have to restart the server, I haven't tested without restart. Edited September 30, 2021 by Q-Droid 2 Link to comment Share on other sites More sharing options...
jant90 15 Posted September 30, 2021 Share Posted September 30, 2021 (edited) @Luke is it possible that Emby server itself is suffering from the same issue when connecting to other API's, such as the Fanart API (https://webservice.fanart.tv) which is also using Let's Encrypt? I can no longer get images from them since today. Edit: I think it is, I see this in my server log: 2021-09-30 20:10:19.690 Error HttpClient: Error getting response from https://webservice.fanart.tv/v3/movies/359724?api_key=xx&client_key=xx *** Error Report *** Version: 4.6.4.0 Command line: /usr/lib/emby-server/EmbyServer.dll -programdata /var/lib/emby -ffdetect /usr/bin/ffdetect-emby -ffmpeg /usr/bin/ffmpeg-emby -ffprobe /usr/bin/ffprobe-emby -restartexitcode 3 Operating system: Linux version 5.14.7-2-MANJARO (builduser@fv-az121-187) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Wed Sep 22 12:22:56 UTC 2021 Framework: .NET Core 3.1.17 OS/Process: x64/x64 Runtime: usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.17/System.Private.CoreLib.dll Processor count: 12 Data path: /var/lib/emby Application path: /usr/lib/emby-server 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. at System.Net.Security.SslStream.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception) at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.PartialFrameCallback(AsyncProtocolRequest asyncRequest) --- End of stack trace from previous location where exception was thrown --- at System.Net.Security.SslStream.EndProcessAuthentication(IAsyncResult result) at System.Net.Security.SslStream.EndAuthenticateAsClient(IAsyncResult asyncResult) at System.Net.Security.SslStream.<>c.<AuthenticateAsClientAsync>b__65_1(IAsyncResult iar) at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean allowHttp2, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.GetHttpConnectionAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken) at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts) at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod) Source: System.Net.Http TargetSite: Void MoveNext() InnerException: System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure. Source: System.Private.CoreLib TargetSite: Void Throw() at System.Net.Security.SslStream.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, ExceptionDispatchInfo exception) at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslStream.PartialFrameCallback(AsyncProtocolRequest asyncRequest) --- End of stack trace from previous location where exception was thrown --- at System.Net.Security.SslStream.EndProcessAuthentication(IAsyncResult result) at System.Net.Security.SslStream.EndAuthenticateAsClient(IAsyncResult asyncResult) at System.Net.Security.SslStream.<>c.<AuthenticateAsClientAsync>b__65_1(IAsyncResult iar) at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization) --- End of stack trace from previous location where exception was thrown --- at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken) Note the "The remote certificate is invalid according to the validation procedure.". Edited September 30, 2021 by jant90 Link to comment Share on other sites More sharing options...
neik 838 Posted September 30, 2021 Share Posted September 30, 2021 3 minutes ago, jant90 said: @Luke is it possible that Emby server itself is suffering from the same issue when connecting to other API's, such as the Fanart API (https://assets.fanart.tv) which is also using Let's Encrypt? I can no longer get images from them since today. Seeing SSL errors related to fanart as well in the logs. Whatever Let's Encrypt did there it seems to have quite an impact on many homepages. 1 Link to comment Share on other sites More sharing options...
Painkiller8818 203 Posted October 2, 2021 Share Posted October 2, 2021 (edited) It is not a Server Problem it is a Client Problem. If your Devices are old or outdated, it might be they are not able to handle the new ISRG Root CA. In my case my old 2008 Macbook was one of them. But here you can download the new ROOT CA and Intermediate for ISRG X1 and X2 and import it to your Clients Certificates Store. After you did this, you will be able to reach all the Lets Enctypt sites again. (Maybe a Browser or App Restart is needed) https://letsencrypt.org/certificates/ Edited October 2, 2021 by Painkiller8818 Link to comment Share on other sites More sharing options...
rossome 3 Posted October 3, 2021 Share Posted October 3, 2021 "Found the issue: The PFX certificate was used in a server written with .NET 5.0. Compiling the server with the latest version of dotnet fixed the issue." from: https://community.letsencrypt.org/t/full-chain-still-contains-expired-r3-certificate-in-pfx/160925 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