mirror of
https://github.com/drwetter/testssl.sh.git
synced 2026-08-03 21:07:39 +02:00
Eric Gu
26a75cf764
Certificates with a short validity period (e.g. Let's Encrypt's 6-day
"shortlived" profile, now GA) always tripped the days2warn expiry
thresholds and were shown in red on the "Certificate Validity (UTC)"
line, even seconds after issuance. That red is misleading for a cert
that is intentionally short-lived.
Detect short-lived certificates by their validity period (notAfter -
notBefore) using a new DAYS_VALID_SHORTLIVED threshold (default 10 days,
per the CA/Browser Forum BR 1.6.1 "Short-lived Subscriber Certificate"
definition, which also covers the LE 6-day profile). For such certs:
- show them as good (not red) with a "short-lived cert (N days)" remark
so the short lifespan reads as intended rather than as an error, and
- warn (HIGH) only when less than 24h of validity is left, and only for
certificates whose total lifetime exceeds 24h (a cert whose whole
life is under 24h stays good until it expires rather than being
flagged the entire time).
Regular certificates are unaffected and keep the existing days2warn
behaviour. The threshold is overridable via the DAYS_VALID_SHORTLIVED
env var (documented in doc/testssl.1.md next to DAYS2WARN1/2) and added
to CHANGELOG.md.
Verified end-to-end with local openssl s_server: 5-day fresh (green),
5-day with <24h left (red, "expires < 24h"), 12h fresh (green), 12h
nearly expired (green), and 90-day (unchanged ">= days").