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.
18422: if [[ $tmp_result -eq 1 ]] && [[ loop_reneg -eq 1 ]]; then
19633: [[ aaa == bbb ]] # provoke return code=1
450:TRUSTED1ST="" # Contains the `-trusted_first` flag, if this version of openssl supports it
The latter check be amended/corrected later, so that backticks in comments are allowed.
Staring with a simple pattern for checking for non-variables at left hand
side like [[ LHS == $value ]]. The file is supposed be amended in the future.
This fixes#3074 .
Upon commit it fails first as there are two instances which will be detected
(one is deliberate but will be changed too) .
When scanning hosts which offer only TLS 1.3 under some circumstances (e.g. using
MacOS) the scan stopped and prompted the user . It happened always when $OPENSSL
supported TLS 1.3. It did not when this was not the case.
This fixes that (see #3083) for 3.3dev by just skipping the rest in determine_optimal_proto()
when TLS13_ONLY is true.
Also it fixes missing line feeds for servoce detecttion and order in which DNS HTTPS
RR are displayed.
[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
... also improve error handling by adding return values in
*https_rr functions.
The error for ~Macs occured because for interpretation of
raw TYPE65 DNS data it was just 1 returned instead of 0
--for empty records.
Dirk Wetter