为何已签名服务器证书可作为CA证书用于cURL请求？

问题描述 #

我为所在机构配置了使用知名公共CA签名证书的HTTPS Web服务器，其他设备通过浏览器均可正常访问，且证书能被浏览器验证通过。但使用cURL测试该服务器的REST API接口时，收到错误提示：

curl: (60) SSL certificate problem: unable to get local issuer certificate

经测试，我将已签名服务器证书通过--cacert参数传入cURL命令后，问题得以解决。另外我尝试通过Chrome点击锁形图标下载证书，将该.crt文件传入cURL也能正常工作，且该下载文件比原签名服务器证书多两个证书。

我的疑问是：为何已签名服务器证书可作为“CA证书”用于cURL命令？原以为错误提示是指无法识别证书颁发CA，但我并未提供真正的CA证书。

问题解答 #

核心逻辑：证书链验证与curl的信任机制 #

这里的关键是curl与浏览器在证书验证逻辑上的差异：

• 浏览器默认内置了完整的公共根CA信任列表，且多数配置规范的服务器在SSL握手时会发送完整证书链（服务器证书+中间CA证书+根CA证书），因此浏览器能自动完成从服务器证书到根CA的追溯验证。
• 你的curl环境大概率存在两个问题：
  1. 系统或curl默认的信任根CA列表中，缺少对应公共CA的根证书（或是根证书版本过旧），导致无法自动完成追溯。
  2. 你的Web服务器在SSL握手时，仅发送了服务器自身的证书，未附带中间CA证书，进一步导致curl验证失败。

当你把服务器证书传给--cacert参数时，curl会将这个证书当作临时信任锚，跳过“向上追溯到根CA”的步骤，直接信任该服务器证书的合法性，因此验证通过。

至于Chrome下载的多证书文件，那是浏览器从服务器获取到的完整证书链（服务器证书+中间CA证书），curl拿到这个链后，就能从服务器证书向上追溯到中间CA，再结合系统中可能存在的根CA完成验证，自然也能正常工作。

对--cacert参数的澄清 #

别被--cacert的名称误导，它的作用是指定curl用于验证服务器证书的信任基准，这个基准不一定必须是根CA证书：

• 可以是根CA证书（标准用法）
• 可以是中间CA证书
• 甚至可以是服务器自身的证书
  只要curl信任这个基准，就会以此为起点验证服务器证书的签名合法性。

内容的提问来源于stack exchange，提问作者Walton C