starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Plex SSL certs a being tagged as self signed #1206

New issue

Closed

opened 2026-02-28 02:13:28 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-28 02:13:28 -05:00

Owner

Originally created by @mjefferys on GitHub (Jun 23, 2022).

⚠️ Please verify that this bug has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

Description

Since upgrading to 1.17 my plex monitor is reporting as down with the error saying the cert is self-signed.

Prior to 1.17 this was fine.

Plex provides SSL certs automagically to its instances on the plex.direct subdomain. As far as I can tell these are perfectly valid and not self-signed. Navigating to the address in a browser instance reports that the certificate is valid.

Yet uptime kuma reports it as invalid.

Ticking 'Ignore TLS/SSL error for HTTPS websites' also does nothing.

Happy to share a test URL privately to repro this.

👟 Reproduction steps

Add a plex instance as a monitor via its plex.direct url Ie:

https://127.0.0.1.509a3db652b64f15a0fe26fce4fa770f.plex.direct:32400/

👀 Expected behavior

Instance is monitored and up

😓 Actual Behavior

Instance is monitored and reports as down due to the certificate being 'self-signed'

🐻 Uptime-Kuma Version

1.71.1

💻 Operating System and Arch

docker container

🌐 Browser

Chrome

🐋 Docker Version

No response

🟩 NodeJS Version

No response

📝 Relevant log output

No response

Originally created by @mjefferys on GitHub (Jun 23, 2022). ### ⚠️ Please verify that this bug has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description Since upgrading to 1.17 my plex monitor is reporting as down with the error saying the cert is self-signed. Prior to 1.17 this was fine. Plex provides SSL certs automagically to its instances on the plex.direct subdomain. As far as I can tell these are perfectly valid and not self-signed. Navigating to the address in a browser instance reports that the certificate is valid. ![image](https://user-images.githubusercontent.com/11043414/175286853-c4492a14-b7aa-4be4-a8cc-ec658589899a.png) Yet uptime kuma reports it as invalid. ![image](https://user-images.githubusercontent.com/11043414/175285988-480f686d-0401-48b3-92a9-c8836ef1dc9e.png) Ticking 'Ignore TLS/SSL error for HTTPS websites' also does nothing. Happy to share a test URL privately to repro this. ### 👟 Reproduction steps Add a plex instance as a monitor via its plex.direct url Ie: https://127.0.0.1.509a3db652b64f15a0fe26fce4fa770f.plex.direct:32400/ ### 👀 Expected behavior Instance is monitored and up ### 😓 Actual Behavior Instance is monitored and reports as down due to the certificate being 'self-signed' ### 🐻 Uptime-Kuma Version 1.71.1 ### 💻 Operating System and Arch docker container ### 🌐 Browser Chrome ### 🐋 Docker Version _No response_ ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output _No response_

deekerman

2026-02-28 02:13:28 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-28 02:13:34 -05:00

Author

Owner

@louislam commented on GitHub (Jun 23, 2022):

https://127.0.0.1.509a3db652b64f15a0fe26fce4fa770f.plex.direct:32400/

Unable to resolve the domain, is it correct?

@louislam commented on GitHub (Jun 23, 2022): > https://127.0.0.1.509a3db652b64f15a0fe26fce4fa770f.plex.direct:32400/ Unable to resolve the domain, is it correct?

deekerman commented

2026-02-28 02:13:34 -05:00

Author

Owner

@mjefferys commented on GitHub (Jun 23, 2022):

Apologies I just gave that as an example host name of the type plex generates certs for. An actual live one looks like this.

https://51-[REDACTED].8a44[REDACTED]d88c3f.plex.direct:32400/

Edit by @louislam: Redacted for safe

@mjefferys commented on GitHub (Jun 23, 2022): Apologies I just gave that as an example host name of the type plex generates certs for. An actual live one looks like this. https://51-[REDACTED].8a44[REDACTED]d88c3f.plex.direct:32400/ Edit by @louislam: Redacted for safe

deekerman commented

2026-02-28 02:13:34 -05:00

Author

Owner

@louislam commented on GitHub (Jun 23, 2022):

It is working in my side.

You can test this in the demo site:
https://demo.uptime.kuma.pet/

@louislam commented on GitHub (Jun 23, 2022): It is working in my side. You can test this in the demo site: https://demo.uptime.kuma.pet/ ![image](https://user-images.githubusercontent.com/1336778/175304290-cecaf568-b1d8-42dc-99af-49e57bc966e7.png)

deekerman commented

2026-02-28 02:13:34 -05:00

Author

Owner

@mjefferys commented on GitHub (Jun 23, 2022):

Hmm, yes, confirmed also how weird.

My instance is just the default uptime-kuma docker container (louislam/uptime-kuma:latest) hosted on a debian vm I assume that demo site is also just that?

michael@mj-mon-01 ~> uname -as
Linux mj-mon-01 5.10.0-9-cloud-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
michael@mj-mon-01 ~> cat /etc/debian_version
11.3

@mjefferys commented on GitHub (Jun 23, 2022): Hmm, yes, confirmed also how weird. My instance is just the default uptime-kuma docker container (louislam/uptime-kuma:latest) hosted on a debian vm I assume that demo site is also just that? michael@mj-mon-01 ~> uname -as Linux mj-mon-01 5.10.0-9-cloud-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux michael@mj-mon-01 ~> cat /etc/debian_version 11.3

deekerman commented

2026-02-28 02:13:35 -05:00

Author

Owner

@louislam commented on GitHub (Jun 23, 2022):

My demo site server is CentOS, but I think it is not related.

Try to spin up an temp Uptime Kuma container uptime-kuma:1.16.1, see if it is really a 1.17.1 issue.
Try to go inside your uptime kuma container and use curl to the website.

docker exec -it uptime-kuma bash

@louislam commented on GitHub (Jun 23, 2022): My demo site server is CentOS, but I think it is not related. - Try to spin up an temp Uptime Kuma container `uptime-kuma:1.16.1`, see if it is really a 1.17.1 issue. - Try to go inside your uptime kuma container and use curl to the website. ``` docker exec -it uptime-kuma bash ```

deekerman commented

2026-02-28 02:13:35 -05:00

Author

Owner

@mjefferys commented on GitHub (Jun 23, 2022):

Super weird, spun up a 1.16.1 and it was fine. Upgraded that instance to 1.17.1 and it was still fine. Deleted and recreated my main instance and it's back to being fine. No idea what happened! Apologies for cluttering things up can close as non-reproducible!

@mjefferys commented on GitHub (Jun 23, 2022): Super weird, spun up a 1.16.1 and it was fine. Upgraded that instance to 1.17.1 and it was still fine. Deleted and recreated my main instance and it's back to being fine. No idea what happened! Apologies for cluttering things up can close as non-reproducible!