TLS and certificate

What it inspects

Makes separate TLS handshakes to port 443 pinned to TLS 1.3, 1.2, 1.1 and 1.0 (using the scanned name as SNI) and records which succeed, then reads the leaf certificate. FAIL if TLS 1.0 or 1.1 completes (SSLv2/3 are not probed), the certificate has expired, it is self-signed (subject equals issuer), or its chain does not verify against the public CA bundle (one extra verifying handshake; a private or local CA, such as the localhost certificate some distributions generate, fails). WARN if it expires within 14 days, or if the chain could not be checked. The hostname is not matched. If nothing answers TLS on 443, the check is skipped. This is a passive check: it sends only what a normal client would.

Why it matters

TLS 1.0 and 1.1 are deprecated and have known protocol weaknesses; every current browser has dropped them. An expired or self-signed certificate makes browsers show a full-page warning, which costs visitors and teaches people to click through warnings. Both are cheap to fix and are easy for an outsider to see.

How to verify

# only against hosts you own
nmap -Pn -p 443 --script ssl-enum-ciphers example.com
# TLSv1.0 and TLSv1.1 must not appear in the output; TLSv1.2 and TLSv1.3 should.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
# Subject equal to issuer means self-signed. notAfter is the expiry date.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep 'Verify return code'
# Anything other than "0 (ok)" means the chain does not lead to a public CA, and the check fails.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -checkend 1209600
# 1209600 seconds is 14 days: "Certificate will expire" means the check's warning window applies.

How to fix

Set the web server to TLS 1.2 and 1.3 only, renew a certbot-issued certificate, and replace a self-signed certificate with a trusted one that renews automatically.

# Offer only TLS 1.2 and TLS 1.3 (the Mozilla "intermediate" profile). Edit whatever answers on port 443; find where protocols are set first:
#   grep -rn ssl_protocols /etc/nginx
#   grep -rn SSLProtocol /etc/apache2 /etc/httpd 2>/dev/null
# nginx: in the http { } block of /etc/nginx/nginx.conf and in every server { } block that sets its own value (a server-level value
#   overrides the http-level one; Debian's stock nginx.conf and older certbot options-ssl-nginx.conf files list TLSv1 and TLSv1.1):
#     ssl_protocols TLSv1.2 TLSv1.3;
# Apache: in the SSL virtual host or the global SSL file (Debian: /etc/apache2/mods-available/ssl.conf, RHEL family: /etc/httpd/conf.d/ssl.conf):
#     SSLProtocol -all +TLSv1.2 +TLSv1.3
#   On the RHEL family the stock ssl.conf follows the system crypto-policy. If TLS 1.0/1.1 are still offered, `update-crypto-policies --show`
#   prints LEGACY; changing the policy affects every TLS client and server on the host, so decide that deliberately (see update-crypto-policies(8)).
# Caddy: nothing to do, it offers TLS 1.2 and 1.3 only. If you set `protocols` in a tls block, remove tls1.0 and tls1.1 there.
# HAProxy: add `ssl-min-ver TLSv1.2` to the bind line or to ssl-default-bind-options.
# A load balancer or CDN in front of the server: the protocol list is a setting of that service (its TLS policy), not of the server behind it.
#
# Validate before you reload. If validation fails, put the old lines back and do NOT reload:
#   nginx -t && systemctl reload nginx
#   apachectl configtest && systemctl reload apache2     (httpd instead of apache2 on the RHEL family)
# Dropping TLS 1.0/1.1 locks out very old clients (Windows XP, Android 4, Java 6/7). The check only counts versions that actually complete
# a handshake, so run the verify command afterwards to see the result.

References

• Mozilla SSL Configuration Generator
• nginx: ngx_http_ssl_module
• Apache: mod_ssl
• Let's Encrypt documentation