curl是Ubuntu命令行下最常用的HTTP请求工具之一，无论是调试接口、下载文件还是编写脚本，都离不开它。但当请求的目标是HTTPS站点时，不少用户会遇到各种SSL错误，比如SSL certificate problem: unable to get local issuer certificate或者certificate verify failed。这些错误本质上都是TLS握手阶段的证书验证失败，原因可能出在系统证书库、系统时间、curl编译参数等多个环节。本文将从原理入手，逐一分析常见的错误场景并给出可操作的修复方案。
一、为什么curl会报SSL错误：先理解证书验证流程
当curl访问一个HTTPS地址时，客户端和服务器会先完成TLS握手。在这个过程中，服务器会把自己的证书链发送给curl，curl则使用本地的CA证书库（通常位于/etc/ssl/certs目录）去验证这张证书是否由受信任的证书颁发机构签发、是否过期、域名是否匹配。只要其中任何一个环节出问题，curl就会中断连接并抛出SSL错误。
理解这个流程之后，排查思路就清晰了。常见的失败原因可以归纳为四类：第一，系统缺少或丢失CA证书库，比如新装的精简版系统没有安装ca-certificates包；第二，证书库太旧，不包含新签发的根证书；第三，系统时间不准确，导致证书被认为还未生效或已经过期；第四，目标站点证书链配置不完整，服务器没有下发中间证书。
可以先运行下面的命令确认当前curl的SSL后端和证书路径，这一步能快速判断证书库配置是否正常：
curl -V # 输出中关注两行： # curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 # Protocols: dict file ftp ftps gopher http https ... # 如果使用OpenSSL后端，证书路径一般是 /etc/ssl/certs
二、安装和更新系统CA证书库
绝大多数unable to get local issuer certificate错误，都是因为系统CA证书库缺失或过旧。Ubuntu通过ca-certificates软件包管理这套证书，修复方法很简单，先更新软件源再安装或升级该包：
sudo apt update sudo apt install --reinstall ca-certificates sudo update-ca-certificates -f
update-ca-certificates命令会扫描/usr/share/ca-certificates目录下的证书文件，并把它们链接到/etc/ssl/certs中，同时更新/etc/ssl/certs/ca-certificates.crt这个合并后的证书束。如果命令输出显示证书数量为0或者目录为空，说明证书库确实损坏了，重装即可恢复。
还有一种情况是企业内网使用了自签名的网关证书，比如公司代理、内部Git服务器、私有Harbor镜像仓库等。这类证书不在公共CA体系内，即使证书库最新也无法验证。解决办法是把企业根证书复制到信任目录并刷新：
# 假设企业根证书为 company-root.crt sudo cp company-root.crt /usr/local/share/ca-certificates/company-root.crt sudo update-ca-certificates
注意/usr/local/share/ca-certificates目录要求证书为PEM格式且扩展名必须是.crt，否则不会被识别。执行成功后会看到提示1 added，之后再访问内网服务就不会报错了。
三、检查系统时间与证书有效期
系统时间错误是容易被忽视的一个原因。TLS证书都有明确的起止时间，如果Ubuntu的系统时钟和真实时间偏差较大，比如虚拟机挂起后恢复导致时间停滞，curl就会认为证书尚未生效或已经过期，报出certificate has expired或not yet valid之类的错误。
先用date命令确认当前时间是否准确，偏差超过几分钟就需要同步。推荐安装并启用NTP时间同步服务：
timedatectl status sudo timedatectl set-ntp true # 如果时区不对，先调整时区 sudo timedatectl set-timezone Asia/Shanghai
如果错误提示是目标网站的证书真的过期了，那是服务器端的问题，客户端无法修复。可以借助OpenSSL命令查看目标站点的证书详情辅助判断：
openssl s_client -connect ippipp.com:443 -servername ippipp.com </dev/null 2>/dev/null | openssl x509 -noout -dates
四、其他常见错误场景与应对方法
除了证书库和时间问题，还有一些场景值得单独说明。第一种是SSL certificate problem: self signed certificate，说明目标站点直接使用了自签名证书。临时调试时可以用-k或--insecure参数跳过验证，但千万不要在脚本中依赖这个选项，因为跳过验证意味着连接可能被中间人攻击劫持，失去了HTTPS的意义。正确的做法是像前文那样把该证书加入信任列表。
第二种是TLS协议版本问题，报错类似OpenSSL SSL_connect: SSL_ERROR_SYSCALL或tlsv1 alert protocol version。旧版curl可能不支持服务器要求的TLS 1.2以上版本，可以显式指定协议测试：
curl --tlsv1.2 https://ippipp.com # 查看curl支持的TLS版本 curl -V | grep -o 'TLS.*'
第三种是通过环境变量或配置指定证书文件的情况。有些脚本会设置CURL_CA_BUNDLE环境变量指向一个不存在的文件，或者~/.curlrc中写了错误的cacert配置，都会导致验证失败。可以用env | grep -i curl检查相关变量，排查配置文件的干扰。
最后提醒一点，如果是在PHP、Python等程序内部调用curl相关函数报错，除了上述系统层面的修复，还可能需要重启对应的PHP-FPM或应用进程，因为它们在启动时就把证书库加载进了内存，不重启不会生效。按照以上步骤逐层排查，Ubuntu下的curl SSL错误基本都能得到彻底解决。
Ubuntu curl SSL错误SSL证书验证失败curl错误修复修改时间：2026-09-01 15:36:30