一、问题回顾
在一次 PHP SSO 单点登录部署过程中，服务端请求 HTTPS 接口时稳定报错：
Peer reports incompatible or unsupported protocol version.
本地环境运行正常，服务器（CentOS 7）失败。 在排除了代码逻辑、证书配置和 OpenSSL 版本问题后，最终将排查重点下沉到系统层 SSL 实现。
真正的关键问题是：
当前服务器上的 cURL，到底是基于 OpenSSL，还是基于 NSS？
二、为什么“cURL 使用的 SSL 实现”很重要
很多开发者会默认认为：
“只要系统装了 OpenSSL，新版 TLS 就一定可用”
但实际上：
- cURL 并不一定使用 OpenSSL
- 在 CentOS / RHEL 体系中，cURL 默认常常链接的是 NSS
- TLS 能力取决于 cURL + SSL 后端库的组合
也就是说：
OpenSSL 版本再高，如果 cURL 不用它，等于没用
三、快速判断方法（最关键）
方法一：curl -V（首选、最直接）
在服务器上执行：
curl -V
典型输出示例（使用 NSS）：
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.28.4 zlib/1.2.7 Protocols: http https ftp ftps Features: SSL
关键判断点：
- 出现 NSS/x.xx → cURL 使用的是 NSS
- 出现 OpenSSL/x.xx → cURL 使用的是 OpenSSL
对比示例（使用 OpenSSL）：
curl 7.88.1 libcurl/7.88.1 OpenSSL/1.1.1t zlib/1.2.13
这是定位问题的第一锤，90% 的情况到这里已经真相大白。
四、为什么 CentOS 7 更容易“踩 NSS 的坑”
复盘过程中发现，问题并非偶然，而是系统默认选择导致的必然结果。
CentOS 7 的几个事实
- 系统发布时间较早
- 默认 cURL 编译时选择 NSS
- NSS 版本升级受系统生命周期限制
- 官方源已停止功能性更新
这意味着：
- TLS 1.2 / 1.3 在“理论上支持”
- 但在实际 HTTPS 握手中，经常与新服务端产生不兼容
最终表现为：
Peer reports incompatible or unsupported protocol version
五、进一步确认（进阶验证）
如果希望更“硬核”一点，可以用下面方式进一步确认。
方法二：查看 cURL 依赖的动态库
ldd $(which curl) | grep -E 'ssl|nss'
可能看到：
libnss3.so => /lib64/libnss3.so
说明：
- 当前 curl 确实链接的是 NSS
- 即便系统中存在 OpenSSL，也不会被使用
六、与 PHP 的关系（为什么 PHP cURL 也会受影响）
在 PHP 中：
- curl_* 函数依赖的是 系统 libcurl
- PHP 并不“自带” SSL 实现
因此：
PHP cURL 行为 = 系统 cURL 行为
这也解释了为什么：
- 本地开发环境（macOS / Ubuntu）正常
- 服务器（CentOS 7）异常
- 修改 PHP 代码参数无法根治问题
七、复盘结论
这次问题的核心不在于：
- PHP
- SSO 逻辑
- 证书配置
而在于一个被长期忽略的事实：
HTTPS 能不能用，取决于 cURL 背后的 SSL 实现，而不是你以为的 OpenSSL 版本
关键经验总结
- TLS 报错优先检查 curl -V
- 不要默认 cURL = OpenSSL
- CentOS 7 默认 NSS 是已知技术债
- 关闭 SSL 校验是错误方向
- 系统依赖库问题，代码层解决不了
八、后续行动建议
- 短期：升级 curl / libcurl（更换支持新 TLS 的 NSS）
- 中期：迁移至 Docker / 新系统（AlmaLinux、Rocky、Ubuntu）
- 长期：避免在 EOL 系统上承载安全敏感服务（SSO / OAuth）
转载请注明：TUTERM.COM » 【问题复盘】一次 TLS 握手失败，如何定位到 cURL 使用的是 NSS 还是 OpenSSL
