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.
Starting with a few simple patterns, like for checking for non-variables at left hand side like [[ LHS == $value ]]. The file is supposed be amended in the future.
This fixes#3074 for 3.2
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.
run_security_headers() listed "Permissions-Policy" twice in its
header_and_svrty checklist: once as OK and again as INFO. The loop
matched the same header on both iterations, emitting two entries to JSON
(headerResponse) and the terminal output. Remove the duplicate INFO
entry, keeping the intended OK classification.
Backport of the 3.3dev fix to the 3.2 branch.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This fixes#3003 for 3.2 .
The conversion to proper UTF-8 should have taken place by just using -nameopt RFC2253, see manpage openssl-namedisplay-options(1ssl).
As @dcooper16 suggested removing esc_msb should help. This may look counterintuitive but works.
The trailing error messages were swapped in the paragraphs / description for MAX_SOCKET_FAIL + MAX_OSSL_FAIL .
This fixes the confusion for 3.2 , see #3028 .
It seems that OpenSSL 4.0.0 allows for the possibility that a server's response to the status request extension may include more than one OCSP response (presumably one for each certificate in the certification path).
As a result, the line indicating that the server does not provide status information was changed from "OCSP response: no response sent" to "OCSP responses: no responses sent". If a response was included, "OCSP responses:" is followed by an indication of the number of responses included.
This commit addresses the change from "response" to "responses".
I do not know of any servers that provide more than one OCSP response, so I have not tried to make any changes to handle more than one response.
When checking early for date flavors, there might be an edge case when a directory with a referred file (for the date command) isn't readable which might cause testssl.sh not to detect the date flavor correctly.
This fixes that (#3009) by cd'ing to / in a subshell which should be cd'able and readable under every platform.
This commit addresses two issues created by changes in certificate printing in OpenSSL 4 (based on testing with OpenSSL 4.0.0-alpha1).
With OpenSSL 4, the public key type for ML-DSA keys is now shown with a string (e.g., ML-DSA-44) rather than an OID. The first change in this commit ensures that the public key size is set correctly in this case.
Second, different information is printed about the size of elliptic curve public keys. All previous versions of OpenSSL (and LibreSSL) just provided the size of the public key:
Public-Key: (256 bit)
OpenSSL 4.0.0-alpha includes additional information:
Public-Key: (256 bit field, 128 bit security level)
The second change in this commit removes this additional information.
Pete Cooper