根本解法是同步配置 PHP 的 curl.cainfo 和 openssl.cafile 指向同一份可信 PEM 格式 CA 证书文件,并通过 composer config --global cafile 补充 Composer 自身 HTTPS 请求的证书路径,确保 OpenSSL 扩展启用、路径无权限问题且格式正确(无 BOM/空行),禁用 secure-http 或 disable-tls 仅限临时调试,存在严重安全风险。

composer 连不上 HTTPS 仓库,报 SSL certificate problem: unable to get local issuer certificate,不是网络不通,而是证书链验证失败。根本解法不是关 TLS,是让 PHP/cURL 和 Composer 都能正确加载你信任的 CA 证书。
确认 PHP 的 OpenSSL 和 cURL 是否真正就绪
Composer 底层依赖 PHP 的 openssl 扩展和 cURL 模块,二者缺一不可,且必须指向同一份可信证书文件。常见误区是只改了 curl.cainfo 却漏配 openssl.cafile,导致部分请求(如 GitHub OAuth 跳转)仍失败。
- 运行
php -m | grep openssl和php -r "print_r(curl_version());"确认扩展已启用 - 查 php.ini 位置:
php --ini,打开对应文件 - 确保这两行都存在且路径一致:
curl.cainfo="/path/to/cacert.pem"openssl.cafile="/path/to/cacert.pem" - Windows 用户常把证书放在
C:\php\cacert.pem,macOS/Homebrew 用户更可能是/opt/homebrew/etc/openssl@3/cert.pem或/etc/ssl/cert.pem
用 composer config --global cafile 指向完整 PEM 链
这个配置专为 Composer 自身的 HTTPS 请求(如 diagnose、audit、私有仓库元数据拉取)服务,它不替代 PHP 的 cafile,而是补充——尤其在私有 Artifactory/Nexus 使用自签名或中间 CA 时。
- 证书文件必须是 PEM 格式,以
-----BEGIN CERTIFICATE-----开头,不能含 BOM、空行或注释 - 若企业用了中间 CA,需合并中间 CA + 根 CA:
cat intermediate.crt root.crt > company-ca.pem(别用编辑器手动拼) - 设全局路径:
composer config --global cafile /etc/ssl/certs/company-ca.pem - 验证是否生效:
composer config --global --list | grep cafile,输出应为绝对路径 - 注意权限:PHP 进程(如
www-data或你的 CLI 用户)必须有读取该文件的权限,否则静默忽略
为什么 composer diagnose 报错但 install 看似成功?
composer diagnose 会真实发起 HTTPS 请求测试 packagist.org 的 TLS 握手、证书有效性及系统信任状态;而 install 可能因缓存、降级或插件干扰绕过校验,导致漏洞被漏检。
- 典型现象:
diagnose显示secure-http: FAIL或SSL certificate problem,但install仍跑通 - 风险在于:
composer audit、show --security或私有源的 signature 验证可能静默跳过 - Artifactory 用户特别注意:
diagnose默认只测packagist.org,不会自动遍历你composer.json里定义的repositories,得手动验证:curl -Iv https://your-artifactory.example.com/artifactory/api/composer/packagist.org/packages.json - 若返回
SSL_ERROR_SYSCALL或证书 CN 不匹配,说明域名与证书 Subject 不一致,需运维重签
别碰 secure-http false 或 disable-tls
这些是临时止痛药,不是解药。禁用后,Composer 允许 HTTP 源、跳过包签名验证、接受自签名证书——供应链攻击面直接大开。
-
composer config --global secure-http false→ 允许http://镜像源,元数据可被中间人篡改 -
composer config --global disable-tls true→ 所有 HTTPS 请求降级为 HTTP,signature-verification失效 - GitHub OAuth 认证失败时,SSL 问题常被掩盖:先清空 token(
composer config --global github-oauth.github.com ""),再跑diagnose,如果这时通过了,说明问题出在 OAuth 流程的 HTTPS 跳转环节,而非证书本身 - 真正安全的配置 = 强制 HTTPS(
secure-http true) + 启用签名验证(security.signature-verification true) + 可信 CA(cafile或系统级openssl.cafile)
最易被忽略的一点:Composer ≥2.5 加载 cafile 时,会先尝试用它初始化 OpenSSL 上下文,失败则 fallback 到系统默认 CA 路径——这意味着路径错、格式错、权限不足,都会静默失败,继续报 60 错误,但你完全看不到明确提示。











