dotvitals

Certificate is valid for longer than a public CA may issue

LowConfirmedtls.certificate.validity-too-long

What this check looks for

The certificate's lifetime is longer than any publicly trusted authority is allowed to grant, which means it did not come from one.

Why it matters

A long-lived certificate cannot be effectively revoked: if the key leaks, it stays usable for years. It is also a strong hint the certificate is self-issued or from an internal CA, which browsers will not trust.

When the check passes, your report says: “The certificate's lifetime is within what a public CA may issue”.

What it costs your score

When this check fails it removes 5 points from your TLS score, before the status, confidence and repeat multipliers are applied. TLS carries a weight of 15 in the overall score.

It shares the tls.certificate family ceiling of 60 points: however many findings that family produces, together they cannot remove more than that from TLS. One underlying problem showing up in several places is still one problem.

Severity
low
Default confidence
confirmed
Status when triggered
warn
Deduction
5 points
Family cap
tls.certificate · 60
Category
TLS
Module
Tls certificate
Fix owned by
user
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Move to short-lived, automatically renewed certificates.

A certificate you cannot revoke in practice is a key you cannot retire.

  1. Issue from a public CA over ACME and let it renew on a timer. That is what makes the falling cap a non-event: a 47-day certificate is no harder than a 398-day one once nobody has to remember it.

  2. Renew at roughly two thirds of the lifetime rather than at the last moment, so a failed renewal has room for a second attempt before anything expires.

  3. If an internal CA has to stay for internal names, shorten its issuance policy to match and automate renewal there too — the revocation problem is the same one, and internal is where long-lived certificates accumulate.

  4. Monitor the expiry rather than trusting the automation silently: a renewal timer that has been failing for a month looks exactly like one that is working until the day it does not.

How to confirm it worked

  • openssl s_client -connect ‹host›:443 -servername ‹host› </dev/null 2>/dev/null | openssl x509 -noout -dates

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx
certbot --nginx -d ‹host›
Caddy
‹host› {
	file_server
}
Technical detail

The validity window is ‹validity days› days. The CA/Browser Forum TLS Baseline Requirements §6.3.2 cap a publicly trusted certificate at **‹maximum days› days** for one issued when this one was, so a longer window means an internal CA, a device-generated certificate, or a clock problem at issuance.

**The cap is a schedule, not a number, and it is still falling.** It is keyed on the date the certificate was issued: 398 days before 2026-03-15, 200 days from 2026-03-15, 100 days from 2027-03-15, and 47 days from 2029-03-15. We judge this certificate against the row that was in force when it was issued, because that is the rule it had to meet — a 398-day certificate issued in 2025 was compliant and an identical one issued today is not.

The requirements key on the issuance date; we read notBefore, which the Subscriber certificate profile requires to be within 48 hours of signing, so it is a close proxy rather than the same thing.

One consequence worth planning for rather than reacting to: with the cap at 47 days from March 2029, manual renewal stops being viable for anyone. Automating it now is the same work as automating it then, done calmly.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the tls certificate checkerBuild the fix

Other tls certificate checks