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

The direct answer

This is expected behavior, not a bug. ssl::verify_peer only asks OpenSSL to validate the certificate chain — trust anchor, signatures, and expiry. Matching the certificate's SAN/CN against the hostname you dialed is application-layer policy (RFC 6125), and Boost.Asio deliberately leaves that to you. So a perfectly valid certificate for other.example.com will pass verify_peer even when you connected to api.example.com.

The fix: use the built-in verification callback

You do not need to write SAN-parsing code. Boost.Asio ships ready-made callback helpers:

ssl::stream<tcp::socket> stream(io_ctx, ssl_ctx);

stream.set_verify_mode(ssl::verify_peer);
stream.set_verify_callback(
    ssl::host_name_verification("api.example.com")); // Boost >= ~1.73
// older Boost: ssl::rfc2818_verification("api.example.com")

// Also set SNI so the server presents the right certificate:
SSL_set_tlsext_host_name(stream.native_handle(), "api.example.com");

stream.handshake(ssl::stream_base::client);

Despite its name, rfc2818_verification checks SANs and falls back to CN only when no SANs exist. host_name_verification is the newer, stricter helper; check BOOST_VERSION if you're unsure which is available.

Two common traps

• Forgetting SNI. Setting the callback alone doesn't send the hostname during the handshake. Without SSL_set_tlsext_host_name, a virtual-hosted server may present a default certificate, and your verification then fails (or worse, passes) for the wrong name.
• Overriding the callback carelessly. Any custom callback that returns true unconditionally — a common debugging shortcut — silently reopens the mismatch hole. If you wrap the built-in helper, propagate its result rather than swallowing it.

Your open questions, briefly

• Portable verification across backends: The Boost helpers assume OpenSSL-style X509 stores. If you drive Schannel or Secure Transport via native_handle(), verification semantics are backend-specific; there is no single portable pattern beyond per-backend checks. Most production Asio code standardizes on OpenSSL for this reason.
• Boost.Beast: Beast adds no hostname verification of its own. Its HTTPS client examples explicitly attach rfc2818_verification/host_name_verification to the underlying Asio stream — that is the intended pattern, not a workaround.
• Standardization: I'm not aware of any C++ Networking TS or std::net proposal that mandates hostname verification at the transport layer. Given that those efforts have stalled, I would not design around it — treat this as uncertain and verify against current proposals if it matters to you.

Verify the behavior yourself

1. Connect to a host by IP (or a wrong subdomain) with only verify_peer set — the handshake succeeds, demonstrating the gap.
2. Add ssl::host_name_verification(expected_host) — the same connection now fails with a certificate verification error.
3. Run openssl s_client -connect host:443 -servername host to inspect which SANs the server actually presents.

Assumptions: OpenSSL-backed Asio, Boost 1.73+ for host_name_verification. If you're on a different TLS backend, the callback approach above needs review.