使用nghttp2开发TLS客户端服务端时Boost asio证书验证失败问题求助

你遇到的问题核心在于nghttp2客户端（基于Boost.Asio）的证书验证逻辑和openssl s_client的默认行为存在差异，下面是具体的原因分析和对应解决方法：

1. 证书主机名不匹配（最常见诱因） #

openssl s_client -connect 127.0.0.1:3002默认只会验证证书链的可信性，不会检查证书中的主机名（CN/SAN字段）是否与连接目标匹配。但Boost.Asio的TLS客户端默认会开启主机名验证——如果你的服务器证书的CN（通用名称）或SAN（主题备用名称）没有包含localhost，就会触发certificate verify failed错误。

解决方法： #

• 检查你的服务器证书，确保它的CN设置为localhost，或者在SAN字段中添加DNS:localhost。
• 如果是用OpenSSL生成证书，生成时可以直接指定：

  openssl req -x509 -newkey rsa:4096 -keyout ausf.pem -out ausf.crt -days 365 -subj "/CN=localhost" -addext "subjectAltName=DNS:localhost" -nodes
  

2. Boost.Asio未正确加载系统可信CA证书 #

虽然你通过update-ca-certificates添加了CA证书，但Boost.Asio的set_default_verify_paths()在部分环境下可能没有正确读取到系统的可信证书目录（比如路径差异、权限问题）。

解决方法： #

手动指定CA证书文件路径，替换客户端代码中的tls.set_default_verify_paths()：

// 替换原有的set_default_verify_paths()，根据你的系统选择对应路径
tls.load_verify_file("/etc/ssl/certs/ca-certificates.crt"); // Ubuntu/Debian
// tls.load_verify_file("/etc/pki/tls/certs/ca-bundle.crt"); // CentOS/RHEL
// tls.load_verify_file("/usr/local/etc/openssl/cert.pem"); // macOS（brew安装的OpenSSL）

3. nghttp2的configure_tls_context覆盖了验证设置 #

nghttp2的configure_tls_context函数会为客户端TLS上下文设置一些默认选项，可能会无意中覆盖你之前配置的验证规则。

解决方法： #

调整代码顺序，把验证相关的配置放在configure_tls_context之前，确保你的设置优先级更高：

boost::asio::ssl::context tls(boost::asio::ssl::context::tlsv12);
// 先设置验证模式和CA路径
tls.set_verify_mode(boost::asio::ssl::context::verify_peer);
tls.load_verify_file("/etc/ssl/certs/ca-certificates.crt");
// 再调用nghttp2的配置函数
configure_tls_context(ec, tls);

4. 服务端未发送完整证书链 #

如果你的ausf.crt只包含服务器证书，没有附带签名它的CA证书，部分严格的客户端实现会因为无法构建完整信任链而验证失败（虽然openssl s_client可能会自动补全）。

解决方法： #

合并服务器证书和CA证书，生成完整的证书链文件：

cat ausf_server.crt ca.crt > ausf.crt

注意顺序：服务器证书在前，CA证书在后。

额外验证步骤 #

你可以用带主机名验证的openssl命令模拟客户端的严格验证逻辑，快速定位问题：

openssl s_client -connect 127.0.0.1:3002 -servername localhost -verify_hostname localhost

如果这个命令返回验证失败，那基本可以确定是主机名不匹配的问题，按照第1点修复即可。

内容的提问来源于stack exchange，提问作者james.a