若要跳过 cURL 的 SSL/TLS 证书验证，可以使用 `-k` 或 `--insecure` 选项。此外，您也可以在 `.curlrc` 文件中添加 `insecure` 配置，或者在代码中禁用 SSL 证书验证。这样做会指示 cURL 即使无法验证服务器证书，也继续执行请求。
不过，请务必仅在信任服务器且了解验证失败原因的情况下，才忽略 SSL 证书错误。
本文将解释 cURL 出现 SSL 证书错误的原因，演示如何在必要时跳过 SSL 证书验证，并介绍一些无需禁用此安全检查即可解决问题的更安全方法。
cURL 中 SSL 的工作原理及失败原因
如果控制台显示 SSL 证书验证错误，说明 cURL 无法验证目标服务器提供的证书，也无法确认该服务器的身份确实如其所声称的那样。导致此 SSL 错误的原因可能有以下几种：
- 服务器证书可能已过期。
- 该证书可能是自签名的，这意味着它是由创建该证书的同一组织签名的，而非由 cURL 信任的第三方权威机构签发。
- 该证书签发时所针对的域名，可能与 cURL 尝试访问的域名不符。
- 证书链可能不完整，导致 cURL 无法将该证书追溯至受信任的根证书颁发机构。
- 有时，SSL 证书问题出在您这一端。您使用的 cURL 程序可能缺失了验证证书所需的信任信息，或者无法找到这些信息。
话虽如此，这个错误并非随机出现。它意味着 cURL 拒绝连接到那些其证书无法建立信任关系的服务器。一旦了解了 cURL 无法完成验证的原因，你就可以决定是修复证书问题，还是有意绕过该验证。
在 cURL 中绕过 SSL 证书验证的方法
在 cURL 中绕过 SSL 证书验证主要有三种方式：使用 `-k` 或 `--insecure` 选项、修改 cURL 配置，或者在代码中禁用验证。
具体选择哪种方法，取决于您是否信任目标对象，以及您是需要一次性的临时解决方案，还是希望该设置能更广泛地生效。
使用 -k 或 --insecure 选项
以下是基本语法：
curl -k https://example.com
或者
curl --insecure https://example.com
`-k` 或 `--insecure` 选项仅适用于当前执行的 cURL HTTPS 请求。它不会永久更改 cURL 的设置，因此下次在不使用该选项的情况下运行 cURL 时，SSL 证书验证将照常进行。不过，如果在同一个 cURL HTTPS 请求中包含多个 URL，则 `-k` 或 `--insecure` 选项将适用于所有这些 URL。
通过代理路由请求需要进行一些额外的设置。请参阅我们关于在 cURL 中使用代理的指南，了解如何配置代理、进行身份验证以及排查相关问题。
修改 cURL 配置文件（.curlrc 方法）
与其每次都使用 `-k` 选项，不如将 `insecure` 添加到 cURL 配置文件中；这样一来，cURL 在执行所有命令时都会自动跳过验证检查。具体操作如下：
在 Linux 和 macOS 系统上，请在主目录（home directory）下创建一个名为 `.curlrc` 的文件。你可以通过终端按如下方式创建该文件：
touch ~/.curlrc
然后用文本编辑器打开它，并添加：
insecure
保存文件。
在 Windows 上，在 PowerShell 中运行此命令：
notepad "$HOME\.curlrc"
然后加入：
insecure
保存文件。
请注意，此设置适用于后续使用该配置文件的 cURL 命令，因此在操作完成后，请移除那行不安全的配置。
在代码中禁用 SSL 验证
如果您使用 PHP 或 Python 发起请求，可以指示 HTTP 客户端不验证服务器证书。例如，假设您有一个 PHP 应用程序，它使用 cURL 调用正在构建的网站的预发布（staging）服务器，而该服务器使用的是自签名证书或本地环境不信任的证书。
您可以进行如下设置：
CURLOPT_SSL_VERIFYPEER => false
这样，请求就会在不验证证书的情况下继续进行。
或者，你可能正在使用 Python 的 `requests` 库从内部 API 或开发环境端点抓取数据，而该端点使用的证书因某种原因无效。
你可以进行如下设置：
requests.get("https://example.com", verify=False)
且 Python 不会验证该请求的服务器证书。
如果您直接从终端发起 API 调用，请参阅我们的 cURL API 请求指南，其中涵盖了请求方法、身份验证、标头及故障排查等内容。
忽略 SSL 证书验证的安全风险
如前所述，您设备上可能失败的 SSL 证书验证，是 cURL 用来确认其通信对象确实是目标服务器的机制。一旦禁用该验证，cURL 便无法确认连接另一端的身份，从而增加了遭受中间人攻击（MITM）的风险。
此类攻击正如其名称所示：在没有 SSL 证书验证的情况下，攻击者可以置身于您与目标服务器之间。因此，原本的情况是：
You → real server
您将获得：
You → attacker → real server
危险之处在于，双方看起来似乎仍在正常通信。攻击者接收你的请求并将其转发给真正的服务器，随后接收服务器的响应并将其转发回给你。这会引发两类问题：
- 拦截：处于中间位置的攻击者可以读取您发送的请求。因此，如果您在请求中包含 API 密钥、Bearer 令牌、登录凭证、会话 Cookie 或任何私密信息，攻击者便能获取这些信息。
- 完整性：由于攻击者处于中间位置，他们不仅能看到来自服务器的响应，还能在转发前对其进行修改。对您的系统而言，这看起来可能仍然像是一个有效的响应。
这就是为什么了解何时禁用 cURL 验证以及何时不这样做很重要。它在以下情况下很有用：
- 测试本地或开发服务器
- 在受控环境中使用已知的自签名证书
- 排查您所掌控的基础设施上的证书问题
在以下情况下，这可能不是个好主意：
- 发送密码、API 密钥或会话数据
- 发起生产环境请求
- 连接到非您掌控的网络
- 处理证书存在您无法理解的问题的服务器
如果你了解 SSL 验证失败的原因，并且能够控制运行环境，那么暂时绕过验证或许是合理的做法。但如果你不清楚证书为何不受信任，最好是解决信任问题，而不是直接忽略警告。
如何安全地处理 cURL 中的 SSL 问题
那么，该如何解决这个问题呢？
如果服务器证书本身有误
如果 cURL 提示证书已过期，您就需要更新该证书。前提是您拥有对目标服务器的控制权。请通过您的主机服务商、证书颁发机构或服务器配置来更新或更换证书，然后重试。
如果证书签发时使用的主机名有误，或者证书链不完整，则需要在服务器端解决这些问题。
如果 cURL 不知道该信任谁
如果 cURL 不知道该信任谁，请为其提供正确的 CA 证书。假设您拥有正确的证书：
company-ca.pem
与其这样做：
curl -k https://api.internal.example
你可以这样做：
curl --cacert company-ca.pem https://api.internal.example
践行安全开发
在使用 cURL 跳过 SSL 证书验证检查时，请记住以下几点建议：
- 避免在生产环境中使用 `--insecure`。仅在您可控的测试环境中使用它。
- 仅临时绕过 SSL 证书验证。如果您在 `.curlrc` 文件中添加了该选项，请在查明 SSL 问题原因或完成向服务器发送请求后将其移除。
- 尽可能优先解决信任问题。如果您能控制服务器或知道应信任哪个 CA（证书颁发机构），最好使用 `--cacert` 或配置正确的 CA 证书库，而不是直接忽略 SSL 证书检查。
- 处理凭据时务必格外小心。在禁用证书验证的情况下，切勿发送 API 密钥、密码、Cookie、令牌或其他敏感信息。
- 保持开发环境与生产环境相互隔离。像 `--insecure` 这样的开发阶段变通方案，绝不应出现在生产环境的脚本或部署配置中。
- 切勿盲目复制来源不可信的 cURL 配置或命令。这些配置或命令可能会指示 cURL 将本地数据或文件发送到您未预期的位置。
结论
总而言之，你可以通过使用 `--insecure` 选项在 cURL 中跳过 SSL 验证。此外，你也可以在 `.curlrc` 文件中配置 cURL 自动忽略验证，或者在 Python 或 PHP 中通过设置 HTTP 客户端不验证服务器证书来实现这一点。
然而，这样做会增加风险，可能导致攻击者在通信双方之间实施“中间人攻击”，从而窃取或篡改传输的数据。因此，仅当你信任目标服务器时，才应跳过验证。如果你拥有该服务器的控制权，应着重解决证书问题，而不是简单地绕过验证。