I have found quite a few threads on this forum posted in the last 12-18 months with similar complaints: that remote access stops working unexpectedly, and the last entry in most peoples’ log files goes something like this:
Jul 22, 2022 05:52:22.958 [0x7f42ac300b38] WARN - [CERT] TLS connection from [::ffff:192.168.11.137]:57607 came in with unrecognized plex.direct SNI name '192-168-11-5.8ba14aca9582413b96e51cbfac493e4a.plex.direct'; using installed plex.direct cert
Jul 22, 2022 05:52:22.993 [0x7f42ac323b38] DEBUG - CERT: incomplete TLS handshake from [::ffff:192.168.11.137]:57602: stream truncated
The most common ‘fix’ seems to involve @ChuckPa or @BigWheel or some other staff member fixing a certificate on the back end.
Can some Plex staff please elaborate on what’s happening here? And is there any official documentation about how to handle certificates, DNS configuration for home routers, advice when using PiHole, etc? Is certificate management a rare or advanced configuration for administrators? What are the expected use cases?
I can’t find a formal channel to submit support tickets. Do paid Plex Pass customers get any such benefit?
Regardless of this, I’m asking on behalf of the entire community for better information around this certificate TLS error because when it happens to Plex, it’s often while the admin is unaware. When I checked my Synology package manager, Plex was still running.
Server Version#: Version 1.27.2.5929
Player Version#: 8.7 (3340)
edit: for reference, here are some of the posts I’m talking about:
It seems like you’re probably mixing up a few unrelated topics, so I’ll break down what’s here:
These two log lines are fairly normal, and almost always safe to ignore; individually:
“Unrecognized plex.direct SNI name” means that a client connected to us using a subdomain we don’t recognize. This generally means that it was trying to connect to a different PMS, from a different network, that happens to have the same IP address (you almost always see this with LAN addresses; in this case, we see it’s in the 192.168/16 block). We respond with our own plex.direct certificate, but the client will likely abort the connection, since the name in the cert it got back didn’t match the server it was looking for.
“incomplete TLS handshake” means that a client started to perform a TLS handshake, but the connection dropped out before it finished. This can happen for a lot of reasons (network dropouts, client app being killed, etc), but in this case, there’s a decent chance the client dropped a connection because the server didn’t turn out to be the one it was looking for.
These logs can help us understand what’s going on between a client and a server, but they aren’t a sign of any particular issue. If you see them in a log, it’s important to understand the context before assuming that they’re relevant to a problem you’re trying to address.
“Handling certificates” is generally handled automatically by PMS; users don’t need to do anything special. The only times when any particular intervention is required are when a cert file is corrupted or deleted on-disk repeatedly, or the cert cache directory can’t be accessed properly.
Custom domain and certificate functionality is also available in PMS, but it’s an advanced tool that we don’t provide support for. It’s not generally recommended, and is never required for Plex apps to work properly.
As for DNS (including Pi-hole): you generally shouldn’t need any particular configuration. The only substantial case to be concerned about is if your resolver blocks certain domains from resolving. In particular, plex.tv and its subdomains must resolve, and for some clients to work, plex.direct subdomains must be able to resolve to addresses on the LAN. If your resolver has a setting to block domains from resolving to LAN addresses, you’ll need to turn that off.
If you have any other questions about specific issues, feel free to ask, but keep in mind that small snippets containing only a few networking-related log lines are almost never meaningful on their own.
There’s some good information in there. What it doesn’t describe in detail is how Plex creates a unique TLS certificate for each server. These are generally in the form where the CN is *.certificateUUID.plex.direct. It’s a wildcard cert which covers all hosts with a particular certificate UUID. This has nothing to do with custom domains and certificates; this is entirely related to the secure connections Plex provides as a matter of course.
Thanks for the responses. I’ll check the PiHole configuration. For reference, should plex.tv resolve to a public address, and plex.direct resolve to a private address? And for the latter, IPv4 or IPv6?
In my case, the loss of remote access to my library coincided with the messages. I’m not in front of my computer at the moment, but I saved the whole log segment around this event so I can share a larger chunk if required.
On my home network, https://plex.tv resolves just fine because it’s external. When I access this page and click “Open Plex” it takes me to the web UI and shows me the library.
I’ve never heard of “plex.direct” , nor can I think of a reason to use it as I know how to access the server directly on the NAS with the local port : https://w.x.y.z:32400.
Is there a situation that can cause Plex central to lose the remote connection on the local server? I reboot my router every Sunday morning at 2am. Is a temporarily lost Internet connection enough to upset Plex?
plex.tv and its subdomains resolve to public addresses (both v4 and v6); plex.direct subdomains may resolve to both public and private addresses, both v4 and v6 (though not to “v6 private” addresses, which aren’t really a meaningful concept in DNS).
Well, those sorts of messages come up very routinely regardless, so it coinciding with them doesn’t really tell us much on its own. They might be relevant, but as always, we’d need to see full logs rather than small snippets to determine that, and may need some specific tests to be performed. It depends on the specifics of the issue you’re experiencing.
Well, https://[LAN IP]/ isn’t trusted by browsers, smart TVs, or other such devices (with good reason, since the server’s certificate isn’t for that address), so we often need to go through a DNS name; that’s where plex.direct comes in.
If a PMS instance loses its connection to plex.tv due to e.g. a network outage, it’ll try to reconnect periodically; this is fairly routine and shouldn’t cause issues on its own.
