starred/uptime-kuma

Fork 0

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

Show EV status and issuer next to the expiration days #3276

New issue

Open

opened 2026-02-28 03:24:06 -05:00 by deekerman · 11 comments

deekerman commented

2026-02-28 03:24:06 -05:00

Owner

Originally created by @Tragen on GitHub (Apr 18, 2024).

No related issues found

🏷️ Feature Request Type

Status-page, Certificate expiry

🔖 Feature description

I monitor a lot of https pages and it shows the certificate expiration time.
I want to show the certificate issuer next to the days.
So if it's Letsencrypt, I don't care if 10 days are left. But if it's from a company or an internal certificate, I need to do something earlier. The times I can configure currently are not very good to handle this different types of workflows very good.
I don't need a reminder 30 days before the expiration for letsencrypt.
But 30 days for EV certificates should be necessary.
And you could also show in this case if its an EV certificate.

✔️ Solution

Show EV status and issuer next to the expiration days

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @Tragen on GitHub (Apr 18, 2024). ### 📑 I have found these related issues/pull requests No related issues found ### 🏷️ Feature Request Type Status-page, Certificate expiry ### 🔖 Feature description I monitor a lot of https pages and it shows the certificate expiration time. I want to show the certificate issuer next to the days. So if it's Letsencrypt, I don't care if 10 days are left. But if it's from a company or an internal certificate, I need to do something earlier. The times I can configure currently are not very good to handle this different types of workflows very good. I don't need a reminder 30 days before the expiration for letsencrypt. But 30 days for EV certificates should be necessary. And you could also show in this case if its an EV certificate. ### ✔️ Solution Show EV status and issuer next to the expiration days ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman added the

labels

2026-02-28 03:24:06 -05:00

deekerman commented

2026-02-28 03:24:09 -05:00

Author

Owner

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

I have updated your title to reflect that you want a Certificate transparency monitor as described on https://certificate.transparency.dev/monitors/
You don't want what you asked for (status and issuer next to the expiration days).

I think that integrating such tooling might be helpfull, but currently not a huge priority as a lot of existing tooling around this already exists.

@CommanderStorm commented on GitHub (Apr 18, 2024): I have updated your title to reflect that you want a **Certificate transparency monitor** as described on https://certificate.transparency.dev/monitors/ You don't want what you asked for (`status and issuer next to the expiration days`). I think that integrating such tooling might be helpfull, but currently not a huge priority as a lot of existing tooling around this already exists.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

@Tragen commented on GitHub (Apr 18, 2024):

I think it's not what I want. I don't want to monitor if somebody creates certificates for my servers.
I want to know which issuer it is and it it's an EV certificate so I can do my workflow easier for renewing certificates if necessary.
Letsencrypt will be automatic, but all others need time and EV needs even more time.

@Tragen commented on GitHub (Apr 18, 2024): I think it's not what I want. I don't want to monitor if somebody creates certificates for my servers. I want to know which issuer it is and it it's an EV certificate so I can do my workflow easier for renewing certificates if necessary. Letsencrypt will be automatic, but all others need time and EV needs even more time.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

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

Why do you use EV certificates and a mix of other CAs?
As far as I know, they are just more hasle without real gain.

@CommanderStorm commented on GitHub (Apr 18, 2024): Why do you use EV certificates and a mix of other CAs? As far as I know, they are just more hasle without real gain.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

@Tragen commented on GitHub (Apr 18, 2024):

Why not?
EV for when it's needed and required and letsencrypt when it's possible and if there is no possibility for port 80 and 443 for letsencrypt then e.g. Sectigo.

@Tragen commented on GitHub (Apr 18, 2024): Why not? EV for when it's needed and required and letsencrypt when it's possible and if there is no possibility for port 80 and 443 for letsencrypt then e.g. Sectigo.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

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

EV for when it's needed and required

Honestly curious: Where would they be required? I never got why people like to spend money on that.
Customers don't really care, it does not add any security and is just annoying as heck to have to manually deal with certs.

if there is no possibility for port 80 and 443 for letsencrypt

LetsEncrypt does have the DNS-01-challenge for this.

@CommanderStorm commented on GitHub (Apr 18, 2024): > EV for when it's needed and required Honestly curious: Where would they be required? I never got why people like to spend money on that. Customers don't really care, it does not add any security and is just annoying as heck to have to manually deal with certs. > if there is no possibility for port 80 and 443 for letsencrypt LetsEncrypt does have the [`DNS-01`-challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) for this.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

@jgerken commented on GitHub (Apr 19, 2024):

Honestly curious: Where would they be required? I never got why people like to spend money on that. Customers don't really care, it does not add any security and is just annoying as heck to have to manually deal with certs.

Let's encrypt supports only domain validated certificates (DV), if you need or want to have company information included in the certificate then you need a owner validated certificate (OV), some use-cases even require extended validation certificates (EV).

@jgerken commented on GitHub (Apr 19, 2024): > Honestly curious: Where would they be required? I never got why people like to spend money on that. Customers don't really care, it does not add any security and is just annoying as heck to have to manually deal with certs. Let's encrypt supports only domain validated certificates (DV), if you need or want to have company information included in the certificate then you need a owner validated certificate (OV), some use-cases even require extended validation certificates (EV).

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

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

Still not getting it: What is the usecase for ev certs you talked about?

My only context is https://wikipedia.org/wiki/Extended_Validation_Certificate#Criticism

@CommanderStorm commented on GitHub (Apr 19, 2024): Still not getting it: What is the usecase for ev certs you talked about? My only context is https://wikipedia.org/wiki/Extended_Validation_Certificate#Criticism

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

@Tragen commented on GitHub (Apr 19, 2024):

Really this discussion? Nobody cares if you like EV certificates or not.
I don't need them, I don't want them.
But e.g. Banks are required to have them.
We have customers that want them. I don't care if they pay for it. Don't discuss this with me.
It's here and as long as you can buy them they will get bought.

@Tragen commented on GitHub (Apr 19, 2024): Really this discussion? Nobody cares if you like EV certificates or not. I don't need them, I don't want them. But e.g. Banks are required to have them. We have customers that want them. I don't care if they pay for it. Don't discuss this with me. It's here and as long as you can buy them they will get bought.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

@Tragen commented on GitHub (Apr 19, 2024):

if there is no possibility for port 80 and 443 for letsencrypt

LetsEncrypt does have the DNS-01-challenge for this.

Host Europe doesn't have any API for managing DNS so this isn't working.

@Tragen commented on GitHub (Apr 19, 2024): > > if there is no possibility for port 80 and 443 for letsencrypt > > LetsEncrypt does have the [`DNS-01`-challenge](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) for this. Host Europe doesn't have any API for managing DNS so this isn't working.

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

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

I am trying to gauge here if this would be a generally usefull feature (i.e. for all users) or just something that falls in the https://github.com/louislam/uptime-kuma/issues/646 category and supports your particular workflow.

Banks are required to have them

But Banks would likely not use this software (we don't have multi-user auth, SSO, nor the necessary features such as a ISO27001 certification)...

We have customers that want them

So your customers want EV-Certs. Why?
I currently don't see a reason why we should implement extra handling around them if there is no usecase to have these certs in the first place.

Including this where we currently do is still fine imo.
What value would including "DigiCert EV RSA CA G2 - DigiCert Inc. (US)" in the notification add?

=> I still don't see a reason why uptime kuma should include this info in a notification..

I somewhat question the premise:

I don't need a reminder 30 days before the expiration for letsencrypt.

LetsEncrypt sends you the expiry notifications at 20 and 7 days => Your LetsEncrypt certs should be renewed before that, likely before the 30 days or on the 30th day like acme.sh.

Tip

In case you dind not know: if you click on how many days are remaining for this cert, you get more information.

@CommanderStorm commented on GitHub (Apr 19, 2024): I am trying to gauge here if this would be a generally usefull feature (i.e. for all users) or just something that falls in the https://github.com/louislam/uptime-kuma/issues/646 category and supports your particular workflow. > Banks are required to have them But Banks would likely not use this software (we don't have multi-user auth, SSO, nor the necessary features such as a ISO27001 certification)... > We have customers that want them So your customers want EV-Certs. Why? I currently don't see a reason why we should implement extra handling around them if there is no usecase to have these certs in the first place. Including this where we currently do is still fine imo. What value would including `"DigiCert EV RSA CA G2 - DigiCert Inc. (US)"` in the notification add? => I still don't see a reason why uptime kuma should include this info in a notification.. I somewhat question the premise: > I don't need a reminder 30 days before the expiration for letsencrypt. LetsEncrypt sends you the [expiry notifications at 20 and 7 days](https://letsencrypt.org/docs/expiration-emails/#:~:text=We%20try%20to%20send%20the,to%20check%20on%20your%20automation.) => Your LetsEncrypt certs should be renewed before that, likely before the 30 days or on the 30th day like [`acme.sh`](https://github.com/acmesh-official/acme.sh#12-how-to-renew-the-certs). > [!TIP] > In case you dind not know: if you click on how many days are remaining for this cert, you get more information. > ![image](https://github.com/louislam/uptime-kuma/assets/26258709/75b73140-3136-46a3-8dc4-569981b7c1d3)

deekerman commented

2026-02-28 03:24:11 -05:00

Author

Owner

@Tragen commented on GitHub (Apr 19, 2024):

One step would be show this information also when you click on the Cert Exp days in the status page. This works only when you are in the dashboard.
For Letsencrypt, they send own reminders but this is not a reason.
a) letsencrypt sends the reminder to those who manage the server. I need to only monitor everything and don't get all reminders.
b) in uptime kuma, I can configure notification times only globally so I need to have it at 30 days for other certificates.

@Tragen commented on GitHub (Apr 19, 2024): One step would be show this information also when you click on the Cert Exp days in the status page. This works only when you are in the dashboard. For Letsencrypt, they send own reminders but this is not a reason. a) letsencrypt sends the reminder to those who manage the server. I need to only monitor everything and don't get all reminders. b) in uptime kuma, I can configure notification times only globally so I need to have it at 30 days for other certificates.