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
- Inspect the full tlsInfoObject (cert info, daysRemaining, issuer) via Uptime-Kuma's cert transparency view to see the exact failure reason.
- Renew and redeploy the certificate if it is expired or near expiry.
- Serve the full intermediate chain so the path to a trusted root can be built.
- Correct clock skew on the Uptime-Kuma host (NTP).
- 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
- Monitor certificate expiry separately so renewals happen before failure.
- Serve the full intermediate chain so the path to a trusted root builds.
- Keep the Uptime-Kuma host clock synced via NTP.
- For internal CAs, add the root to the host trust store.
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
- SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.
Related errors
- Expected TLS alert '${expectedTlsAlert}' but connection succ
- TLS certificate is not authorized: ${tlsInfo.error}
- TLS Connection failed: ${message}
- Expected TLS alert '${expectedTlsAlert}' but received '${res
- This Chromium executable path is not allowed by default. If
AI-assisted analysis of louislam/uptime-kuma@6b5ea01557 (2026-08-12).
Data as JSON: /api/errors/070fbfcfec03f540.
Report an issue: GitHub.