状态：在用 · 2026-05 至今 · 本身不换，管的范围随 CF 覆盖度收缩
速读#
证书到期不能靠记忆，certbot 接走的是「到期续期」这条最容易被人忘掉的链路。90 天有效期不是麻烦，而是在逼我自动化；真正要养成的动作，是用 dry-run 确认续期路径一直通。这篇也写清楚：哪些场景其实不该选它。
90 天有效期是设计，不是缺陷#
Let’s Encrypt 把证书卡在 90 天，不是「太短不方便」，是故意的。逻辑很直接：一年一续的事，人靠记忆还能勉强撑住；90 天一续，谁也不会靠记忆撑——它等于把「必须自动化」写进了有效期里。短有效期还有个附带收益：证书泄露或配置出错，最多也就错 90 天。
这件事比证书本身更大：
有期限的东西，不能靠「我记得」，必须靠「系统自动 + 我演练过」。
续期交给 timer，但人要验证 timer 真能续上——和 systemd 拉进程、fail2ban 封 IP 同一范式：人定规则并验证，机器 7×24 执行。
为什么是它#
证书这件最不能出事、也最该自动化的活，我交给 certbot。开源仓库：certbot/certbot（Python，ACME 流程能翻，不是黑盒）。
| 选项 | 判断 |
|---|---|
| acme.sh | 轻，不带 Python 依赖；但几千行 shell，真出问题时读它比读 Python 痛苦 |
| 自己撸 ACME 客户端 | 协议是公开的，但验证、续期、部署钩子每一样都要自己扛着不出错 |
| certbot | EFF 维护、Let’s Encrypt 官方推荐、--nginx 插件把签发、改配、跳转一把过 |
场景卡得很准：个人几台机器、跑着 Nginx、要省心、也要能看懂实现——这个格子里没有更合适的。
什么情况下不该选它#
推荐一个工具，得同时写清它的失效场景，不然就是安利：
- 要泛域名证书：
*.example.com只能走 DNS-01 验证，得给 certbot 配 DNS 服务商的 API 插件。域名多、服务商杂的时候，acme.sh 那边的 DNS API 覆盖面反而更省事。 - 整站已经在 Cloudflare 后面：CF 的源站证书（Origin CA）有效期 15 年，只被 CF 信任，但「回源这一段」正好够用——那种站再跑 certbot 属于多余。
- 愿意换 Web 服务器：Caddy 把 ACME 直接内建进服务器，证书这个「问题」整个消失。我没走这条路，是因为 Nginx 的配置和肌肉记忆攒了一堆，不值得为证书搬家——但从零开始的新手，这条路确实更短。
工具没有全场景最优。certbot 赢的是「Nginx + 个人机器」这一格，不是所有格。
先 dry-run#
apt install certbot python3-certbot-nginx -ycertbot --nginx -d app.example.com
# 走完续期流程，但不真签发——验通路certbot renew --dry-runrenew --dry-run 验通，你才能信到期那条 certbot renew 会真的成。它走的是 Let’s Encrypt 的 staging 环境：流程完整走一遍，但不消耗正式环境的签发额度——所以演练可以随便跑，不心疼。
装完还要核对一件事：续期到底挂在哪。
systemctl list-timers | grep certbotDebian 系装包时会自动注册 certbot.timer，一天摸两次到期状态。「应该有个定时任务」和「我看到了那个定时任务」是两回事——核对过才算数。
我每年还会手动跑一次 dry-run，不为别的，就为确认「自动续期这条路还通」——这是我对一切 set-and-forget 系统的纪律。续期路径是会漂移的：防火墙某次收紧把 80 端口关了（HTTP-01 验证要走 80）、Nginx 配置改了验证路径、CF 代理规则动了——每一样都可能让当年验通的路悄悄断掉。dry-run 演练的真正对象不是 certbot，是这条路上的一切。
会不会换#
certbot 本身不换。
要标清的是管的范围：
- 现在管：Cloudflare 回源到我服务器这一段，以及没套 CF 的子域
- 哪天某站整站交给 CF Full (strict)、证书全用 CF 签发，certbot 才从那个站退场
那是按站点迁，不是换工具。准答案是：工具不动，覆盖范围随 CF 收缩。
证书这件事最反人性的地方：到期日是死的，人记不住。certbot 接走「到期续期」；我对它的唯一要求是——续期这条路我一直验得通。