SSL证书过期怎么办？

约 8 分钟读完 1 阅
文章导读
SSL 证书过期后，最先该做的不是去面板上点「重新签发」，而是确认三件事：过期的是哪张证书、notAfter 具体是哪一天、这张证书被哪个进程或哪台设备实际加载。这三件事决定你接下来是续签、替换证书文件，还是只补一次 reload。在多节点、CDN 或反向代理的结构里，跳过确认直接重签，很容易只修好一台机器，其他地方照旧报错。
📋 目录
  1. Ⅰ SSL证书过期怎么办才能恢复
  2. Ⅱ SSL证书过期先定位在哪一层
  3. Ⅲ SSL证书过期：先看这四个位置
  4. Ⅳ SSL证书过期：按可能性从高到低排除
  5. Ⅴ SSL证书过期：改完怎么确认真的解决了
A A

SSL 证书过期后，最先该做的不是去面板上点「重新签发」，而是确认三件事：过期的是哪张证书、notAfter 具体是哪一天、这张证书被哪个进程或哪台设备实际加载。这三件事决定你接下来是续签、替换证书文件，还是只补一次 reload。在多节点、CDN 或反向代理的结构里，跳过确认直接重签，很容易只修好一台机器，其他地方照旧报错。

适用场景：浏览器提示证书已过期或有效期无效。操作动作：先用 openssl s_client 带 -servername 拉出服务端实际返回的证书有效期，再和源站配置里 ssl_certificate 指向的文件、云控制台证书页的到期时间做对比。验证方式：notAfter 变成新的日期，且 curl -I 与浏览器都不再报证书错误。风险边界：证书可能终止在 CDN 或负载均衡上，只改源站文件不会生效；容器或 Java 应用有独立的证书存储，改宿主机不等于改应用。

SSL证书过期怎么办才能恢复

在「SSL证书过期」这件事里，对应「恢复」的一步是：完成续签或替换证书，并让实际处理 TLS 的进程重新加载。判断是不是卡在这一步，用一条命令核对服务端真实返回的证书：

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

输出里的 notBefore / notAfter 就是这张证书的实际有效期。notAfter 早于当前 UTC 时间，说明确实是过期；notAfter 还在未来却照样报错，问题不在有效期，按第 2 节去定位层。顺便用 date -u 核对服务器和客户端的时间，客户端时间偏差也会触发同样的报错。

确认过期后，Certbot 管理的证书可以直接续签并重载（示例域名和 reload 命令按实际环境替换）：

certbot renew --cert-name example.com
nginx -t && systemctl reload nginx

Apache 一般是 systemctl reload apache2 或 httpd；证书由云厂商面板签发的，需要在面板里重新签发并部署到对应资源。只替换证书文件而不 reload，进程内存里仍是旧证书，这点在排查时最容易被忽略。

SSL证书过期先定位在哪一层

证书可能被四层中的任意一层终止，先看清是哪一层，再动手改，否则会在错误的位置反复折腾。

  • 客户端/终端层：检查本机 date -u 与服务端返回的 notAfter，排除终端时间错误造成的误报。
  • 边缘/接入层：域名解析到 CDN、SLB、WAF 时，证书通常由边缘节点持有。检查位置是云控制台的证书管理页，看证书 ID、绑定域名和到期时间字段。
  • Web 服务器/反向代理层：看 nginx -T 输出里 ssl_certificate 指向的文件，再对文件本身执行 openssl x509 -in /path/fullchain.pem -noout -dates。
  • 应用运行时层：Java 用 keytool -list -v -keystore your.jks 看别名下的有效期；容器镜像内置证书的，需要重建镜像而不是改宿主机文件。

判断依据很直接：命令带 -servername 拿到的那张证书，和源站配置文件里指向的文件不是同一张，说明前面还有一层在终止 TLS，应该去那一层处理。

SSL证书过期怎么办？

SSL证书过期：先看这四个位置

命令输出

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates

日志

grep -iE 'ssl|certificate' /var/log/nginx/error.log | tail -n 50
tail -n 50 /var/log/letsencrypt/letsencrypt.log

Apache 对应 /var/log/httpd/ssl_error_log 或 /var/log/apache2/error.log。

配置项

nginx -T 2>/dev/null | grep -nE 'server_name|ssl_certificate|ssl_certificate_key'

面板字段

云厂商证书管理页上的「到期时间」「绑定域名」「部署资源」三列，能直接看出证书有没有绑到当前实例；自建面板（如宝塔）在网站设置的 SSL 页显示证书到期时间和续签状态。有面板时以面板显示的资源为准，不要只改服务器上的文件。

SSL证书过期：按可能性从高到低排除

  1. 多台机器只续签了一台。确认动作：在每台机器上分别对证书文件执行 openssl x509 -noout -dates，比对 notAfter 是否一致；不一致就是没同步。处理：逐台续签，或统一从证书平台下发。
  2. 续签成功但没有 reload。确认动作：ls -l --time-style=full-iso 证书文件，对比 systemctl show nginx -p ActiveEnterTimestamp 的启动时间；进程启动早于证书更新就说明还没加载。处理：nginx -t 通过后 reload。
  3. 自动续签任务没跑或跑失败。确认动作：systemctl list-timers | grep -i certbot、crontab -l | grep -i certbot，再看 letsencrypt.log 末尾的报错。处理：HTTP-01 验证需要 80 端口可达，修好后再手动 renew 一次。
  4. 证书与访问域名不匹配。确认动作：openssl s_client -connect 服务器IP:443 -servername 实际域名，看返回的 subject 和 SAN 是否包含该域名；落到默认站点就是 SNI 没命中。处理：补 server_name 或为该域名单独配置。
  5. 证书链不完整。确认动作：浏览器正常但 Java、旧版 Android 报错时，检查配置引用的是 cert 还是 fullchain 文件。处理：改用包含中间证书的 fullchain。
  6. 客户端时间错误。确认动作：在报错的终端执行 date -u，与服务端时间比对。处理：校时后重试。

SSL证书过期：改完怎么确认真的解决了

先看服务端返回的新有效期，再看 HTTP 层是否通：

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates
curl -sSI https://example.com | head -n 5

页面侧再确认两处：浏览器地址栏的锁标识不再报错；云控制台证书管理页的到期时间字段已经变成新日期。观察时长建议至少覆盖下一次自动续签的执行时间点——如果续签任务在凌晨跑，就在那个时间之后复查一次 notAfter 是否再次更新，同时确认这段时间内错误日志里不再出现 SSL 相关条目。

改动前先备份，回滚才有东西可退：

cp -a /etc/nginx/conf.d/example.conf /root/example.conf.bak-$(date +%F)
cp -a /etc/letsencrypt/archive/example.com /root/example.com.cert.bak-$(date +%F)

回滚步骤：把备份文件覆盖回原路径，执行 nginx -t 确认语法通过，再 systemctl reload nginx 或 apache2，最后重跑上面的 openssl 命令核对 notAfter。需要说明的是，如果证书本身已经过期，回滚到旧证书并不会恢复可用性，回滚只针对配置改动和部署动作；真正的退路是保留一张尚未过期的证书文件，所以续签成功后不要急着删掉上一版可用证书。