I am trying to setup nginx in front of my plex server on the same box to do some SNI type stuff. With that being said plex has it’s own ssl certificate for plex.direct. Is there anyway I can use that certificate inside of my nginx configuration to add plex.direct support?
To my knowledge, that’s never been attempted.
I’m not sure it’s possible from the user side because all you have is the P12 file for the server. You don’t have a cert & key file.
From my experience the p12 file generally has the both the cert and key… All we really need is the password to unlock it.
For obvious reasons, Plex will never publish the keys to its certs as that would defeat the purpose of certs.
The issue you face is about the PMS - Plex.tv communication which CANNOT have Nginx in between
1 Like
It’s on my system and if I’m not mistake then cert is specific to my plex.direct. Such as *.<uuid>.plex.direct, so this is kinda annoying that plex is putting stuff on my system that I don’t have access to that is only related to my system. The only thing that we would need is the password for the p12 to unlock it and get the cert and key.
That file /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache/cert-v2.p12 is used for your clients and plex.tv communication to ensure HTTPS connections.
NO, you’re not getting the password to unlock it.
Would you banking institution give you the password to the backside engine?
That seems like an oversight to load a bunch of stuff in to a single p12 file rather than having certain pieces available to the user to utilize. Also, the difference is I don’t run an application on my linux box for my bank. There are ways to do this where we the user would get access to the essentially an acme cert for *.<uuid>.plex.direct so we can use it how we need to make sure all services work when things connect it. Can’t that be a feature request and something that would allow us to make plex more flexable?
ABSOLUTELY that can be a feature request.
I see no reason either to prevent repartitioning of services.
The challenge in that would be how to migrate existing → new.
Please do feel free to write up a suggestion.
If i’m not mistaken the p12 file is deleted fairly quickly for example mine expires Fri, 01 Sep 2023 18:02:51 UTC (expires in 2 months and 9 days). So, during the install of the new version it deletes the old p12 file creates one that is for the plex.tv services and another for *.<uuid>.plex.direct that is a known password that is put in to the plex.tv help center.
OR
you guys open up an authenticated acme setup and leave the p12 cert alone for normies, but allow users to request a cert using a regular acme client and you explain how the <uuid> in the *.<uuid>.plex.direct is generated or gotten and then we could use that to generate our own certs anytime we need to like any acme cert setup. You guys just regulate the signing to only plex.direct domains and that is it. I’m sure you could also regulate it to only the domains that have already been registered with you already and have systems setup.
You can add your own FQDN certificate to PMS in Settings - Server - Network - Show Advanced
You provide the path to the P12/PFX and the password (if any)
In that certificate file, you must include:
- Cert
- Key
- CA
Once validated and added, PMS will accept connection requests using it.
Internally, PMS uses its certificate for Plex.tv and clients.
Externally, you use your FQDN
I’m aware that I can add my cert, but there are certain services like the Amazon echo plex that uses the plex.direct domain to connect to it rather than the fqdn supplied in the network section.
Plex uses its certificate to communicate with Plex-internal services and protocols.
Plex will NOT use your FQDN cert to connect from your server to a player device and then run Plex-proprietary streaming protocols.
Your FQDN serves as “Inbound Only”.
Wow, that wasn’t what I said at all. I’m aware the cert is used for only inbound communications. I’m fully aware of that, but what I am saying is there are plex services that connect to my server that don’t use my FQDN and use the plex.direct domain instead. And I used the alexa player as an example. The player should be connecting to my server via the fqdn I provide and not via the plex.direct domain.
All I am saying is this:
(any client or service inbound toward my plex: Plexamp, prologue, plex app, web browser) → my plex (connect to my fqdn not your plex direct domain if I provide one and set my custom ssl cert)
The reason I’m bringing this up is because somethings bypass the my server fqdn that I set in plex. I give my parents access to my server who is lucky literally 5 minutes up the road from me, so if they have trouble I can fix it, but I would love to be able to put all of this behind a nginx server that protects for one and two can do ip address filtering. I would love to use aws cloudfront infront of my stuff because since it’s only 8 people (me, my wife, kids, and my parents) I can essentially get free cloudflare type protection for my plex server. Since there is no way I could ever cross the data cap because again 8 people. The agents that you guys make don’t always use the fqdn provided in the network tab all of the time. That should be the first thing that is attempted to connect to.
You missed it.
The answer here is NO.
Let me try to give you the sequence:
- Player has a manual server address set (your FQDN)
- Player attempts to securely connect to the address
- PMS accepts the initial connection because it knows your FQDN
- Player and server now authenticate
- Player and server now SWITCH to your Plex certificate and URL.
- All future communication is using the Plex certificate and URL.
( Every player and server must be signed in so this always works )
I have my own FQDN for my server.
I don’t use a Proxy because it’s a PITA.
Instead, I use a DDNS/ static IP firewall rule to control access to the server WAN port.
( I have also added the plex.tv domain which is what allows Remote Access service to confirm connectivity)
I just want to note two things:
- I understand prologue isn’t you guys
- I get you are worried about your protocol, but I need a way of protecting my server. I don’t want my server hacked or ddos because I have to essentially open the main port to my plex server wide open to the world. You guys need to work with your customers to find a happy medium.
Then why don’t you put a firewall on the front end which DROPs all traffic which isn’t authorized?
This doesn’t stop anyone from performing a DDOS on your internet service but it at least makes your Plex server completely invisible unless the source is from an allowed IP address / domain.
If we put additional blocking in, it’s still YOUR PORT which is open.
We can’t block port scans happening against your internet service.
So, if I allow plex.tv inbound to my plex server that fixes the remote connectivity test issue.
But Alexa plex can come from a large amount of ip addresses since it uses essentially aws for the backend.
Secondly, when I’m on my phone I can’t guarentee the public ip address that is used. Or my wife’s phone or kids’.
We have to be able to come to some sort of compromise to protect the plex server.
Also, I already have a very well configured firewall. I’m just trying to add an extra layer of security.
Plex uses AWS.
As for accessing the server when remote on my phone?
I keep it really simple – Wireguard. Wireguard doesn’t care what the IP address is.
To be completely tinfoil about it?
I can turn Remote Access OFF and still access my Plex server over WIreguard.
Problem solved.
But the inbound ip address for Alexa plex isn’t going to resolve to plex.tv ip address. It will be a random aws ip.
