根本原因是系统CA证书库过旧导致HTTPS验证失败；应优先更新ca-certificates包，重建证书索引，并校准Python证书路径，而非禁用SSL验证。
宝塔面板安装脚本报错 certificate verify failed
根本原因是系统内置的 CA 证书库过旧（尤其是 CentOS 6/7、Ubuntu 16.04 或某些精简版镜像），而宝塔的安装脚本（install.sh）通过 HTTPS 请求其 API 时，无法验证新签发的 TLS 证书链，直接中断执行。
这不是宝塔的问题，而是系统级信任链缺失。别急着换源或关 SSL 验证——临时禁用校验（如加 --no-check-certificate）可能跳过关键安全检查，且新版宝塔已限制该参数生效。
- 先确认错误是否真实由证书引起：运行
curl -I https://download.bt.cn，若返回curl: (60) SSL certificate problem，即为根证书问题 - 优先尝试更新系统 CA 包：
yum update ca-certificates（CentOS/RHEL）或apt-get update && apt-get install --reinstall ca-certificates（Ubuntu/Debian） - 若仍失败，说明系统自带证书库已严重滞后（如 OpenSSL 版本
手动导入 Mozilla 根证书到系统信任库
宝塔使用 Let’s Encrypt 签发的证书，其根证书（如 ISRG Root X1）未被老系统收录。直接下载并合并到系统 CA 包是最稳妥方式。
- 下载最新 Mozilla CA 包：
curl -o /tmp/cacert.pem https://curl.se/ca/cacert.pem - 追加到系统默认证书文件（路径因系统而异）：
– CentOS/RHEL：cat /tmp/cacert.pem >> /etc/pki/tls/certs/ca-bundle.crt
– Ubuntu/Debian：cat /tmp/cacert.pem >> /etc/ssl/certs/ca-certificates.crt - 重建证书索引（关键！否则部分工具不识别）：
update-ca-trust（CentOS 7+/RHEL）或update-ca-certificates（Debian/Ubuntu） - 验证是否生效：
openssl s_client -connect download.bt.cn:443 -servername download.bt.cn 2>/dev/null | grep "Verify return code"，输出应为Verify return code: 0 (ok)
宝塔安装脚本仍报错？检查 Python 的证书路径
部分系统中，宝塔安装脚本实际由 Python 执行（尤其在有多个 Python 版本时），而 Python 可能未使用系统 CA 路径，导致前面操作无效。
- 查 Python 当前信任路径：
python -c "import ssl; print(ssl.get_default_verify_paths())"，重点关注cafile和capath - 若
cafile指向一个不存在或陈旧的文件（如/etc/ssl/cert.pem），可软链过去：ln -sf /etc/pki/tls/certs/ca-bundle.crt /etc/ssl/cert.pem（CentOS） - 或强制 Python 使用系统路径（临时）：
export SSL_CERT_FILE=/etc/pki/tls/certs/ca-bundle.crt，再运行宝塔安装命令 - 注意：Python 2.7.9+ 和 Python 3.4+ 默认启用证书验证，低于此版本需升级 Python 或打补丁，不建议硬绕过
跳过证书校验不是长久之计
有人用 sed -i 's/curl -sS/curl -k -sS/g' install.sh 强行绕过验证，短期能装上，但隐患明显：
- 后续面板自动更新、插件下载、SSL 申请等所有 HTTPS 请求都失去证书校验，中间人攻击风险上升
- 新版宝塔（如 8.0+）已对
-k参数做拦截，修改脚本可能直接退出 - 同一台服务器若运行其他 Python/Node.js 服务，它们也会继承不安全的全局设置，影响面远超面板本身
真正省事的做法，是一次性把系统 CA 库和 Python 证书路径对齐，之后所有 HTTPS 工具（curl、wget、pip、requests）都自然生效。老系统维护成本高，但安全基线不能妥协。
