解决libcpr/cpr在Windows下HTTPS请求的SSL证书问题

问题背景

在使用libcpr/cpr库进行HTTPS请求时，Windows用户可能会遇到"SSL certificate problem: unable to get local issuer certificate"的错误。这个问题主要出现在cpr 1.10.5及以上版本和libcurl 8.0及以上版本的组合中。

问题分析

这个问题的根源在于Windows平台上的SSL/TLS证书验证机制。在较新版本的libcurl中，默认的SSL后端可能没有正确配置为使用Windows系统的证书存储。Windows使用自己的证书存储机制（称为Schannel），而不是像Linux那样使用OpenSSL的证书存储。

解决方案

方法一：使用Schannel作为SSL后端

最直接的解决方案是在构建libcurl时明确指定使用Windows原生的Schannel作为SSL后端。这可以通过在Conan配置中添加以下选项实现：

[options]
libcurl/*:with_ssl=schannel

Schannel是Windows内置的SSL/TLS实现，它会自动使用Windows证书存储中的根证书进行验证，避免了手动管理证书的麻烦。

方法二：降级库版本

虽然不推荐长期使用，但临时解决方案是降级到cpr 1.10.4及以下版本和libcurl 7.88.1及以下版本。这些旧版本可能使用了不同的SSL验证机制或默认配置。

技术细节

为什么会出现这个问题

1. 证书验证机制变化：新版本的libcurl可能修改了默认的证书验证行为，更严格地要求证书链的完整性。

2. Windows证书存储：Windows不像Unix-like系统那样使用标准的CA证书存储位置，而是有自己的证书存储系统。

3. 构建配置差异：不同包管理器（如vcpkg）可能有不同的默认构建选项，导致SSL后端的选择不同。

为什么Schannel能解决问题

Schannel是Windows的本地安全通道实现，具有以下优势：

1. 自动集成Windows证书存储
2. 无需手动管理CA证书包
3. 更好的Windows系统集成
4. 支持最新的Windows安全特性

最佳实践建议

1. 明确指定SSL后端：在Windows平台上构建时，始终明确指定使用Schannel作为SSL后端。

2. 保持库更新：尽量使用最新版本的cpr和libcurl，配合正确的配置，而不是降级使用旧版本。

3. 测试环境一致性：确保开发、测试和生产环境使用相同的SSL后端配置，避免环境差异导致的问题。

总结

Windows平台上的HTTPS请求问题通常源于SSL/TLS实现的配置差异。通过正确配置libcurl使用Windows原生的Schannel作为SSL后端，可以充分利用系统的证书管理机制，避免手动管理证书的复杂性。这种方法不仅解决了当前的证书验证问题，还能提供更好的系统集成和安全性。