starred/uptime-kuma

Fork 0

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

Dealing with revoked certificates #797

New issue

Open

opened 2026-02-28 01:59:30 -05:00 by deekerman · 12 comments

deekerman commented

2026-02-28 01:59:30 -05:00

Owner

Originally created by @ccoenen on GitHub (Feb 3, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

Other

🔖 Feature description

Uptime Kuma checks the time until certificates expire. It could also check for the validity based on their revocation status.

✔️ Solution

On top of alerting for outdated certs, it should also alert for revoked certs.

❓ Alternatives

No response

📝 Additional Context

Let's encrypt is in the process of revoking a number of certificates this week. The issued certificates would still be before their expiration date, but will nonetheless be causing security warnings for clients. This can't be fully avoided with this, but at least one would not be notified by users/clients but from the monitoring system.

More context: https://www.bleepingcomputer.com/news/security/lets-encrypt-is-revoking-lots-of-ssl-certificates-in-two-days/

While this supposed future enhancement will not help with this week's problem, it might help mitigate a potential future similar incident.

Originally created by @ccoenen on GitHub (Feb 3, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type Other ### 🔖 Feature description Uptime Kuma checks the time until certificates expire. It could also check for the validity based on their revocation status. ### ✔️ Solution On top of alerting for outdated certs, it should also alert for revoked certs. ### ❓ Alternatives _No response_ ### 📝 Additional Context Let's encrypt is in the process of revoking a number of certificates this week. The issued certificates would still be before their expiration date, but will nonetheless be causing security warnings for clients. This can't be _fully_ avoided with this, but at least one would not be notified by users/clients but from the monitoring system. More context: https://www.bleepingcomputer.com/news/security/lets-encrypt-is-revoking-lots-of-ssl-certificates-in-two-days/ While this supposed future enhancement will not help with this week's problem, it might help mitigate a potential future similar incident.

deekerman added the

feature-request

A:cert-expiry

labels

2026-02-28 01:59:30 -05:00

deekerman commented

2026-02-28 01:59:32 -05:00

Author

Owner

@kfeina commented on GitHub (Apr 9, 2024):

Hello,

Is there any plan to implement the revoke certificate check?

Thanks a lot.

@kfeina commented on GitHub (Apr 9, 2024): Hello, Is there any plan to implement the revoke certificate check? Thanks a lot.

deekerman commented

2026-02-28 01:59:35 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Apr 9, 2024):

I think the same arguments as in node apply: https://github.com/nodejs/node/issues/16338
Seems like the security people have spoken that implementing this system is not sensible.
=> If they don't think doing so adds extra value we also should not spend the effort, or am I missing something?

I read https://scotthelme.co.uk/revocation-is-broken/ there is no real way to do what is being asked in this issue. OCSP might help but is not perfect.

As it currently stands there is a real problem, we can't revoke certificates if someone obtains our private key.

If someone wants to look into OCSP Stapling, we would be open to a PR. Our contribution guide is here.
Note that you can likely provide your CRL via the mechanisms in node if the risks noted in https://github.com/nodejs/node/issues/16338 are fine for you.

@CommanderStorm commented on GitHub (Apr 9, 2024): I think the same arguments as in node apply: https://github.com/nodejs/node/issues/16338 Seems like the security people have spoken that implementing this system is not sensible. => If they don't think doing so adds extra value we also should not spend the effort, or am I missing something? I read https://scotthelme.co.uk/revocation-is-broken/ there is no real way to do what is being asked in this issue. OCSP might help but is not perfect. > As it currently stands there is a real problem, we can't revoke certificates if someone obtains our private key. If someone wants to look into OCSP Stapling, we would be open to a PR. Our [contribution guide is here](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md). Note that you can likely provide your CRL via the mechanisms in node if the risks noted in https://github.com/nodejs/node/issues/16338 are fine for you.

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@kfeina commented on GitHub (Apr 12, 2024):

Hello again,

Maybe we miss the oportunity to check revoked certificates. I mean, something was revoked but we can not detect it with our monitoring tool (in this case uptime kuma). .

I understand this is a technical difficult problem, but I can't help programming it cause I don't have the required skills. I could only help in the testing steps.

Maybe OCSP stapling is the correct way to check it and forget CRL and OCSP?

Thanks a lot for your time.

@kfeina commented on GitHub (Apr 12, 2024): Hello again, Maybe we miss the oportunity to check revoked certificates. I mean, something was revoked but we can not detect it with our monitoring tool (in this case uptime kuma). . I understand this is a technical difficult problem, but I can't help programming it cause I don't have the required skills. I could only help in the testing steps. Maybe OCSP stapling is the correct way to check it and forget CRL and OCSP? Thanks a lot for your time.

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@misery commented on GitHub (Sep 18, 2024):

I really like to see support for OCSP-Stapling, too. :-)

@misery commented on GitHub (Sep 18, 2024): I really like to see support for OCSP-Stapling, too. :-)

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Sep 26, 2024):

Scratch the plan above.
The ISRG has an excellent take on this: https://www.abetterinternet.org/post/replacing-ocsp-with-crls/

=> OCSP Stapling means that one leaks which domain one requests to the CA. Said CA might be legally compelled to collect said information which is terrible for privacy. Since the big CAs are moving away from OCSP towards CRLs, that would apparently prefered..

I don't know how we (as an uptime software) should implement this though..
When should we fetch said list??

@CommanderStorm commented on GitHub (Sep 26, 2024): Scratch the plan above. The ISRG has an excellent take on this: https://www.abetterinternet.org/post/replacing-ocsp-with-crls/ => OCSP Stapling means that one leaks which domain one requests to the CA. Said CA might be legally compelled to collect said information which is terrible for privacy. Since the big CAs are moving away from OCSP towards CRLs, that would apparently prefered.. I don't know how we (as an uptime software) should implement this though.. When should we fetch said list??

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@misery commented on GitHub (Sep 26, 2024):

I think you mix "OCSP-Stapling" and "ask OCSP-Responder" here. The leak only exists if the client ask for the OCSP-Response itself. THAT is the reason of OCSP-Stapling.... the client doesn't ask the OCSP-Responder itself.

@misery commented on GitHub (Sep 26, 2024): I think you mix "OCSP-Stapling" and "ask OCSP-Responder" here. The leak only exists if the client ask for the OCSP-Response itself. THAT is the reason of OCSP-Stapling.... the client doesn't ask the OCSP-Responder itself.

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@Gldywn commented on GitHub (Aug 9, 2025):

Hey guys 👋

I’ve been working the past few weeks on something that I think directly addresses this exact problem: hardened-https-agent.
It’s a drop-in replacement for Node’s built-in https.Agent that adds browser-grade certificate validation to outbound HTTPS connections, specifically designed to catch revoked or mis-issued certificates, which Node (and therefore Uptime Kuma) does not handle by default.

Out of the box it supports:

OCSP stapling (validates the staple provided during the TLS handshake)
OCSP direct (queries the CA directly if the staple is missing or invalid)
OCSP mixed mode (use stapling when available, fallback to direct OCSP if not)
CRLSet checks (aggregated revocation lists similar to Chrome’s approach)
Certificate Transparency enforcement (verifies presence of Signed Certificate Timestamps against a trusted CT log list)

The library is fully configurable, you can enable/disable each check, bring your own CA bundle, adjust CT requirements, etc.
It’s open source and open to contributions from anyone interested in improving certificate validation for Node-based tools 👍

@CommanderStorm do you think Uptime Kuma would be open to a PR that adds an optional “Advanced TLS Validation” mode using this approach?
It could be fully opt-in in the settings, so users who want stricter revocation checks (OCSP stapling/direct, CRLSet, CT) can enable it without affecting the default behavior.

@Gldywn commented on GitHub (Aug 9, 2025): Hey guys 👋 I’ve been working the past few weeks on something that I think directly addresses this exact problem: [`hardened-https-agent`](https://github.com/Gldywn/hardened-https-agent). It’s a drop-in replacement for Node’s built-in `https.Agent` that adds **browser-grade certificate validation** to outbound HTTPS connections, specifically designed to catch revoked or mis-issued certificates, which Node _(and therefore Uptime Kuma)_ does not handle by default. Out of the box it supports: - **OCSP stapling** (validates the staple provided during the TLS handshake) - **OCSP direct** (queries the CA directly if the staple is missing or invalid) - **OCSP mixed mode** (use stapling when available, fallback to direct OCSP if not) - **CRLSet** checks (aggregated revocation lists similar to Chrome’s approach) - **Certificate Transparency** enforcement (verifies presence of Signed Certificate Timestamps against a trusted CT log list) The library is fully configurable, you can enable/disable each check, bring your own CA bundle, adjust CT requirements, etc. It’s open source and open to contributions from anyone interested in improving certificate validation for Node-based tools 👍 @CommanderStorm do you think Uptime Kuma would be open to a PR that adds an *optional* “Advanced TLS Validation” mode using this approach? It could be fully opt-in in the settings, so users who want stricter revocation checks (OCSP stapling/direct, CRLSet, CT) can enable it without affecting the default behavior.

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 9, 2025):

Shure, but I don't see why we would need to make it configurable, or?

We can just check and alert for this..
This would only be "breaking" for somebody with revoked certificates, where their certs are broken anyhow.

@CommanderStorm commented on GitHub (Aug 9, 2025): Shure, but I don't see why we would need to make it configurable, or? We can just check and alert for this.. This would only be "breaking" for somebody with revoked certificates, where their certs are broken anyhow.

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@Gldywn commented on GitHub (Aug 9, 2025):

Hmm sorrry I didn’t explain myself clearly earlier.

What I meant is: if a user explicitly checks the “Ignore TLS/SSL errors for HTTPS websites” option when creating a monitor, then we should skip the advanced revocation validation entirely for that monitor.

For all other cases, I agree with you we can enable the checks by default (if HTTPS) and alert if a revocation is detected.

This way we keep the current behavior for people who knowingly want to ignore TLS/SSL validation, while still improving security for everyone else.

@Gldywn commented on GitHub (Aug 9, 2025): Hmm sorrry I didn’t explain myself clearly earlier. What I meant is: if a user explicitly checks the “Ignore TLS/SSL errors for HTTPS websites” option when creating a monitor, then we should skip the advanced revocation validation entirely for that monitor. <img width="568" height="256" alt="Image" src="https://github.com/user-attachments/assets/1c3ed811-b30b-442c-a0e1-529154590a95" /> For all other cases, I agree with you we can enable the checks by default (if HTTPS) and alert if a revocation is detected. This way we keep the current behavior for people who *knowingly* want to ignore TLS/SSL validation, while still improving security for everyone else.

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 9, 2025):

Sounds good to me

@CommanderStorm commented on GitHub (Aug 9, 2025): Sounds good to me

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Sep 13, 2025):

https://github.com/louislam/uptime-kuma/pull/6062 is out and ready for testing by others.
I would like for some of the people in this thread to have a look if this works as expected.

Here is our guide on how to test PRs:
https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

@CommanderStorm commented on GitHub (Sep 13, 2025): https://github.com/louislam/uptime-kuma/pull/6062 is out and ready for testing by others. I would like for some of the people in this thread to have a look if this works as expected. Here is our guide on how to test PRs: https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests

deekerman commented

2026-02-28 01:59:36 -05:00

Author

Owner

@Gldywn commented on GitHub (Oct 3, 2025):

If anyone has time to test #6062, that would really help move it forward 🙏

@Gldywn commented on GitHub (Oct 3, 2025): If anyone has time to test #6062, that would really help move it forward 🙏