# HTTPS certs are missing trust roots **URL:** \ **Category:** Remote Access\ **Tags:** server-linux\ **Created:** [September 22, 2026, 10:51pm UTC](https://forums.plex.tv/t/https-certs-are-missing-trust-roots/943238 "2026-09-22T22:51:43Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![toddself](https://sea1.discourse-cdn.com/plex/user_avatar/forums.plex.tv/toddself/32/271083_2.png) [@toddself](https://forums.plex.tv/u/toddself)\ **Post date:** [September 22, 2026, 10:51pm UTC](https://forums.plex.tv/t/https-certs-are-missing-trust-roots/943238/1 "2026-09-22T22:51:43Z")
Server Version#: 11.43.4.10903-e5521bd8c Player Version#: 4.16. PMS serves an incomplete plex.direct certificate chain under Let’s Encrypt “Generation Y” (ISRG Root YR) — Remote Access permanently “Not Reachable” Since my `plex.direct` wildcard certificate was renewed on **2026-09-20** , it is issued under Let’s Encrypt’s new “Generation Y” hierarchy (`Let's Encrypt YR2` → `ISRG Root YR`). PMS serves **only the leaf + the YR2 intermediate**. It does **not** serve the cross-signed `ISRG Root YR` certificate (the one signed by the universally-trusted `ISRG Root X1`) that Let’s Encrypt publishes specifically for this transition. `ISRG Root YR` is not yet in any shipping trust store — Let’s Encrypt lists it as “pending inclusion”. The result is that any client validating strictly (OpenSSL/GnuTLS, i.e. no AIA chasing) cannot build a path to a trusted root and aborts the handshake with `unknown ca`. **This includes Plex’s own reachability checker** , so Remote Access is permanently stuck at `Mapped - Not Published (Not Reachable)` even though the port forward is open and verified reachable from the internet. | | | | | | | --- | --- | --- | --- | --- | | PMS version | `1.43.4.10903-e5521bd8c` | | | | | Platform | Linux x86\_64, `plexinc/pms-docker:latest` | | | | | Cert validity | `notBefore=Sep 20 10:01:11 2026 GMT` / `notAfter=Dec 19 10:01:10 2026 GMT` | | | | | Remote Access | manual port map, TCP/UDP 32400 → 32400, verified open externally | | | | ### 1. The served chain stops at an untrusted root ```auto $ openssl s_client -connect 174-21-45-20.31564bb9326f4034a92f04c7a0f0016e.plex.direct:32400 \ -servername 174-21-45-20.31564bb9326f4034a92f04c7a0f0016e.plex.direct -showcerts 0 s:CN=*.31564bb9326f4034a92f04c7a0f0016e.plex.direct i:C=US, O=Let's Encrypt, CN=YR2 1 s:C=US, O=Let's Encrypt, CN=YR2 i:C=US, O=ISRG, CN=Root YR <-- chain ends here; Root YR is not in trust stores Verify return code: 20 (unable to get local issuer certificate) ``` Identical chain is served on the LAN path (`192-168-1-3..plex.direct`), so this is not a network/interception artifact. ### 2. Adding the published cross-sign resolves it — against the _existing_ ISRG Root X1 Using the system trust store (which contains ISRG Root X1 and X2, but not Root YR): ```auto # as served today $ openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted int-yr2.pem leaf.pem error 20 at 1 depth lookup: unable to get local issuer certificate FAIL # with the cross-signed Root YR added to the chain (letsencrypt.org/certs/gen-y/root-yr-by-x1.pem) $ openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt \ -untrusted int-yr2.pem -untrusted root-yr-by-x1.pem leaf.pem leaf.pem: OK PASS # or by trusting the new root directly (letsencrypt.org/certs/gen-y/root-yr.pem) $ openssl verify -CAfile root-yr.pem -untrusted int-yr2.pem leaf.pem leaf.pem: OK PASS ``` So shipping the cross-signed `Root YR` in the served chain is sufficient and requires no trust-store changes anywhere. ### 3. Plex’s own infrastructure rejects the certificate From `Plex Media Server.log` — note `34.202.97.122`, which is Plex’s reachability checker: ```auto CERT: incomplete TLS handshake from [::ffff:34.202.97.122]:31278: tlsv1 alert unknown ca (SSL routines) [EventSourceClient/pubsub/pubsub04.pop.fmt.plex.bz:443] MyPlex: mapping state set to 'Mapped - Not Published (Not Reachable)'. ``` Many other clients on the network do the same: ```auto CERT: incomplete TLS handshake from [::ffff:192.168.1.1]:48696: tlsv1 alert unknown ca (SSL routines) CERT: incomplete TLS handshake from [::ffff:192.168.1.240]:60744: tlsv1 alert unknown ca (SSL routines) CERT: incomplete TLS handshake from 127.0.0.1:51768: tlsv1 alert unknown ca (SSL routines) ``` ### 4. Secondary issue: PMS’s bundled CA store also lacks Root YR `/usr/lib/plexmediaserver/Resources/cacert.pem` (dated Aug 16 2026, 138 certificates) contains `ISRG Root X1` but not `ISRG Root YR`. Because of this, PMS cannot validate **its own** certificate during the self-reachability check: ```auto WARN - [HttpClient] HTTP error requesting GET https://174-21-45-20..plex.direct:32400/identity (60, SSL peer certificate or SSH remote key was not OK) (SSL certificate problem: unable to get local issuer certificate) DEBUG - MyPlex: mapping state set to 'Mapped - Not Published'. ``` I confirmed this by appending `root-yr.pem` + `root-yr-by-x1.pem` to that bundle (140 certs) and restarting: the outbound self-check now returns `http=200 ssl_verify=0` and the log error is gone. The inbound `unknown ca` rejections continue, because those depend on the chain PMS _serves_. ## Impact - Remote Access is permanently unavailable; the UI reports the server as offline/indirect. - Strict-validating clients cannot connect over `plex.direct` at all. - LAN playback still works only because local clients fall back to plain HTTP (`httpsRequired=0`), which masks the problem for the owner while remote users are locked out. - Clients that perform AIA chasing (Apple, Windows/Schannel) can recover via the leaf’s `CA Issuers - URI:``http://yr2.i.lencr.org/`, which is likely why this is reported as intermittent/inconsistent across client platforms rather than a clean total failure. ## Expected behaviour PMS should serve the full chain for Gen-Y certificates: ```auto leaf *..plex.direct └─ Let's Encrypt YR2 └─ ISRG Root YR (cross-signed by ISRG Root X1) <-- currently missing ``` ## References - Let’s Encrypt, “New Generation Y Hierarchy of Root and Intermediate Certificates” — [https://letsencrypt.org/2025/11/24/gen-y-hierarchy](https://letsencrypt.org/2025/11/24/gen-y-hierarchy) - Let’s Encrypt, Chains of Trust — [https://letsencrypt.org/certificates/](https://letsencrypt.org/certificates/) - Cross-signed root PEM — [https://letsencrypt.org/certs/gen-y/root-yr-by-x1.pem](https://letsencrypt.org/certs/gen-y/root-yr-by-x1.pem) \ ---
**Author:** ![veeejay](https://avatars.discourse-cdn.com/v4/letter/v/9dc877/32.png) [@veeejay](https://forums.plex.tv/u/veeejay)\ **Post date:** [September 22, 2026, 10:53pm UTC](https://forums.plex.tv/t/https-certs-are-missing-trust-roots/943238/2 "2026-09-22T22:53:27Z")
Stop plex, remove the certificate.p12 file from the Cache directory in the Plex Media Server folder and start plex back up. It will download a new certificate, cert-v2.p12. ---
**Author:** ![toddself](https://sea1.discourse-cdn.com/plex/user_avatar/forums.plex.tv/toddself/32/271083_2.png) [@toddself](https://forums.plex.tv/u/toddself)\ **Post date:** [September 22, 2026, 10:58pm UTC](https://forums.plex.tv/t/https-certs-are-missing-trust-roots/943238/3 "2026-09-22T22:58:03Z")
y’all that fixed it. but man, what a stupid problem! ---
**Author:** ![BeerMan81](https://sea1.discourse-cdn.com/plex/user_avatar/forums.plex.tv/beerman81/32/9435_2.png) [@BeerMan81](https://forums.plex.tv/u/BeerMan81)\ **Post date:** [September 26, 2026, 10:14pm UTC](https://forums.plex.tv/t/https-certs-are-missing-trust-roots/943238/4 "2026-09-26T22:14:35Z")
Independent confirmation of this on 1.43.4.10903 (Linux LXC), and your AIA-chasing point explains something that had me chasing my own tail for an hour — worth spelling out for anyone else debugging this: **curl on Windows/macOS will tell you the certificate is fine.** Schannel and Secure Transport chase the leaf’s `CA Issuers` URI and fetch the missing cross-sign, so they validate happily. OpenSSL with a normal bundle does not, and neither does [plex.tv](http://plex.tv)’s checker: ```auto openssl s_client -connect :32400 -servername .plex.direct -CAfile /etc/ssl/certs/ca-certificates.crt /dev/null | grep 'Verify return code' Verify return code: 20 (unable to get local issuer certificate) ``` I retracted a correct diagnosis on the strength of a passing curl before spotting that. Test with OpenSSL, not the OS stack. On my side the inbound half looked exactly as you describe — every probe from [plex.tv](http://plex.tv)’s checkers (34.239.73.157, 34.202.97.122, 44.207.218.81) arrived, was NATed, reached the server and got answered, and the [server logged:](https://support.plex.tv/articles/200250417-plex-media-server-log-files/) ```auto CERT: incomplete TLS handshake from [::ffff:34.239.73.157]: tlsv1 alert unknown ca (SSL routines) MyPlex: mapping state set to 'Mapped - Not Published (Not Reachable)' ``` **A workaround that doesn’t need Plex to change anything** : force an ECDSA certificate instead of the RSA Gen-Y one. Tick Settings → Network → **Strict TLS configuration** (it “switches to ECDSA certificates when renewing”), then stop the server, move `Cache/certificate.p12` aside, and start it again — a restart alone won’t do it, since the [server logs](https://support.plex.tv/articles/200250417-plex-media-server-log-files/) `CERT: Certificate will not expire soon; we'll check again in a week.` The ECDSA chain is cross-signed the whole way down, so no AIA chasing is required: ```auto 0 s:CN=*..plex.direct (ECDSA, NIST P-256) i:C=US, O=Let's Encrypt, CN=YE2 1 s:C=US, O=Let's Encrypt, CN=YE2 i:C=US, O=ISRG, CN=Root YE 2 s:C=US, O=ISRG, CN=Root YE i:C=US, O=Internet Security Research Group, CN=ISRG Root X2 3 s:C=US, O=Internet Security Research Group, CN=ISRG Root X2 i:C=US, O=Internet Security Research Group, CN=ISRG Root X1 Verify return code: 0 (ok) ``` Remote Access went green on the next probe. Caveat: Strict TLS also drops legacy ciphers, so old clients may fail (one local client here immediately logged `no suitable signature algorithm`) — that makes it a workaround rather than a fix, and your “PMS should serve the full chain” request is still the right ask. My write-up of the same issue from the network side (firewall state, checker byte counts, the openssl output): [Remote Access not reachable: plex.tv checker rejects our plex.direct cert (unknown ca)](https://forums.plex.tv/t/remote-access-not-reachable-plex-tv-checker-rejects-our-plex-direct-cert-unknown-ca/943493) ---
**Author:** ![Alex\_Stork](https://avatars.discourse-cdn.com/v4/letter/a/958977/32.png) [@Alex\_Stork](https://forums.plex.tv/u/Alex_Stork)\ **Post date:** [October 10, 2026, 11:04am UTC](https://forums.plex.tv/t/https-certs-are-missing-trust-roots/943238/5 "2026-10-10T11:04:57Z")
Adding a Windows 11 occurrence from October 10, 2026. Plex Media Server: 1.43.4.10903-e5521bd8c. Client: Plex for iOS on cellular data. The phone initially reported unavailable libraries after signing out and back in. Local library reads and existing sharing permissions remained intact. After fixing a separate connection-publication failure, the resources API now advertises the server’s current HTTPS addresses. Direct authenticated HTTPS requests using Python requests with normal certificate verification still fail with: ```plaintext [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate ``` The current served leaf certificate has issuer Let’s Encrypt YR1 and validity October 9, 2026 to January 7, 2027. An earlier certificate inspected during the same incident had issuer YR2. The cache contains certificate.p12; no cert-v2.p12 is present. Redacted server-log excerpts, America/Chicago time: ```plaintext Oct 10, 2026 05:48:15.219 ERROR - [CERT] Failed to parse intermediate certificate. Oct 10, 2026 05:51:47.623 DEBUG - CERT: incomplete TLS handshake from [::ffff:
]:58629: tlsv1 alert unknown ca (SSL routines) ``` Remote Access still reports Not available outside your network. The iOS client can now browse and play over cellular, but the live session is secure and relayed, not a verified direct connection. I have not completed full-chain analysis or replaced the cached certificate yet, so I am reporting the observed validation failure rather than asserting which exact chain certificate is missing. Please confirm whether this matches the Gen-Y chain issue and advise how to restore a complete trusted chain while preserving compatibility with older clients. The separate publication issue and successful Ethernet-interface workaround are documented here: [Servers.plex.tv Cloudflare WAF returns 403 "Sorry, you have been blocked" for any device - #2 by Alex\_Stork](https://forums.plex.tv/t/servers-plex-tv-cloudflare-waf-returns-403-sorry-you-have-been-blocked-for-any-device/943246/2)