curl: (60) SSL证书错误：自签名证书不被信任

Question

在使用curl访问内部HTTPS服务时，常遇到“curl: (60) SSL certificate problem: self-signed certificate”错误。这是由于服务器使用了自签名证书，而curl默认启用SSL证书验证，无法通过CA信任链校验该证书，导致请求被拒绝。此问题多见于企业内网、开发测试环境或私有API网关场景。虽然可通过`-k`或`--insecure`参数临时绕过验证，但会降低通信安全性。理想解决方案是将自签名证书添加至系统或curl的受信任根证书库，或配置`--cacert`指定本地证书文件，以实现安全且稳定的HTTPS通信。

Answer 1

1. 问题背景与现象分析

在企业内网、开发测试环境或私有API网关中，HTTPS服务常采用自签名证书以降低部署成本。然而，当使用curl访问此类服务时，常出现如下错误：

curl: (60) SSL certificate problem: self-signed certificate

该错误表明curl在执行SSL/TLS握手过程中，无法验证服务器证书的可信性。默认情况下，curl依赖操作系统的CA信任链进行证书校验，而自签名证书未被任何公共CA签发，因此不在信任列表中，导致连接中断。

2. 常见临时解决方案及其风险

• -k 或 --insecure：跳过SSL证书验证，适用于调试场景。
• 适用命令示例：

  curl -k https://internal-api.example.com

• 风险提示：此方式完全关闭证书校验，易受中间人攻击（MITM），不应在生产环境或自动化脚本中长期使用。

3. 深入理解证书验证机制

curl的SSL后端通常依赖于OpenSSL、GnuTLS或BoringSSL等库，其证书验证流程如下：

1. 客户端发起HTTPS请求，服务器返回证书链。
2. 客户端检查证书有效期、域名匹配及是否由可信CA签发。
3. 若证书为自签名，且未被显式信任，则验证失败。
4. 操作系统或curl配置的CA bundle文件（如/etc/ssl/certs/ca-certificates.crt）决定信任锚点。

4. 可行的长期解决方案

方案	适用场景	安全性	维护成本
--cacert 指定证书	单次调用或脚本化访问	高	低
系统级CA证书注入	多服务共享信任	高	中
使用私有PKI体系	大规模内网部署	极高	高

5. 方案一：使用 --cacert 显式指定证书

将自签名证书导出为PEM格式，并通过--cacert参数告知curl使用该证书进行验证。

# 获取服务器证书（以OpenSSL为例）
echo | openssl s_client -connect internal-api.example.com:443 2>/dev/null | openssl x509 > internal-ca.pem

# 使用curl指定CA证书
curl --cacert ./internal-ca.pem https://internal-api.example.com

6. 方案二：将证书添加至系统信任库

以Ubuntu/Debian系统为例，可将自签名证书安装至系统CA存储：

sudo cp internal-ca.pem /usr/local/share/ca-certificates/
sudo update-ca-certificates

此后所有依赖系统CA bundle的应用（包括curl）将自动信任该证书。

7. 方案三：构建私有公钥基础设施（PKI）

对于大型企业或微服务架构，建议部署私有CA（如使用Hashicorp Vault或EasyRSA），统一签发和管理内部服务证书。流程图如下：

graph TD
    A[私有根CA] --> B[签发中间CA]
    B --> C[签发服务端证书]
    C --> D[部署至API网关]
    D --> E[curl 配置 --cacert 根CA]
    E --> F[安全通信建立]

8. 自动化与DevOps集成建议

在CI/CD流水线中，可通过以下方式提升安全性与可维护性：

• 将内部CA证书作为密文注入Kubernetes Secrets或Hashicorp Vault。
• 在Pod启动时挂载并更新容器内CA store。
• 使用Ansible/Puppet批量部署证书至边缘节点。
• 监控证书有效期，提前触发轮换机制。