TLS, unknown player error and *.plex.direct

PMS Version#: 1.25.4.5426
Samsung client: 5.29.1 (platform 4)

Last September, I switched my PMS certificate from Let’sEncrypt to ZeroSSL to workaound DST ROOT CA X3 expiration on broken clients. Since then, old TVs were back on track except my Samsung TVs (>2016) when transcoding was required.

So, Samsung TVs are able to play content over secure channel until no transcoding is involved.

With transcoding, error messages from the client are:

Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] DEBUG - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [PlaybackSessionController] Opening playback
Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (NONE)] open ("https://[**redacted**].plex.direct:32400/video/:/transcode/universal/start.mpd?session=4aipm3fughp1kgojkdqex3l3")
Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setListener ({})
Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setDisplayRect (79, 0, 1762, 1080)
Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setDisplayMethod ("PLAYER_DISPLAY_MODE_FULL_SCREEN")
Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setTimeoutForBuffering (120)
Jan 24, 2022 23:29:08.498 [0x7f7bfbc56b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] prepareAsync (, )
Jan 24, 2022 23:29:43.628 [0x7f7bfc13eb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [PlaybackSessionController] playback state changed to: stopped
Jan 24, 2022 23:29:43.628 [0x7f7bfc13eb38] WARN - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] Failed to send transcode action stop to source: server://a7f4d5c45423575c44292b8710bf5aa7dd652ce0/com.plexapp.plugins.library/library/metadata/80950
Jan 24, 2022 23:29:43.628 [0x7f7bfc13eb38] ERROR - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] Playback error occurred. Reason: Unknown, An unknown player error occurred. code: 0, message: An unknown error occurred: Unknown error
Jan 24, 2022 23:29:43.629 [0x7f7bfc13eb38] WARN - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [PlaybackSessionController] could not retry, reporting error

On the server side:

# grep -i handshake Plex\ Media\ Server.log
Jan 24, 2022 23:27:50.244 [0x7f7bfb7deb38] DEBUG - WebSocket: Performing handshake from origin https://[**redacted**]:32400
Jan 24, 2022 23:27:53.222 [0x7f7bfb7deb38] DEBUG - WebSocket: Performing handshake from origin 
Jan 24, 2022 23:27:53.224 [0x7f7bfb7bbb38] DEBUG - WebSocket: Performing handshake from origin http://[**redacted**].plex.direct:32400
Jan 24, 2022 23:28:05.866 [0x7f7bfb7bbb38] DEBUG - WebSocket: Performing handshake from origin file://
Jan 24, 2022 23:28:17.266 [0x7f7bfc599b38] DEBUG - CERT: incomplete TLS handshake from 192.168.1.12:48801: tlsv1 alert unknown ca

When direct play, no error and playback is ok. Here is the log output from the client:

Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [MDE] Server decision, directPlay: true, directStreamVideo: true, directStreamAudio: true
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy]   reason: Direct play OK.
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlayFactory] Requesting new player...
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (NONE)] load: {
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [SubtitleConnectionManager] Subtitle connection ignored. App is not rendering subtitles.
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [PlaybackSessionController] playback state changed to: buffering
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (NONE)] open ("https://[[**redacted**]plex.direct:32400/library/parts/622614/1640639653/file.mkv?X-Plex-Token=xxxxxxxxxx
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setListener ({})
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setDisplayRect (0, 0, 1920, 1080)
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setDisplayMethod ("PLAYER_DISPLAY_MODE_FULL_SCREEN")
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] setTimeoutForBuffering (120)
Jan 25, 2022 00:31:16.566 [0x7f7bff08fb38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] prepareAsync (, )
Jan 25, 2022 00:31:21.786 [0x7f7bf82c0b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] Buffering...
Jan 25, 2022 00:31:21.786 [0x7f7bf82c0b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] onBuffering: 2%
Jan 25, 2022 00:31:21.786 [0x7f7bf82c0b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] onBuffering: 3%
Jan 25, 2022 00:31:21.786 [0x7f7bf82c0b38] INFO - [Plex for Samsung] [seblu:x7bo0byefrat3754b1emipjy] [AVPlay[1] (IDLE)] onBuffering: 3%

My intuition at the moment is that there is a problem with the *.plex.direct:32400. certificate because its chain is using the problematic DST ROOT CA X3.

See the chain:

$ openssl s_client 192-168-1-1.666666666666.plex.direct:32400
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = *.666666666666.plex.direct
verify return:1
---
Certificate chain
 0 s:CN = *.666666666666.plex.direct
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3

So, if used by Samsung TVs, this certificate cannot be trusted and secure connections fails. Yet, I don’t understand why this certificate is used (and only when transcoding) instead of my valid and working certificate from ZeroSSL.

The Custom server access URLs in PMS settings is pointing to my own domain, no plex.direct.
Do you have any ideas to correct this?

@ChuckPa I see you are involved in fixing certificate issue in other threads. Do you have an idea of why this certificate issue only happen when transcoding is required?

First. your server certificate (which includes your Plex.direct) is valid.

Valid	Tue, 28 Dec 2021 08:20:56 +0000	Tue, 28 Dec 2021 08:21:05 +0000

What are you doing with the Custom Server Access URLs?

Plex.tv has a very broken entry for you.

(Privacy redacted below)

PUBLISHED YES (82.XX.XXX.XXX:32400) 
LOCAL ADDRESSES PLEX.SXXXXXXX.XXX, 192.168.242.4, HTTPS

Why is HTTPS in that clause as a stand-alone item?
It has no business being there.

What are you doing with the Custom Server Access URLs?

<?xml version="1.0" encoding="utf-8"?>
<Preferences MachineIdentifier="****" ProcessedMachineIdentifier="*****" TranscoderTempDirectory="/var/tmp/plexmediaserver/" OldestPreviousVersion="legacy" AnonymousMachineIdentifier="*****" MetricsEpoch="1" GracenoteUser="****" AcceptedEULA="1" FriendlyName="Plex****" PublishServerOnPlexOnlineKey="1" PlexOnlineToken="****" PlexOnlineUsername="seblu" PlexOnlineMail="***" CertificateVersion="3" LastAutomaticMappedPort="0" PubSubServer="178.79.165.194" PubSubServerRegion="lhr" PubSubServerPing="26" LanguageInCloud="1" sendCrashReports="0" FSEventLibraryUpdatesEnabled="1" ScheduledLibraryUpdatesEnabled="1" ManualPortMappingMode="1" PlexOnlineHome="1" DlnaEnabled="0" secureConnections="1" CinemaTrailersFromLibrary="0" TranscodeCountLimit="0" logDebug="0" GenerateBIFBehavior="asap" GenerateChapterThumbBehavior="asap" ScannerLowPriority="1" HardwareAcceleratedCodecs="1" LanNetworksBandwidth="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" WanPerUserStreamCount="****" ButlerEndHour="10" ButlerStartHour="7" CloudSyncNeedsUpdate="0" FSEventLibraryPartialScanEnabled="1" allowMediaDeletion="1" ButlerTaskRefreshLibraries="1" LoudnessAnalysisBehavior="asap" customCertificateDomain="https://plex.domain.tld:32400/" customCertificateKey="****" customCertificatePath="/var/lib/plexmediaserver/certificate.pfx" ScheduledLibraryUpdateInterval="43200" allowedNetworks="" iTunesSharingEnabled="0" customConnections="https://plex.domain.tld:32400/" WanTotalMaxUploadRate="***" TreatWanIpAsLocal="1" TranscoderQuality="0" DlnaReportTimeline="0" TranscoderH264BackgroundPreset="medium" ButlerUpdateChannel="0" LogVerbose="0" BackgroundQueueIdlePaused="0" autoEmptyTrash="0" OnDeckWindow="4" TranscoderThrottleBuffer="60" CertificateUUID="*****" EnableIPv6="0" WebHooksEnabled="1" MinutesAllowedPaused="30" DvrIncrementalEpgLoader="0" CinemaTrailersPrerollID="" CinemaTrailersType="0" GdmEnabled="1" PreferredNetworkInterface="" RelayEnabled="0" HardwareAcceleratedEncoders="1" TranscoderToneMapping="1" DisableTLSv1_0="0" MergedRecentlyAdded="0" ButlerTaskRefreshEpgGuides="1"/>

Notes:

  • customConnections and customCertificateDomain are equal.
  • Server has only 1 IPv4 address (RFC1918)
  • Server has 1 FQDN (e.g plex.domain.tld) which resolve to the local IPv4 address inside local networks and to the ISP public IP otherwise.

Why is HTTPS in that clause as a stand-alone item?

I don’t know, where did you get this output?
Is this related to https inside the customConnections?

@seblu

I looked directly at the record Plex.tv has for your server.

It listed your URLs and then has ,HTTPS on the end as if you were trying to do something else but did not complete it.

I don’t know the format of the record you have for my server at Plex.tv, so I have no idea where this , HTTPS comes from.

I sent you my server Preferences.xml where the network configuration of the Plex Media Server is. Do you see something wrong in it which can lead to this , HTTPS in your record?

Do you think this could be the cause of the problem that only affects transcoding on Samsung TVs?

@seblu

Where did you send it? I’m looking at my PMs and do not see anything.

In my previous answer from 4:41pm.

@seblu

I figured it out

  1. You have a FULL URL for the Domain name.
  2. You only want domain.tld .
  3. This is why Plex.tv is seeing HTTPS. It thinks https://name.domain.tld:32400 is the domain name and parsing it incorrectly.
  4. The Custom Access URL is different :wink:

I was looking right at it and didn’t see it :man_facepalming:

Oh, I see. I misinterpreted the using your mapped port in the help text. It’s fixed and after server restart the main issue remain.

Reminder: Transcoding fail on 2018 Samsung TVs and my current guess is it’s related to the certificate authority provided by plex.direct (i.e https://192-168-242-****.plex.direct:3240) which is expired.

LOGs please so I may see the player error ?

There are MANY televisions impacted by the 30-Sept-2021 LE certificate expiration

LOGs please so I may see the player error ?

There is a selection of interesting log lines in my post description. Did you see them?
Do you want a complete log output? I can send it to you in PM to avoid too much anonymization.

There are MANY televisions impacted by the 30-Sept-2021 LE certificate expiration

Yes and these TVs are impacted, that’s why I switched my plex certificate from Let’sEncrypt to ZeroSSL which is also free but doesn’t have an expired RootCA in less than 5 years hardware.

Doing this fixed TV access to the server and direct play.
Please note, this is a better solution than the one proposed by Plex, which is in a nutshell, disable security on these devices.

When transcoding, the only solution is to disable security, which led me to discover that another (and bad) certificate was used somewhere when transcoding was involved.

Do you know why PMS is NOT using my valid certificate to access my server?

  1. I would like the full logs.

  2. When you give Plex your certificate, you must ALSO INCLUDE the CA.

  • you can confirm whether the cert is accepted or not when PMS starts (right at the top)
    – Finds a user cert
    – Checks basic certificate and authenticates the chain.
    – Pins it if valid
    – Tells you the CA is missing if not provided.
  1. How do you handle installing an updated root certificate in a TV?

Done in PM

In my current configuration, the intermediate CAs are included, but the Root CA. This is the traditional way to configure certificates in web servers, as the Root CA when sent is ignored because it must be in the client trust store.

I did a test with a pfx file with the root certificate authority in the chain but it does not change the playback issue in TVs.

openssl s_client -showcerts -connect plex.domain.tld:32400                                            
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = AT, O = ZeroSSL, CN = ZeroSSL RSA Domain Secure Site CA
verify return:1
depth=0 CN = plex.domain.tld
verify return:1
---
Certificate chain
 0 s:CN = plex.domain.tld
   i:C = AT, O = ZeroSSL, CN = ZeroSSL RSA Domain Secure Site CA
 1 s:C = AT, O = ZeroSSL, CN = ZeroSSL RSA Domain Secure Site CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
 3 s:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services

This is too much work, even for my house TVs and not scalable to my friends.
And I don’t need to.
There are valid CAs in the TV trust store. These TVs are still able to connect “securely” to youtube or other services with their trust store.
Because, in the end, the problem is Let’s Encrypt not providing a certificate trusted by these not so old devices.
So, getting a trusted certificate is a far easier alternative. You can buy it, or you can even get one for free with ZeroSSL. Their certificates are trusted by Comodo Root CA up to 2028 and downloadable via ACME:

For example, here is the RootCA I use.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
        Validity
            Not Before: Jan  1 00:00:00 2004 GMT
            Not After : Dec 31 23:59:59 2028 GMT
        Subject: C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services

When Plex is configured to use a Custom certificate and domain, that’s in addition to the automagical *.plex.direct certificate and addresses.

The *.plex.direct certificate is still used and is the default.

The Custom certificate is only used when an HTTPS SNI request matches the configured Custom certificate domain.

The *.plex.direct certificate and hostnames are also used for local connections. Plex always and only registers the *.plex.direct name and certificate for local connections. It does not register the Custom domain or address for local connections.

Look at what’s being registered here:

https://plex.tv/api/resources?includeHttps=1&includeIPv6=1&X-Plex-Token=INSERT-TOKEN-HERE

Finding an authentication token / X-Plex-Token | Plex Support

To prevent the *.plex.direct local connection URL from being used, you may need to push the TVs off of the same network as Plex, so they treat it as a remote connection.

Any custom Custom Server Access URL will then be prioritized as the first (non-local) connection.

Disabling Remote Access entirely would prevent Plex from registering the other (non-local) *.plex.direct addresses, but I don’t think that should be necessary.

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