X.509 expiration monitoring #4339

New issue

Open

opened 2026-02-28 03:58:57 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 03:58:57 -05:00

Owner

Originally created by @jakcyl on GitHub (Oct 17, 2025).

It would be nice to manually add expiration dates for certificates that are not just for ssl/tls on domain.

🏷️ Feature Request Type

Certificate expiry

🔖 Feature description

a new monitor time based

✔️ Solution

while the expiration date approces the color of the monitor will change to yellow / red and send a notification before 90-60-30-15 days

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @jakcyl on GitHub (Oct 17, 2025). ### 📑 I have found these related issues/pull requests It would be nice to manually add expiration dates for certificates that are not just for ssl/tls on domain. ### 🏷️ Feature Request Type Certificate expiry ### 🔖 Feature description a new monitor time based ### ✔️ Solution while the expiration date approces the color of the monitor will change to yellow / red and send a notification before 90-60-30-15 days ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman added the

feature-request

A:monitor

type:new

labels

2026-02-28 03:58:57 -05:00

deekerman commented

2026-02-28 03:59:00 -05:00

Author

Owner

@maxmichels commented on GitHub (Oct 27, 2025):

I will try to create a monitor for this. @jakcyl did i understood you correctly, you want a monitor type to monitor certificate expiration which are available via DNS/FQDN on specified port, e.g. smtp-server certificate?

@maxmichels commented on GitHub (Oct 27, 2025): I will try to create a monitor for this. @jakcyl did i understood you correctly, you want a monitor type to monitor certificate expiration which are available via DNS/FQDN on specified port, e.g. smtp-server certificate?

deekerman commented

2026-02-28 03:59:00 -05:00

Author

Owner

@jakcyl commented on GitHub (Oct 27, 2025):

Thanks @maxmichels! It's close but what i meant is a bit broader. i'd like to monitor certificates that are not available via dns or net ports. Like mTls, apple push (apns) certificates, or any other local/manually managed certificate file.

the idea would be to have a new monitor where i can either enter an expiration date or upload (temporarly?) the certicate so kuma can extract its expiry date. then when it's expirying/expired you can update the cert or date with the new one

basically a time based certificate expiry monitor for services where certificates aren't publically "queryable".

Thanks again for looking into this 🦸

@jakcyl commented on GitHub (Oct 27, 2025): Thanks @maxmichels! It's close but what i meant is a bit broader. i'd like to monitor certificates that are not available via dns or net ports. Like mTls, apple push (apns) certificates, or any other local/manually managed certificate file. the idea would be to have a new monitor where i can either enter an expiration date or upload (temporarly?) the certicate so kuma can extract its expiry date. then when it's expirying/expired you can update the cert or date with the new one basically a time based certificate expiry monitor for services where certificates aren't publically "queryable". Thanks again for looking into this 🦸

deekerman commented

2026-02-28 03:59:00 -05:00

Author

Owner

@appletalk commented on GitHub (Nov 6, 2025):

I'm also interested in this for monitoring XMPP server certificates. I can query my XMPP cert using the following command and monitoring the expiry in uptime-kuma would be great!

echo | openssl s_client -starttls xmpp-server -connect xmpp.example.com:5269 | openssl x509 -noout -dates

Edit: My use case might be covered by #5678

@appletalk commented on GitHub (Nov 6, 2025): I'm also interested in this for monitoring XMPP server certificates. I can query my XMPP cert using the following command and monitoring the expiry in uptime-kuma would be great! `echo | openssl s_client -starttls xmpp-server -connect xmpp.example.com:5269 | openssl x509 -noout -dates ` Edit: My use case might be covered by #5678