关于疑似卡巴斯基 HTTPS 扫描导致 Node.js 访问 api.deepseek.com 报 SELF_SIGNED_CERT_IN_CHAIN 的反馈

[LeeJazen]

标题： 关于疑似卡巴斯基 HTTPS 扫描导致 Node.js 访问 api.deepseek.com 报 SELF_SIGNED_CERT_IN_CHAIN 的反馈

正文：

大家好，我想向 DSH 社区反馈一个 Node.js 访问 DeepSeek API 时与卡巴斯基的兼容性问题，希望社区或官方文档能记录为已知问题，并给出解决指引。

可能的原因：
昨天我能够正常使用DSH完成任务，今天更新完卡巴斯基数据库后，DSH调用模型失败，显示：本轮运行失败DeepSeek API request to https://api.deepseek.com failed
随后使用以下命令发现问题，关闭卡巴斯基后DSH正常使用
复现命令：

node -e "fetch('https://api.deepseek.com').then(r => console.log('HTTP', r.status)).catch(e => { console.error(e, e.cause); process.exit(1) })"

实际结果：

TypeError: fetch failed
[cause]: Error: self-signed certificate in certificate chain
code: 'SELF_SIGNED_CERT_IN_CHAIN'

排查结果：
关闭卡巴斯基的“加密连接扫描 / HTTPS 扫描”，或者直接退出卡巴斯基后，同样的命令可以正常返回 HTTP 状态码。开启卡巴斯基时则稳定复现上述证书错误。

原因判断：
看起来是卡巴斯基对 HTTPS 流量进行中间人扫描，使用它自己的自签名根证书重新签发了证书链，而 Node.js 默认不信任这个根证书，因此 fetch 失败。

临时规避：

• 退出卡巴斯基

建议：
这不是要求 DeepSeek 修改 API 证书，而是希望 DSH 社区/官方文档能补充一个 FAQ：
“卡巴斯基等安全软件的 HTTPS 扫描可能导致 Node.js 访问 api.deepseek.com 时报 SELF_SIGNED_CERT_IN_CHAIN，可通过信任其根证书或调整扫描设置解决。”

期望：
Deepseek能够解决这个问题

如果需要，我可以补充卡巴斯基版本、Node 版本和证书链截图。

谢谢。

标签： DeepSeek API Node.js Kaspersky HTTPS SSL

---

Title: Feedback: Suspected Kaspersky HTTPS Scanning Causing Node.js Requests to api.deepseek.com to Fail with SELF_SIGNED_CERT_IN_CHAIN

Body:

Hi DSH Community,

I would like to report a compatibility issue between Node.js access to the DeepSeek API and Kaspersky. I hope the community or official documentation can record it as a known issue and provide troubleshooting guidance.

Possible cause:

Yesterday I was able to use DSH normally to complete tasks. Today, after updating the Kaspersky databases, DSH failed to call the model and showed:
This run failed: DeepSeek API request to https://api.deepseek.com failed.

I then used the following command to identify the problem. After turning off Kaspersky, DSH worked normally again.

Reproduction command:

node -e "fetch('https://api.deepseek.com').then(r => console.log('HTTP', r.status)).catch(e => { console.error(e, e.cause); process.exit(1) })"

Actual result:

TypeError: fetch failed
[cause]: Error: self-signed certificate in certificate chain
code: 'SELF_SIGNED_CERT_IN_CHAIN'

Troubleshooting:
After disabling Kaspersky's "Encrypted connection scanning / HTTPS scanning", or exiting Kaspersky completely, the same command returns a normal HTTP status code. With Kaspersky enabled, the certificate error reproduces consistently.

Likely cause:
It appears that Kaspersky performs man-in-the-middle scanning of HTTPS traffic and re-signs the certificate chain with its own self-signed root certificate. Node.js does not trust this root certificate by default, so fetch fails.

Temporary workaround:

• exit Kaspersky.

Suggestion:
This is not a request for DeepSeek to change its API certificate. Instead, I hope the DSH Community/official documentation can add an FAQ:
"HTTPS scanning by Kaspersky and similar security software may cause Node.js requests to api.deepseek.com to fail with SELF_SIGNED_CERT_IN_CHAIN. This can be resolved by trusting the relevant root certificate or adjusting the scanning settings."

Expectation:
I hope DeepSeek can resolve this issue.

If needed, I can provide the Kaspersky version, Node version, and certificate chain screenshots.

Thank you.

Tags: DeepSeek API Node.js Kaspersky HTTPS SSL

[PerryLink]

你的判断是对的, 而且有一个不用关掉 HTTPS 扫描的解法: 卡巴斯基的根证书可以加进 Node 的信任库.

根因: 卡巴斯基的「加密连接扫描」对 TLS 做中间人, 用它自己的自签名根证书重新签发证书链. Node 默认不信任这张根证书, 所以 fetch 抛 SELF_SIGNED_CERT_IN_CHAIN. 关掉扫描就能恢复, 正说明被替换的是本地这一段证书链, 与 api.deepseek.com 服务端的证书无关 -- 这一点你已经验证过了.

解法: NODE_EXTRA_CA_CERTS

先在 Windows 上导出卡巴斯基的根证书:

1. Win+R 打开 certlm.msc, 展开「受信任的根证书颁发机构」->「证书」
2. 找名称含 Kaspersky 的那张根证书 (通常在列表靠前的厂商区)
3. 右键 -> 所有任务 -> 导出 -> 选 Base64 编码 X.509 (.CER) -> 存为 kaspersky-root.pem

然后在启动 DSH 之前指向它:

$env:NODE_EXTRA_CA_CERTS = "C:\path\to\kaspersky-root.pem"
dsh

要让所有终端长期生效, 就把 NODE_EXTRA_CA_CERTS 写进系统环境变量.

这不是经验之谈, 我在本机做了 A/B 对照. Node v22.22.3, 起一个用自签名证书的本地 HTTPS 服务, 同一条命令只改这一个环境变量:

环境	fetch('https://localhost:8443')
不设 NODE_EXTRA_CA_CERTS	fetch failed / DEPTH_ZERO_SELF_SIGNED_CERT
设了, 指向该证书的 PEM	SUCCESS: {"ok":true,"via":"d5-tls-test"}

https 模块在同一组条件下行为一致. ⇒ Node 的 fetch (undici) 确实读取 NODE_EXTRA_CA_CERTS, 所以你不需要在「保留扫描」和「访问 API」之间二选一.

两个坑:

1. 路径写错不会报错. 指向不存在的文件时, Node 只打印一条 warning (Ignoring extra certs from ...), 然后照常失败, 错误码还是 SELF_SIGNED_CERT_IN_CHAIN. 所以如果设了仍然失败, 先确认路径可达, 且文件是 PEM 文本 (-----BEGIN CERTIFICATE----- 开头), 不是二进制 .cer.
2. 不要用 NODE_TLS_REJECT_UNAUTHORIZED=0. 实测它确实能连通 (返回 200), 但它关闭的是全部证书校验, Node 自己会打印安全警告. 救急可以, 不该当成解法.

一个可用于确认的中间态: 如果设了 NODE_EXTRA_CA_CERTS 之后, 错误码从 SELF_SIGNED_CERT_IN_CHAIN 变成了 ERR_TLS_CERT_ALTNAME_INVALID, 那说明证书已经被信任了, 只剩主机名不匹配 -- 那是另一个问题 (证书 SAN 与访问的域名/IP 不一致), 与卡巴斯基无关.

Disclosure of scope: measured on Node v22.22.3 (Windows) against a locally generated self-signed certificate and a local HTTPS server; I did not have Kaspersky installed, so the export steps come from its documented certificate behaviour rather than from a machine I tested end to end.

[LeeJazen]

谢谢你的回答。作为一个小白，我还有几个问题，我之前是能正常运行的，是在今天卡巴斯基更新数据库后出现这个问题的，问AI说可能是因为卡巴斯基这次更新换了证书导致的，那未来会不会还有可能再次因为更新数据库导致这个问题。 如果出现这个问题，还是按照这个方法吗。 或者说，会不会有可能，后续卡巴斯基数据库更新会修复这个问题。 这几个问题我问了几个AI，答案不一样，所以想问问大佬确认一下答案，不好意思

[PerryLink]

先直接回答你三个问题, 再给你一条自己就能跑的判断命令. 你问的几个 AI 答案不一样, 多半是把三张不同的证书混在一起讲了 -- 先把它们分开, 后面的问题就都清楚了:

证书	谁签发	会不会变
api.deepseek.com 的服务端证书	公共 CA (TrustAsia / DigiCert 等)	几个月轮换一次, 和本次问题无关
卡巴斯基的本地根证书	卡巴自己 (自签名)	安装时生成并存进 Windows 信任库; 重装 / 大版本升级会换
卡巴每次连接现场签发的叶证书	上面那张根	随时在变 -- 而这正是下面这个解法能长期有效的原因

NODE_EXTRA_CA_CERTS 信任的是第二张(根): 只要根没换, 它签发的所有叶证书(第三张)自动被信任, 不管变多少次.

问题 1: 以后会不会又因为卡巴更新数据库出现这个问题?

• 特征库(数据库)更新本身不会去换根证书 -- 根是安装期生成、存进 Windows 信任库的. 所以只要根不变, 你导出的那个 PEM 就一直有效, 天天更新也不影响.
• 但说实话: 你「昨天能用、今天不能用」, 变的不是 DeepSeek 的证书, 而是卡巴这边的拦截行为. 这类变化以后还可能发生(例如它开始拦截以前不拦的域名). 不过因为你在根这一层做了信任, 它以后再改拦截范围, 你也不会再看到这个报错 -- 这一招不只修了今天, 也把以后同类变化一起挡掉了.
• 真正需要你重新动手的只有一种情况: 根证书本身被换掉(重装卡巴 / 大版本升级 / 根到期). 那时重新导出、覆盖同一个文件就行, 环境变量不用动.

怎么判断是哪一种? 这条命令只读, 不改任何设置, 也不关闭校验:

node -e "const t=require('tls');const s=t.connect({host:'api.deepseek.com',port:443,servername:'api.deepseek.com',rejectUnauthorized:false},()=>{const p=s.getPeerCertificate(true);console.log('authorized:',s.authorized,'| authError:',s.authorizationError||'(none)');console.log('leaf:',p.subject.CN,'<- issuer:',p.issuer.CN||p.issuer.O);let x=p,g=0;while(x&&g++<8){if(!x.issuerCertificate||x.issuerCertificate===x){console.log('root:',x.subject.CN||x.subject.O);console.log('rootValidFrom:',x.valid_from);console.log('rootSHA256:',x.fingerprint256);break}x=x.issuerCertificate}s.end()})"

怎么读:

• leaf: ... <- issuer: Kaspersky... ⇒ 卡巴正在拦截(这一步是正常的)
• authError: SELF_SIGNED_CERT_IN_CHAIN 且 issuer 是 Kaspersky ⇒ 就是本次这个问题, 按老办法
• authorized: true ⇒ 已经好了
• 把 rootSHA256 抄下来. 下次复发再跑一次: 指纹相同 ⇒ 不是根的问题(去查卡巴的拦截规则); 指纹不同 ⇒ 根换了, 重新导出覆盖即可.

问题 2: 出现这个问题还是按这个方法吗?

是. 建议一次做两件事, 以后最多花 10 秒:

1. 导出的证书放固定路径(别放 %TEMP%, 会被清理), 例如 C:\certs\kaspersky-root.pem
2. NODE_EXTRA_CA_CERTS 写进系统环境变量(不是只在当前终端设), 然后重开终端
3. 复发时: 重新导出覆盖那个文件 -> 重启 DSH. 环境变量不用动.

验证: 直接跑你最初那条复现命令, 现在应该返回 HTTP 401. 401 是正常的(没带 API key), 只要不再是 SELF_SIGNED_CERT_IN_CHAIN 就说明通了.

还有一个可能更省心的替代项, 如果你的 Node >= v22.15.0:

node -v                            # 先确认版本
$env:NODE_OPTIONS = "--use-system-ca"

这条让 Node 直接读 Windows 信任库(卡巴的根本来就在里面). 我在本机 (Windows, Node v22.22.3) 量过: 不开这个开关时 Node 默认信任 145 张根(全是它自带的), 开了之后是 305 张 = 145 张自带 + 160 张系统库 -- 也就是追加, 不是替换, 而且 NODE_OPTIONS 接受这个参数(实测). 好处: 卡巴以后换根时 Windows 信任库会跟着更新, 你什么都不用做; 代价: 信任范围从「只多一张卡巴根」扩大到「整个系统库」. 怎么选: 图省事、以后不想再管 -> --use-system-ca(前提是 Node >= v22.15.0); Node 版本较低、或只想做最小改动 -> 就用上一个 NODE_EXTRA_CA_CERTS. 两个选一个就行, 不用都设(要长期生效同样写进系统环境变量). 如果不想碰证书, 还有第三条路: 在卡巴的「加密连接扫描」里把 api.deepseek.com 加进排除项, 让这一段不被扫描(菜单名以你的版本为准, 官方说明: https://support.kaspersky.com/kaspersky-for-windows/21.23/157530).

问题 3: 卡巴将来更新会不会自己修好?

不会, 不建议等. 这不是 bug, 而是两边的设计撞在一起: 卡巴的 HTTPS 扫描必须做中间人才能扫描内容(这就是它的工作方式), 而 Node 故意不使用系统信任库(它自带一份跨平台一致的根列表). 所以两边都不会去「修」. 同样的问题会出现在任何自带信任库的程序(Python / Java / Go ...)搭配任何做 HTTPS 拦截的软件(ESET / Bitdefender / 企业代理如 Zscaler)上, 社区里这类 FAQ 很多. 也正因如此, 你提的「文档里记一条」是有价值的 -- 不过这属于 DSH 仓库 / 文档维护者的取舍, 你可以去仓库开一条 issue 或 PR 提这个建议(API 侧本身没有问题可修).

Disclosure of scope: measured on Node v22.22.3 (Windows) with a locally generated self-signed certificate and a local HTTPS server; the version requirement for --use-system-ca (v22.15.0 / v23.8.0) comes from Node's official CLI documentation; I still have no Kaspersky installed, so the root-certificate lifecycle above is described from the product's documented behaviour rather than from a machine I tested end to end.

[17-qxm]

我有相同的问题，我的dsh在卡巴斯基删除后也不再会出现相同的问题了，但是我发现我的nodejs相关环境中卡巴斯基似乎并不是请求的中间人

PS C:\Users\lenovo> node -e "const t=require('tls');const s=t.connect({host:'api.deepseek.com',port:443,servername:'api.deepseek.com',rejectUnauthorized:false},()=>{const p=s.getPeerCertificate(true);console.log('authorized:',s.authorized,'| authError:',s.authorizationError||'(none)');console.log('leaf:',p.subject.CN,'<- issuer:',p.issuer.CN||p.issuer.O);let x=p,g=0;while(x&&g++<8){if(!x.issuerCertificate||x.issuerCertificate===x){console.log('root:',x.subject.CN||x.subject.O);console.log('rootValidFrom:',x.valid_from);console.log('rootSHA256:',x.fingerprint256);break}x=x.issuerCertificate}s.end()})"
authorized: true | authError: (none)
leaf: api.deepseek.com <- issuer: TrustAsia DV TLS RSA CA 2025
root: DigiCert Global Root G2
rootValidFrom: Aug  1 12:00:00 2013 GMT
rootSHA256: CB:3C:CB:B7:60:31:E5:E0:13:8F:8D:D3:9A:23:F9:DE:47:FF:C3:5E:43:C1:14:4C:EA:27:D4:6A:5A:B1:CB:5F

我更想知道在这里，我该如何处理这个问题？
我无法判断问题是如何发生的，请帮帮我

[PerryLink]

你的两条观察不矛盾, 反而互相印证. 关键是你这条测试的测量时点:

rejectUnauthorized:false 并不是"不校验"——它让连接在校验失败时继续建立, 但校验本身照跑, 结果仍记在 authorized / authorizationError 里. 所以这条命令其实有探测能力: 真链 → authorized:true; 被卡巴换签的链 → authorized:false + authError: SELF_SIGNED_CERT_IN_CHAIN. 问题在于你是在删除卡巴之后才跑它: authorized:true + TrustAsia→DigiCert 只证明"现在"这条链是干净的, 不能回溯到故障时刻. 如果在扫描开启时跑同一条命令, issuer 会变成 Kaspersky 且 authError 变成 SELF_SIGNED_CERT_IN_CHAIN——那才是拦截实锤. 换句话说: 你的实验没有测错, 只是测错了时刻, 它不构成"卡巴不是中间人"的证据.

两条证据线这样自洽:

1. 故障发生在卡巴还装着、扫描还开着的期间, 报错码 SELF_SIGNED_CERT_IN_CHAIN; 删卡巴后扫描消失, 连接恢复直连, 链自然回到 TrustAsia→DigiCert 原链. "删掉就好了"本身就是"扫描期间中间人存在"的直接证据.
2. 该错误码不是 DSH 生成的: 全仓搜不到对 SELF_SIGNED 的任何处理或映射, 它是 Node TLS 层的内置错误. DSH 只是把它包进 LlmError("DeepSeek API request to ... failed", 'TRANSPORT', { cause })(packages/llm/llm-deepseek/src/adapter.ts:657-663), 原始 cause 链里就是 TLS 报的 SELF_SIGNED_CERT_IN_CHAIN.

处理建议:

• 已卸载卡巴: 什么都不用做, 现状即健康状态.
• 想保留卡巴, 三选一: (1) 把 dsh / node 加入卡巴的受信任应用(跳过其加密连接扫描); (2) 关闭"加密连接扫描/HTTPS 扫描"; (3) 保留扫描, 导出卡巴根证书为 PEM 并设 NODE_EXTRA_CA_CERTS(步骤见本线程我上一条回复; 该变量在 Node fetch/TLS 侧已本机 A/B 实测生效). 说明: (1)(2) 是卡巴 UI 侧配置, 我没有卡巴环境逐一实测; (3) 的导出步骤基于卡巴文档行为. 以后复发时先跑你那条链检查命令看 issuer: 出现 Kaspersky 即拦截又开, 仍是同一问题.

[phquathi]

Confirmed on Windows, plus a one-variable fix that keeps HTTPS scanning enabled: NODE_USE_SYSTEM_CA=1

I hit the same failure and can confirm the diagnosis in this thread with certificate-level evidence, and add a workaround that does not require turning off the antivirus' encrypted-connection scanning.

Environment

• Windows 11 Pro 10.0.26200 (AMD64), Windows PowerShell 5.1.26100.9444
• Node.js v26.7.0 (npm 11.19.0)
• @deepseek-ai/dsh 0.1.5-rc.1, started as npx @deepseek-ai/dsh web
• No proxy-related environment variables are set (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, NODE_EXTRA_CA_CERTS, NODE_TLS_REJECT_UNAUTHORIZED are all absent). Windows Internet Settings does have a local system proxy configured.
• SecurityCenter2 lists both Windows Defender and Kaspersky Anti-Virus as installed AV products.

Symptoms

• dsh was working, then in the middle of an agent turn every request started failing with DeepSeek API request to https://api.deepseek.com failed, after the normal retry sequence.
• A new conversation, a new workspace, an older project, and killing/restarting the dsh web process all made no difference: every request re-ran the full retry sequence and failed again.
• The DeepSeek status page was healthy, and another client on the same machine (OpenCode) could reach the same API at the same time.

Minimal reproduction

node -e "fetch('https://api.deepseek.com').then(r=>console.log('HTTP',r.status)).catch(e=>console.error(e, e.cause))"

TypeError: fetch failed
[cause]: Error: self-signed certificate in certificate chain
code: 'SELF_SIGNED_CERT_IN_CHAIN'

Certificate-level evidence

• Connecting to api.deepseek.com with SNI, the leaf certificate is CN=api.deepseek.com issued by Kaspersky Anti-Virus Personal Root Certificate (O=AO Kaspersky Lab) — on both resolved addresses.
• That root is present in the Windows trust stores (Cert:\LocalMachine\Root / Cert:\CurrentUser\Root; 82 roots in total on this machine).
• require('tls').rootCertificates on Node v26.7.0 lists 118 roots and 0 matching "Kaspersky": the local interception root is simply not in Node's bundled CA set.
• Default trust: tls.connect({host:'api.deepseek.com', port:443, rejectUnauthorized:true}) fails with SELF_SIGNED_CERT_IN_CHAIN, and fetch fails identically.
• With NODE_USE_SYSTEM_CA=1: the same connection reports authorized: true, and fetch returns HTTP 401 — TLS succeeded and the request reached the API.

Fix / workaround

setx NODE_USE_SYSTEM_CA 1

Then open a new shell (setx only affects processes started afterwards) and restart dsh. To test in the current shell only:

$env:NODE_USE_SYSTEM_CA="1"

NODE_EXTRA_CA_CERTS (pointed at the exported Kaspersky root) also works; NODE_USE_SYSTEM_CA=1 is a single variable and additionally covers other enterprise/AV roots that are in the Windows store.

Please do not use NODE_TLS_REJECT_UNAUTHORIZED=0 — it disables certificate validation for every HTTPS request the process makes.

Secondary observation

When the TLS client does not send SNI, the same endpoint presents a DigiCert-issued certificate for an unrelated domain (*.unionpayintl.com). It is reproducible on this machine, the mechanism is unconfirmed, and it does not change the fix above — but the TLS path on this host is worth inspecting before blaming the API service.

Questions for maintainers

1. Would you consider using the OS certificate store by default (or exposing a documented opt-in) on Windows/macOS, so that enterprise/AV HTTPS interception does not look like an API outage?
2. dsh-llm-deepseek already attaches the underlying error (new LlmError(\DeepSeek API request to ${connection.baseURL} failed`, "TRANSPORT", { cause: error })), but the user-visible message is only DeepSeek API request to ... failed. Could something like error.cause.code (SELF_SIGNED_CERT_IN_CHAIN`) be surfaced in the UI/log, turning a multi-hour hunt into a one-minute diagnosis?
3. Could the docs gain a troubleshooting entry for "Windows + enterprise/AV HTTPS interception + Node CA trust" (NODE_USE_SYSTEM_CA, NODE_EXTRA_CA_CERTS)?

中文摘要：本机同样复现该问题（dsh 0.1.5-rc.1 / Node v26.7.0 / Windows 11）。根因是卡巴斯基的加密连接扫描用其自签根证书重签了 api.deepseek.com 的证书链；该根证书在 Windows 证书库中，但不在 Node 内置 CA 里，因此 Node 与 undici 报 SELF_SIGNED_CERT_IN_CHAIN。除"关闭扫描"或 NODE_EXTRA_CA_CERTS 之外，还有一个更省事的变量：setx NODE_USE_SYSTEM_CA 1（需新开终端并重启 dsh），可保留 HTTPS 扫描。请勿使用 NODE_TLS_REJECT_UNAUTHORIZED=0。