Certbot 与 Nginx：证书签发、续期和加载验证

整理 HTTPS 证书签发与续期流程，纠正 HTTP-01 校验端口和低频续期计划，说明证书文件与 Nginx 实际加载结果的核对方法。

选择验证方式，而不是先停止所有 Web 服务

原文的 standalone 示例使用 HTTP-01 验证，对外需要的是 80 端口，不是 443。域名解析、云防火墙、主机防火墙与实际监听都需要满足验证条件。

如果 Nginx 已经服务于该域名，可评估 webroot 或 Nginx 插件方式，避免为签发证书停掉整站。standalone 会临时启动验证服务，因此要处理它与现有 80 端口监听的冲突。

首次签发的核对顺序

从 Certbot 官方入口按操作系统和服务方式安装；不要假定所有发行版都有相同包。
确认域名的相关 DNS 记录指向预期服务器。
选择与现有部署方式匹配的验证插件。
先在合适的测试流程中检查挑战能否完成，再执行正式签发。

历史 standalone 命令形式如下，域名必须替换为自己控制且已正确解析的域名：

sudo certbot certonly --standalone -d example.com -d www.example.com
sudo certbot certificates

此处没有执行任何证书签发。证书的实际名称和文件路径以 certbot certificates 输出为准，不能假定一定是 www.example.com 目录。

自动续期应定期检查，而不是两个月才运行一次

原文的低频 cron 计划缺少失败重试机会，也把证书生命周期与任务触发周期混在一起。本次删除固定两个月续期的写法。

先检查安装方式是否已经配置了 systemd timer 或 cron。已有自动任务时不要重复添加。续期流程由 certbot renew 判断哪些证书需要续期，并应定期执行、记录失败和检查服务加载结果。

sudo certbot renew --dry-run

演练成功不等于未来永远成功，DNS、端口和凭据变化后仍应重新检查。使用 webroot 或其他插件时，需确保其验证路径和权限长期可用。

Nginx 加载证书的配置形态

以下是配置片段，CERTIFICATE_NAME 必须替换成实际名称：

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/CERTIFICATE_NAME/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/CERTIFICATE_NAME/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8888;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

先用 nginx -t 检查配置，再采用现有服务管理方式重载。续期成功后的 deploy hook 可用于触发检查和重载，但路径、权限和服务名称需要按实际系统配置。不要把未经检查的重载命令当作通用安装脚本。

最终从客户端检查域名、证书链和有效期，确认 Nginx 正在提供新的证书，而不只是磁盘文件已经变化。

参考

Certbot 用户指南：验证与续期
Nginx 命令参数
原 SQL 标记为转载，但未提供明确原文地址；不将本次整理冒充为全部原创经历。