记一次使用 Certbot Webroot 模式平滑续期 Nginx 泛域名证书

在为移动端应用配置 Universal Links (通用链接) 或是打通微信 / 支付宝的 OAuth 分享域名（例如 auth.imwind.cc）时，HTTPS 是一道无法绕过的强制性安全门槛。

对于很多刚接触 HTTPS 部署的开发者，通常会顺手使用 Let's Encrypt 官方推荐的 Certbot 的 --nginx 插件，它会自动帮你修改 nginx.conf 来完成配置。

但在真实的生产环境中，我们极度反感这种“黑盒式”的自动修改： 它不但容易把原本结构清晰的反向代理、负载均衡配置文件改得面目全非，而且一旦自动修改的语法与你手写的复杂策略发生冲突，甚至会直接导致 Nginx 宕机。

本文将介绍一种更优雅、更稳健的生产级打法：使用 Webroot 模式，在绝对不侵入你原有 Nginx 业务逻辑的前提下，实现零宕机的自动化证书获取与定时续期。

一、 为什么架构师偏爱 Webroot 模式？

相比于直接让 Certbot 接管 Nginx 配置（--nginx 模式）或者让它临时跑个服务器（--standalone 模式需要干掉你的 Nginx 服务），Webroot 模式具有压倒性的企业级优势：

  1. 绝对的非侵入性：Certbot 仅仅作为一个“静态文件生成器”，它只负责在你指定的目录下放入一个验证文件。你的 nginx.conf 代码只有你自己能碰，杜绝配置被意外污染。
  2. 零停机时间 (Zero Downtime)：不需要停止正在运行的 Nginx 服务（standalone 模式的硬伤）。
  3. 极致的可控性：你可以自由且独立地定义你想要的 HTTPS 现代安全参数（如 HSTS 强制跳转、TLS 1.3 现代加密套件等，而不是接受 Certbot 的默认全家桶）。
  4. 穿透复杂架构：无论你的后端是套了几层 Docker，还是前面挂了 CDN 节点，只要 HTTP 的验证路径能连通，Webroot 就能工作。

二、 原理揭秘：一场 HTTP 的文件捉迷藏

Webroot 的工作流其实非常极客且简单。 它本质上是 Let's Encrypt 官方发起的“查房”机制：

  1. 你运行 Certbot 命令，告诉它：“我想要 auth.imwind.cc 的证书，我的网页根目录在 /var/www/letsencrypt。”
  2. Certbot 就会在你这个目录下偷偷创建一个名为 .well-known/acme-challenge/随机字符串 的深层临时文件。
  3. 随后，Certbot 通知远在国外的 Let's Encrypt 服务器：“文件放好了，你过来验明正身吧！”
  4. Let's Encrypt 服务器发起一个 HTTP GET 请求：http://auth.imwind.cc/.well-known/acme-challenge/随机字符串。
  5. 如果你的 Nginx 成功把这个文件返回给它，它就相信你确实拥有这个域名的服务器控制权，随后给你颁发包含私钥的绿标 SSL 证书。

三、 实战演练：步步为营的配置

1. 划定“验证专用特区”

为了绝对不影响业务代码（你的博客、你的 Node.js 服务等），我们强烈建议在 Linux 上创建一个专门用来应对 Let's Encrypt 查房的空壳目录：

# 创建验证专用的空目录
sudo mkdir -p /var/www/letsencrypt

# 确保 Nginx 运行用户（通常是 www-data 或 nginx）对这个目录有读取权限
sudo chown -R www-data:www-data /var/www/letsencrypt

2. 配置 Nginx 的 HTTP 绿灯通道

接着，去修改你该域名对应的 Nginx 配置文件。我们需要在原本监听 HTTP（80 端口）的 Server 块中，加入一条特殊的路由 location，专门把验证请求指派到刚才创建的目录。

server {
    listen 80;
    server_name auth.imwind.cc;

    # 关键配置：开通绿灯通道！
    # 只要是请求 /.well-known/acme-challenge/ 开头的路径
    # 全部由 /var/www/letsencrypt 目录来响应
    location ^~ /.well-known/acme-challenge/ {
        allow all;
        root /var/www/letsencrypt;
        default_type "text/plain"; # 确保不用下载而是作为普通文本读取
    }

    # 剩下的所有正常用户的 HTTP 请求？不好意思，强制跳转到 HTTPS！
    location / {
        return 301 https://$host$request_uri;
    }
}

配置完成后别忘了热重载：sudo nginx -s reload。

3. 一击必杀：使用 Certbot 拿证

万事俱备，执行核心命令。注意其中最灵魂的参数 certonly，这代表你的态度：“我只拿东西，你别碰我别的东西”。

sudo certbot certonly --webroot \
    -w /var/www/letsencrypt \
    -d auth.imwind.cc \
    --email your-email@example.com \
    --agree-tos \
    --no-eff-email

如果屏幕打出绿色的 Congratulations!，你会看到证书文件已经被静静地安放在了：/etc/letsencrypt/live/auth.imwind.cc/ 目录下。

4. 手动组装巅峰配置

最后一步，在你的 443（HTTPS）的 Server 块中，手动挂载这把宝剑，并配上现代化的安全套件配置：

server {
    listen 443 ssl http2;
    server_name auth.imwind.cc;

    # 挂载刚申请下来的证书
    ssl_certificate /etc/letsencrypt/live/auth.imwind.cc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/auth.imwind.cc/privkey.pem;

    # 现代加密套件，拒绝远古浏览器，提升评级到 A+
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;

    # 你的核心业务...
    location / {
        proxy_pass http://localhost:8080;
    }
}

四、 终局：如何实现无人值守的自动续期？

Let's Encrypt 唯一的痛点就是证书生命周期极短，只有 90 天。但在我们的 Webroot 架构下，自动化续期简直是降维打击。

系统后台其实会自动运行 certbot renew 的定时任务（cron 或 systemd timer）。但这有个隐患：证书文件确实更新了，可是常驻内存的 Nginx 服务根本不知道！

为了解决这个问题，我们需要在系统续期的脚本中注入一个 Deploy Hook (部署钩子)，也就是告诉它：“每次你成功弄到了新证书之后，请顺手帮我敲一下重载 Nginx 的命令”。

你可以用这条命令来测试并固化这个钩子逻辑：

# --dry-run 表示模拟演练而不是真去续期
sudo certbot renew --dry-run --deploy-hook "systemctl reload nginx"

只要模拟测试显示成功，自此，你的服务器就成为了一台可以自给自足、永不过期的 HTTPS 堡垒引擎。即使过了几年，这套配置依然稳如磐石。