本质是PHP底层OpenSSL无法验证远程HTTPS证书链，主因包括系统CA证书库过旧、PHP未正确加载openssl.cafile路径，或网络中间设备劫持TLS连接；应优先系统级修复证书而非关闭验证。
Composer报SSL certificate error的本质是什么
这不是Composer的问题，而是PHP底层OpenSSL无法验证远程HTTPS证书链。常见表现是file_get_contents(): SSL operation failed或cURL error 60: SSL certificate problem。根本原因通常是：系统CA证书库过旧、PHP没读到正确openssl.cafile路径、或网络中间设备（如企业代理、杀毒软件）劫持了TLS连接。
怎么让Composer用上有效的CA证书
优先走系统级修复，别直接关SSL验证。关键操作顺序如下：
- 确认当前PHP用的OpenSSL路径：
php -r "print_r(openssl_get_cert_locations());" - 检查
openssl.cafile是否为空或指向不存在的文件（用php --ini找php.ini，再搜openssl.cafile） - macOS用户用Homebrew装完
ca-certificates后，证书通常在/opt/homebrew/etc/openssl@3/cert.pem（M1/M2）或/usr/local/etc/openssl@3/cert.pem（Intel），手动设进去：composer config --global cafile /opt/homebrew/etc/openssl@3/cert.pem - Linux用户可试
/etc/ssl/certs/ca-certificates.crt（Debian/Ubuntu）或/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem（RHEL/CentOS） - Windows用户若用XAMPP/MAMP，需进其PHP目录下找
extras/ssl/cacert.pem，然后在php.ini里写死openssl.cafile="C:\xampp\php\extras\ssl\cacert.pem"
为什么COMPOSER_NO_SSL=1或--no-secure-http不能当正解
这些只是绕过验证，不是更新证书链。后果很实在：
- 所有HTTPS请求都不校验证书，攻击者可中间人劫持packagist.org流量，往
vendor/里塞恶意代码 - CI流水线一旦启用，等于给整个交付链开后门
- 某些企业安全策略会直接拦截这类不验证书的出站连接，反而让问题更难排查
-
composer audit等依赖安全扫描功能会失效，因为底层HTTP客户端跳过了证书校验逻辑
验证证书链是否真正生效
别只看composer install能跑通，要确认OpenSSL真在用你配的证书：
- 执行
php -r "var_dump(stream_context_create(['http' => ['method' => 'GET']]))"，观察是否报SSL: CA certificate bundle not found - 运行
composer diagnose，它会明确告诉你CA file路径是否可读、是否包含足够证书 - 临时加个测试包触发HTTPS请求：
composer require --dev phpunit/phpunit:^10.5，失败时错误信息里会显示实际尝试读取的CA路径 - 如果用了Docker，注意宿主机和容器内证书路径不同——
cafile配置必须对准容器里的PHP环境，不是你本地终端的
证书链不是“更新一次就一劳永逸”的东西。系统升级、PHP重装、切换OpenSSL版本都可能重置路径。最易被忽略的是：Composer自身不管理证书，它完全依赖PHP的OpenSSL扩展配置；而很多开发者只改了composer config --global cafile，却忘了同步修正php.ini里的openssl.cafile，结果两个配置打架，后者胜出。
