手把手教你为Composer私有仓库配置HTTPS证书-composer-PHP中文网

答案是php未加载私有仓库根证书，需在php.ini中同步配置openssl.cafile与curl.cainfo指向同一pem格式根证书文件，并确保其为完整信任链、权限正确、路径绝对且重启服务生效。

手把手教你为composer私有仓库配置https证书

私有仓库用了HTTPS，但composer install报cURL error 60怎么办

这不是 Composer 不支持你的证书，而是它根本没加载到你期望的根证书。Composer 自身不提供 --cacert 这类参数，所有 HTTPS 证书校验完全由 PHP 底层的 OpenSSL 或 cURL 承担——它只认 openssl.cafile 和 curl.cainfo 这两个 PHP 配置项指向的文件。

常见错误现象：

file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed
即使配置了 ssl.cafile，composer diagnose 仍显示 secure-http: OK 但请求失败
用 curl -v https://your-private-repo.com 能通，但 composer install 报错

实操建议：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

先确认 PHP 加载的 CA 路径：php -r "print_r(openssl_get_cert_locations());"，重点看 default_cert_file 是否存在且可读
不要单独配 ssl.cafile ——它在 Composer 2.5+ 中只是 fallback，必须同时确保 openssl.cafile 和 curl.cainfo 在 php.ini 中指向同一个 PEM 文件
该 PEM 文件必须是完整证书链（中间 CA + 根 CA），顺序为中间在前、根在后；用 cat intermediate.pem root.pem > cacert.pem 拼接，别手动编辑
改完 php.ini 后，重启 PHP-FPM 或 Web 服务器（如 nginx）才能生效

composer config ssl.cafile 配了却没用，为什么

因为 composer config ssl.cafile 是 Composer 2.2 引入的兼容性字段，仅在部分场景下被读取，且优先级低于 PHP 原生配置。从 2.5 开始，它不再直接透传给 cURL，而是尝试用于初始化 OpenSSL 上下文——一旦路径错、格式错或权限不足，就静默忽略，退回到系统默认 CA。

所以你看到“配了没用”，大概率是以下之一：

composer config --global ssl.cafile /path/to/ca.pem 写的是项目级路径（比如 ./ca.pem），而全局命令运行时工作目录不是项目根
PHP 进程（如 www-data）无权读取该文件，尤其在 Docker 或 systemd 服务中
文件里混入了 Windows 换行符、BOM 或注释行，导致 OpenSSL 解析失败
你用的是 Alpine Linux 镜像，但没运行 update-ca-certificates，系统 CA 目录为空

实操建议：

优先放弃 ssl.cafile，直接改 php.ini：openssl.cafile = /etc/ssl/certs/company-ca.pem 和 curl.cainfo = /etc/ssl/certs/company-ca.pem
验证是否加载成功：php -i | grep -E "(openssl|curl).*ca"
在 Docker 中，确保 COPY 证书文件并 RUN chmod 644 /etc/ssl/certs/company-ca.pem

私有仓库用了自签名证书，能绕过校验吗

不能，也不该绕过。Composer 没有 --insecure 或 disable-tls 这类开关。设 "config": {"disable-tls": true} 会直接破坏 signature 验证链，导致 signature verification: FAIL，安全机制彻底失效。

真正可行的路径只有一条：把自签名证书的根 CA 加入信任链。注意不是加“自签名证书本身”，而是它的签发者（即你公司内网 PKI 的根 CA）。

实操建议：

拿到根 CA 证书（.crt 或 .pem），确认是 PEM 格式：head -n 1 your-ca.crt 应输出 -----BEGIN CERTIFICATE-----
如果只有 DER 格式（.cer），转成 PEM：openssl x509 -inform DER -in your-ca.cer -outform PEM -out ca.pem
不要试图用 openssl s_client -connect your-repo.com:443 -showcerts 抓下来的证书——那是服务端证书，不是根 CA
若私有仓库由 Nginx 反向代理，确保 Nginx 的 ssl_trusted_certificate 也指向同一根 CA 文件，否则浏览器访问都可能报错

GitLab/GitHub 私有仓库走 HTTPS，需要额外配证书吗

不需要。GitHub 和 GitLab 官方域名（github.com、gitlab.com）使用的是公共可信 CA（如 DigiCert、Let’s Encrypt）签发的证书，只要系统或 PHP 的 CA bundle 是最新的，就天然受信。

你唯一要配的是认证凭证，不是证书：

GitHub：用 composer config --global github-oauth.github.com <token></token>
GitLab：用 composer config --global gitlab-oauth.gitlab.com <token></token>
若用自托管 GitLab（如 gitlab.example.org），那就回归上一节——配好该域名对应的根 CA

容易被忽略的一点：如果你的私有 GitLab 实例启用了 mTLS（客户端证书双向认证），Composer 无法支持。它不会发送客户端证书，连接必然失败。这种场景下，必须关掉 GitLab 的 ssl_client_certificate 和 ssl_verify_client 配置，改用 OAuth 或 HTTP Basic 认证。