DV证书根证书过期导致客户端报错？解决方案来了！

　　很多用DV证书的朋友遇到过这种情况：网站明明刚续了费、证书也在有效期内，偏偏有人反馈“连接不安全”或“证书已过期”。这时候第一反应往往是“证书是不是出问题了”，但查了一圈发现证书本身没问题。实际上，报错的根子不在你的证书，而在客户端的根证书信任库。

　　HTTPS的信任体系是链式的：服务器证书由中间证书签发，中间证书由根证书签发。客户端浏览器或App在验证证书时，会沿着这条链往上查，最终必须找到一个它自己信任的根证书。如果这个根证书在客户端的信任库里已经过期或被移除，整条信任链就断了，报错就来了。

　　DV证书因为申请门槛低、签发快、大多是免费的，普及率非常高。但也正因为它常用的是Let‘s Encrypt这类自动化CA，根证书的轮换频率和影响面也更大。最近几年几次大规模根证书过期事件，波及面最广的就是DV证书用户。

　　近期的几起“根证书过期”大事件

　　Let's Encrypt：DST Root CA X3过期

　　Let's Encrypt的证书最初依赖DST Root CA X3这个交叉根来获得广泛信任——因为ISRG Root X1当时还没被所有操作系统内置。DST Root CA X3于2021年9月30日过期后，Let's Encrypt的证书就必须依赖ISRG Root X1来验证了。

　　问题在于：ISRG Root X1只在较新版本的操作系统中才被内置信任。老系统用户(比如Windows XP SP3以下、macOS 10.12.1以下、Android 7.1.1以下、Java 8u141以下)仍然只认DST Root CA X3，不认ISRG Root X1。于是这些用户访问任何使用Let's Encrypt证书的网站都会报错。

　　DigiCert：G1根证书即将停用

　　DigiCert的情况类似。根据Mozilla的新信任策略，可信根证书生成后每15年需要更换一次。DigiCert的旧根(G1根)将陆续被Mozilla停止信任：DigiCert Global Root CA将于2026年4月15日失效。

　　2024年12月1日之后签发的DigiCert DV证书将使用新的G2根签发。新证书在主流PC浏览器上没问题，但App、IoT终端、老版本操作系统等非浏览器环境可能没有预置G2根证书，就会出现验证失败。

　　GlobalSign：中间CA更换导致续费证书不受信任

　　2019年5月27日，GlobalSign更新了签发SSL证书用的中间CA——从旧的R1根切换到R3根。结果是：在此日期后续费的DV和OV证书，在老系统上可能不被信任，因为老系统里没有R3根。

　　报错什么样?怎么识别

　　客户端报错的形式因环境而异：

　　浏览器端：

　　Chrome/Edge：显示“您的连接不是私密连接”，NET::ERR_CERT_AUTHORITY_INVALID

　　Firefox：显示“警告：检测到潜在的安全风险”，SEC_ERROR_UNKNOWN_ISSUER

　　证书详情里提示“无法将这个证书验证到一个受信任的证书颁发机构”

　　命令行工具(如wget/curl)：

ERROR: cannot verify example.com's certificate, issued by '/C=US/O=Let's Encrypt/CN=R3':
Issued certificate has expired.

　　Java应用：抛出SSLHandshakeException，提示PKIX path building failed或unable to find valid certification path to requested target。

　　关键判断原则：

　　你的证书本身在有效期内(检查openssl x509 -in yourcert.pem -noout -dates)

　　报错只出现在部分老设备上，新设备正常

　　报错信息指向根证书或中间证书

　　基本确定是客户端根证书信任库问题，而不是你服务器证书的问题。

　　解决方案：按场景选，对号入座

　　方案一：升级客户端系统(治本)

　　这是最干净、最长远的解决方案。更新系统的CA证书包，让新根证书自动纳入信任库，未来类似的CA变更也能自动适配。

　　实际操作(以Linux服务器为例)：

# CentOS / RHEL
yum upgrade openssl gnutls ca-certificates

# Ubuntu / Debian
apt upgrade openssl libgnutls30 ca-certificates

　　升级完成后重启服务即可。

　　方案二：手动导入缺失的根证书

　　如果系统版本太老、无法升级，或者升级成本太高，可以手动把缺失的根证书导入客户端的信任库。

　　Let's Encrypt用户需要导入的根证书：ISRG Root X1(PEM格式可从Let's Encrypt官网下载链获取)。

　　Windows操作：

1. 按Win+R，输入certmgr.msc打开证书管理器
2. 找到“受信任的根证书颁发机构”→“证书”
3. 右键→所有任务→导入，选择下载的根证书文件
4. 按提示完成导入

　　Linux(update-ca-certificates方式)：

1. 将根证书(.crt格式)放入/usr/local/share/ca-certificates/
2. 执行sudo update-ca-certificates
3. 重启服务

　　Java应用(使用keytool导入JVM信任库)：

sudo keytool -import -alias isrgrootx1 -keystore $JAVA_HOME/lib/security/cacerts -file ISRG_Root_X1.pem -storepass changeit

　　方案三：针对过期的旧根证书做“移除”操作

　　有些场景下，系统同时存在新旧两个根证书，而客户端优先尝试了过期的旧根，导致验证失败，即使新根已经在信任库中也没被使用。

　　解决办法是显式禁用或删除过期的旧根证书。

　　Linux(以DST Root CA X3为例)：

# 编辑ca-certificates配置文件
vi /etc/ca-certificates.conf
# 在 mozilla/DST_Root_CA_X3.crt 这一行前加 ! 禁用
!mozilla/DST_Root_CA_X3.crt

# 更新证书链
update-ca-certificates

# CentOS 7+ 还需额外执行
cp /etc/pki/ca-trust/extracted/cadir/DST_Root_CA_X3.pem /etc/pki/ca-trust/source/blacklist/
update-ca-trust

　　Windows：

1. 打开证书管理器(certmgr.msc)
2. 在“受信任的根证书颁发机构”和“不信任的证书”中搜索DST Root CA X3
3. 删除该证书

　　Java：

sudo keytool -delete -alias dstrootcax3 -cacerts -storepass 'changeit'

　　方案四：更换为付费证书(推荐给生产环境)

　　如果不想跟根证书轮换的节奏长期纠缠，换一张有更广泛兼容性的付费证书是省心的选择。付费证书品牌(如DigiCert、Sectigo)通常有更成熟、更广泛预置的根证书体系，兼容性覆盖更全面。有效期也更长(一年)，不像Let's Encrypt每90天就要续一次。

　　方案五：临时绕过(仅限调试，绝对不要用于生产)

　　可以用--no-check-certificate临时跳过验证来做测试。但这个做法只适合排查问题时的临时手段，线上环境开启等于把HTTPS的保护完全撤掉。

# wget跳过证书验证
wget --no-check-certificate https://你的域名

# curl跳过证书验证
curl -k https://你的域名

　　排查和修复流程：按这几步走

　　1. 确认问题类型：检查报错信息和客户端环境，判断是否根证书过期导致。

　　2. 确定缺失的根证书：根据报错中显示的CA信息(Let's Encrypt的ISRG Root X1、DigiCert的G2根、GlobalSign的R3根等)，定位需要补充或更新的根证书。

　　3. 选修复路径：

• 能升级系统 → 执行系统更新(方案一)
• 不能升级但能手动导 → 导入缺失根证书(方案二)
• 存在旧根干扰 → 禁用/删除旧根(方案三)
• 生产环境求稳 → 换付费证书(方案四)

　　4. 验证修复：在原先报错的客户端上重新访问，确认报错消除。

　　5. 监控：关注官方公告，了解根证书或中间证书的变更通知，提前准备。

　　记住一句话：根证书过期不等于你的网站证书过期，问题出在客户端不信任签发链的最顶端。 你不需要重新签证书，只需要让客户端“认识”签发证书的那个根就行了。