Summary

Plugin 142960 now validates the identity of an HTTPS service in line with the current RFC 9525 as opposed to the obsolete RFC 6125. When a service's TLS certificate contains Subject Alternative Name (SAN) entries, the plugin compares the target hostname against those SANs only and no longer considers the certificate's Common Name (CN). If the certificate has no SANs, the plugin falls back to using  the CN, so coverage for legacy certificates is unchanged.

Background

Plugin 142960 checks whether a detected web server supports HTTP Strict Transport Security (HSTS). Before it evaluates the service, the plugin must confirm that the service's TLS certificate covers the identity of the host. This confirms that the server is authorized to answer for that host, and that the finding describes the target host and not whichever service happened to respond on its behalf. If the identity check fails, the plugin cannot evaluate the service.

Until now, the plugin performed this check by comparing the resolvable hostname against the CN of the certificate presented on the relevant port. If the CN covered the hostname, the service was evaluated for HSTS.

RFC 9525, which supersedes the identity-matching guidance in RFC 6125 (which allowed for the checking of CNs) states that when a certificate carries one or more SAN entries, hostname identity must be validated against those SANs only. The CN must not be used for this purpose, even if it matches the hostname. The RFC gives several reasons: the CN is ambiguous, it cannot hold multiple identifiers, and its use leads to security and parsing inconsistencies.

This change was prompted by a case in which a host's service could only be identified through the SAN of its certificate and not through the CN. Research into that case led to RFC 9525, and the update follows its guidance.

Changes

Service identity validation in plugin 142960 now works as follows:

• If SANs were enumerated from the service's TLS certificate, the hostname is compared against the SANs only. The CN is not used, even when it matches the hostname.
• If no SANs were enumerated from the certificate, the plugin uses the CN to validate the service identity, as it did before.

Impact

For services whose certificates include SANs, the outcome of the identity check depends only on the SAN values. A service whose SANs cover the hostname but whose CN does not will now be validated and evaluated for HSTS. A service whose CN matches the hostname but whose SANs do not will no longer pass validation, so the plugin will not evaluate it.

Services with certificates that have no SANs are evaluated as before.

Affected Plugins

142960 - HSTS Missing From HTTPS Server (RFC 6797)

Targeted Release Date

Monday, October 12, 2026