使用Boost与OpenSSL验证SSL证书时的信任链问题及相关疑问

嘿，我来帮你拆解一下这个SSL证书验证的问题，你遇到的情况其实是OpenSSL（Boost Asio SSL的底层依赖库）和浏览器在证书信任链处理上的差异导致的，咱们一步步捋清楚：

为什么ctx.set_default_verify_paths()不生效？ #

OpenSSL的这个方法会加载系统默认的信任根证书存储，但这里的核心问题是服务器返回的是中间证书，而非由根CA直接签发的证书。浏览器有个实用的自动补全机制：当服务器返回的证书链不完整时，它会读取证书里的AIA（Authority Information Access）字段，自动去对应的URL下载缺失的中间证书，补全整个信任链后再验证。但OpenSSL默认没有这个自动补全功能——它只会严格检查你提供的信任存储里有没有能衔接整个链的证书，如果系统默认根CA里没有对应根证书，或者服务器没发完整链，验证就会失败。

为什么load_verify_file("cert-chain.pem")可行，单独cert.pem不行？ #

cert-chain.pem应该包含了完整的信任链：从服务器的中间证书一直到最终的根CA证书。而单独的cert.pem只有中间证书，OpenSSL找不到能信任的根CA来验证这个中间证书的合法性，自然就验证失败了。

浏览器是怎么完成验证的？ #

浏览器有两个关键优势：

• 内置了海量的主流可信根CA证书，覆盖了绝大多数正规网站的签发机构；
• 会自动处理不完整的证书链，通过AIA字段获取缺失的中间证书，补全后再走完整的验证流程。这就是为什么你用浏览器访问没问题，但Boost/OpenSSL不行的原因。

关于自定义验证回调的顾虑——你的担心是对的！ #

你提到自己实现了自定义验证，但因为代码开源，担心别人伪造符合验证逻辑的证书，这个顾虑完全合理。像你写的这个示例回调：

ctx.set_verify_callback(std::bind(&custom_verify_callback, std::placeholders::_1, std::placeholders::_2));

[...]

bool custom_verify_callback(bool preverified, boost::asio::ssl::verify_context& ctx)
{
    // Perform your custom verification logic here
    X509* cert = X509_STORE_CTX_get_current_cert(ctx.native_handle());
    // Example: Check if the certificate is issued by a trusted CA
    // This is a simplistic example and may not cover all verification requirements
    if (preverified && cert != nullptr)
    {
        // Check if the certificate is issued by a trusted CA
        // You may need to implement more complex logic here depending on your requirements
        // For example, checking if the intermediate certificate is present in the chain
        // or verifying the hostname
        // Example: Check the issuer of the certificate
        X509_NAME* issuer = X509_get_issuer_name(cert);
        if (issuer != nullptr)
        {
            // Compare the issuer name with your trusted CA's name
            // For simplicity, this example assumes a specific issuer name
            if (X509_NAME_cmp(issuer, "") == 0)
            {
                return true;
            }
        }
    }
    return false;
}

它的逻辑太简化了，缺少证书有效期校验、hostname匹配、吊销状态检查、完整链验证等关键环节，很容易被绕过，完全失去了SSL证书验证的安全意义。手动实现完整的证书验证逻辑不仅工作量大，还容易出错，远不如依赖OpenSSL的原生验证流程靠谱。

正确的解决思路 #

给你几个靠谱的方案：

• 方案一：确保系统信任根包含对应根CA：检查你系统的默认证书存储（比如Linux上的/etc/ssl/certs，Windows的证书管理器），如果服务器证书链的根CA不在里面，手动添加它到系统信任存储，这样set_default_verify_paths()就能正常工作了。
• 方案二：手动提供完整信任链：把根CA证书和中间证书打包到同一个PEM文件里，用load_verify_file()加载；或者用add_verify_path()指定包含所有信任证书的目录（注意要按OpenSSL要求用哈希值命名证书文件）。
• 方案三（不推荐）：自动补全证书链：如果服务器没返回完整链，你可以自己解析AIA字段、下载中间证书补全链后再交给OpenSSL验证，但这个逻辑复杂，还要处理网络请求、缓存等问题，除非特殊需求不建议这么做。

备注：内容来源于stack exchange，提问作者Patrick Charron Morneau