最近处理一个 HTTPS 证书自动续期的问题现象非常典型certbot renew正常跑完进程退出码是 0日志里也出现类似Running deploy-hook command的输出但打开站点一看证书还是旧的那张有效期没有变化甚至浏览器还在报证书过期。更迷惑的是手动执行nginx -s reload命令同样返回 0可 Nginx 进程和线上证书好像完全没动。这个组合可以浓缩成一句话Nginx reloaded nothing. Certbot still exited 0。它真正想表达的问题是工具链的每个环节都“返回成功”但最终结果没有落到证书加载上。原因通常是把三件事混为一谈了Certbot 的成功退出、reload 指令的信号发送、Nginx master 进程对配置和证书的实际加载。这篇文章会围绕 Certbot Nginx 的证书续期场景把如何判断证书是否真的生效、如何验证 reload 是否真的发生、如何配置自动续期后自动 reload、以及退出码 0 但站点无变化时该怎么查完整过一遍。适合自己维护 Nginx 反代、用 Lets Encrypt 证书或者刚接手别人定时证书任务的运维和开发。1. 问题定位速览先给一张速览表把这个问题涉及的关键项和判断基线列清楚。排查项说明问题现象certbot renew/nginx -s reload均返回 0但站点仍使用旧证书涉及组件Certbot、Nginx、Lets Encrypt 证书、systemd / crontab 定时任务exit code 0 的真实含义只表示 Certbot 流程执行完毕或证书未到续期时间不代表证书已加载进 NginxNginx reload 的真实行为向 master 进程发送信号master 先做配置校验校验失败则保留旧配置核心验证手段nginx -t、nginx -T、openssl x509、curl -vI、日志时间戳自动化修复方向deploy hook 或--renew-hook中执行systemctl reload nginx适合读者使用 Nginx 反代 Lets Encrypt 证书的运维和开发这里最需要先纠正的判断是exit code 0 是流程状态不是结果状态。Certbot 返回 0只能说明它自己的执行路径走完了既不表示“一定换了证书”也不表示“Nginx 已经加载了证书”。下面拆开讲。2. 为什么“退出码 0”会骗人Nginx reloaded nothing. Certbot still exited 0这个组合通常对应三种完全不同的底层情况。2.1 证书根本没到续期时间Certbot 默认只有在证书剩余有效期不足 30 天时才会尝试续期。如果你在证书还有 80 天到期时执行certbot renew日志里会出现Certificate not yet due for renewal; no action taken.然后进程退出码依然是 0。此时没有新证书写入也没有 reload 的必要——“reloaded nothing”是完全正常的。这种场景最容易让人误判因为定时任务每天都会“成功”执行但实际什么都没做。排查方式是看certbot certificates输出的到期时间而不是只看退出码。2.2 证书续期成功但 Nginx 没有重新加载如果证书到了续期窗口Certbot 会生成新证书并更新/etc/letsencrypt/live/example.com/下的软链。但注意Certbot 默认只负责写证书文件不负责通知 Nginx 重载。只有两种情况下它会主动 reload使用certbot --nginx插件申请或续期证书时插件会直接修改 Nginx 配置并触发 reload配置了 deploy hook / reload hook。如果你用certbot certonly拿证书再手动在 Nginx 里写ssl_certificate路径那么certbot renew永远不会去碰 Nginx。证书文件更新了Nginx 进程还在旧证书上跑直到你手动 reload 或重启。2.3nginx -s reload返回 0但配置实际没加载这是最隐蔽的一种情况。很多人看到“Nginx reloaded nothing”就怀疑是 Nginx 没执行 reload但实际上命令执行了只是被 master 进程拒绝了。nginx -s reload做的事情是向 master 进程发送 HUP 信号。master 收到信号后会先对配置文件做一次nginx -t类似的语法检查如果检查失败master 会拒绝重新加载并在错误日志里写入类似[emerg] ssl_certificate directive is duplicate in /etc/nginx/conf.d/example.conf [notice] signal process started这种情况下nginx -s reload命令本身的退出码仍然是 0因为信号已经成功发送了。但实际结果是“reloaded nothing”。这就是为什么验证链路不能只看命令退出码。3. 先确认证书本体的真实状态不管日志怎么显示第一步先查证书本身。通过下面一组命令把证书有效期、软链指向、续期记录看清楚。# 查看 Certbot 管理的所有证书和到期时间 sudo certbot certificates # 直接查看某个证书文件的到期时间 sudo openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/fullchain.pem # 查看 live 目录下软链指向哪个 archive 文件 ls -l /etc/letsencrypt/live/example.com/判断要点如果certbot certificates显示证书还有 60 天且最近一次续期记录时间很旧说明还没到续期窗口exit code 0是“正常跳过”。如果ls -l显示软链指向的archive/example.com/certN.pem序号没有变化说明续期根本没发生。如果软链序号变化了但openssl看到的证书序列号和线上访问到的证书序列号不一致问题就出在 Nginx 加载环节。不要跳过这一步。很多排错浪费时间就是因为一上来就改 Nginx 配置结果证书其实没续上。4. 检查 Nginx 到底加载了哪张证书确认证书文件更新之后下一步是确认 Nginx 加载的证书和磁盘上的证书是否一致。这里有两种常用方式。4.1 看 Nginx 实际配置指向的证书路径sudo nginx -T | grep -E ssl_certificate|server_name重点看两个地方ssl_certificate是否指向/etc/letsencrypt/live/example.com/fullchain.pem这种 live 软链路径ssl_certificate_key是否指向对应的privkey.pem。如果配置指向的是/etc/letsencrypt/archive/example.com/cert1.pem这种绝对路径就会有一个隐患续期后 Certbot 会生成cert2.pem并更新 live 软链但 Nginx 配置里写死的老路径文件可能没有变。后续续期会出现“文件换了服务还是旧的”。更稳妥的做法是 Nginx 配置统一写 live 软链路径让 Certbot 的续期逻辑接管文件切换。4.2 对比线上证书和本地证书的序列号# 从线上抓取当前站点实际使用的证书 echo | openssl s_client -connect example.com:443 -servername example.com 2/dev/null \ | openssl x509 -noout -serial -enddate # 查看本地证书文件 sudo openssl x509 -noout -serial -enddate -in /etc/letsencrypt/live/example.com/fullchain.pem如果两边的serial不一致说明 Nginx 还在用旧证书。这个对比是判断“reload 是否真正生效”最直接的手段比盯着进程和日志更可靠。5. reload 的正确姿势与验证方法如果确认证书文件已经更新、Nginx 还在用旧证书接下来要做就是一次真正可靠的 reload。5.1 先测试配置再发送 reloadNginx 的 reload 并不是无条件的。master 收到 HUP 信号后会先校验配置文件校验失败就继续沿用旧配置。所以推荐把配置测试和 reload 串起来执行# 先校验配置 sudo nginx -t # 校验通过后再 reload sudo nginx -s reload如果担心命令之间的失败传播写成一行也可以sudo nginx -t sudo nginx -s reload但要注意这个写法里nginx -s reload的退出码依然不能代表真实加载结果只能代表信号发送成功。真正要确认加载结果还需要看日志和线上证书。5.2 systemd 环境的 reload大多数发行版用 systemd 管理 Nginx推荐使用systemctl reload nginx而不是直接发信号。它走的是服务单元里的ExecReload配置通常已经包含了配置校验逻辑sudo systemctl reload nginx执行后可以用下面几条命令确认 master 有没有重新初始化# 查看 master 进程启动时间reload 后时间应更新 ps -o lstart -p $(cat /run/nginx.pid) # 查看 Nginx 相关进程的存活时间 ps -eo pid,ppid,etime,cmd | grep nginx再配合第 4 节里的openssl s_client对比证书序列号就能确认 reload 真的生效了。5.3 检查 Nginx 错误日志如果 reload 后证书序列号还是没变优先看错误日志sudo tail -n 50 /var/log/nginx/error.log常见现象有[emerg]开头配置有致命错误reload 被拒绝[alert] cannot load certificate证书文件权限或路径有问题[notice] reconfiguringmaster 已经开始重新加载说明信号生效了。6. Certbot 自动续期时自动 reload解决了手动 reload 的问题接下来处理自动化场景。很多人配置了certbot renew的定时任务但定时任务里没有 reload导致证书续期成功但站点一直用旧证书直到某天浏览器报警。6.1 通过 deploy hook 实现续期后 reloadCertbot 支持在续期成功后执行 deploy hook。推荐写在 cli.ini 里避免命令行参数遗漏# /etc/letsencrypt/cli.ini deploy-hook systemctl reload nginx或者手动执行时用参数指定sudo certbot renew --deploy-hook systemctl reload nginx这里的要点是deploy-hook只在证书真正续期成功时执行。如果证书还没到续期时间hook 不会运行所以不会出现误 reload。如果希望无论是否续期都强制 reload可以在 systemd 服务的ExecStartPost里写后面会提到。6.2 通过 systemd timer 做定时续期推荐用 systemd timer 而不是 crontab因为可以配合日志系统统一管理。创建两个文件# /etc/systemd/system/certbot-renew.service [Unit] DescriptionCertbot certificate renewal Afternetwork-online.target [Service] Typeoneshot ExecStart/usr/bin/certbot renew --quiet ExecStartPost/bin/systemctl reload nginx# /etc/systemd/system/certbot-renew.timer [Unit] DescriptionRun certbot renewal daily [Timer] OnCalendar*-*-* 03:17:00 RandomizedDelaySec3600 Persistenttrue [Install] WantedBytimers.target然后启用 timersudo systemctl daemon-reload sudo systemctl enable --now certbot-renew.timer sudo systemctl status certbot-renew.timer这个方案里ExecStartPost的作用是certbot renew只要退出码为 0无论是否真的续期都会触发一次systemctl reload nginx。Nginx reload 本身成本很低不会中断现有连接所以每天多 reload 一次完全可接受。注意ExecStart和ExecStartPost的路径要按实际安装位置调整snap 安装的 certbot 路径通常是/snap/bin/certbot。6.3 crontab 替代方案如果习惯用 crontab等价写法是# certbot 每天 3 点执行--quiet 表示只输出错误 15 3 * * * /usr/bin/certbot renew --quiet --deploy-hook /usr/bin/systemctl reload nginxcrontab 方式的缺点是没有独立的日志单元排查时需要自己把输出重定向到文件。建议至少写成15 3 * * * /usr/bin/certbot renew --deploy-hook /usr/bin/systemctl reload nginx /var/log/certbot-renew.log 217. Nginx reload 的系统行为与性能观察很多第一次接触 Nginx reload 的人会担心reload 会不会造成断连实际上 Nginx 的 reload 是平滑热更新机制。整个流程是这样的master 收到 HUP 信号后先校验配置校验通过后启动一组新的 worker 进程新 worker 使用新配置、新证书旧的 worker 继续处理已有的连接处理完自然退出。所以对客户端来说HTTP/HTTPS 连接不会中断正在下载中的文件也不会被切断。在性能观察方面有几点值得注意reload 本身开销极小通常毫秒级完成不会产生明显负载如果站点存在大量长连接比如 WebSocket 或 keepalive 时间很长旧 worker 会存活较久内存中会同时保留新旧两份证书上下文如果证书文件权限有问题新 worker 启动时会报cannot load certificate此时 master 会回滚到旧配置线上依然是旧证书。观察指标用这几条命令就够# 查看 443 端口监听进程 sudo ss -lntp | grep :443 # 查看 Nginx worker 数量和存活时间 sudo ps -eo pid,ppid,etime,cmd | grep nginx # 查看 reload 相关日志 sudo journalctl -u nginx --since 10 minutes ago这些命令的价值在于在 reload 前后各执行一次通过对比能直接判断 reload 是否真的发生。8. 常见问题与排查方法下面把这个问题最常见的几种表现、原因和处置方式整理成一张表。问题现象可能原因排查命令解决方案exit code 0 但没有任何新证书未到续期时间sudo certbot certificates等待自动续期或确认需求后用--force-renewalnginx -s reload返回 0 但配置没变配置校验失败master 拒绝 reloadsudo nginx -t检查 error.log修复配置再 reload证书文件更新了页面仍是旧证书reload 未执行或 reload 目标错误openssl s_client对比序列号配置 deploy hook 或手动 reload续期日志显示 reload 但站点无变化reload 的是容器内 Nginx 或其它实例systemctl status nginxdocker ps调整 reload 目标服务reload 后出现 SSL 错误新证书文件权限不足或路径不对ls -l /etc/letsencrypt/archive/修复权限保证 Nginx 能读 fullchain 和 privkey定时任务每天执行但从未续期证书有效期还长属于正常跳过查看 timer 日志或 crontab 日志确认证书剩余天数无需处理证书已过期但 renew 仍不续期Certbot 或 Nginx 插件状态异常sudo certbot renew --dry-run根据 dry-run 输出修复插件或网络问题排查遵循一个固定思路先本地证书 - 再 Nginx 配置 - 再线上证书 - 再看日志。不要跳过openssl s_client对比序列号这一步这是验证最终结果的唯一可靠手段。9. 自动化监控与安全加固建议9.1 监控证书剩余天数证书续期链路跑通之后还需要一个监控手段防止“到期了但没人发现”。下面这个脚本可以直接用于 crontab 或监控系统#!/usr/bin/env bash # check_cert_expiry.sh DOMAINexample.com CERT_FILE/etc/letsencrypt/live/${DOMAIN}/fullchain.pem if [ ! -f $CERT_FILE ]; then echo cert file missing: ${CERT_FILE} 2 exit 1 fi END_DATE$(openssl x509 -enddate -noout -in $CERT_FILE | sed s/notAfter//) END_EPOCH$(date -d $END_DATE %s) NOW_EPOCH$(date %s) DAYS$(( (END_EPOCH - NOW_EPOCH) / 86400 )) echo ${DOMAIN} cert days left: ${DAYS} if [ $DAYS -le 7 ]; then echo cert will expire soon 2 exit 1 fi exit 0配合定时执行0 9 * * * /usr/local/bin/check_cert_expiry.sh /var/log/cert-check.log 21这样一旦证书剩余天数低于 7 天脚本退出码非 0可以接入监控告警。9.2 权限和私钥保护/etc/letsencrypt/live/和/etc/letsencrypt/archive/下的私钥只有 root 可读正常情况下不要让 Nginx 工作进程直接读取私钥。Nginx master 进程以 root 启动读证书文件没有问题。如果改了 Nginx 的运行用户或使用了一些特殊权限限制务必在 reload 后查看错误日志确认没有cannot load certificate key之类的报错。9.3 回滚方案如果 reload 之后发现新证书有问题准备一个回滚思路先确认旧证书文件是否还在 archive 目录Certbot 默认会保留历史证书手动修改 Nginx 配置指向旧证书文件执行nginx -t systemctl reload nginx确认线上序列号回退。不过这个方案只能应急。正常续期前建议先用certbot renew --dry-run做一次演练把证书链路的问题提前暴露。10. 总结Nginx reloaded nothing. Certbot still exited 0这类问题的核心教训只有一句不要把退出码当成结果。Certbot 的 0 只代表它自己的流程走完Nginx reload 的 0 只代表信号发出最终结果必须以线上证书序列号为准。最先应该验证的是certbot certificates看证书是否到期、openssl s_client看线上证书序列号是否和本地一致。最容易踩的坑是配置文件里写了旧的绝对路径或者定时任务里只写certbot renew而没有 deploy hook。后续可以继续扩展的方向是把整条链路串起来Certbot 续期 - deploy hook 触发 Nginx reload - 监控脚本检查剩余天数 - 异常告警。这四步跑通之后HTTPS 证书基本可以不管了。建议把本文里的命令和 systemd 配置存一份到自己的运维笔记里下次遇到同样情况直接照着查。
最近处理一个 HTTPS 证书自动续期的问题现象非常典型certbot renew正常跑完进程退出码是 0日志里也出现类似Running deploy-hook command的输出但打开站点一看证书还是旧的那张有效期没有变化甚至浏览器还在报证书过期。更迷惑的是手动执行nginx -s reload命令同样返回 0可 Nginx 进程和线上证书好像完全没动。这个组合可以浓缩成一句话Nginx reloaded nothing. Certbot still exited 0。它真正想表达的问题是工具链的每个环节都“返回成功”但最终结果没有落到证书加载上。原因通常是把三件事混为一谈了Certbot 的成功退出、reload 指令的信号发送、Nginx master 进程对配置和证书的实际加载。这篇文章会围绕 Certbot Nginx 的证书续期场景把如何判断证书是否真的生效、如何验证 reload 是否真的发生、如何配置自动续期后自动 reload、以及退出码 0 但站点无变化时该怎么查完整过一遍。适合自己维护 Nginx 反代、用 Lets Encrypt 证书或者刚接手别人定时证书任务的运维和开发。1. 问题定位速览先给一张速览表把这个问题涉及的关键项和判断基线列清楚。排查项说明问题现象certbot renew/nginx -s reload均返回 0但站点仍使用旧证书涉及组件Certbot、Nginx、Lets Encrypt 证书、systemd / crontab 定时任务exit code 0 的真实含义只表示 Certbot 流程执行完毕或证书未到续期时间不代表证书已加载进 NginxNginx reload 的真实行为向 master 进程发送信号master 先做配置校验校验失败则保留旧配置核心验证手段nginx -t、nginx -T、openssl x509、curl -vI、日志时间戳自动化修复方向deploy hook 或--renew-hook中执行systemctl reload nginx适合读者使用 Nginx 反代 Lets Encrypt 证书的运维和开发这里最需要先纠正的判断是exit code 0 是流程状态不是结果状态。Certbot 返回 0只能说明它自己的执行路径走完了既不表示“一定换了证书”也不表示“Nginx 已经加载了证书”。下面拆开讲。2. 为什么“退出码 0”会骗人Nginx reloaded nothing. Certbot still exited 0这个组合通常对应三种完全不同的底层情况。2.1 证书根本没到续期时间Certbot 默认只有在证书剩余有效期不足 30 天时才会尝试续期。如果你在证书还有 80 天到期时执行certbot renew日志里会出现Certificate not yet due for renewal; no action taken.然后进程退出码依然是 0。此时没有新证书写入也没有 reload 的必要——“reloaded nothing”是完全正常的。这种场景最容易让人误判因为定时任务每天都会“成功”执行但实际什么都没做。排查方式是看certbot certificates输出的到期时间而不是只看退出码。2.2 证书续期成功但 Nginx 没有重新加载如果证书到了续期窗口Certbot 会生成新证书并更新/etc/letsencrypt/live/example.com/下的软链。但注意Certbot 默认只负责写证书文件不负责通知 Nginx 重载。只有两种情况下它会主动 reload使用certbot --nginx插件申请或续期证书时插件会直接修改 Nginx 配置并触发 reload配置了 deploy hook / reload hook。如果你用certbot certonly拿证书再手动在 Nginx 里写ssl_certificate路径那么certbot renew永远不会去碰 Nginx。证书文件更新了Nginx 进程还在旧证书上跑直到你手动 reload 或重启。2.3nginx -s reload返回 0但配置实际没加载这是最隐蔽的一种情况。很多人看到“Nginx reloaded nothing”就怀疑是 Nginx 没执行 reload但实际上命令执行了只是被 master 进程拒绝了。nginx -s reload做的事情是向 master 进程发送 HUP 信号。master 收到信号后会先对配置文件做一次nginx -t类似的语法检查如果检查失败master 会拒绝重新加载并在错误日志里写入类似[emerg] ssl_certificate directive is duplicate in /etc/nginx/conf.d/example.conf [notice] signal process started这种情况下nginx -s reload命令本身的退出码仍然是 0因为信号已经成功发送了。但实际结果是“reloaded nothing”。这就是为什么验证链路不能只看命令退出码。3. 先确认证书本体的真实状态不管日志怎么显示第一步先查证书本身。通过下面一组命令把证书有效期、软链指向、续期记录看清楚。# 查看 Certbot 管理的所有证书和到期时间 sudo certbot certificates # 直接查看某个证书文件的到期时间 sudo openssl x509 -enddate -noout -in /etc/letsencrypt/live/example.com/fullchain.pem # 查看 live 目录下软链指向哪个 archive 文件 ls -l /etc/letsencrypt/live/example.com/判断要点如果certbot certificates显示证书还有 60 天且最近一次续期记录时间很旧说明还没到续期窗口exit code 0是“正常跳过”。如果ls -l显示软链指向的archive/example.com/certN.pem序号没有变化说明续期根本没发生。如果软链序号变化了但openssl看到的证书序列号和线上访问到的证书序列号不一致问题就出在 Nginx 加载环节。不要跳过这一步。很多排错浪费时间就是因为一上来就改 Nginx 配置结果证书其实没续上。4. 检查 Nginx 到底加载了哪张证书确认证书文件更新之后下一步是确认 Nginx 加载的证书和磁盘上的证书是否一致。这里有两种常用方式。4.1 看 Nginx 实际配置指向的证书路径sudo nginx -T | grep -E ssl_certificate|server_name重点看两个地方ssl_certificate是否指向/etc/letsencrypt/live/example.com/fullchain.pem这种 live 软链路径ssl_certificate_key是否指向对应的privkey.pem。如果配置指向的是/etc/letsencrypt/archive/example.com/cert1.pem这种绝对路径就会有一个隐患续期后 Certbot 会生成cert2.pem并更新 live 软链但 Nginx 配置里写死的老路径文件可能没有变。后续续期会出现“文件换了服务还是旧的”。更稳妥的做法是 Nginx 配置统一写 live 软链路径让 Certbot 的续期逻辑接管文件切换。4.2 对比线上证书和本地证书的序列号# 从线上抓取当前站点实际使用的证书 echo | openssl s_client -connect example.com:443 -servername example.com 2/dev/null \ | openssl x509 -noout -serial -enddate # 查看本地证书文件 sudo openssl x509 -noout -serial -enddate -in /etc/letsencrypt/live/example.com/fullchain.pem如果两边的serial不一致说明 Nginx 还在用旧证书。这个对比是判断“reload 是否真正生效”最直接的手段比盯着进程和日志更可靠。5. reload 的正确姿势与验证方法如果确认证书文件已经更新、Nginx 还在用旧证书接下来要做就是一次真正可靠的 reload。5.1 先测试配置再发送 reloadNginx 的 reload 并不是无条件的。master 收到 HUP 信号后会先校验配置文件校验失败就继续沿用旧配置。所以推荐把配置测试和 reload 串起来执行# 先校验配置 sudo nginx -t # 校验通过后再 reload sudo nginx -s reload如果担心命令之间的失败传播写成一行也可以sudo nginx -t sudo nginx -s reload但要注意这个写法里nginx -s reload的退出码依然不能代表真实加载结果只能代表信号发送成功。真正要确认加载结果还需要看日志和线上证书。5.2 systemd 环境的 reload大多数发行版用 systemd 管理 Nginx推荐使用systemctl reload nginx而不是直接发信号。它走的是服务单元里的ExecReload配置通常已经包含了配置校验逻辑sudo systemctl reload nginx执行后可以用下面几条命令确认 master 有没有重新初始化# 查看 master 进程启动时间reload 后时间应更新 ps -o lstart -p $(cat /run/nginx.pid) # 查看 Nginx 相关进程的存活时间 ps -eo pid,ppid,etime,cmd | grep nginx再配合第 4 节里的openssl s_client对比证书序列号就能确认 reload 真的生效了。5.3 检查 Nginx 错误日志如果 reload 后证书序列号还是没变优先看错误日志sudo tail -n 50 /var/log/nginx/error.log常见现象有[emerg]开头配置有致命错误reload 被拒绝[alert] cannot load certificate证书文件权限或路径有问题[notice] reconfiguringmaster 已经开始重新加载说明信号生效了。6. Certbot 自动续期时自动 reload解决了手动 reload 的问题接下来处理自动化场景。很多人配置了certbot renew的定时任务但定时任务里没有 reload导致证书续期成功但站点一直用旧证书直到某天浏览器报警。6.1 通过 deploy hook 实现续期后 reloadCertbot 支持在续期成功后执行 deploy hook。推荐写在 cli.ini 里避免命令行参数遗漏# /etc/letsencrypt/cli.ini deploy-hook systemctl reload nginx或者手动执行时用参数指定sudo certbot renew --deploy-hook systemctl reload nginx这里的要点是deploy-hook只在证书真正续期成功时执行。如果证书还没到续期时间hook 不会运行所以不会出现误 reload。如果希望无论是否续期都强制 reload可以在 systemd 服务的ExecStartPost里写后面会提到。6.2 通过 systemd timer 做定时续期推荐用 systemd timer 而不是 crontab因为可以配合日志系统统一管理。创建两个文件# /etc/systemd/system/certbot-renew.service [Unit] DescriptionCertbot certificate renewal Afternetwork-online.target [Service] Typeoneshot ExecStart/usr/bin/certbot renew --quiet ExecStartPost/bin/systemctl reload nginx# /etc/systemd/system/certbot-renew.timer [Unit] DescriptionRun certbot renewal daily [Timer] OnCalendar*-*-* 03:17:00 RandomizedDelaySec3600 Persistenttrue [Install] WantedBytimers.target然后启用 timersudo systemctl daemon-reload sudo systemctl enable --now certbot-renew.timer sudo systemctl status certbot-renew.timer这个方案里ExecStartPost的作用是certbot renew只要退出码为 0无论是否真的续期都会触发一次systemctl reload nginx。Nginx reload 本身成本很低不会中断现有连接所以每天多 reload 一次完全可接受。注意ExecStart和ExecStartPost的路径要按实际安装位置调整snap 安装的 certbot 路径通常是/snap/bin/certbot。6.3 crontab 替代方案如果习惯用 crontab等价写法是# certbot 每天 3 点执行--quiet 表示只输出错误 15 3 * * * /usr/bin/certbot renew --quiet --deploy-hook /usr/bin/systemctl reload nginxcrontab 方式的缺点是没有独立的日志单元排查时需要自己把输出重定向到文件。建议至少写成15 3 * * * /usr/bin/certbot renew --deploy-hook /usr/bin/systemctl reload nginx /var/log/certbot-renew.log 217. Nginx reload 的系统行为与性能观察很多第一次接触 Nginx reload 的人会担心reload 会不会造成断连实际上 Nginx 的 reload 是平滑热更新机制。整个流程是这样的master 收到 HUP 信号后先校验配置校验通过后启动一组新的 worker 进程新 worker 使用新配置、新证书旧的 worker 继续处理已有的连接处理完自然退出。所以对客户端来说HTTP/HTTPS 连接不会中断正在下载中的文件也不会被切断。在性能观察方面有几点值得注意reload 本身开销极小通常毫秒级完成不会产生明显负载如果站点存在大量长连接比如 WebSocket 或 keepalive 时间很长旧 worker 会存活较久内存中会同时保留新旧两份证书上下文如果证书文件权限有问题新 worker 启动时会报cannot load certificate此时 master 会回滚到旧配置线上依然是旧证书。观察指标用这几条命令就够# 查看 443 端口监听进程 sudo ss -lntp | grep :443 # 查看 Nginx worker 数量和存活时间 sudo ps -eo pid,ppid,etime,cmd | grep nginx # 查看 reload 相关日志 sudo journalctl -u nginx --since 10 minutes ago这些命令的价值在于在 reload 前后各执行一次通过对比能直接判断 reload 是否真的发生。8. 常见问题与排查方法下面把这个问题最常见的几种表现、原因和处置方式整理成一张表。问题现象可能原因排查命令解决方案exit code 0 但没有任何新证书未到续期时间sudo certbot certificates等待自动续期或确认需求后用--force-renewalnginx -s reload返回 0 但配置没变配置校验失败master 拒绝 reloadsudo nginx -t检查 error.log修复配置再 reload证书文件更新了页面仍是旧证书reload 未执行或 reload 目标错误openssl s_client对比序列号配置 deploy hook 或手动 reload续期日志显示 reload 但站点无变化reload 的是容器内 Nginx 或其它实例systemctl status nginxdocker ps调整 reload 目标服务reload 后出现 SSL 错误新证书文件权限不足或路径不对ls -l /etc/letsencrypt/archive/修复权限保证 Nginx 能读 fullchain 和 privkey定时任务每天执行但从未续期证书有效期还长属于正常跳过查看 timer 日志或 crontab 日志确认证书剩余天数无需处理证书已过期但 renew 仍不续期Certbot 或 Nginx 插件状态异常sudo certbot renew --dry-run根据 dry-run 输出修复插件或网络问题排查遵循一个固定思路先本地证书 - 再 Nginx 配置 - 再线上证书 - 再看日志。不要跳过openssl s_client对比序列号这一步这是验证最终结果的唯一可靠手段。9. 自动化监控与安全加固建议9.1 监控证书剩余天数证书续期链路跑通之后还需要一个监控手段防止“到期了但没人发现”。下面这个脚本可以直接用于 crontab 或监控系统#!/usr/bin/env bash # check_cert_expiry.sh DOMAINexample.com CERT_FILE/etc/letsencrypt/live/${DOMAIN}/fullchain.pem if [ ! -f $CERT_FILE ]; then echo cert file missing: ${CERT_FILE} 2 exit 1 fi END_DATE$(openssl x509 -enddate -noout -in $CERT_FILE | sed s/notAfter//) END_EPOCH$(date -d $END_DATE %s) NOW_EPOCH$(date %s) DAYS$(( (END_EPOCH - NOW_EPOCH) / 86400 )) echo ${DOMAIN} cert days left: ${DAYS} if [ $DAYS -le 7 ]; then echo cert will expire soon 2 exit 1 fi exit 0配合定时执行0 9 * * * /usr/local/bin/check_cert_expiry.sh /var/log/cert-check.log 21这样一旦证书剩余天数低于 7 天脚本退出码非 0可以接入监控告警。9.2 权限和私钥保护/etc/letsencrypt/live/和/etc/letsencrypt/archive/下的私钥只有 root 可读正常情况下不要让 Nginx 工作进程直接读取私钥。Nginx master 进程以 root 启动读证书文件没有问题。如果改了 Nginx 的运行用户或使用了一些特殊权限限制务必在 reload 后查看错误日志确认没有cannot load certificate key之类的报错。9.3 回滚方案如果 reload 之后发现新证书有问题准备一个回滚思路先确认旧证书文件是否还在 archive 目录Certbot 默认会保留历史证书手动修改 Nginx 配置指向旧证书文件执行nginx -t systemctl reload nginx确认线上序列号回退。不过这个方案只能应急。正常续期前建议先用certbot renew --dry-run做一次演练把证书链路的问题提前暴露。10. 总结Nginx reloaded nothing. Certbot still exited 0这类问题的核心教训只有一句不要把退出码当成结果。Certbot 的 0 只代表它自己的流程走完Nginx reload 的 0 只代表信号发出最终结果必须以线上证书序列号为准。最先应该验证的是certbot certificates看证书是否到期、openssl s_client看线上证书序列号是否和本地一致。最容易踩的坑是配置文件里写了旧的绝对路径或者定时任务里只写certbot renew而没有 deploy hook。后续可以继续扩展的方向是把整条链路串起来Certbot 续期 - deploy hook 触发 Nginx reload - 监控脚本检查剩余天数 - 异常告警。这四步跑通之后HTTPS 证书基本可以不管了。建议把本文里的命令和 systemd 配置存一份到自己的运维笔记里下次遇到同样情况直接照着查。
