根本原因是php openssl扩展未启用，需通过php -m | grep openssl和php -i | grep "openssl support"验证运行时是否加载成功，并确认cli与web使用的php.ini路径一致、extension=openssl已取消注释、依赖dll存在且extension_dir正确。
Composer 报错 “cURL error 60: SSL certificate problem” 或直接提示无法连接 HTTPS 源，大概率是 PHP 的 openssl 扩展没启用，不是证书或网络问题。
确认 openssl 扩展是否真的加载了
别只看 php.ini 里有没有 extension=openssl，得验证运行时是否生效：
- 执行
php -m | grep openssl，无输出即未加载 - 执行
php -i | grep "OpenSSL Support"，返回OpenSSL Support => disabled同样说明失败 - 常见坑：CLI 和 Web（如 Apache/Nginx）用的是两套 php.ini，
php -i显示的Loaded Configuration File路径必须和你编辑的配置文件一致
Windows 下启用 openssl 的关键步骤
多数报错发生在 Windows + PHP 官方二进制包环境：
- 确保
php.ini中取消注释：extension=openssl（不是extension=php_openssl.dll） - 检查
extension_dir路径是否正确，例如extension_dir = "ext"，且该目录下存在php_openssl.dll - 确认系统 PATH 包含 PHP 目录，并且
libssl-1_1-x64.dll和libcrypto-1_1-x64.dll（或对应版本）在 PHP 目录下——缺失这两个 DLL 会导致扩展加载静默失败 - 改完后必须重启命令行终端（CMD/PowerShell），否则
php -v仍读旧配置
Linux/macOS 下 openssl 加载失败的典型原因
不是“没装 openssl”，而是 PHP 编译时没链接对库，或运行时找不到符号：
- Debian/Ubuntu：装
php-curl和php-openssl包（如sudo apt install php-openssl），而非只装openssl - CentOS/RHEL：用
php-opcache同源仓库，确认php --modules输出含openssl - 源码编译 PHP 时漏了
--with-openssl参数，或指定路径错误（如--with-openssl=/usr/local/ssl但实际在/usr） - Docker 环境常因 Alpine 使用
musl而不兼容预编译的 OpenSSL 扩展，建议换debian:slim基础镜像
绕过 SSL 验证只是临时调试手段
用 composer config -g secure-http false 或加 --no-verify-peer 可跳过证书校验，但不能解决根本问题：
- 这会让 Composer 降级走 HTTP，可能被中间人劫持、下载被篡改的包
- 某些私有源（如 Satis、Artifactory）强制 HTTPS，此设置无效
- PHP 8.2+ 已废弃
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false)，部分新版 Composer 会直接报错拒绝执行 - 真正要跑通 CI/CD 或生产部署，必须修复 openssl 扩展，而不是屏蔽验证
最常被忽略的是：扩展名写错（openssl ≠ php_openssl）、DLL 依赖缺失、CLI 与 Web 配置不一致——先盯死 php -i | grep "Loaded Configuration File" 这一行，再动其他。
