你在访问 DeepSeek 的 chat.deepseek.com 时被 Chrome 拦下，并看到一段看似吓人的提示：Your connection is not private，并附带错误码 net::ERR_CERT_AUTHORITY_INVALID，紧接着又强调站点启用了 HSTS，因此无法绕过继续访问。把这件事讲透，需要把浏览器的安全模型、证书信任链、以及 HSTS 的硬性约束放在同一张图里看。下面我用工程化的思路，把出现这种提示的成因拆开，给出一条能落地的排错路径，并在合适的地方提供命令与可运行代码，帮你快速定位到底是本机环境、网络中间设备，还是网站一端在背锅。

---

这条报错到底说明了什么

NET::ERR_CERT_AUTHORITY_INVALID 的直译是：浏览器无法把对端服务器端的 TLS 证书与一个受信任的证书颁发机构对应起来。常见原因包含三大类：站点证书链配置不完整或失效、本地或网络侧有 TLS 拦截/代理、以及系统或浏览器的信任根集合与对端证书不兼容。Chrome 在这种情况下会直接弹出连接非私密的红屏。对于开启了 HSTS 的站点，Chrome 严格禁止你点继续访问的一键冒险，因为 HSTS 的语义就是只允许通过 HTTPS 并且证书要可被信任，否则一律拒绝连接。(Kinsta®)

补充一个容易被忽视的变化：Chrome 现在有自己的 Chrome Root Store 与 Chrome Root Program，在多个平台上并不完全依赖操作系统的根证书库。这意味着同一张证书在 Edge 或系统层面被信任，但在 Chrome 里可能依旧不被信任，直接触发 ERR_CERT_AUTHORITY_INVALID。(Chromium Blog)

---

HSTS 为什么让我就想先进去看看变得不可能

HSTS 是浏览器和网站约定的一条硬规则：在一定时间窗口内，只能 用 HTTPS 访问，并且若证书校验失败，不允许用户绕过。很多大站点还把自己的域名提交到 HSTS 预加载清单，等于把这条规则烧进浏览器的内置列表里，连第一次访问的窗口都关死了。只要命中预加载清单，本地清缓存或清 HSTS 条目都无效，唯一的正道是修好证书链或换一个不触发规则的域名。(Chromium)

---

先给出一条安全又高效的排错路径

为了不在错误的方向上浪费时间，建议按影响面从小到大去排：

1) 用别的设备 + 别的网络做 A/B 验证

拿手机的蜂窝数据开热点，或换一台设备试一下。如果在另一条网络上能正常打开，说明问题大概率在你当前网络或本机环境，例如公司网关的 TLS 检查、家用路由的安全功能、或公用 Wi-Fi 的上网认证页在劫持连接。很多认证网关或防火墙如果用的是自签名或不被 Chrome 信任的证书，就会诱发这类错误，且与 HSTS 相冲。(Fortinet Community)

2) 核对本机时钟与浏览器状态

系统时间漂移、缓存的旧策略、或异常的扩展也会放大问题。

• 把系统日期与时区校准到网络时间。
• 开一个 无痕窗口 或把所有扩展禁用后重试。
• 清除 SSL 状态、缓存与 Cookie。
• 关闭 VPN 或杀毒软件的 HTTPS 扫描 再观察。(Google Help)

3) 判断是否被 HSTS 预加载命中

在 Chrome 中，访问 chrome://net-internals/#hsts，尝试 Query HSTS/PKP domain 查看该域是否有本地策略；若有，先 Delete domain security policies 清掉本地动态策略再试。注意：如果域名处于 HSTS 预加载清单，即便清除了本地条目也无法绕过。(HOSTKEY — premium web services provider)

4) 看清对端到底给了什么证书链

在命令行用 openssl 直接握手，打印证书链、颁发者与有效期：

# Linux/macOS，Windows 可用 WSL 或 Git Bash
openssl s_client -connect chat.deepseek.com:443 -servername chat.deepseek.com -showcerts </dev/null

关注输出中的 issuer、subject、Verify return code。如果 Verify return code 显示链不完整或unable to get local issuer certificate，说明网站侧可能少发了中间证书，或链条本身失效。缺中间证书是经典易忽略问题，浏览器会直接判定不可信。(SSL.com)

5) 排除本地或企业级 TLS 拦截

很多杀毒软件、家长控制、公司网关会下发一个自建根证书，劫持 TLS 做解密扫描。若该根证书没被 Chrome 的根库认可，就会触发 ERR_CERT_AUTHORITY_INVALID。

• 在 Windows 打开 certlm.msc 查看受信任的根证书颁发机构里是否有公司或安全软件安装的根；
• 在 macOS 打开 钥匙串访问 看系统钥匙串的受信任根；
• 留意 Chrome 与其他浏览器的差异，因为 Chrome 使用自己的根程序与根库策略。(Super User)

6) 识别是否被公用 Wi-Fi 的认证页劫持

公用 Wi-Fi 经常通过先劫持任意域名，后弹出登录页的方式实现认证。如果这一跳恰好选择了启用 HSTS 的大站，便会与 HSTS 规则冲突，导致你眼前的错误。切回运营商 4G/5G 或手动打开一个众所周知未开启 HSTS 的 http 页，让认证页先完成登录，再访问目标站点。(Fortinet Community)

---

把排错落到具体操作

A. 针对用户侧的可执行动作

• 校准系统时间与时区，并更新浏览器到最新稳定版。很多证书校验严格依赖系统时间。(SSLs.com)
• 清理浏览器的 HSTS 动态策略：chrome://net-internals/#hsts 中 Delete domain security policies 输入域名后删除，随后完全重启浏览器。若该域被 HSTS 预加载，清理无效，需看后续步骤。(HOSTKEY — premium web services provider)
• 临时禁用 VPN/杀毒的 HTTPS 扫描，或者切换到移动热点验证是否网络侧拦截。(Kinsta®)
• 检查代理设置，确保没有残留的系统代理或代理扩展。
• 换浏览器/换设备交叉验证。如果只有 Chrome 报错而 Edge/Firefox 正常，考虑到 Chrome Root Store 的差异性，你可能需要把企业私有根证书导入到 Chrome 自身的证书管理器中，而不是只导入操作系统。(Super User)

B. 针对网站侧的核查要点（如果你能联系站点方）

• 补齐中间证书，确保服务器完整发送Leaf → Intermediate(s) → Root的链条。少中间证书是最常见的线上事故之一。(SSL.com)
• 确认证书由受信任的公认 CA 颁发，而不是测试用或只在企业内信任的 CA。Chrome 对根库的管控较严格，与系统信任可能不同步。(googlechrome.github.io)
• 核对证书 CN/SAN 是否覆盖 chat.deepseek.com，以及有效期与 OCSP/CRL 可达性。
• 检查 HSTS 配置：若站点使用 Strict-Transport-Security 并处于预加载，任何证书问题都会被放大为不可绕过的阻断。(Chrome for Developers)

---

一段可运行的 Python 小脚本，自动抓取与解析证书

下面这段脚本会直接和目标主机握手，打印证书的 subject、issuer、有效期、SAN，并尝试用系统/certifi 信任库做一次校验，帮助你判断问题落在证书链/信任还是网络拦截。我全部使用单引号，避免你复制后因为双引号被替换而跑不起来。

#!/usr/bin/env python3
import ssl, socket, datetime, idna
from OpenSSL import crypto

def fetch_cert_chain(hostname, port=443):
    hostname_idna = idna.encode(hostname).decode('ascii')
    ctx = ssl.create_default_context()
    conn = ctx.wrap_socket(socket.socket(socket.AF_INET), server_hostname=hostname_idna)
    conn.settimeout(10)
    conn.connect((hostname_idna, port))
    der = conn.getpeercert(True)
    pem = ssl.DER_cert_to_PEM_cert(der)
    conn.close()
    # 用 pyOpenSSL 解析链条细节
    x509 = crypto.load_certificate(crypto.FILETYPE_PEM, pem)
    subject = dict(x509.get_subject().get_components())
    issuer = dict(x509.get_issuer().get_components())
    not_before = datetime.datetime.strptime(x509.get_notBefore().decode('ascii'), '%Y%m%d%H%M%SZ')
    not_after  = datetime.datetime.strptime(x509.get_notAfter().decode('ascii'), '%Y%m%d%H%M%SZ')
    san = []
    for i in range(x509.get_extension_count()):
        ext = x509.get_extension(i)
        if ext.get_short_name().decode('ascii') == 'subjectAltName':
            san = [e.strip() for e in str(ext).split(',')]
    return {
        'subject': {k.decode(): v.decode() for k, v in subject.items()},
        'issuer':  {k.decode(): v.decode() for k, v in issuer.items()},
        'not_before': not_before.isoformat() + 'Z',
        'not_after':  not_after.isoformat() + 'Z',
        'san': san,
        'pem': pem
    }

def quick_verify_with_certifi(hostname, port=443):
    import certifi
    ctx = ssl.create_default_context(cafile=certifi.where())
    try:
        with ctx.wrap_socket(socket.socket(), server_hostname=hostname) as s:
            s.settimeout(10)
            s.connect((hostname, port))
            s.do_handshake()
        return True, 'verified by certifi'
    except Exception as e:
        return False, f'verify failed: {e}'

if __name__ == '__main__':
    host = 'chat.deepseek.com'
    info = fetch_cert_chain(host)
    print('Subject:', info['subject'])
    print('Issuer :', info['issuer'])
    print('Valid  :', info['not_before'], '→', info['not_after'])
    print('SAN    :', info['san'])
    ok, msg = quick_verify_with_certifi(host)
    print('Trust  :', ok, msg)

用法与解读

• 如果 Trust : True verified by certifi，而浏览器仍报 ERR_CERT_AUTHORITY_INVALID，多半是网络里存在 TLS 拦截导致浏览器校验路径不同。
• 如果 Trust : False，并且 Issuer 显示为某个陌生机构或企业内部 CA，说明链条不被公信根信任。
• 如果 not_after 已过期或 SAN 不包含 chat.deepseek.com，那就是站点证书本身的问题。

---

你可能遇到的几类真实世界场景

场景一：公用 Wi-Fi 的认证页拦截了 HSTS 站点

机场 Wi-Fi 常见做法是把你访问的第一个域名拦到自家认证页。若你打开的是 chat.deepseek.com 这种可能启用了 HSTS 的站点，浏览器会拒绝与一个证书不匹配的目的地建立连接，于是你看到的就是连接非私密与 HSTS 提示。做法是切到蜂窝数据先完成登录，或直接打开一个 http://neverssl.com 这类用于触发认证页的站点，再回来访问目标站。(Fortinet Community)

场景二：公司网关或安全软件在做 TLS 检查

很多企业合规需要对流量做解密审计，通常通过在客户端植入一张企业根证书来中间人解密。如果这张根证书没被 Chrome 根库接受，或部署不完整，就会在 Chrome 独有的根计划下报 ERR_CERT_AUTHORITY_INVALID，而 Edge/Firefox 可能还工作正常。(Chromium Blog)

场景三：网站侧少发了中间证书

证书从叶子证书到公信根之间往往需要一到多个中间证书。如果站点只配了叶子证书，某些浏览器或平台会尝试链路修复，但 Chrome 经常会直接报错。服务端补齐完整链条即可恢复。(SSL.com)

场景四：HSTS 预加载 + 证书失效的组合拳

若域名被编进浏览器的 HSTS 预加载清单，只要证书出差错，用户侧没有任何继续访问按钮，清缓存也无用。网站方需要尽快更换为有效证书，或在极端情况下从预加载清单申请移除（流程严格而且需要时间）。(HSTS Preload)

---

操作系统维度的一些细节

• Windows：很多人把企业根证书导入到了当前用户而不是本地计算机证书库，导致系统信任但 Chrome 不一定同步。用 certlm.msc 打开本地计算机证书管理器核查。(Stack Overflow)
• macOS：Keychain 里要放在 System 钥匙串并明确设置 Always Trust，只是放在 login 钥匙串并不够。(-)
• Linux：Chrome 可能使用 NSS 或自身的根库，和系统的 ca-certificates 并非完全一致，某些环境需要把自定义根导入到 Chrome/Chromium 使用的证书数据库。(Super User)

---

给到你的即刻可做清单（按优先级）

1. 换网络与设备做一次交叉验证，判断问题在本机/网络还是网站。(Fortinet Community)
2. 校准系统时间，更新 Chrome，并在无痕模式下重试。(SSLs.com)
3. 检查是否被 VPN、代理、杀毒的 HTTPS 扫描拦截，尝试暂时关闭后重试。(Kinsta®)
4. 在 chrome://net-internals/#hsts 查询与删除该域的动态 HSTS 条目（若非预加载）。(HOSTKEY — premium web services provider)
5. 运行上面的 Python 脚本或 openssl s_client 看看实际下发的证书链与颁发者。(SSL.com)
6. 如果确认是网站侧链条异常或证书过期，只有网站方能修。若确认是公司网络的 TLS 检查，找 IT 部门，把企业根证书按 Chrome 的要求正确分发。(Chromium Blog)

---

关于能不能强行忽略继续访问

对于开启了 HSTS 的站点，不建议也几乎不能 强行忽略。即使在一些场景下可以清理本地 HSTS 动态条目，若域名处于预加载名单，浏览器仍会一票否决。把强行继续当成方案，只会把你暴露在中间人攻击或钓鱼页面前。(HSTS Preload)

---

把工程思维落在你的具体报错上

你问题描述中提到的两点至关重要：ERR_CERT_AUTHORITY_INVALID 与 HSTS。这两者一起出现，意味着要么 你所在路径中有人在充当 chat.deepseek.com 的代理但证书不被 Chrome 信任，要么 站点侧证书链本身不满足 Chrome 根计划的要求。先按上面的 A/B 测试与 openssl/脚本检查，把问题定位到网络侧还是站点侧，接着再决定是找 IT 还是等待网站方修复。

如果你确认是本地或网络侧的问题，而又必须临时访问相关服务，现实可行的缓解方式只有两种：一是换到一条干净的网络（比如手机热点），二是用一台不受企业拦截策略影响的设备进行访问。不建议 通过导入不明来源的根证书去骗过浏览器，这会把整台机器的信任模型掀翻。

---

参考与延伸阅读

• Chrome 的 Your connection is not private 与 NET::ERR_CERT_AUTHORITY_INVALID 的通俗解释与常见排查方向，可作为用户侧自检清单。(Kinsta®)
• HSTS 的工作方式、Strict-Transport-Security 响应头、以及对不可绕过体验的解释。(MDN Web Docs)
• HSTS 预加载清单与其在各大浏览器中的共享，理解为何清缓存/删策略无效。(HSTS Preload)
• Chrome Root Program/Root Store 的政策与差异，理解为什么 Edge 可以但 Chrome 不行。(Chromium Blog)
• 站点端证书链缺失的诊断与修复，解释Verify return code 异常的根源。(SSL.com)
• 公用 Wi-Fi/企业网关的 TLS 拦截与 HSTS 冲突案例，帮助你识别是不是被中间设备挡了刀。(Fortinet Community)

---

如果你愿意，把你在两个网络下的 openssl s_client 输出或上面 Python 脚本的结果发我。我会按照链是否完整、颁发者是否在 Chrome 根计划里、证书是否过期、SAN 是否匹配这四个维度，给你一个明确的结论与后续动作建议。