Custom TLS Certificates do not work no matter what I do

Plex Media Server NAS & Devices
,
1

So I’ve spent the afternoon working with Plex Media server on my Qnap server trying to make custom certificates work. I am using lego which is a go based acme client. I have valid certificates that were issued by using DNS validation with Cloud Flare. I’ve tried everything I can imagine and the server refuses to even provide the certificates I have configured.

I’ve already validated the certificates 7 ways to Sunday but if someone wants to offer anther option let me know. I built and rebuilt the p12 file, I even manually downloaded the cross signed root which is absolutely not required and added that to the p12 file.

Every time I add and remove the certificate in debug mode I see what appears to be success but then it proceeds to load a new plex.direct DigiCert certificate.

I have configured the custom certificate domain, customer access urls, and disabled remote access all to no avail. I have removed my LAN subnet settings, removed view Wan as Lan for Bandwidth, etc. I’ve also tried blowing away the cache.

Note there are no errors in loading the cert and it’s performing stapling.

I use my own DNS at home with pi-hole and unbound. plex.direct urls are already marked as private domains and DNS rebind protection is not enabled. Internally the domain name of the cert resolves to the LAN IP. Externally it resolves to a public IP.

The server has 2 public addresses one which is a VPN tunnel and not used for server access and one which is bound to the fqdn of the cert. I cannot change this.

Server Version#: 1.18.3.2156

Dec 31, 2019 22:27:13.555 [0x7f068e999700] DEBUG - CERT: Installed certificate with fingerprint 00:c5:6e:eb:ec:e3:e6:f5:4a:ea:62:9f:bb:42:17:2a:76:bd:e3:ff.
Dec 31, 2019 22:27:13.555 [0x7f068e999700] DEBUG - CERT: Installed new private key.
Dec 31, 2019 22:27:13.555 [0x7f068e999700] DEBUG - CERT: Subject name is /C=US/ST=California/L=Los Gatos/O=Plex, Inc./CN=*.<uniq id>.plex.direct
Dec 31, 2019 22:27:13.556 [0x7f068e999700] DEBUG - CERT: OCSP requests for stapling will be made to 'http://ocspx.digicert.com/'.
Dec 31, 2019 22:27:13.556 [0x7f068e999700] INFO - OCSP: Successfully retrieved response from cache.
Dec 31, 2019 22:27:13.556 [0x7f068e999700] DEBUG - CERT: Installed intermediate certificate.
Dec 31, 2019 22:27:13.557 [0x7f068e999700] DEBUG - CERT: Loaded a user-provided certificate.
Dec 31, 2019 22:27:13.558 [0x7f068e999700] DEBUG - CERT: OCSP requests for stapling will be made to 'http://ocsp.int-x3.letsencrypt.org/'.
Dec 31, 2019 22:27:13.558 [0x7f068e999700] INFO - OCSP: Successfully retrieved response from cache.
2

Bump !

3

So I’ve looked at this some more. I can now say with certainty that Plex is loading my pix file just fine. If I remove the password from the Custom certificate encryption key field it reports a Verify Mac error which tells me that the file is accessible and usable. When I replace the password I see that it reads the file and returns an OCSP response. So my certificate is loaded but no matter what I do Plex continues to return the .direct certificate.

I looked at the Plex.tv web app and I can see it’s calling my server directly by https://fqdn:32400 but even in this case the Plex server on returns the .direct certificate instead of my certificate which causes a Common Name Error in the browser blocking direct access.

What am I missing? Anyone? Plex staff? Someone that works on this implementation of TLS?

4

…sigh… I was really trying to avoid building a reverse proxy to work around an awfully designed TLS implementation that’s missing a checkbox to override the built-in certificate system. No thoughts from any one I suppose. Maybe I’ll try reddit.

5

I’m experiencing the same problem. The thing that’s frustrating is that Plex used to work with this configuration. I’m actually already running a reverse-proxy on the same server with my plex system for some other things, so I suppose I’ll have to go down that road.

It really sucks when the feature that’s there by design stops working, and no one cares to acknowledge it, much less fix it. :\

1 Like
6

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