curl: (60) SSL证书错误：测热体地擦特ch使用自签名证书

Question

在使用curl访问测热体地擦特ch（如内网监测设备或自建服务）时，常因该系统采用自签名SSL证书而触发“curl: (60) SSL certificate problem: self-signed certificate”错误。此问题源于curl默认启用SSL证书验证，而自签名证书未被系统信任链所包含，导致连接中断。常见于开发测试环境或私有部署的物联网设备中。开发者试图通过脚本自动化获取数据时，会因此无法完成HTTPS请求，影响集成与调试进度。解决方式包括：临时忽略验证（使用`-k`或`--insecure`参数）、将自签名证书添加至本地信任库，或通过`--cacert`指定证书路径。虽`-k`选项便捷，但存在中间人攻击风险，不推荐生产环境使用。正确管理自签名证书的信任关系，是保障通信安全与服务可用性的关键平衡点。

Answer 1

1. 问题背景与常见场景

在使用 curl 访问内网监测设备或自建服务（如测热体地擦特ch系统）时，开发者常遇到如下错误：

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

该错误表明 curl 在发起 HTTPS 请求时，无法验证目标服务器的 SSL 证书。其根本原因在于：现代版本的 curl 默认启用严格的 SSL/TLS 证书验证机制，而许多私有部署系统（尤其是物联网设备、测试平台或内部监控系统）采用的是自签名证书（self-signed certificate），这类证书未被操作系统或 CA 信任链所认可。

此类问题高频出现在以下场景中：

• 开发与测试环境中搭建的临时 HTTPS 服务
• 企业内网部署的传感器管理平台（如测热体地擦特ch）
• 边缘计算节点或工业控制系统的 Web API 接口
• CI/CD 脚本中调用内部 HTTPS 端点进行健康检查

2. 技术原理剖析：SSL 验证流程与信任链

要深入理解此问题，需掌握 HTTPS 的证书验证机制。当客户端（如 curl）连接到一个 HTTPS 服务时，会执行以下步骤：

1. 服务器返回其 SSL 证书
2. 客户端检查证书是否由受信任的根证书颁发机构（CA）签发
3. 验证证书域名匹配性、有效期及吊销状态（CRL/OCSP）
4. 若任一环节失败，则终止连接并报错

对于自签名证书，由于其既非由公共 CA 签发，也未被本地信任库收录，因此第 2 步验证失败，触发错误代码 60。

Linux 系统通常依赖于 /etc/ssl/certs 目录下的 CA bundle 文件（如 ca-certificates.crt）作为信任锚点。Windows 和 macOS 则分别通过各自的证书存储管理系统维护信任链。

3. 解决方案对比分析

方案	命令示例	安全性	适用环境	维护成本
忽略验证（-k）	curl -k https://device.local	低（存在中间人攻击风险）	临时调试	最低
--cacert 指定证书	curl --cacert /certs/selfsigned.pem https://device.local	高（精确控制信任源）	生产脚本、自动化任务	中等
导入至系统信任库	sudo cp cert.pem /usr/local/share/ca-certificates/ && sudo update-ca-certificates	高（全局生效）	多工具共用场景	较高

4. 实践操作指南

以下是针对不同需求的具体实施方法：

4.1 快速绕过验证（仅限调试）

curl -k --verbose https://thermal-device.internal

使用 -k 或 --insecure 参数可跳过证书验证，适合快速验证接口连通性，但绝不应用于生产环境。

4.2 使用 --cacert 指定可信证书

首先从目标服务器导出其自签名证书：

echo | openssl s_client -connect thermal-device.internal:443 2>/dev/null | openssl x509 > thermal-cert.pem

然后在 curl 中显式引用：

curl --cacert ./thermal-cert.pem https://thermal-device.internal/api/status

此方式实现了最小权限原则，适用于 CI 脚本、Ansible playbook 等自动化流程。

4.3 将证书加入系统信任链

以 Debian/Ubuntu 系统为例：

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

此后所有依赖系统 CA bundle 的程序（包括 curl、wget、Python requests 等）均可正常访问该设备。

5. 安全架构设计建议

在长期运维中，应避免对自签名证书采取“一刀切”的处理策略。推荐采用分层信任模型：

graph TD A[客户端] --> B{请求HTTPS资源} B --> C[目标为公共网站?] C -->|是| D[标准CA验证] C -->|否| E[是否在白名单?] E -->|是| F[使用--cacert加载专用证书] E -->|否| G[拒绝连接或告警] H[定期轮换自签名证书] --> F I[建立内部私有CA] --> H

更优实践是建立企业级私有 CA（Private CA），统一签发设备证书，从而实现集中管理与自动信任，提升整体安全水位。