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").
In mass-testing mode main() runs run_mass_testing()/run_mass_testing_parallel()
and exits without ever calling lets_roll() for the scan itself, so
calc_scantime() never runs and SCAN_TIME stays 0. fileout_json_footer(),
invoked from cleanup() on exit, treats SCAN_TIME==0 as an interrupted scan
and writes "scanTime": "Scan interrupted" for the whole batch.
START_TIME is already set by the earlier "lets_roll init" call, so compute
the overall scan time with calc_scantime() before exiting the mass-testing
path. The aggregate footer now reports the real elapsed time as an INFO
finding instead of a spurious WARN.
check_proxy() gated IPv6 proxy support on a home-grown version check
${OSSL_VER_MAJOR$}${OSSL_VER_MINOR} -ge 11 at two places, which had a
stray "$" causing a "bad substitution" error. On non-LibreSSL builds
this aborted the rest of check_proxy() for any IPv6 proxy (literal
[addr]:port, or a hostname resolving only to AAAA), so PROXY was never
rebuilt into a valid "-proxy ..." argument and downstream openssl calls
failed with an error mentioning neither IPv6 nor the proxy.
Beyond the typo, the concatenation approach was itself unsound:
OSSL_VER_MINOR carries the patch component (e.g. "1.1" for OpenSSL
1.1.1), so ${OSSL_VER_MAJOR}${OSSL_VER_MINOR} yields "11.1" and
[[ 11.1 -ge 11 ]] is an arithmetic error. Replace both checks with the
dotted-glob idiom used everywhere else in the file for OpenSSL >= 1.1
gates (e.g. testssl.sh:21441, :8216), which is robust and greppable.
pr_url() and pr_boldurl() interpolated their argument directly into
<a href="$1">$1</a> without HTML escaping. The most notable caller
passes the raw HTTP Location: header from the scanned server, so a
malicious HTTPS target could inject arbitrary HTML/JS into an
operator's --htmlfile report. Route both the href attribute and the
link text through the existing html_reserved() escaper, matching the
pattern already used by every other pr_* HTML-output function.
[BUG / possible BUG] Inverted return check in sym-encrypt() at testssl.sh:14741 makes the function return error 7 on every success. The tm_out line at testssl.sh:14743 is unreachable.
#3079
Eric Gu