certbot renew 未自动续证主因是系统定时任务未配置或权限不足；需检查 systemd timer/cron 是否存在，再用 –install-cron-job 或手动添加 crontab，并确保 –post-hook 重载 web 服务。
certbot renew 命令为什么没自动续上证书
绝大多数“自动续期失败”不是因为没跑 certbot renew，而是它根本没触发——系统级定时任务（比如 systemd timer 或 cron）压根没配，或者配了但没权限读写 /etc/letsencrypt/。默认情况下，certbot 不会自己注册定时任务，装完就完事了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 检查是否真有定时任务：运行
sudo systemctl list-timers | grep certbot（systemd 系统），或sudo crontab -l | grep certbot（cron 系统） - 如果没有，别手写 cron 行，直接用官方推荐命令安装：
sudo certbot renew --dry-run成功后，再执行sudo certbot renew --install-cron-job（部分版本支持）；否则手动加一行到 root 的 crontab：0 12 * * 1 /usr/bin/certbot renew --quiet --post-hook "/bin/systemctl reload nginx" -
--post-hook很关键：续期后必须重载 Web 服务，否则旧证书还在内存里，浏览器看到的仍是过期的
acme 客户端（如 acme.sh）和 certbot 的 renew 行为差异
acme.sh 默认不依赖系统服务管理器，它的 --renew 是纯脚本逻辑，每次执行都查证书剩余天数，满足条件才续；而 certbot renew 是批量扫描所有证书，只要任一证书距过期 ≤30 天就全量处理——这意味着你可能在日志里看到“Skipping X.com (expired)”却仍触发了其他域名续期。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
acme.sh --list查看每个域名的到期时间，比certbot certificates更直观 -
acme.sh的--force和certbot的--force-renewal都慎用：前者会绕过本地缓存直接走 ACME 协议，后者可能被 Let’s Encrypt 限频（7 天内同一域名最多 5 次） - 路径差异：acme.sh 默认把证书放在
~/.acme.sh/，certbot 放在/etc/letsencrypt/，Web 服务配置里千万别引错路径
续期失败时常见的 DNS-01 验证卡点
DNS-01 验证失败几乎从不报“DNS 错误”，而是表现为 urn:ietf:params:acme:Error:dns 或更隐蔽的 Timeout during connect——本质是 ACME 服务器查不到你刚设的 TXT 记录，原因通常是 DNS 未生效、TTL 过长、或 API 凭据权限不足。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别等
certbot renew自己去查：先手动触发验证并观察过程：certbot certonly --manual --preferred-challenges=dns -d example.com，它会打印要设置的 TXT 值，你设完后用dig -t txt _acme-challenge.example.com确认返回值一致 - 云厂商 DNS API（如阿里云、Cloudflare）需确保 AccessKey 有
Alidns:DescribeDomainRecords和Alidns:AddDomainRecord权限，只给Read不够 - 本地 DNS 缓存干扰：Mac 上跑
sudo dscacheutil -flushcache，linux 上可能是sudo systemd-resolve --flush-caches，但更可靠的是直接用dig查权威服务器（加@8.8.8.8）
证书续期后 Nginx/apache 仍用旧证书
这不是证书没续成，而是 Web 服务没加载新文件。常见于配置中硬编码了证书路径（比如 ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem），但没注意到 fullchain.pem 是符号链接，指向实际日期命名的子目录——而某些部署脚本或监控工具会把它“固化”成绝对路径。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 永远用
live/下的符号链接路径，别用archive/里的具体文件名；检查链接是否断裂：ls -l /etc/letsencrypt/live/example.com/fullchain.pem - Nginx 必须
reload（不是restart），否则 worker 进程仍持旧文件句柄；Apache 要sudo a2ensite后再systemctl reload apache2 - 验证是否生效：用
openssl s_client -connect example.com:443 -servername example.com 2>/dev/NULL | openssl x509 -noout -dates，看notAfter是否更新
证书路径、服务重载、DNS 生效这三环，任意一环断掉，都会让你以为自动续期“失效”——其实它早跑完了，只是没人告诉 Web 服务该换人了。