如何修复 ERR_CERT_AUTHORITY_INVALID：完整指南
ERR_CERT_AUTHORITY_INVALID 是 Chrome 最常见的 SSL 警告之一。当浏览器无法将网站的 SSL 证书追溯到操作系统或浏览器内置的受信任根证书颁发机构（CA）时，就会出现该错误。Chrome 不会加载页面，而是显示"您的连接不是私密连接"，并将 NET::ERR_CERT_AUTHORITY_INVALID 标为根本原因。
该错误并不代表网站是恶意的 — 它仅仅表示 Chrome 无法验证证书的签发者。这种情况有几种正当原因：服务器使用了自签名证书、连接叶证书与受信任根的中间证书缺失、根 CA 已过期或被弃用、企业防火墙用自己的 CA 拦截流量、操作系统的 CA 证书包过时，或者证书被绑定到 Chrome 不再信任的机构。本指南将逐一解释这些原因，并提供完整的六步修复流程。
什么是 ERR_CERT_AUTHORITY_INVALID？
当浏览器连接到 HTTPS 网站时，服务器会在 TLS 握手期间发送其 SSL/TLS 证书。随后，Chrome 尝试从该叶证书出发，经过一个或多个中间 CA，构建一条通往其信任库中预装的根 CA 的信任链。如果这条链无法完成 — 因为中间证书缺失、根证书不被识别，或签发者完全不为人知 — Chrome 就会中止握手并抛出 ERR_CERT_AUTHORITY_INVALID。
区分相关错误很重要。ERR_CERT_DATE_INVALID 指向过期问题，而 ERR_CERT_COMMON_NAME_INVALID 指向主机名不匹配。ERR_CERT_AUTHORITY_INVALID 专门针对签发者的身份与可信度，而非证书上的日期或名称。正因如此，一张证书可能完全有效、未过期且签发给正确的域名，但当通往受信任根的链路断裂时，仍会触发此错误。
常见原因
六个根本原因几乎涵盖了 ERR_CERT_AUTHORITY_INVALID 的每一次出现。识别出哪一条适用，是通往修复的最快路径。
- 自签名证书：服务器使用自行生成的证书，没有任何公共根为其签名。常见于内部工具和开发环境。
- 缺少中间证书：叶证书有效，但服务器未发送将其桥接到受信任根所需的中间证书，因此无法构建信任链。
- 根 CA 过期或被弃用：最初为该链签名的根已过期或被移出 Chrome 的信任库 — 例如 2018 年被弃用的旧版赛门铁克根证书。
- 企业 MITM 代理：防火墙或安全设备用自己的 CA 对流量重新签名，而该 CA 未安装在你的机器上，因此 Chrome 看到陌生的签发者。
- 操作系统 CA 证书包过时：较旧的操作系统缺少验证较新证书所需的根，例如 Let's Encrypt 的 ISRG Root X1。
- 证书绑定到错误的 CA：应用级绑定期望特定的 CA，但证书由不同的机构重新签发，导致绑定不再匹配。
分步修复指南
按顺序执行以下六个步骤。前三步解决最常见的服务器端原因；后三步涵盖客户端和应用层问题。
1. 使用 OpenSSL 检查证书链
首先查看服务器实际发送的内容。使用 openssl s_client 连接并检查链中的每一张证书：
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null查看底部的 Verify return code 行。值为 0 (ok) 表示链受信任；其他任何值（如 unable to get local issuer certificate）都确认存在信任缺口。数一下证书块 — 健康的链至少发送叶证书加一张中间证书。
2. 识别自签名或不受信任的颁发者
检查叶证书的颁发者以了解谁为其签名：
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -subject如果颁发者和使用者相同，说明是自签名证书，默认没有浏览器会信任它。如果颁发者是真实的 CA 但验证仍失败，问题在于缺少中间证书或根证书库过时 — 继续后续步骤。
3. 安装缺失的中间证书
最常见的服务器端修复是提供完整链。从你的 CA 下载中间证书，将叶证书和中间证书合并为单个 fullchain.pem，并让 Web 服务器指向它：
cat example.com.crt intermediate.crt > fullchain.pem
# 重新加载服务器
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2在 Nginx 中将 ssl_certificate 设为 fullchain.pem；在 Apache 中将 SSLCertificateFile 设为 fullchain.pem。重新加载并用 openssl s_client 重新测试，直到验证码显示 0 (ok)。
4. 更新操作系统和浏览器的 CA 证书包
如果证书有效且链完整，但错误仅在一台机器上持续出现，说明本地信任库可能已过时。更新 CA 软件包和浏览器：
# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates
# RHEL / CentOS / Fedora
sudo dnf upgrade ca-certificates
# 更新 Chrome，然后检查版本
chrome://settings/help更新后重启计算机以加载新的根证书库。这能解决由近期新增的根（如 ISRG Root X1）或移除旧版根引起的错误。
5. 信任或绕过企业 MITM 代理
如果错误仅在公司网络出现，很可能是安全设备用自己的 CA 拦截了 HTTPS。检查颁发者即可确认 — 如果它以你的雇主或 Zscaler、Netskope、Fortinet 等厂商命名，就说明存在 MITM 代理。将代理的根证书安装到系统信任库，以便 Chrome 能验证重新签名的证书：
# Linux：将代理 CA 复制到信任库
sudo cp corporate-ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
# Windows：添加到"受信任的根证书颁发机构"存储区
certutil -addstore -f "Root" corporate-ca.crt如果无法安装该 CA，唯一安全的办法是更换网络或请 IT 发布证书。绝不要为了绕过警告而全局禁用证书验证。
6. 修复绑定到错误 CA 的证书绑定
当错误只出现在某个移动或桌面应用中，而 Chrome 中没有时，该应用很可能使用了证书绑定。证书由不同的 CA 重新签发后，存储的绑定不再匹配，应用便会拒绝连接。将绑定更新为新 CA 的公钥，或更好的做法是绑定到叶证书的 SPKI，并在过渡期间轮换绑定：
# 为新证书提取 SPKI 哈希
openssl x509 -in example.com.crt -pubkey -noout \
| openssl pkey -pubin -outform der \
| openssl dgst -sha256 -binary \
| openssl base64在应用更新中发布新绑定，并在重叠期内保持旧绑定有效，使现有安装继续工作直到用户升级。
SSL 诊断命令
下面的命令能让你全面了解证书、其证书链以及本地信任库。在出现错误的机器上从终端运行它们。
# 1. 打印服务器提供的完整证书链
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null
# 2. 显示有效期、颁发者、使用者和 SAN
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -dates -issuer -subject -ext subjectAltName
# 3. 对照系统信任库验证证书链
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt example.com.crt
# 4. Windows：列出受信任的根 CA
certutil -store Root | findstr /C:"Cert:"
# 5. Java：列出 JDK 信任的 CA
keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit
# 6. 检查某个根证书是否存在
trust anchor --list | grep -i "ISRG Root X1"快速参考表
用此表将症状匹配到其根本原因及相应的修复方法。
| 症状 | 原因 | 修复方法 |
|---|---|---|
| 仅你的机器看到错误 | 企业 MITM 代理或 CA 证书包过时 | 安装代理 CA（步骤 5）或更新操作系统（步骤 4） |
| 所有人都看到错误；证书来自真实 CA | 缺少中间证书 | 提供 fullchain.pem（步骤 3） |
| 错误仅出现在内部或开发站点 | 自签名证书 | 使用真实 CA 或在本地安装证书 |
| 证书续期后立即出现 | 新 CA 尚未受信任或绑定不匹配 | 更新绑定（步骤 6）或等待 CA 生效 |
| 新系统正常，旧系统报错 | CA 证书包过时，缺少较新的根 | 更新操作系统 CA 证书包（步骤 4） |
| 错误仅出现在某个应用，Chrome 中没有 | 证书绑定到错误的 CA | 将绑定更新为新 CA 的 SPKI（步骤 6） |
常见问题
看到 ERR_CERT_AUTHORITY_INVALID 时点击"继续访问网站"安全吗？
通常不安全。点击继续会关闭 Chrome 的保护，使你面临潜在的中间人攻击。仅在你能控制证书的受信任内部网络（如开发服务器）上绕过警告，绝不在公开网站或输入凭据时这样做。请先用上述步骤排查原因。
为什么错误在公司网络出现，在家里却没有？
你的公司很可能运行着 HTTPS 检查代理，用它自己的证书颁发机构对流量重新签名。在家里没有拦截，因此 Chrome 信任网站原有的证书。解决方法是将公司的根 CA 安装到你的信任库（步骤 5），IT 应提供该证书。
如何修复 localhost 上自签名证书导致的此错误？
使用 mkcert 生成受本地信任的证书，而非原始的自签名证书。mkcert 会将本地根 CA 安装到系统信任库，因此 Chrome 会接受它为 localhost 和任何开发域名签发的证书。或者，通过 ngrok 之类的隧道暴露开发服务器，以自动获得由 CA 签发的证书。
即使我的网站证书有效，过期的根证书也会导致 ERR_CERT_AUTHORITY_INVALID 吗？
会。如果最终为你的链签名的根 CA 已过期或被弃用，即使叶证书有效且未过期，Chrome 也无法构建受信任路径。典型例子是 2018 年对旧版赛门铁克根证书的弃用。解决方法是通过当前受信任的 CA 重新签发证书并提供新的链。
总结
ERR_CERT_AUTHORITY_INVALID 始终表示同一件事：Chrome 无法从服务器证书构建一条通往它所认可的根的信任链。原因几乎总是六种之一 — 自签名证书、缺少中间证书、根 CA 过期或被弃用、企业 MITM 代理、CA 证书包过时，或陈旧的证书绑定。按顺序执行这六个步骤：检查证书链、识别签发者、安装中间证书、更新信任库、处理代理，并修复绑定。
错误消除后，请保持证书自动续期、始终提供完整链，并定期更新操作系统以保持根证书库最新。少量的主动维护即可避免此警告干扰你的用户。