composer连接私有库提示ssl certificate problem，是因自签名证书不被系统ca信任；解决方法是通过composer.json中repositories的options.ssl.cafile指定pem证书路径，或全局配置cafile，确保路径有效、权限正确、内容纯净且包含完整证书链。
Composer连接私有库时提示SSL certificate problem
这是最常见现象：Composer用curl或PHP的stream_context发起HTTPS请求时，发现私有库的自签名证书不被系统CA信任，直接中止。它不会自动降级或跳过验证——这是安全设计，不是bug。
解决思路不是“关掉SSL”，而是让Composer明确知道该信任谁。关键在两处配置：
-
composer.json里为仓库指定options，传入sslcapath或sslcafile - 或全局配置
cafile路径（推荐用于团队统一环境）
注意：sslcapath必须是OpenSSL格式的目录（含c_rehash生成的符号链接），而sslcafile可直接指向单个PEM文件，对私有库更实用。
repositories中配置sslcafile参数
只影响该私有库，隔离性好，适合多私有源混合场景。但必须确保路径在所有运行Composer的机器上都有效（比如CI/CD节点、开发者本地）。
示例（composer.json片段）：
{
"repositories": [
{
"type": "composer",
"url": "https://repo.internal.example.com",
"options": {
"ssl": {
"cafile": "/etc/ssl/certs/internal-ca.pem"
}
}
}
]
}
常见错误：
- 路径写相对路径（如
./certs/internal.pem）——Composer不解析当前目录，会报failed to open stream - 证书文件权限不对（如600但Web服务器用户无读权限），静默失败
- PEM文件里混入了非证书内容（如注释、空行、多余文本），导致解析失败
全局设置cafile避免重复配置
如果所有私有库都用同一CA签发，用全局配置更省事。执行命令一次，后续所有composer install/update自动生效：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer config -g cafile /etc/ssl/certs/internal-ca.pem
这个值会写入~/.composer/config.json的config.cafile字段。效果等同于每个仓库都加了ssl.cafile，但优先级更低（仓库级配置会覆盖全局）。
性能与兼容性注意点：
- PHP 7.3+ 和 Composer 2.0+ 支持此字段；旧版本需改用
openssl.cafileini 设置 - 若同时设了
cafile和系统CA路径（如/etc/ssl/certs），Composer会合并两者，不是替换 - CI环境中务必确认
composer config -g执行用户与运行Composer的用户一致（比如GitLab Runner用gitlab-runner用户）
验证证书是否真被加载
光配完不验证，很容易以为好了，结果包拉不下来。最直接的方法是加-v参数看详细日志：
composer update -v 2>&1 | grep -i "cafile\|certificate"
你会看到类似Using custom CA bundle: /etc/ssl/certs/internal-ca.pem的输出。没这句？说明配置没生效。
另一个硬核验证法：临时把cafile指向一个不存在的路径，再跑composer update——如果报错变成Unable to locate peer certificate之类，说明路径已被识别；如果还是原来的SSL certificate problem，那就是配置压根没读到。
最容易被忽略的是证书链完整性：自签名CA没问题，但如果私有库用的是中间CA签发的证书，必须把整个链（根CA + 中间CA）都放进cafile，顺序无所谓，但缺一不可。
