Backport of the short-lived certificate handling from 3.3dev (commit
26a75cf7) to the 3.2 branch, as the issue was reported against 3.2.4.
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, and
- warn (HIGH) only when less than 24h of validity is left, and only for
certificates whose total lifetime exceeds 24h.
Regular certificates are unaffected. 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. The 3.2 man/HTML docs are
Ronn-NG generated, so the entry was added to match that format.
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.
Backport of the 3.3dev fix to the 3.2 branch.
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.
Eric Gu