Windows WSL环境执行curl请求报TLS alert: unknown CA错误咨询

问题复现命令及日志 #

curl -v https://google.com:443/
* Trying 172.217.169.78...
* TCP_NODELAY set
* Connected to google.com (172.217.169.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

问题1解答：请求过程中为何同时出现TLSv1.3和TLSv1.2的入站、出站报文 #

• curl发起请求时默认优先支持TLSv1.3，因此发送的Client Hello报文被标记为TLSv1.3 (OUT)
• 对端返回的Server Hello报文确认兼容TLSv1.3，因此被标记为TLSv1.3 (IN)
• 后续握手报文显示为TLSv1.2属于TLSv1.3的向下兼容设计：部分设备的TLSv1.3实现会复用TLSv1.2的报文结构完成剩余握手流程，curl仅如实标注报文实际使用的协议版本标识，不属于异常。如果你所处的企业网络部署了SSL中间人拦截代理，代理本身的TLS实现不支持完整的TLSv1.3握手流程，也会出现该现象。

问题2解答：该情况是否是引发“unable to get local issuer certificate”报错的潜在原因 #

• 不是。TLS版本混合显示只是握手阶段的协议兼容表现，和证书校验失败无直接关联。
• 该报错的核心原因是Windows企业版通常会在域内部署SSL中间人代理，代理会替换所有HTTPS请求的服务端证书，而WSL2内置的CA证书库仅包含公网可信根证书，没有导入企业代理的自签名根证书，因此无法验证代理返回的证书合法性。此前更新公网CA证书包的操作无法覆盖企业自定义根证书的场景，因此无法解决问题。

修复方案 #

• 打开Windows系统证书管理器，运行命令certmgr.msc即可唤起，在受信任的根证书颁发机构\证书路径下找到你企业的代理根证书，导出为Base64编码的PEM格式文件
• 将导出的证书文件上传到WSL2的/usr/local/share/ca-certificates/目录下，文件后缀命名为.crt
• 执行sudo update-ca-certificates命令，即可将企业根证书导入到WSL2的系统CA库中，后续curl请求即可正常验证证书。

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