I’m also have certificate issues.
Plex Media Server (Docker, Unraid) cannot obtain its certificate. CSR upload succeeds (PUT /api/v2/devices//certificate/csr → 204), but GET /api/v2/devices//certificate/download returns 202 then times out (logged as 408 - Failed to retrieve cert from plex.tv). Server stays “Mapped - Not Published.” Brand-new machineIdentifier (removed, see new ident in later post) , DNS/connectivity verified fast, secure connections = Preferred.
I had it stopped for 24 hours and just started it back up an hour ago.
Jun 11, 2026 08:01:33.863 [22368174848824] DEBUG - CERT: Certificate did not exist, fetching a new one.
Jun 11, 2026 08:03:05.337 [22368174848824] ERROR - CERT: Error acquiring new certificate: Failed to retrieve cert from plex.tv: 408,
Jun 11, 2026 08:16:05.338 [22368158825272] DEBUG - CERT: Forcing refresh.
Jun 11, 2026 08:16:05.340 [22368158825272] DEBUG - CERT: Certificate did not exist, fetching a new one.
Jun 11, 2026 08:17:36.701 [22368158825272] ERROR - CERT: Error acquiring new certificate: Failed to retrieve cert from plex.tv: 408,
=== STATE ===
Jun 11, 2026 08:26:48.577 [22368174848824] DEBUG - [EventSourceClient/pubsub/pubsub05.pop.yyz.plex.bz:443] MyPlex: mapping state set to 'Mapped - Not Published'.
Jun 11, 2026 08:27:22.836 [22368216509240] DEBUG - [EventSourceClient/pubsub/pubsub05.pop.yyz.plex.bz:443] MyPlex: mapping state set to 'Mapped - Not Published (Not Reachable)'.
Jun 11, 2026 08:27:27.177 [22368158825272] DEBUG - [EventSourceClient/pubsub/pubsub05.pop.yyz.plex.bz:443] MyPlex: mapping state set to 'Mapped - Not Published'.
Please check certificate issuance for this device/account.
Don’t recycle the manual port forwarding rule of a previous server instance.
You will need a separate port forwarding, using a different external port number if you are not retaining the Preferences.xml of the previous server.
I reset cert for new server instance but it has not gotten a new one automatically so you likely need to restart it.
Thanks @OttoKerner that was exactly it. I’d been recycling the previous server’s port-forward. Just to clear up the mess I threw out that container and started a server from scratch. I set up a brand-new rule:
- Router: WAN port 48000 → 192.168.1.3:32400 (and deleted the old 32400 → 32400 rule)
- Plex → Remote Access → Manually specify public port = 48000
And it published, Remote Access went to “Fully accessible outside your network” for the first time, showing Public x.x.x.x:48000 →
Private 192.168.1.3:32400. So the that’s working.
The trouble is it won’t hold it. After a server restart it drops back to “Mapped - Not Published” and the certificate fails to come back. The cert log shows this on every startup:
CERT: Certificate did not exist, fetching a new one.
ERROR - CERT: Error acquiring new certificate: Failed to retrieve cert from plex.tv: 408
The CSR upload succeeds (PUT …/certificate/csr → 204), but GET …/certificate/download returns 202 and then times out → the 408. Two things I can’t explain:
- It logs “Certificate did not exist” on every single startup, it never persists/reuses a cert, so it re-requests from scratch each time and then fails the download.
- The 408 on download persists even though the port-forward is now correct and dedicated, the public IP is stable, DNS resolves fast (~25 ms to plex.tv, verified), and the port is reachable from outside.
This is a freshly-built server (new machineIdentifier “ce2ba2fa149e42c510d6cf6eb90127aee6565834”, wiped appdata) that I rebuilt a few times during troubleshooting, so I suspect the certificate state for this device/account on plex.tv’s side may be stuck.
Is there a way to get plex.tv to reliably deliver the cert or to reset the device’s certificate state? And/or any reason the cert wouldn’t persist across restarts? Setup is PMS in Docker (plexinc/pms-docker) on Unraid, host networking.
Thanks again.
@BigWheel Thanks, can you check my other message. I spun up a new server with a different issue (possibly related).
Not sure if you saw the edit to your post in the other topic. You have something else going on that is causing your cert to be continually get rate limited because the server keeps requesting. ( the other thread folks certs were getting stuck generating)
gonna copy part of the note here
requested a new cert every ~15 minutes or so for the last 2 days. Is it possible that your container doesn’t have “write” permission to the storage where the Plex Data Folder is supposed to be? Please create a separate forum thread, in order to not derail this thread here.]
I don’t know if that is for sure what is going on. I made a report for our account devs to look into it since I have not seen the issue you are having in a long while.
@BigWheel thanks. Ruled out write-permissions, the whole Plex data folder is owned by nobody:users (99:100, matching PLEX_UID/PLEX_GID) and PMS is actively writing it (Preferences.xml, Cache, Logs all have current timestamps). I also verified the container’s networking is clean: DNS resolves in ~25ms via 1.1.1.1, plex.tv connects in ~150ms, and there’s no IPv6 in play (plex.tv resolves IPv4-only).
What I do see: the cert only ever exists as temp files, Cache/cert-v2.p12.tmp. (3 leftovers) with no finalized cert-v2.p12, and CertificateUUID is empty in Preferences.xml. So each download starts but never completes/finalizes, PMS re-requests “reason=missing” every ~15 minutes, and that’s what keeps it pinned on the 429.
I think the earlier (now-fixed) port-forward and DNS issues seeded that request loop and tripped an account-level rate limit that rebuilding can’t clear. A fresh machineIdentifier just re-enters the same loop. Could you please clear the certificate rate limit for machineIdentifier ce2ba2fa149e42c510d6cf6eb90127aee6565834? Once it’s cleared I’ll do a single restart and leave it so the one request can complete cleanly.
@BigWheel following up here, it’s been a few days and the certificate still won’t issue, so I’m hoping someone on the cert API side can take a look.
Status update: the server has been stable and running quietly for two days now (the earlier libusb crash loop stopped on its own), so it is no longer hammering the API. Today I ran one clean test to rule out anything local. I stopped the server, deleted the three leftover 0-byte cert-v2.p12.tmp files from the Cache folder, and started it once. It immediately logged:
CERT: Certificate did not exist, fetching a new one.
ERROR - CERT: Error acquiring new certificate: Failed to upload CSR: 429
So with no stale temp files in the way and a completely fresh request, the CSR upload itself is now being rejected with 429. This has actually escalated from what I reported earlier: before, the upload succeeded (204) and only the download timed out (408); now the upload is hard-blocked at 429. That points squarely at an account/device-level rate limit on the plex.tv side that is not aging out on its own.
machineIdentifier ce2ba2fa149e42c510d6cf6eb90127aee6565834
I have stopped restarting so I do not keep re-tripping the limit. As soon as you are able to clear the rate limit for that device, just say the word and I will do a single restart and leave it so the one request can complete cleanly. Setup is unchanged: PMS in Docker (plexinc/pms-docker) on Unraid, host networking, Secure Connections = Preferred, DNS verified fast (~25 ms) to plex.tv.
Thanks very much for any help.
I just reset your cert again. if still having issues can you grab the server logs again
Thanks @BigWheel that reset cleared the 429, the CSR upload is going through fine now. We’ve made progress but it’s not done yet, so here are fresh logs as you asked.
I did one clean restart right after your reset and then left the server completely alone. It has auto-retried on its own since (no further restarts from me). Every attempt now gets past the upload and fails at the download step with a 408:
Jun 16 22:35:53 DEBUG - CERT: secure connections newly enabled, fetching a cert.
Jun 16 22:37:24 ERROR - CERT: Error acquiring new certificate: Failed to retrieve cert from plex.tv: 408
Jun 16 22:47:24 DEBUG - CERT: Forcing refresh.
Jun 16 22:47:24 DEBUG - CERT: Certificate did not exist, fetching a new one.
Jun 16 22:48:55 ERROR - CERT: Error acquiring new certificate: Failed to retrieve cert from plex.tv: 408
So the upload (no more 429) succeeds, the API reports it’s generating the certificate, but the download never completes within the ~90 second poll window
and times out at 408. This has now repeated across the unattended auto-retry, so it’s consistent, not a one-off. No certificate file is ever written (no cert-v2.p12 in the Cache folder), so remote access stays offline.
Setup is unchanged and verified healthy: PMS in Docker (plexinc/pms-docker) on Unraid, host networking, Secure Connections = Preferred, DNS fast (~25 ms) to plex.tv, no stale temp files.
machineIdentifier ce2ba2fa149e42c510d6cf6eb90127aee6565834
Could you check whether the cert is actually being generated and made available for that device? I’ll leave the server running so it keeps retrying cleanly, and it should pick up the cert automatically once the generation side completes. Thanks again for the help.
Can you message me your server logs so I can ask some other folks about it.
Thanks for logs. I moved this to a new topic because it was not the same issue as the OP from the initial one.
So looking at some of the info that the backend team noted in the report so far they indicated it looks like you have recreated your docker server multiple times but are not saving the /config files which contain the servers identity. ( so it is not listed as a whole new server each time.) For example between June 9 and Jun 11 this happened 4 times in 3 days. which each instance requesting multiple certs every time.
At this point right now Let Encrypt themselves have it rate limited rathe than it being on our end so it may take a week for it to be cleared.
This is not to say there is still not an issue with why it is not writing the cert to the cert-v2.p12 file in the first place but it can’t even get to that point right now.
Important thing they noted is to not recreate the docker so it remains seen as the same server.
Thanks, there were a few misfires while getting plex moved over to unraid. I’ll check back in a week to see if we’re unblocked.
