starred/uptime-kuma

Fork 0

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

Status page shows "No/Bad Certificate" for self signed https servers instead of days #2497

New issue

Open

opened 2026-02-28 02:56:50 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-28 02:56:50 -05:00

Owner

Originally created by @Tragen on GitHub (Aug 19, 2023).

⚠️ 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

I can check the uptime for https even if the server is serving a self signed certificate. But the status page show "No/Bad Certificate".

👟 Reproduction steps

Create a web server with a self signed certificate

👀 Expected behavior

Show the expiration date

😓 Actual Behavior

No/Bad Certificate

🐻 Uptime-Kuma Version

1.23.0

💻 Operating System and Arch

Debian bookworm

🌐 Browser

Firefox 116.0.3

🐋 Docker Version

No response

🟩 NodeJS Version

v18.13.0

📝 Relevant log output

No response

Originally created by @Tragen on GitHub (Aug 19, 2023). ### ⚠️ 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 I can check the uptime for https even if the server is serving a self signed certificate. But the status page show "No/Bad Certificate". ![image](https://github.com/louislam/uptime-kuma/assets/1700241/0346c077-15c2-4072-8b53-3e1ac71d9b04) ### 👟 Reproduction steps Create a web server with a self signed certificate ### 👀 Expected behavior Show the expiration date ### 😓 Actual Behavior No/Bad Certificate ### 🐻 Uptime-Kuma Version 1.23.0 ### 💻 Operating System and Arch Debian bookworm ### 🌐 Browser Firefox 116.0.3 ### 🐋 Docker Version _No response_ ### 🟩 NodeJS Version v18.13.0 ### 📝 Relevant log output _No response_

deekerman added the

bug

A:status-page

A:cert-expiry

labels

2026-02-28 02:56:50 -05:00

deekerman commented

2026-02-28 02:56:54 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 19, 2023):

As I read this, you are stating that the following is a bug, correct?
Selfsigned certificate => showing No/Bad Certificate on the status page.

Just that we are on the same page:
Selfsigned certificates are not valid certificates, unless you register your certificate's CA with the underlying system.
Have you registered your CA with your OS?

⇒ I think showing No/Bad Certificate in the case of selfsigned certificates is what the results should be.

Did I misunderstand the issue?

@CommanderStorm commented on GitHub (Aug 19, 2023): As I read this, you are stating that the following is a bug, correct? Selfsigned certificate => showing `No/Bad Certificate` on the status page. Just that we are on the same page: Selfsigned certificates are not valid certificates, unless you register your certificate's CA with the underlying system. Have you registered your CA with your OS? ⇒ I think showing `No/Bad Certificate` in the case of selfsigned certificates is what the results should be. Did I misunderstand the issue?

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@Tragen commented on GitHub (Aug 20, 2023):

I haven't registered our CA with my OS.
But still it should show the days and can still show bad certificate.

@Tragen commented on GitHub (Aug 20, 2023): I haven't registered our CA with my OS. But still it should show the days and can still show bad certificate.

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 20, 2023):

Why should it show the days? (I don't understand your rationale)
If you have not registered the CA, that is an invalid cert.
=> showing No/Bad Certificate is intended
=> I don't see the bug

Doing what you requested would be detrimental for other users:
Some webservers I know (nginx, traefik) deliver selfigned certs, if the website somehow (invalid letsencrypt configuration/...) cannot get a cert ⇒ an invalid certificate warning should be present, as the cert is invalid

@CommanderStorm commented on GitHub (Aug 20, 2023): Why should it show the days? (I don't understand your rationale) If you have not registered the CA, that is an invalid cert. => showing `No/Bad Certificate` is intended => I don't see the bug Doing what you requested would be detrimental for other users: Some webservers I know (nginx, traefik) deliver selfigned certs, if the website somehow (invalid letsencrypt configuration/...) cannot get a cert ⇒ an invalid certificate warning should be present, as the cert is invalid

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@Tragen commented on GitHub (Aug 20, 2023):

Because the certificate is not invalid internally and we still need to replace the certificate when it expires.
You mix two different features. Showing days left and showing if it's a self signed / bad certificate.
You could still show: "Cert Exp: 25 days (No/Bad certificate)"

@Tragen commented on GitHub (Aug 20, 2023): Because the certificate is not invalid internally and we still need to replace the certificate when it expires. You mix two different features. Showing days left and showing if it's a self signed / bad certificate. You could still show: "Cert Exp: 25 days (No/Bad certificate)"

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 20, 2023):

IMO, that would be very confusing for users, as this would mix the messaging “your cert is invalid” and “your cert is alive for another x days”.
Editing the tag as suggested would not have obvious messaging to me.

Because the certificate is not invalid internally

It is for the OS you are running uptime-kuma on.
=> please register your CA there as well

@CommanderStorm commented on GitHub (Aug 20, 2023): IMO, that would be very confusing for users, as this would mix the messaging “your cert is invalid” and “your cert is alive for another x days”. Editing the tag as suggested would not have obvious messaging to me. > Because the certificate is not invalid internally It is for the OS you are running `uptime-kuma` on. => please register your CA there as well

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@louislam commented on GitHub (Aug 20, 2023):

Checked the handling inside the dashboard, it indeed shows the days rather than bad cert. I agree that the status page is a bit not consistent.

Test case:

https://self-signed.badssl.com/
Check Ignore TLS/SSL error for HTTPS websites

@louislam commented on GitHub (Aug 20, 2023): Checked the handling inside the dashboard, it indeed shows the days rather than bad cert. I agree that the status page is a bit not consistent. Test case: - https://self-signed.badssl.com/ - Check `Ignore TLS/SSL error for HTTPS websites` ![image](https://github.com/louislam/uptime-kuma/assets/1336778/0b34b0af-e20a-4777-b30e-c0d2157cb0fc)

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 20, 2023):

Indeed that is a bug.
I did not check that checkbox when reproducing the bug

@CommanderStorm commented on GitHub (Aug 20, 2023): Indeed that is a bug. I did not check that checkbox when reproducing the bug

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 20, 2023):

Okay, I looked into it.
Currently, these systems (expiry + validity) are very entangled in the frontend and don't work well with the Ignore TLS/SSL error for HTTPS websites feature.

TO solve this, these are the goals Goals:

splitting these systems
keeping functionality

Only way I can see to achieve both is to introduces a new tag "valid Certificate" to the frontend.
I would like to have a way to manage which tags are displayed using a modal.
Such a change would involve a database migration.
I think the best way forward would be to introduce a bugfix for this in v2.0
I can work on this.

@CommanderStorm commented on GitHub (Aug 20, 2023): Okay, I looked into it. Currently, these systems (expiry + validity) are very entangled in the frontend and don't work well with the `Ignore TLS/SSL error for HTTPS websites` feature. TO solve this, these are the goals Goals: - splitting these systems - keeping functionality Only way I can see to achieve both is to introduces a new tag "valid Certificate" to the frontend. I would like to have a way to manage which tags are displayed using a modal. Such a change would involve a database migration. I think the best way forward would be to introduce a bugfix for this in v2.0 I can work on this.

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@Tragen commented on GitHub (Aug 23, 2023):

I would be happy to have it implemented into v2.0

@Tragen commented on GitHub (Aug 23, 2023): I would be happy to have it implemented into v2.0

deekerman commented

2026-02-28 02:56:55 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 20, 2024):

I think the best way forward would be to introduce a bugfix for this in v2.0
I can work on this

I currently am quite stressed with exams and a bachlor thesis
=> being able to work on this is unlikely
=> removing this "write-lock"

@CommanderStorm commented on GitHub (Feb 20, 2024): > I think the best way forward would be to introduce a bugfix for this in v2.0 I can work on this I currently am quite stressed with exams and a bachlor thesis => being able to work on this is unlikely => removing this "write-lock"