速读#
这篇讲 HTTPS 最后一步，但真正留下的是「证书续期不能靠记忆」的心智。Let’s Encrypt 的 90 天有效期不是缺陷，而是逼你接受自动续期；自动化不是设了就完，续期路径要用 dry-run 定期演练。
个人站点：三条路只剩一条#
有了域名和 Nginx 反代，最后一步才是 HTTPS。对个人站点，我只比较三种路径：
| 方案 | 代价 |
|---|---|
| 自签 | 浏览器报警，信任崩 |
| 商业证书 | 花钱 + 常要手动续 |
| Let’s Encrypt + certbot | 免费 + 可自动续期 |
不是「它最好」，是个人站点场景几乎无对手。
apt install certbot python3-certbot-nginx -ycertbot --nginx -d app.example.comcertbot 读 Nginx 配置，申请证书、改 443、配 HTTP→HTTPS 跳转。签发前它要向 Let’s Encrypt 证明「这个域名归你管」——默认走 HTTP 验证，对方会来访问你 80 端口上 /.well-known/acme-challenge/ 下的一个临时文件。这意味着 80 端口必须可达：防火墙只留 443 的话，签发和续期都会悄悄失败。另一个边界：HTTP 验证签不了泛域名，那要走 DNS 验证（往域名解析里放记录）——我这个规模用不上，知道岔路在哪就够。
90 天是设计，不是缺陷#
有效期 90 天，有意为之：逼你自动化，而不是靠记忆续期，某天忘了站点掉线。 官方还有一层理由：就算私钥泄露或证书误签，90 天的窗口也把损害期压短了。短有效期同时压缩两样东西——人的侥幸，和坏证书的寿命。
有期限的东西，不能靠「我记得」，必须靠「系统自动 + 我演练过」。
和 systemd 拉进程、fail2ban 封 IP 同一范式：人定规则并验证，机器 7×24 执行。
自动化本身是装包时送的：Debian 上 certbot 自带 systemd timer，每天两次检查证书，离到期 30 天内才真正续。可以核对它确实在排班：
systemctl list-timers | grep certbot续期：先 dry-run#
certbot renew --dry-run走完续期流程但不真签发。验通，才信 timer 到期会真的成。
为什么要演练？因为续期路径会漂移：改过 Nginx 配置、收紧过防火墙、换过验证方式——每一个都可能在你不知情时弄断续期，而证书还有两个月才过期，断了也毫无感觉。dry-run 把「到期那天才爆发的失败」提前到今天暴露。
我每年还会手动跑一次 dry-run——确认自动续期这条路还通。这是对一切 set-and-forget 系统的纪律：设好的自动化会腐化，演练是唯一的体检。
和 Cloudflare 的边界#
| 段落 | 谁管证书 |
|---|---|
| 浏览器 ↔ Cloudflare | 常由 CF 侧处理 |
| CF 回源 ↔ 你的服务器 | 仍可能是 certbot / 源站证书 |
| 没套 CF 的子域 | certbot |
套了 CDN 不等于证书问题消失，只是拆成了两段，各段各有归属。回源改用 Cloudflare Origin CA 证书、加密模式开到 Full (strict) 时，certbot 才从那个站退场——按站点迁，不是换工具。
反代层 HTTPS 跳转、证书路径，改完仍走：
nginx -t && systemctl reload nginx带走的心智比命令重要：证书到期是死的，人记不住；续期必须自动，且路径必须你验过。