TLS certificate has at least 14 days until expiry
Authored by Stanley Hong · AgentReserve (founder).
The peer certificate's `notAfter` is at least 14 days in the future. Certificates that expire imminently cause sudden client-side failures and indicate an unmanaged renewal process.
When this rule runs
Evaluated on every scan — observable from the URL, TLS handshake, or HTTP response headers, even when the MCP layer is auth-walled or unresponsive.
Why it matters
A certificate that expires in days, not months, is one renewal misfire away from a hard outage. It's a leading indicator of operational hygiene more than a direct security finding.
Pass condition
`notAfter - now` is at least 14 days.
Fail condition
`notAfter - now` is less than 14 days (or already in the past).
Evidence examples
When the rule fails, the report records evidence in roughly this shape:
{"daysUntilExpiry": 3}
Remediation
Automate certificate renewal (cert-manager, ACM, Let's Encrypt with certbot) and alert on `< 30 days` to expiry.
Methodology
This rule belongs to the Transport security dimension. How the server is reached on the wire. Covers TLS and protocol-level confidentiality of probe traffic.
Read the full methodology for how rules are aggregated into a score, how verdicts are decided, and how hard-fail rules override the aggregate.