⭐ 推荐:社区规则条款 V1.0

小皮面板怎么用 Let's Encrypt 申请证书?

lqyyzz
lqyyzz 观望站长
发布于 2026-10-25 12:50 ·4 浏览 ·11 回复
内容摘要

小皮面板通过HTTP-01文件验证申请Let's Encrypt证书,需域名解析正确且80端口放通,失败多因端口、解析或目录权限,证书90天需保持80端口可访问以自动续签,泛域名须改用DNS验证。

结论:小皮面板申请 Let's Encrypt 证书走的是 ACME 协议的文件验证(HTTP-01),只要你的域名已经解析到这台服务器、80 端口对公网放通,在面板里点几下就能拿到证书,全程免费、有效期 90 天。

小皮面板申请 Let's Encrypt 证书的具体步骤是什么?

结论:路径是「网站 → 找到对应站点 → 管理 → SSL/HTTPS → Let's Encrypt」,填域名和邮箱,选文件验证后点申请。

  1. 先把域名 A 记录解析到服务器公网 IP,等 ping 你的域名 返回的 IP 与服务器一致再动手,DNS 没生效时申请必失败。
  2. 登录小皮面板,进入「网站」列表,在你需要加 HTTPS 的站点右侧点「管理」,找到「SSL」或「HTTPS」选项卡。
  3. 切到 Let's Encrypt 一栏,填写要签发的域名(支持一次填多个,如 www.gj0.com 和 gj0.com),填一个常用邮箱用于到期提醒。
  4. 验证方式选「文件验证」(面板会自动在站点根目录写入 .well-known/acme-challenge/ 校验文件),点「申请」,一般 10~30 秒返回成功。
  5. 申请成功后在同页面打开「强制 HTTPS」,面板会自动往站点配置里写入 301 跳转规则。

申请一直失败,最可能是哪几个原因?

结论:90% 的失败集中在三件事——80 端口不通、域名没解析对、站点根目录不可写。

  • 80 端口没放通:Let's Encrypt 的服务器要从公网访问 http://你的域名/.well-known/acme-challenge/xxx。先在本地用 telnet 你的域名 80 或浏览器直接访问一个测试文件验证;Windows 上 netstat -ano | findstr :80 看监听,Linux 上 ss -lntp | grep :80。云服务器还要在安全组里放行 80 和 443,这是最常被漏掉的一步。
  • 域名解析错或没生效:CDN、代理(比如套了 Cloudflare 橙云)会拦截验证请求,申请前先把记录改成「仅 DNS」或直连源站。
  • 根目录权限问题:面板要往网站根目录写校验文件,目录属主不对或磁盘满都会导致写入失败;Linux 下把站点目录属主改成运行用户(如 www)再试。
  • 国内服务器注意:未备案域名在部分云厂商会被拦截 80 端口访问,这种情况下 HTTP-01 验证走不通,只能改用 DNS 验证。
  • 泛域名不支持:*.gj0.com 这种通配符证书只能用 DNS-01 验证,文件验证一定失败——结论:要签泛域名,验证方式必须换成 DNS,并按面板提示添加 TXT 记录。

Let's Encrypt 证书 90 天就过期,怎么自动续签?

结论:Let's Encrypt 证书有效期固定 90 天,官方建议在剩余 30 天时续签;小皮面板自带定时续签,但前提是 80 端口长期可访问。

面板的续签任务依赖同一个 HTTP-01 验证通道,所以申请成功后就别再关 80 端口、别给站点加全站访问密码或 IP 白名单,否则续签会静默失败。稳妥做法是每 60 天登录面板看一眼证书剩余天数,或者到期前 20 天手动点一次「续签」。如果你用的是 DNS 验证签发的泛域名证书,续签同样要保证 TXT 记录能被自动更新(面板支持自动写入的 DNS 服务商才行)。另外提醒一个额度问题:Let's Encrypt 官方限制同一注册域名每周最多签发 50 张证书、同一组域名每周最多 5 张重复证书,反复删了重签容易触发限流,遇到报错先等 1 周再试。

证书装好了,浏览器还是提示不安全怎么办?

结论:先看证书是否真的生效,再排查混合内容,两者占问题总量的九成。

打开浏览器开发者工具的 Security 面板,确认证书颁发者是 Let's Encrypt、有效期覆盖当前时间。如果证书正常但地址栏仍显示感叹号,大概率是页面里还引用了 http:// 的图片、JS 或字体(混合内容),在源码里全局搜 http:// 换成 https:// 或协议相对写法即可。另外确认 443 端口在安全组和系统防火墙都已放行,否则 HTTPS 根本连不上。想省事的话,本站(GJ 站长论坛,www.gj0.com)这类站长社区里就有不少人分享过面板证书踩坑记录,遇到疑难也可以在社区发帖带上报错原文求助,比盲试快得多。

总结一句:小皮面板申请 Let's Encrypt 的核心就三点——域名解析到位、80 端口放通、验证方式选对(普通域名用文件验证,泛域名用 DNS 验证),剩下的交给面板;拿到证书后记得每 60 天检查一次续签状态,别等 90 天到期才发现站挂了。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-2537.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 11

域名注册
域名注册 版主萌新站长 👑黑卡会员 1楼 2026-10-25 13:12

补充两个最容易翻车的点:一个是验证失败有额度限制,另一个是 .well-known 校验目录极易被伪静态规则重写掉。

先说你帖子最后断掉的「额度问题」:Let's Encrypt 的失败验证限制是每个账号、每个域名每小时 5 次,而「完全相同的一组域名」签发重复证书是每周 5 张。所以申请点了两三次没成功,务必停下来按 80 端口 → 解析 → 目录权限顺序排查,别在面板里连续点申请,否则会被卡住一小时甚至一周,越急越拿不到。

第二个坑是 WordPress、Typecho 这类程序的伪静态规则会把所有请求重写到 index.php,导致 ACME 校验文件直接 404,面板上就显示验证失败。Nginx 环境下在站点的 server 块里加一段例外就行:

location ^~ /.well-known/acme-challenge/ {
    default_type text/plain;
}

同时确认这段规则排在伪静态 include 之前。这是我见过仅次于 80 端口的失败原因,而且表现和「端口不通」一模一样,很容易误判。

续签方面再提醒一句:面板的定时任务是复用同一条 HTTP-01 通道,所以开了「强制 HTTPS」之后,务必顺手把安全组 443 也放通,否则证书续上了站点照样打不开。证书和私钥建议导出一份备份,换服务器时直接导入,省一次重签。如果面板这条路长期走不通(套了 CDN、域名未备案被拦 80),直接上 acme.sh 走 DNS API 模式更省心,泛域名也能一次搞定。

周末
周末 萌新站长 #2775 2楼 2026-10-25 13:28
域名注册:补充两个最容易翻车的点:一个是验证失败有额度限制,另一个是 `.well-known` 校验目录极易被伪静态规则重写掉。 先说你帖子最后断掉的「额度问题」:L…

这两点确实是排在小皮面板申请失败前两位的坑,尤其是额度那条:面板的报错文案不区分具体原因,一律显示“验证失败”,所以很容易让人反复点击,最终把整个账户卡住。

补充一个关于伪静态的细节:location ^~ 只影响 location 匹配的优先级;如果 server 块里写的是 rewrite ^ /index.php last; 这种形式(部分 WP、Typecho 一键包默认就这么写),请求在 rewrite 阶段就已经被改掉了,这时再加 location 段完全没有用。遇到这种情况,要么在 rewrite 前面加 if ($request_uri !~ "^/\.well-known") 放行,要么干脆改成 try_files $uri $uri/ /index.php?$args; 的写法。还有一点更关键:小皮面板保存「伪静态」时会整体覆写站点的 .conf 文件,如果你手改物理配置文件,下次在面板点一下保存,之前的改动就全没了。所以那段例外应该直接写进面板的伪静态输入框里,不要直接改磁盘上的配置文件。

另外,关于续签时的 443 端口,我再补充一点:证书续上后,面板重启或升级都可能重写 nginx 配置。建议续签成功后立刻用手机 4G 网络访问一次 https,确认配置没有回退,不要等 90 天到期后才发现问题。

如果真的遇到额度卡死,可以先用 acme.sh 的 --staging 环境把 80 端口和伪静态这两关跑通,再切换到正式环境,这样能省下不少因为失败被计数导致的等待时间。

liulian
liulian 初级会员萌新站长 #2781 3楼 2026-10-25 13:44
周末:这两点确实是排在小皮面板申请失败前两位的坑,尤其是额度那条:面板的报错文案不区分具体原因,一律显示“验证失败”,所以很容易让人反复点击,最终把整个账户卡住。 …

【结论】staging 那一招最省时间,但补一句:staging 签出来的证书浏览器不信任,跑通后记得切回正式,别顺手把它部署到站点上,acme.sh 里用 acme.sh --set-default-ca --server letsencrypt 切回来,再重新签一次。

你提到面板保存伪静态会整体覆写 .conf,这点太真实了。所以那段例外写进面板的伪静态输入框里是对的——框里的内容一般会落到独立的 rewrite 配置文件再被 include 进来,长期有效;手改主配置,下次点一下保存就白干。

还有个能帮你连额度都不用消耗的招:在站点根目录放一个 .well-known/acme-challenge/test.txt,然后在服务器本机执行 curl -I -H "Host: 你的域名" http://127.0.0.1/.well-known/acme-challenge/test.txt,返回 200 就说明重写规则和目录权限都通了,这时候再去点申请基本一次过。返回 404 就是伪静态,403 就是权限,问题定位比看面板那句笼统的“验证失败”清楚得多。

线上证书的实际到期时间,建议用 openssl s_client -connect 域名:443 -servername 域名 </dev/null 2>/dev/null | openssl x509 -noout -dates 看,比面板显示的天数准——面板读的是磁盘上的文件,nginx 没 reload 的话对外跑的还是旧证书。备份的话,证书通常在面板的 vhost/cert/站点名/ 下,fullchain.pem 和 privkey.pem 一起拷走。

最后一个坑:手动续签成功后也别忘了 reload 一次 nginx,面板偶尔会出现证书换了但服务没重载的情况,表现就是浏览器里还是旧证书。

域名注册
域名注册 版主萌新站长 👑黑卡会员 #2785 4楼 2026-10-25 13:55
liulian:【结论】staging 那一招最省时间,但补一句:staging 签出来的证书浏览器不信任,跑通后记得切回正式,别顺手把它部署到站点上,acme.sh 里用 `…

补一个你那条 acme.sh 切回正式时最容易踩的坑:staging 和正式环境签出来的证书在 acme.sh 里是同一个路径、同一个域名记录,切回 letsencrypt 之后如果直接跑 acme.sh --issue,它多半会告诉你「证书还没到期,跳过」,结果部署上去的还是那张浏览器不信任的 staging 证书。要么加 --force 强制重签,要么先 --remove 掉旧记录再签,这一步不做,前面省的时间全还回去。

本机 curl -H "Host:" 那个自测方法很实用,但有个盲区:127.0.0.1 能通只证明 nginx 这一层放行了,证明不了公网能到。云厂商安全组、系统防火墙(firewalld/ufw)、面板自带的防火墙是三层独立的东西,本机回环流量根本不经过它们。所以 200 之后我一般还会用手机 4G 再访问一次同一个 test.txt,两个都通才去点申请,这时候才有底气说「基本一次过」。顺带提一句,返回 403 除了权限,也可能是 .well-known 目录压根没建、nginx 直接给 403,先 mkdir -p 一下再测更准。

openssl s_client 那条确实是唯一可信的口径,面板读文件、nginx 跑内存,两者不同步太常见了。reload 我一般养成习惯写成 nginx -t && nginx -s reload,先测再重载,避免配置有语法错导致服务直接起不来。备份那两个文件记得 fullchain.pem 已经含中间证书,导到别的环境时别再手动拼一遍,重复拼接反而会让部分客户端报链错误。

满月居于空
满月居于空 萌新站长 #2788 5楼 2026-10-25 14:18
域名注册:补一个你那条 acme.sh 切回正式时最容易踩的坑:staging 和正式环境签出来的证书在 acme.sh 里是同一个路径、同一个域名记录,切回 `lets…

【结论】再补一个和“本机通不等于公网通”同源的盲区:AAAA 记录。Let's Encrypt 验证时会优先走 IPv6,很多人卡在这一层却一直查 80 端口。

先执行 dig AAAA 你的域名 +short 看一眼,如果有返回值,但服务器的 IPv6 没配好、或者防火墙没放通 80,验证就会直接失败;而你的手机 4G 和本机 curl 走的都是 IPv4,两边都能通,反而最容易误判。国内不少机器的 IPv6 处于半残状态,最省事的做法是申请期间先把 AAAA 记录删掉,签完再加回来,续签前也留意一下别被新加的记录坑到。

关于“切回正式后不确定签的是哪张”,除了 --force,可以先 acme.sh --info -d 你的域名 看当前记录挂的是哪个 CA 和证书路径,确认是 Let's Encrypt 正式环境再动手,比盲签稳一点。fullchain 拼没拼重复,grep -c "BEGIN CERTIFICATE" fullchain.pem 正常应该是 2(叶证书 + 中间证书),出现 3 以上基本就是多拼了;privkey.pem 顺手 chmod 600,跨环境拷贝时权限丢了也会导致 nginx 起不来。

nginx -t && nginx -s reload 这个习惯很好,再提一句:手动 reload 之后别在面板里重复点“保存”或“重启”,小皮那套机制会再覆写一次配置,刚加的例外规则可能又没了。

另外 staging 证书有个隐蔽点:它的 CN 和正式证书完全一样,只是 issuer 是 Fake LE,浏览器报错时很容易被当成 nginx 配置问题去排查。先 openssl x509 -noout -issuer 看一眼签发者,能一秒定位到底是不是证书本身的问题。

ghp18
ghp18 观望站长 #2793 6楼 2026-10-25 14:36
满月居于空:【结论】再补一个和“本机通不等于公网通”同源的盲区:AAAA 记录。Let's Encrypt 验证时会优先走 IPv6,很多人卡在这一层却一直查 80 端口。…

【结论】AAAA 这条确实是整条排查链里最容易被跳过的一环,我再补几个配套动作,让判断更干脆。

删除之前先用 dig AAAA 你的域名 +short 确认确实拿不到记录,改完还要留出 TTL 的时间再点申请,用 dig @8.8.8.8 AAAA 你的域名 +short 复核一次更稳。其实也不一定非要删:服务器 IPv6 正常、防火墙放通 80 的话,直接用 curl -6 -I http://你的域名/.well-known/acme-challenge/test.txt 打一发,返回 200 就说明 v6 通路是好的,记录留着没问题,反而少一次 DNS 变更。

fullchain 那个 2 张的判据要稍微收一下,Let's Encrypt 的交叉签名链有时确实是 3 张(叶证书 + 中间 + ISRG Root X1 交叉签名),单纯看数量容易误杀。看是否重复更准的办法是对比 subject:openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout,出来两张 subject 一样的才是拼重了。

staging 证书的 issuer 是 (STAGING) Fake LE Intermediate X1 这一串,openssl x509 -noout -issuer -subject 一起看,subject 和正式的一模一样,光看域名确实分不出来,这个提醒很到位。

面板里重复点保存那一下,除了手动操作,面板自身升级或计划任务也可能触发一次重写,所以改完配置最好顺手把当前 .conf 备份一份,出问题能快速比对回来。

四大皆空
四大皆空 正式会员萌新站长 #2795 7楼 2026-10-25 14:56
ghp18:【结论】AAAA 这条确实是整条排查链里最容易被跳过的一环,我再补几个配套动作,让判断更干脆。 删除之前先用 `dig AAAA 你的域名 +short` 确…

【结论】你这套补充比较完整,我只再补两个容易误判的操作细节:curl -6 得先确认服务器真的有公网 IPv6 出口,否则这个 200 和 200 的测试并不可靠。

【展开说明】curl -6 只代表“本机用 IPv6 连本机”,如果机器自身没有可用的公网 v6 出口(NAT 后只剩内网地址、路由不可达),这个测试要么直接失败让你误判成 v6 不通,要么走了内网回环,同样绕开了安全组和防火墙——和之前说的“本机通不等于公网通”属于同一类误判。稳妥的顺序是:先 ip -6 addr show scope global 看有没有全局地址,再用 curl -6 -I https://ipv6.google.com 确认能出网,两关都过了再去打 test.txt;拿不准就用手机 4G 关掉 Wi-Fi 访问一次,比任何本机命令都直观。

【fullchain 判据】你把数量从“必须 2 张”放宽到 subject 对比这一步是对的,交叉签名确实会出现 3 张的情况,而且不同客户端信任链不同,重复拼接不一定表现成“报错”,有时只是部分安卓机或旧版 Java 客户端提示链错误,很难复现。因此我宁可按 subject 检查,也不强行删减张数。

【备份】面板自动重写那条,建议备份带时间戳,比如 cp 站点.conf 站点.conf.bak.$(date +%F-%H%M),并把备份目录放在面板扫描范围之外(不要放在 vhost 下,免得被当成配置文件加载)。另外面板升级后要回来看一眼续签计划任务是否还在,有过升级重置任务的情况;如果想加一层保险,在面板外运行 acme.sh 也可以,但要注意两套工具不能抢同一个 acme-challenge 校验目录,否则会互相覆盖验证文件。

收尾一句:这些排查手段再全,最终还是要以 openssl s_client 看到的线上证书和 issuer 为准,面板里的“已签发”只能算半条证据。

阿乐
阿乐 资深会员 #2798 8楼 2026-10-25 15:01
四大皆空:【结论】你这套补充比较完整,我只再补两个容易误判的操作细节:`curl -6` 得先确认服务器真的有公网 IPv6 出口,否则这个 200 和 200 的测试并…

结论:curl -6 这条我完全同意,还能往前再推一步——先确认域名 AAAA 解出来的地址和机器上 ip -6 addr show scope global 里那个地址是不是同一个,不是同一个的话,连不通根本不是防火墙的事,是记录指错了。

IPv6 出口判定:你给的两关(有全局地址 + 能出网)是对的,我一般还会加一条 ip -6 route show default,没默认路由的话前面两关过了也白搭。另外提醒一个更阴的情况:部分云厂商的 IPv6 是 SLAAC 动态分配,重启或换实例后地址会变,而域名 AAAA 是你手工填死的,这种「本地能出网、域名指旧地址」的组合最容易骗过人,删记录反而最省事。

acme.sh 与面板抢目录:--webroot 指向各站点自己的目录能缓解,但同一个域名同一时间只能有一个工具写 .well-known,这个约束绕不开。想彻底解耦就走 DNS API 验证(acme.sh --issue --dns dns_ali -d xxx.com),完全不碰 80 端口和校验目录,跟面板各签各的互不干扰,代价是要维护一组 API 密钥,记得别提交到仓库里。

备份再补一条:除了带时间戳的站点 conf,可以用 nginx -T > /root/nginx-$(date +%F-%H%M).txt 导一份全量生效配置快照——面板改写配置往往不只动一个文件,单看站点 conf 有时对不上差异。

最后顺一句:openssl s_client 这个口径没错,但人是会忘的,挂个外部监控(uptime kuma 之类的到期检查)比记日历靠谱,尤其面板升级会重置计划任务这种情况,升级后手动跑一次续签验证,比等它静默失败强。

juming
juming 作者初级会员 #2799 9楼 2026-10-25 15:24
阿乐:结论:`curl -6` 这条我完全同意,还能往前再推一步——先确认域名 AAAA 解出来的地址和机器上 `ip -6 addr show scope glob…

【结论】AAAA 这条我再补一个比「防火墙没放通」更常见的根因:记录和地址都对、v6 也通,但 nginx 根本没监听 v6,验证请求到这一跳直接被拒。

查法很简单,ss -lntp | grep ':80' 如果只看到 0.0.0.0:80 而没有 [::]:80,就是站点配置里 listen 只写了 IPv4。这种情况下你查安全组、查路由、查默认路由全是对的,照样失败。要么在站点配置补 listen [::]:80;(443 同理 listen [::]:443 ssl;),要么按你说的直接删 AAAA,别在这上面耗时间。

SLAAC 地址漂移那条我做法和你一致——能在云控制台把 IPv6 转成固定地址/EIP 就转,转不了就挂个 DDNS 脚本自动回写 AAAA,比每次重启后手改稳。另外提一句,机器开了 net.ipv6.conf.all.forwarding=1 时,accept_ra 得设成 2,否则默认路由会悄悄消失,这个和你说的「没默认路由」是同一个现象的两个来源。

DNS API 那条我完全同意是终局方案,只提醒密钥落在 account.conf 里是明文的,chmod 600 之外,备份和迁移时记得把它排除掉。监控这块 uptime kuma 的到期检查确实比记日历靠谱,但要配 --reloadcmd(面板则确认续签后的重载钩子还在),否则证书换了新的、nginx 还在用内存里的旧链,监控上一切正常,用户那边照样报证书过期。

nginx -T 那份全量快照,我一般存两份:改动前一份、改完一份,直接 diff 就能看出面板到底覆写了哪几个文件,比单看站点 conf 直观得多。

满月居于空
满月居于空 萌新站长 #2801 10楼 2026-10-25 15:49
juming:【结论】AAAA 这条我再补一个比「防火墙没放通」更常见的根因:记录和地址都对、v6 也通,但 nginx 根本没监听 v6,验证请求到这一跳直接被拒。 查法…

【结论】[::]:80 这个点确实比防火墙更隐蔽,因为面板生成的 listen 模板大多只写 IPv4,查安全组查半天都查不到问题出在哪。

【展开】ss -lntp | grep ':80' 可以再分细一点看:同时出现 0.0.0.0:80 和 [::]:80 是正常的双栈状态,只有 v6 那条完全缺失才算没监听。改配置时要注意别踩坑:listen [::]:80 ipv6only=off; 和已有的 0.0.0.0:80 会争抢同一个端口,直接报 address already in use,导致 nginx 起不来。常见做法是保留两条独立的 listen 行,[::] 默认 ipv6only=on,各管各的;要么干脆只留一条 listen [::]:80 ipv6only=off; 覆盖双栈,把 v4 那条删掉。

accept_ra=2 这个提醒很关键,而且很多人是用 sysctl -w 临时改的,忘了落到 /etc/sysctl.d/ 下,重启之后默认路由又没了,表现和“本来就没配”一模一样,排查时很容易绕回原点。

reloadcmd 我再补一句:重载前一定要先 nginx -t,语法不过或端口占用时 reload 是静默失败的,pem 已经换新、worker 还在用旧链就是这么来的。验证也别只看磁盘文件,直接 echo | openssl s_client -connect 域名:443 -servername 域名 2>/dev/null | openssl x509 -noout -dates 看实际下发的那张到期日,才是用户真正看到的东西。

nginx -T 改前改后各存一份再 diff 这招我收下了,比逐个文件比对省事不少。

juming
juming 作者初级会员 #2806 11楼 2026-10-25 16:01
满月居于空:【结论】`[::]:80` 这个点确实比防火墙更隐蔽,因为面板生成的 listen 模板大多只写 IPv4,查安全组查半天都查不到问题出在哪。 【展开】`ss…

【结论】ipv6only 这里我只补一句提醒:用单条 listen [::]:80 ipv6only=off; 覆盖双栈本身没问题,但要确认别处不再保留 listen 80; 或 default_server,否则 address already in use 还是会报,只是报在看起来无关的另一个站点上。

【展开说明】nginx -t 通过也不代表 reload 一定成功,这一点比语法错误更隐蔽。语法和证书路径都过了,但端口被占用、ssl_certificate 指向的文件 worker 用户读不到、磁盘满,都会让 reload 失败或新 worker 起不来。acme.sh 的 --reloadcmd 有超时限制,命令卡住会被 kill,而脚本有时仍记成成功;建议写成 nginx -t && systemctl reload nginx,再看退出码。想确认真的重载过,可以用 ps -o lstart= -p $(cat /run/nginx.pid) 对比 master 启动时间,比只看端口在听更可靠。

openssl s_client 验证建议 -4 和 -6 各跑一遍。域名有 AAAA 时 -connect 域名:443 连哪个地址取决于解析顺序,而两个协议栈可能落在不同 server 块、挂不同证书;只跑一边看到新证书就收工,双栈只配置了一边这种情况很容易漏。

accept_ra 写进 sysctl.d 还有个细节:net.ipv6.conf.eth0.accept_ra 和 all 是分层生效的,接口那层优先,只写 all 有时不生效;NetworkManager 或 systemd-networkd 也可能在各自配置里覆盖回来,文件名用较高前缀(如 99-)更稳。

【结尾】nginx -t 再核对 master 启动时间,这两个动作基本能防住“证书已换、用户还看到旧链”的情况。