CA check reports -635 days

[yitsushi]

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

After I updated to 1.22.0 I got a lot of notifications about "expired" CA certificates. My certs are coming from Let's encrypt and they are Not After: Mon, 04 Jun 2035 11:04:38 GMT.

(matrix alert)

I have a few platforms to alert and I got spammed on all channels.

👟 Reproduction steps

I just update, nothing special.

👀 Expected behavior

I don't get notified about expired CA certificate if it's not expired.

😓 Actual Behavior

I got expired CA notification for every single https monitors.

🐻 Uptime-Kuma Version

1.22.0

💻 Operating System and Arch

Ubuntu 20.04

🌐 Browser

N/A

🐋 Docker Version

Docker 20.10.14 + Swarm

🟩 NodeJS Version

I'm using the official docker image

📝 Relevant log output

nothing

[CommanderStorm]

Cannot reproduce the cert working:
https://github.com/louislam/uptime-kuma/assets/26258709/bc2c7569-0e73-40b0-be2d-f3d6aebabed8
https://github.com/louislam/uptime-kuma/assets/26258709/9e7c5e84-113a-4c1e-803c-12dbd7a0026a

Edit: nevermind, gitea is not spelled GitTea...

[helix26j]

But that CA is expired, so the server certificate would also reflect expired even though it was issued beyond the expiry date of the CA:
https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/

This is an old issue, though the article suggests they could be cross-signed so if that is the case perhaps it has to do with the method used to verify it. I can't see the details of the CA nor the intermediates which would have signed this cert.

[louislam]

I think the message indeed is not handled correctly. It actually means that your CA cert has been expired for 635 days. You should update your CA cert.

You can click here to see the cert details.

[yitsushi]

Indeed it's expired. When I checked this page I think I misread that part (or my eyes said "nope I'm not going to read that, the first 3 are correct".

[feld]

I'm getting this too on every HTTPS endpoint I am monitoring with the certificate expiration check enabled.

I don't see the point in monitoring the Root CA's expiration by default. That should probably be an advanced option and UptimeKuma really needs to better understand certificate chains / cross signing so these false positives don't happen.

edit: if you don't want UptimeKuma to bother checking expiration of the rest of the cert chain you can use this crude hack to stop it from checking

diff --git a/server/model/monitor.js b/server/model/monitor.js
index 2732a341..28503fe6 100644
--- a/server/model/monitor.js
+++ b/server/model/monitor.js
@@ -1287,7 +1287,7 @@ class Monitor extends BeanModel {
                             log.debug("monitor", `call sendCertNotificationByTargetDays for ${targetDays} deadline on certificate ${subjectCN}.`);
                             await this.sendCertNotificationByTargetDays(subjectCN, certInfo.certType, certInfo.daysRemaining, targetDays, notificationList);
                         }
-                        certInfo = certInfo.issuerCertificate;
+                        certInfo = null;
                     }
                 }
             }

[chakflying]

@skaempfe

It's evidently not a good idea to notify every cert in the chain for expiry. I don't see any other way to fix this then to check each cert against some "trusted roots", and stopping there.

[feld]

@skaempfe

I don't see any other way to fix this then to check each cert against some "trusted roots", and stopping there.

But testing if the certificate is valid is already being handled, right?

/**
 * Check if certificate is valid
 * @param {Object} res Response object from axios
 * @returns {Object} Object containing certificate information
 */
exports.checkCertificate = function (res) {
    if (!res.request.res.socket) {
        throw new Error("No socket found");
    }

    const info = res.request.res.socket.getPeerCertificate(true);
    const valid = res.request.res.socket.authorized || false;  👈 👈 👈 👈

    log.debug("cert", "Parsing Certificate Info");
    const parsedInfo = parseCertificateInfo(info);

    return {
        valid: valid, 👈 👈 👈 👈
        certInfo: parsedInfo
    };
};

if res.request.res.socket.authorized is false the certificate is not trusted, which should happen when the issuer or an intermediate is expired, or if it's from an untrusted root

[chakflying]

authorized returns whether the whole chain is trusted. It doesn't give any information about which certificate is valid or not.

[feld]

Correct, but that should be sufficient.

I've never seen an HTTPS monitoring tool try to validate the whole chain's expirations. Typically (IMO) you'll monitor that certificate directly with another mechanism otherwise you just end up with hundreds or thousands of redundant alert notifications when your private CA root is going to be expiring.

If e.g., LetsEncrypt's CA is expiring next week, notifying me is rather pointless. If we have to do the CA's job for them we're in a heap of trouble...

Anyway, just glad I found a workaround so I can continue experimenting with this software.

Thanks, all!

[gmta]

Note that a TLS CA certificate expiry is only relevant if it's part of the trust chain. In this case, it's not, since there's another CA certificate beside it that has not yet expired.

See also: https://letsencrypt.org/certificates/

[foliovision]

We had to stop the SSL checking of Uptime Kuma as it was completely useless for these Letsencrypt certificates.

Would it be possible to simple ignore errors with the "DST Root CA X3" certificate that expires on 2021-09-30?

Seems like that would stop the false alarms for Letsencrypt without having it understand that modern browsers no longer need that certificate.

[chakflying]

Fixed by #3874.