After realising I couldnt access plex.tv due to the certificate error (it happens once a week & I need to ask plex to reset it), I stopped the plex server within the plex app on the Shield & now i cant get it to switch back on, even after you have reset the certificate. Any ideas?
Controlling PMS on the shield has never been easy for me.
When it needs a restart – I end up restarting the Shield.
If you can’t get the Shield itself to start up – that’s not a good sign.
I know, in fact in Plex network settings there’re the data required: like I already explained some messages before, all was working fine and suddently, without any change in my LAN, NAS, etc. the problem has appeared.
I am getting “[CERT] TLS connection from 80.62.xx.xx:28054 came in with unrecognized plex.direct SNI name ‘xx-3x-x-135.xxxxx9d1454cxxxx74839ce603a03.plex.direct’; using installed plex.direct cert”
Would you be so kind to reset my certificate?
I understand.
Your cert was freshly issued Sept 22.
There are no flags/faults on your Plex.tv account.
Something changed on your side and, as much of a B**** as it is, you need to walk through, one step at a time.
I’d start with making sure
- All Certs are valid and hosts restarted if certs recently changed
- DNS resolution . Having the FQDN coming through is often the browser.
(You should have the name → IP converted ??)
I see where you deleted the previous server and recreated on the same host?
The new server instance has a new certificate and hence a new SNI.
Have you restarted the device coming in and causing that bad SNI ?
Yes, it related to multiple devices and rebooting the clients does not solve it.
Please make certain the server DEBUG logging is enabled.
Next, restart the server
Wait 2 minutes
Download the logs Zip file and attach.
I want to see how it handles its own certificate
Thank you.
-
Stop Plex
-
Remove file
/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/cert-v2.dat -
Restart PMS.
Your logs show it loading the cached copy. It’s not aware the certificate needed downloading again due to the the newness of the existing cert.
Sep 29, 2022 19:44:41.442 [0x7f2ecef0a1c0] DEBUG - [CERT] Subject name is /CN=*.c3e2d4ee32f64dd8941bf3a5bbf65c40.plex.direct
Sep 29, 2022 19:44:41.442 [0x7f2ecef0a1c0] DEBUG - [CERT] Installed certificate with fingerprint 78:8d:0b:ff:6b:85:df:89:a5:a6:55:96:4c:50:b4:8b:51:d1:f8:82.
Sep 29, 2022 19:44:41.442 [0x7f2ecef0a1c0] DEBUG - [CERT/OCSP] Stapling requests will be made to 'http://r3.o.lencr.org/'.
Sep 29, 2022 19:44:41.443 [0x7f2ecef0a1c0] INFO - [CERT/OCSP] Successfully retrieved response from cache.
Sep 29, 2022 19:44:41.443 [0x7f2ecef0a1c0] DEBUG - HttpServer: Listening on port 32400.
There is no file with the name “cert-v2.dat”
However there is a file called cert-v2.p12 which I believe is an encrypted certificate.
Let me know if I remove cert-v2.p12.
ls -l -h
total 116K
-rw-r--r-- 1 plex plex 9.0K Sep 29 16:50 autotag_wordlist.json
-rw-r--r-- 1 plex plex 4.4K Aug 26 15:28 cert-v2.p12
-rw-r--r-- 1 plex plex 21K Sep 29 21:26 CloudAccessV2.dat
-rw-r--r-- 1 plex plex 11K Sep 29 19:44 CloudAccountV2.dat
-rw-r--r-- 1 plex plex 9.0K Sep 29 21:37 CloudUsersServices.dat
-rw-r--r-- 1 plex plex 2.4K Sep 29 21:26 CloudUsersSubscriptionsV2.dat
-rw-r--r-- 1 plex plex 2.1K Sep 29 21:26 CloudUsersV2.dat
-rw-r--r-- 1 plex plex 9.8K Sep 29 19:44 Flags.dat
drwxr-xr-x 2 plex plex 4.0K May 21 21:04 fontconfig
drwxr-xr-x 2 plex plex 4.0K Sep 27 10:19 OCSP
drwxr-xr-x 258 plex plex 4.0K Sep 6 2021 PhotoTranscoder
-rw-r--r-- 1 plex plex 7.6K Sep 29 19:44 Privacy.dat
drwxr-xr-x 5 plex plex 4.0K Aug 24 14:49 Transcode
-rw-r--r-- 1 plex plex 384 Sep 29 19:44 UpdateChannels.dat
I have made a backup so I will go ahead and remove cert-v2.p12 and see how that goes. I will report back.
I’m sorry. Fat-fingered that one. 
Yes, cert-v2.p12
no problem. I have now deleted cert-v2.p12 and started plexmediaserver again.
I now get this from when I start Plex from my client. Plex seems to be working but I get this DEBUG message: “CERT: incomplete TLS handshake from 87.xx.xx.xx:34335: stream truncated”
And I still get the original: [CERT] TLS connection from 192.xx.xx.xx:50791 came in with unrecognized plex.direct SNI name ‘77-xx-xx-xx.9885212xxxxxxc96574839ce603a03.plex.direct’; using installed plex.direct cert
I completely reset your certificate.
Please restart the server then restart the client(s)
I have restarted server and clients. But it seems that the problem is still there. Here is a new 2 minute log dump.
Plex Media Server Logs_2022-09-29_23-31-12.zip (1.3 MB)
Something is trying to come INBOUND with an unknown certificate.
Does this make sense to you?
Do you have your own FQDN + Cert somewhere ?
A Proxy?
Sep 29, 2022 23:28:04.450 [0x7f57ba39bb00] DEBUG - [HttpClient/HCl#1] HTTP/2.0 (0.2s) 200 response from GET https://plex.tv/media/providers?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
Sep 29, 2022 23:28:04.450 [0x7f57ba5beb00] DEBUG - [MediaProviderManager/HCl#3] HTTP requesting GET https://plex.tv/media/providers?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx
Sep 29, 2022 23:28:04.457 [0x7f57bd5aab00] DEBUG - CERT: incomplete TLS handshake from 89.XXX.XXX.XXX:50860: sslv3 alert certificate unknown
Sep 29, 2022 23:28:04.462 [0x7f57bd3a7b00] DEBUG - CERT: incomplete TLS handshake from 89.XXX.XXX.XXX:50862: sslv3 alert certificate unknown
Sep 29, 2022 23:28:04.499 [0x7f57ba39bb00] DEBUG - [HttpClient/HCl#3] HTTP/2.0 (0.0s) 200 response from GET https://plex.tv/media/providers?X-Plex-Token=xxxxxxxxxxxxxxxxxxxx (reused)
Sep 29, 2022 23:28:04.499 [0x7f57ba5beb00] DEBUG - [MediaProviderManager] discovered cloud provider (Metadata)
Yes correct, I am using Nginx Proxy Manager. But I notice now that the 89.xx address is not my mobile phone as I thought. But I recognize this foreign address. I will make sure this client is restarted. Thanks for your help. I will report back if I cannot solve it.
After a loooooong search far and wide… I find (randomly!) the issue, that I report below to try to help some users that may be in the same situation.
The timestamp file is used by the script (in the same folder) for compare the actual certificate vs a (probably) new certificate: in fact, Let’s Encrypt emits a new certificate every 3 months.
This file, for a something strange reason, was reporting a date for the old certificate newer than today, so the script was thinking “Okay, so I have no reason to update the certificate details inside Plex”… so Plex was using an old certificate that wasn’t matching with the current certificate.
