Boost.Asio SSL stream accepts certificates for mismatched hostnames without custom verification callback

Symptom

A Boost.Asio SSL client configured with ssl::verify_peer successfully validates a server certificate chain — trust anchor, expiration, and signature — yet connects to a host whose certificate contains a different Subject Alternative Name or Common Name than the target hostname. No verification failure occurs unless the application installs a custom callback that explicitly matches the hostname against the certificate's SAN or CN fields.

Context

Boost.Asio's ssl::stream and ssl::context provide TLS transport primitives but do not implement RFC 6125 hostname verification by default. The library's built-in verify_callback checks chain validity only. Developers must supply their own callback, typically using X509_check_host (OpenSSL 1.1.0+) or manual SAN parsing, to enforce that the connected hostname appears in the certificate. This design reflects Asio's low-level abstraction philosophy, deferring application-layer policy to the user.

Open questions

• What is the recommended pattern for portable hostname verification across OpenSSL, Schannel, and Secure Transport backends when using ssl::context::native_handle()?
• Does Boost.Beast's HTTP client expose any helper to enable RFC 6125 verification without reimplementing the callback logic?
• Are there plans in the C++ Networking TS or std::net proposals to standardize hostname verification requirements?