技术 · 实用指南
curl 报错 60？使用 --insecure 前先审计证书链与信任库
“unable to get local issuer certificate”并不对应一个通用修复。先记录 curl 的 TLS 后端、CAfile、CApath 与代理路径，再修复服务器证书链、客户端信任输入或检查代理。
curl 错误 60 是验证失败，不是关闭验证的命令。缺失环节可能在服务器提供的链、curl 选择的信任输入、应用专用证书包或 TLS 检查代理。
按端点、证书链、后端、信任输入、修复的顺序审计；证据决定应修服务器、安装已核验的私有 CA、选择预期的系统/文件信任库，还是修复代理信任。
冻结失败端点与 curl 构建信息
修改信任前记录准确 URL、主机、端口、用户环境、代理变量和完整错误。运行 curl -V 记录版本与 TLS 后端，再用 curl -v 保存 CAfile、CApath、连接目标和 CONNECT 代理；可删凭据，但不要删颁发者和路径。浏览器成功只说明浏览器找到了可信链。
必须在实际失败的 shell、容器或服务账号中复现。root、桌面用户、PHP、Git 与 Composer 可能读取不同配置。若 -k 能成功，只能说明验证是边界；立即移除它，curl 官方明确反对生产环境跳过验证。
检查端点实际提供的证书链
针对准确主机和端口（含 SNI）检查链，记录叶证书主题、颁发者和服务器发送的中间证书。公共站点漏发中间证书属于服务端部署问题：补全链后用干净客户端复测，不要把叶证书当根信任。
若安全设备终止 TLS，颁发者可能属于组织而非公共站点。结合 curl -v、环境变量和颁发者证明路径。curl 将 HTTPS 代理信任与源站信任分开，代理 CA 参数只控制代理连接。
证明此 curl 构建使用哪一份信任输入
curl 同时验证签名链和主机名。Schannel 构建通常使用 Windows 原生 CA 库；许多其他后端默认用文件库。检查 CURL_CA_BUNDLE、SSL_CERT_FILE、SSL_CERT_DIR、应用配置和容器挂载，再考虑替换系统证书包。
--cacert 只应指向已核验的 PEM CA 文件，--capath 目录必须正确准备；构建支持且策略要求时使用 --ca-native。Apple 平台可组合 --ca-native 与 --cacert，但行为仍取决于构建。
应用最小且可验证的修复
服务器漏链就修服务端。若确实需要私有或企业 CA，应通过已认证渠道核验指纹和所有者，再在最小范围内信任。Ubuntu 记录的是把 .crt PEM 放入 /usr/local/share/ca-certificates 后运行 update-ca-certificates；Red Hat 使用自己的 anchors 目录和 update-ca-trust。
若只有一个应用失败，修它的 CA 路径，不要扩大系统信任。若只有 HTTPS 代理失败，使用代理专用 CA 控制。颁发者出乎预期时停止并升级处理，不要直接导入。
复测验证范围与回滚
不带 -k 和临时覆盖复测，在详细输出中确认主机名、颁发者、后端和 CA 来源，再测试真实应用与干净环境。一次性 --cacert 成功只证明该文件能验证对端，不保证 PHP、Git、容器或服务会读取它。
记录失败证据、准确的信任改动、CA 所有者、到期日和回滚命令。服务端修复要跨多个干净客户端验证；私有锚点也要验证删除流程。保持验证开启，让下一个意外颁发者仍然可见。
