Both ‘DST Root CA X3’ and intermediate authority ‘R3’ (which issued .plex.direct cert for my server) are expiring in 4 days and I’d like to ask how PMS handles this transition. This will certainly break things for me, since I use HAProxy for all remote traffic (using wildcard ACME cert) that is configured to check backend server cert against a local copy of this CA. Is there any mechanism in place to detect the fact that cert chain is expiring even though cert itself is not?
I tried setting up custom domain cert form self-signed CA, but run into problem. It seems to work when I access PMS with FQDN that is a Common Name for custom cert, but when I browse directly with IP address, there still is .plex.direct cert active, same is seem by my HAProxy frontend. Custom cert appears to be a virtual host via SNI.
I was notified with this post before. As I’ve read it, there is only a claim that they are aware and that clients won’t notice much, apart from IoT use case. Still there is little to no explanation as to how one root cert gets magically swapped by a new cross-signed one on a live machine (if it does at all).
My understanding is that, the application serving the certificate has to send the complete chain, including server certificate itself and all the intermediates. So in order for chain swap there has to be at least a web server conf update and reload. And in case of PMS where .plex.direct domain is softcoded and related cert+key pair is controlled by 3rd party, there has to be an update on Plex Devs side.
Well thats the thing. My plex.direct cert just got renewed on 22nd and it is still issued by R3 from ‘DST Root CA X3’. Next renew is not going to happen for at least a month , so it will be 3 weeks after CA expiration.
These are what seen when accessing my instance by IP from local net, see for yourself:
Ok, I downloaded new CA cert, replaced old one with it in HaProxy’s SSL check and PMS is still reachable, meaning that .plex.direct cert on my instance actually checks out.
So it really is a Chrome’s misrepresentation.
Thanks BigWheel for pointing in the right direction.
I spoke to soon. This failed when I reopened tab. Had to revert SSL check to old chain in order to restore connectivity.
Not really sure what’s going on now.
CA expired (? or is about to?), but now I get this:
I’d appreciate anyone explaining how the hell this still works and passes checks.
Upd: I figured out that (at least with HAProxy checks) when I verify cert against CA only it works with both DST (expired) and ISRG. But when I check against R3 - ISRG chain it fails.
.plex.direct cert checks out against file containing:
R3 - DST Root CA X3
R3 - ISRG Root X1 - DST Root CA X3
DST Root CA X3
ISRG Root X1
But fails against:
R3 - ISRG Root X1
ISRG Root X1 sure acts like Intermediate Authority and not CA.
Honestly, LE themselves made a poor explanation of cross-sign. They used a simple language, but omitted all the details which might not be obvious unless you already know how certification system works on quite a sophisticated level. I mean it’s a “Let’s encrypt” project after all, it was initially designed to make HTTPS affordable and hassle-free, but their texts feel like written for a reader with like a degree on the subject.
I had a better gain of understanding from SE:
Turned out that ‘ISRG Root X1’ is not a unique entity as I though. There are two different certs of completely different type that for some reason carry the same Common Name:
So ISRG from screenshot in last post was indeed an Intermediate.
Confusingly enough, during expiration period of DST root Full Chain of my PMS instance automatically changed multiple times (as seen by Chrome on Win). Now looks like this:
Lesson learned, do not trust browsers and Windows CryptoAPI System Architecture to show the most appropriate certs and always download PEM files for SSL Check configurations directly from sources.
For some reason Chrome/Win was preferring to show me old trust chains until they completely expire and only then (probably discarding them) presented the ones that always had a longer validity left.
Sure enough, my reverse proxy setup depended on preventive change of config to account for SSL Check changes and I failed to figure the whole confusing picture before hand, but at least could minimize downtime as there was an expectation that things won’t go smoothly.
