TLS Certificate Expiring Soon

Rule Severity and Score

Rule id

http.tls_expiring

Group

HTTP

Severity of a failure

Info

Counts in the score

Yes, whenever it applies to the page

Required for a score

No

Condition and Exceptions

Condition

Probe tls: days from the probe's checked_at to valid_to, against thresholds proportional to the validity period L (valid_from to valid_to, same handshake): ≤ min(30, L/3) → review; ≤ min(7, L/12) → fail (info). A 90-day or 1-year certificate keeps 30 and 7 days; a 6-day certificate is reviewed with 2 days left. Host-level: one issue per host (IssueTracker::HOST_RULES), one result per crawl

Exceptions

http page → not_applicable; certificate not valid → not_applicable (http.tls_invalid); no probe, no valid_to or no checked_at, HTML mode → not_checked; no valid_from (a probe stored before lot 3) → the fixed 30 and 7 days

Sources and Project Decision

Sources

RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile, section 4.1.2.5 Validity (IETF, Q73)
Let's Encrypt FAQ: renew 90-day certificates every 60 days and six-day certificates every three days (Let's Encrypt, Q14)

Project decision

Thresholds proportional to the certificate's validity period L: review when the days left are at most min(30, L/3), an info failure at min(7, L/12). Let's Encrypt renews 90-day certificates with a third left and 6-day certificates with half left (Q14), so a short-lived certificate inside its normal renewal window is not flagged. The 30 and 7 day caps are project decisions [D]. Days are counted from the moment the certificate was read (checked_at). One result per host.