答案是default_cert_file路径需通过php -r "print_r(openssl_get_cert_locations());"命令输出确定,它是所有SSL证书问题排查的起点;该路径若为空、不存在、不可读或过期,将直接导致Composer等HTTPS请求失败。

php -r "print_r(openssl_get_cert_locations());" 输出的 default_cert_file 是哪条路径?
这是所有排查的起点。Composer 本身不管理证书,它完全依赖 PHP 底层 OpenSSL/cURL 的配置。运行该命令后,重点看 default_cert_file 和 ini_cafile 两个字段:
- 如果两者为空或指向不存在的文件(
ls -l /path/to/file报错),说明 PHP 根本没加载任何 CA 文件 - 如果文件存在但权限是
777,PHP 会拒绝读取(OpenSSL 安全策略) - 如果文件最后修改时间早于 2022 年,大概率含已吊销的
DST Root CA X3,无法验证 ISRG Root X1 签发的新证书 - macOS 上 Homebrew PHP 常见坑:
default_cert_file指向/usr/local/etc/openssl@3/cert.pem,但该文件可能为空或过期
cURL error 60: SSL certificate problem: self signed certificate 怎么确认是自签名还是链缺失?
错误信息里带 self signed certificate,不代表你真用了自签名服务——更可能是中间证书缺失,导致 OpenSSL 认为“叶证书没上级”,误判为自签。
- 用
curl -v https://packagist.org/packages.json看完整握手过程:若在* Server certificate:后只显示一个证书(无subject/issuer匹配),就是链不全 - 对比
curl -v https://mirrors.aliyun.com/composer/packages.json:如果官方源 OK、镜像源报错,说明镜像服务器配置了不完整的证书链(常见于企业私有镜像) - 临时验证是否链问题:
curl --cacert /path/to/full-chain.pem https://your-mirror.com/packages.json,用含完整链(根→中间→叶)的 PEM 文件测试
cafile 配置写对了,为什么 composer install 还是走旧证书?
写了 curl.cainfo 和 openssl.cafile 却无效,90% 是因为改错了 php.ini 或没重启环境。
工作流任务拆解与模型编排技能。使用场景:(1) 收到复杂工作任务需要拆解为可执行步骤,(2) 需要为不同步骤选择最合适的模型,(3) 需要跟踪工作流进度和模型使用情况,(4) 长时间任务卡住需要问题诊断和解决方案。
- CLI 和 Web SAPI 加载的是不同 php.ini:
php --ini显示的是 CLI 路径;phpinfo()页面里找 “Loaded Configuration File” 才是 Web 环境路径 - Windows 下路径必须用正斜杠或双反斜杠:
openssl.cafile="C:/php/extras/ssl/cacert.pem",单反斜杠C:\php\...会被 PHP 当作转义序列解析失败 - 改完必须重启:CLI 用户需新开终端;Apache 要
sudo apachectl restart(reload不重读 php.ini);Docker 容器得重建,不是docker exec里改了就生效 - 验证是否生效:
php -r "echo ini_get('curl.cainfo');"和php -r "echo ini_get('openssl.cafile');"必须输出你写的绝对路径
只能临时解决时,该用 --no-secure-http 还是 cafile=/dev/null?
二者效果不同,适用场景也不同:
-
--no-secure-http只禁用 HTTP 协议降级警告,**不绕过 SSL 证书校验**,对cURL error 60完全无效 -
composer config -g cafile /dev/null(Linux/macOS)或composer config -g cafile NUL(Windows)才会让 Composer 强制跳过证书验证——但仅限composer命令本身,不影响file_get_contents等其他 PHP 函数 - CI 环境中更推荐显式指定证书:
composer config -g cafile /certs/company-root.crt,而不是关验证——后者会让所有 HTTPS 请求失去信任锚点 - 容器内若用 Alpine,系统默认无 CA bundle,
apk add ca-certificates后再update-ca-certificates,比单独配cafile更彻底
证书路径、文件内容、权限、环境重启,四者缺一不可。最容易被忽略的是:你以为改了 php.ini,其实改的是 Apache 加载的那个,而你在终端跑的是 CLI 版本。

















