Goal

Restrict the hostname verification CN fallback to fully qualified DNS domain names (FQDN)

Why

When a certificate has no subjectAltName (SAN) extension, s2n_verify_host_information() falls back to the Common Name (CN) field via s2n_verify_host_information_common_name(). This function passes the raw CN string to the verify_host_fn callback without checking whether the CN value is an IP address. If the client is using s2n_default_verify_host, which performs a plain string comparison against conn->server_name, a certificate with CN=127.0.0.1 (or any IP) and no SAN is accepted when the client targets that same IP literal.

This violates RFC 6125 section 6.4.4, which restricts the CN fallback to strings whose form matches that of a fully qualified DNS domain name. Per section 6.2.1, IP reference identities must only be matched against iPAddress SAN entries, never against CN values.

How

In s2n_verify_host_information_common_name(), after extracting the CN into peer_cn, check whether it parses as an IPv4 or IPv6 address (via inet_pton). If it does, fail with S2N_ERR_CERT_UNTRUSTED instead of forwarding it to the verify callback.

Callouts

We would like to thank Oleh Konko from 1seal (https://1seal.org) for reporting this issue.

Testing

Added a new unit test where test certs with IP address CN and no SAN extension are rejected. The test certs are generated from openssl req -x509. Verify cert configuration:

% openssl x509 -in tests/pems/ip_cn_no_san_rsa_cert.pem -noout -subject -ext subjectAltName 2>&1
subject=C=US, ST=WA, L=Seattle, O=Amazon, OU=s2n, CN=127.0.0.1
No extensions in certificate

% openssl x509 -in tests/pems/ipv6_cn_no_san_rsa_cert.pem -noout -subject -ext subjectAltName 2>&1
subject=C=US, ST=WA, L=Seattle, O=Amazon, OU=s2n, CN=::1
No extensions in certificate

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.