Deno audit 在企业 CA 下报 UnknownIssuer，检查审计客户端的根证书配置

同一台机器上 deno install 等命令能访问 npm registry，deno audit 却报 UnknownIssuer，可以检查审计请求是否拿到了已经配置的企业根证书。尤其是 TLS 检查代理会用私有 CA 重新签发上游证书的环境。

Deno 2.8.1 的 Linux x86_64 案例中，设置 DENO_CERT 后其他 registry 操作恢复，但 audit 仍失败。排查时应保持 registry、代理和 CA 相同；仅看到两条命令表现不同，还不能排除它们访问了不同服务。

问题在审计工具创建 HTTP 客户端的入口。旧代码另外构造客户端，没有使用 CLI 工厂提供的 HTTP client provider，丢掉了根证书库配置。继续往正确 CA 文件里添加相同证书不能改变这一数据流，关闭证书验证也不应当成为修补。

Deno 2.9.7 包含处理：audit 复用 CLI 工厂的客户端 provider，使用相同的证书信任设置。更新后再按环境配置经过核实的 CA 文件：

DENO_CERT=/absolute/path/company-ca.pem deno audit

如果部署依赖系统根证书库，应核对原有 DENO_TLS_CA_STORE 设置及系统是否真正安装了该 CA，而不是同时修改所有变量后再猜是哪项生效。CA 文件必须来自可信的组织管理渠道；这一修补不会让不可信证书自动变得可信。

验收要用原来失败的审计请求，确认 TLS 握手成功，并保留正常的 audit 输出或实际发现的漏洞结果。audit 可能因发现漏洞而返回非零状态，这与 TLS 仍失败不同；不要把所有非零退出都归为证书错误，也不要把没有执行的审计算作通过。

在受控测试环境可以比较设置正确 CA、没有该 CA 两种条件。前者应建立可信连接，后者仍应拒绝未知签发者，这能检查升级是否只是绕过了验证。生产网络上的代理认证、DNS 或连接超时仍需要单独排查。

这个边界只覆盖 audit 没有继承已配置根证书库的路径。过期证书、主机名不匹配、无法处理的 critical 扩展，以及 registry 服务端真正的证书链错误，都不能仅凭 UnknownIssuer 字样承诺由同一版本解决。