louislam/uptime-kuma · error · Error

Certificate is invalid

Error message

Certificate is invalid

What it means

Thrown by checkTlsCertificate() after a TLS handshake completed and checkCertificate() returned a tlsInfoObject whose 'valid' field is false. This indicates the certificate itself failed Uptime-Kuma's validity rules (expired, not-yet-valid, untrusted CA, hostname mismatch, revoked). The error is then re-wrapped by the surrounding catch into 'TLS Connection failed: Certificate is invalid'.

Source

Thrown at server/monitor-types/tcp.js:269

                        const info = checkCertificate(socket);
                        resolve(info);
                    } catch (error) {
                        reject(error);
                    }
                });

                socket.on("error", (error) => {
                    reject(error);
                });

                socket.setTimeout(1000 * TIMEOUT, () => {
                    reject(new Error("Connection timed out"));
                });
            });

            await monitor.handleTlsInfo(tlsInfoObject);
            if (!tlsInfoObject.valid) {
                throw new Error("Certificate is invalid");
            }
        } catch (error) {
            const message = error instanceof Error ? error.message : "Unknown error";
            throw new Error(`TLS Connection failed: ${message}`);
        } finally {
            if (socket && !socket.destroyed) {
                socket.end();
            }
        }
    }

    /**
     * Check for expected TLS alert (for mTLS verification)
     * @param {object} monitor Monitor object
     * @param {object} heartbeat Heartbeat object
     * @param {string} expectedTlsAlert Expected TLS alert name
     * @returns {Promise<void>}
     */

View on GitHub (pinned to 6b5ea01557)

Solutions

  1. Inspect the full tlsInfoObject (cert info, daysRemaining, issuer) via Uptime-Kuma's cert transparency view to see the exact failure reason.
  2. Renew and redeploy the certificate if it is expired or near expiry.
  3. Serve the full intermediate chain so the path to a trusted root can be built.
  4. Correct clock skew on the Uptime-Kuma host (NTP).
  5. If the cert is legitimately self-signed for internal use, install the CA into the host trust store or disable expiry/cert notification for that monitor.
Defensive patterns

Strategy: validation

Validate before calling

function isCertValid(tlsInfo) { return !!tlsInfo && tlsInfo.valid === true; }

Type guard

function isCertValid(tlsInfo) { return !!tlsInfo && tlsInfo.valid === true && (tlsInfo.daysRemaining == null || tlsInfo.daysRemaining > 0); }

Try / catch

if (!isCertValid(tlsInfoObject)) { heartbeat.status = DOWN; heartbeat.msg = `Certificate is invalid (${tlsInfoObject.certInfo_messages?.join(", ")})`; return; }

Prevention

When it happens

Trigger: Produced when monitor.smtpSecurity is 'secure' or 'starttls', expiry notification is enabled, the TLS handshake succeeds, but checkCertificate() flags the cert invalid — e.g. notAfter in the past, self-signed/untrusted chain, CN/SAN mismatch with monitor.hostname, or a broken chain.

Common situations: Expired certificate; self-signed cert without a trusted root; intermediate chain not served by the server; certificate issued for a different hostname; clock skew on the Uptime-Kuma host making a valid cert appear expired/not-yet-valid; recently renewed cert not yet deployed.

Understand the failure class

Related errors


AI-assisted analysis of louislam/uptime-kuma@6b5ea01557 (2026-08-12). Data as JSON: /api/errors/070fbfcfec03f540. Report an issue: GitHub.