Ubuntu 22.04 下用 Certbot standalone 模式获取 Let‘s Encrypt SSL 证书

1. 项目概述：为什么 standalone 模式是 Ubuntu 22.04 上最干净的证书获取起点

在 Ubuntu 22.04 上给一个刚搭好的 Nginx 或 Apache 服务配 SSL，你大概率会卡在第一步——不是证书申请失败，而是根本连 Let’s Encrypt 的验证环节都过不去。我见过太多人反复重装 certbot、改防火墙、查端口占用，最后发现只是因为没理解 standalone 模式的底层逻辑。它不是“备选方案”，而是 Certbot 在无 Web 服务器干扰、无反向代理遮挡、无 CDN 缓存污染时，最接近“原生验证”的方式。关键词 Certbot 、 standalone 、 Let's Encrypt 、 SSL 、 Ubuntu 22.04 全部指向一个核心事实：你在用一台干净的、刚初始化的 Ubuntu 22.04 LTS 服务器，为一个尚未对外暴露的、甚至还没写完的 Web 应用，提前拿到一张受信任的 HTTPS 证书。这不是生产环境的最终部署流程，而是开发、测试、CI/CD 流水线里最值得信赖的“首张证书”生成器。它不依赖你已有的 Web 服务配置是否正确，不关心你用的是 Nginx 还是 Caddy，甚至不care你有没有域名解析生效——只要你能确保 80 端口在那一刻完全空闲，Certbot 就能自己拉起一个微型 HTTP 服务器，完成 ACME 协议要求的 http-01 挑战。这正是它和 webroot 、 nginx 插件的本质区别：后者是“借力”，前者是“自立”。而 Ubuntu 22.04 的 systemd、Python 3.10 环境、默认的 ufw 防火墙策略，恰好为 standalone 模式提供了最稳定、最可预测的运行土壤。你不需要成为系统管理员，但必须明白：standalone 不是“偷懒”，而是把验证过程从复杂的基础设施中剥离出来，让证书这件事回归到最简单的“我能响应一个 HTTP 请求”这个原子命题上。

2. 核心设计思路与方案选型深度拆解

2.1 为什么 standalone 是 Ubuntu 22.04 上的首选验证模式？

很多人一看到 “standalone” 就下意识觉得“不专业”、“只适合测试”，这是对 ACME 协议和 Certbot 架构的根本误解。我们来拆解三个关键决策点：

第一，验证阶段的“控制权”问题。
Let’s Encrypt 的 http-01 挑战，本质是要求你的服务器在 http://yourdomain/.well-known/acme-challenge/xxx 这个路径上，返回一个由 CA 提供的、一次性的随机字符串。这个动作必须由你的服务器完成，且必须能被公网上的 Let’s Encrypt 服务器直接访问。如果你用 webroot 插件，Certbot 会把文件写进你指定的 Web 服务器静态目录（比如 /var/www/html/.well-known/acme-challenge/ ），然后依赖你已有的 Nginx/Apache 配置能正确地把这个路径映射出去。但问题来了：你的 Nginx 配置可能有错误的 location 规则、可能启用了 gzip 导致文件被压缩后无法识别、可能设置了 X-Frame-Options 或 Content-Security-Policy 干扰了纯文本响应。这些都不是 Certbot 能控制的。而 standalone 模式，Certbot 自己启动一个极简的、单线程的 Python HTTP 服务器，监听在 80 端口，只处理那一个 .well-known 路径的请求，其他所有请求一律 404。它绕开了你整个 Web 服务栈，把验证的“确定性”牢牢握在自己手里。在 Ubuntu 22.04 上，这个内置的 HTTP 服务器基于 http.server 模块，轻量、稳定、无额外依赖，完美契合 LTS 版本追求长期稳定的哲学。

第二，Ubuntu 22.04 的默认安全策略天然适配。
Ubuntu 22.04 默认安装 ufw （Uncomplicated Firewall），其默认策略是 deny incoming 。这意味着，除非你明确 ufw allow 80 ，否则任何外部请求都无法到达你的服务器。这看起来是个障碍，实则是保护伞。当你执行 certbot certonly --standalone -d example.com 时，Certbot 会尝试绑定 80 端口。如果失败，它会立刻报错 Problem binding to port 80: Could not bind to IPv4 or IPv6. ，而不是默默失败或给你一张无效证书。这个错误信息极其精准，它直接告诉你：“嘿，你的 80 端口被占用了，或者被防火墙拦住了。” 你只需要一条命令 sudo ufw allow 80 ，再加一条 sudo ss -tuln | grep ':80' 查看谁在监听，就能在 30 秒内定位问题。相比之下， webroot 模式失败时，错误日志可能深埋在 Nginx 的 error.log 里，提示 Permission denied ，你得去查 SELinux（虽然 Ubuntu 默认不用）、查文件权限、查 open_file_limit ，排查时间可能长达数小时。standalone 把复杂度降到了最低，把“端口是否可用”这个单一变量，变成了整个流程的成败开关。

第三，“evergreen standalone installer” 的真实含义。
网络热词里提到的 “evergreen standalone installer”，指的并不是某个神秘的新工具，而是 Certbot 官方推荐的、通过 snap 安装的、自动更新的 Certbot 版本。Ubuntu 22.04 是 snap 的深度集成者， snap install certbot --classic 安装的 Certbot，其 standalone 模块是经过 Canonical 和 EFF（电子前哨基金会）联合认证和持续维护的。它不像 apt install python3-certbot-nginx 那样，会把 Certbot 和 Nginx 插件打包在一起，导致版本锁定。snap 版本的 Certbot 是一个独立的、沙盒化的、永远保持最新的二进制包。它的 standalone 功能，就是“evergreen”的——你今天装的，和三个月后装的，API 行为、错误码、兼容性都是一致的。这才是“evergreen”的真正价值：不是功能多炫酷，而是行为可预期、升级无风险。所以，当你看到 “certbot 工具, evergreen standalone installer” 这个组合词时，它本质上是在说：用 snap 装 Certbot，你就拥有了一个在 Ubuntu 22.04 上永不落伍、开箱即用的 standalone 证书工厂。

2.2 standalone 与其他插件的本质区别：不只是“怎么装”，更是“谁负责”

网上常有人问 “standalone installer 和 webroot 的区别”，这个问题本身就预设了一个错误前提——standalone 不是一个“installer”，它是一个“验证器”（Authenticator）。Certbot 的架构分为两大部分： Authenticator （验证器）和 Installer （安装器）。Authenticator 负责证明“你拥有这个域名”，Installer 负责把拿到的证书“放到正确的地方并通知服务重启”。

• --standalone 是一个 Authenticator。
• --webroot 是另一个 Authenticator。
• --nginx 既是 Authenticator（它会临时修改 Nginx 配置来响应挑战），也是 Installer（它会把证书写入 Nginx 的 ssl_certificate 指令）。
• --apache 同理。

所以， certbot --standalone 和 certbot --nginx 的区别，不是“哪个更简单”，而是“责任边界在哪里”。 --standalone 只做一件事：证明所有权。它成功后，证书文件（ fullchain.pem , privkey.pem ）会安静地躺在 /etc/letsencrypt/live/yourdomain/ 下，仅此而已。后续怎么用，完全由你决定：你可以手动把它配给 Nginx，可以写个脚本自动 reload，也可以用 certbot --nginx 命令来“接管”这个证书，让它变成一个 Installer。而 --nginx 则是一条龙服务：它先改 Nginx 配置来通过验证，验证成功后再把证书写进去，并 reload Nginx。这种“全包”模式看似省事，但一旦出错，你得同时懂 ACME 协议、Nginx 配置语法、systemd 服务管理，调试链路极长。standalone 的哲学是“分而治之”：验证归验证，部署归部署。在 Ubuntu 22.04 这个强调清晰职责划分的系统上，这种解耦设计，恰恰是最符合工程直觉的。

提示： certbot --standalone 生成的证书，和 certbot --nginx 生成的证书，在文件内容上是完全一样的。区别只在于 Certbot 是否帮你动了 Web 服务器的配置。你可以把 standalone 当作一个“纯证书生成器”，把 nginx 插件当作一个“证书+配置自动化管家”。

3. 核心细节解析与实操要点：从零开始的每一步都踩准节奏

3.1 环境准备：Ubuntu 22.04 的“纯净基线”检查清单

在敲下第一个 certbot 命令之前，请务必花 2 分钟完成这份检查清单。这不是形式主义，而是避免后续所有“no required ssl certificate was sent”这类玄学错误的基石。

1. 确认系统时间绝对准确。
Let’s Encrypt 的证书有效期只有 90 天，且其 OCSP（在线证书状态协议）响应对时间极其敏感。Ubuntu 22.04 默认使用 systemd-timesyncd ，但它可能因网络原因同步失败。执行：

timedatectl status

检查输出中的 System clock synchronized: yes 和 NTP service: active 。如果显示 no ，立即修复：

sudo timedatectl set-ntp on
sudo systemctl restart systemd-timesyncd
# 等待 10 秒，再检查
timedatectl status

我曾遇到一个案例：服务器时间快了 5 分钟， certbot 能成功申请证书，但浏览器打开时却提示“证书尚未生效”，因为证书的 Not Before 时间比服务器时间晚。这个错误不会在 certbot 日志里体现，只会让你在应用层抓耳挠腮。

2. 彻底清空 80 端口。
这是 standalone 模式失败的头号原因。不要只相信 netstat -tuln | grep ':80' ，因为它可能漏掉被 systemd 管理的 socket。请用更权威的 ss 命令：

sudo ss -tuln | grep ':80'

如果输出非空，说明有进程在监听。常见“隐形”占用者：

• nginx ：即使你没启动， nginx.service 可能被设置为 enabled ， systemd 会在某些条件下自动拉起。
• apache2 ：同理。
• docker ：如果你运行了任何容器，检查 docker ps ，有些镜像（如 nginx:alpine ）默认就监听 80。
• caddy 或 traefik ：这些现代反向代理也爱占 80。

终极清理命令（谨慎使用）：

# 停止所有已知的 Web 服务
sudo systemctl stop nginx apache2 caddy traefik
sudo systemctl disable nginx apache2 caddy traefik
# 杀死所有监听 80 的进程（按需）
sudo ss -tulnp | grep ':80' | awk '{print $7}' | cut -d',' -f2 | cut -d' ' -f2 | xargs -r kill -9

执行完后，再次 sudo ss -tuln | grep ':80' ，必须为空。

3. 防火墙放行 80 端口。
Ubuntu 22.04 默认启用 ufw 。即使你清空了 80 端口，如果防火墙没放行，Let’s Encrypt 的验证服务器依然无法访问你。执行：

sudo ufw status verbose

检查 80 (http) 是否在 Allowed 列表中。如果没有，添加：

sudo ufw allow 80
# 如果你用的是云服务器（如 AWS EC2, 阿里云 ECS），别忘了还要在云平台的安全组里放行 80 端口！

4. 域名 DNS 解析必须生效。
这是最容易被忽略的“外部依赖”。 certbot --standalone 不需要你的 Web 服务在线，但它 绝对需要 你的域名能被公网 DNS 正确解析到这台 Ubuntu 22.04 服务器的公网 IP。执行：

dig +short yourdomain.com
# 或
nslookup yourdomain.com

输出必须是你服务器的公网 IP。如果不是，请检查你的 DNS 服务商（如 Cloudflare, DNSPod）的 A 记录是否已添加且 TTL 设置合理（建议首次设置为 300 秒，便于快速生效）。注意：Cloudflare 的橙色云朵（Proxy）状态会拦截 Let’s Encrypt 的验证请求，此时必须暂时切换为灰色云朵（DNS only）。

注意： importerror: can't connect to https url because the ssl module is not available. 这个错误，通常发生在你试图在 Python 脚本里用 urllib 访问 HTTPS 站点时，但你的 Python 环境没有编译 SSL 支持。这和 Certbot 本身无关，Certbot 的 snap 版本自带完整 SSL 栈。如果你在自己的 Python 项目里遇到这个错误，请单独修复 Python 环境，不要怀疑 Certbot。

3.2 Certbot 安装：为什么必须用 snap，而不是 apt？

Ubuntu 22.04 的官方仓库 ( apt ) 中的 python3-certbot 包，版本是固定的（通常是 1.x），而 Let’s Encrypt 的 ACME 协议在 2021 年已升级到 v2，且不断有小修订。 apt 包无法及时跟进，会导致 certbot 无法与 Let’s Encrypt 的新 API 对话，出现 urn:acme:error:unauthorized 等错误。而 snap 版本是官方唯一推荐的、保证永远最新的安装方式。

标准安装流程（官方唯一推荐）：

# 1. 更新系统（确保基础环境最新）
sudo apt update && sudo apt upgrade -y
# 2. 安装 snapd（Ubuntu 22.04 默认已安装，但确认一下）
sudo apt install snapd -y
# 3. 确保 snapd 服务已启动
sudo systemctl enable --now snapd.socket
# 4. 创建 /snap/bin 的软链接（让 certbot 命令全局可用）
sudo ln -s /var/lib/snapd/snap /snap
# 5. 安装 certbot（--classic 是必须的，它赋予 certbot 访问系统文件的权限）
sudo snap install certbot --classic
# 6. 创建一个指向 certbot 的符号链接，方便直接输入 certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

执行完后，验证：

certbot --version
# 输出应为类似：certbot 2.8.0

这个版本号会随时间自动更新。你不需要手动 snap refresh certbot ，它每天会自动检查更新。

为什么不能用 pip install certbot ？
pip 安装会把 Certbot 的所有 Python 依赖（包括 requests , pyopenssl , cryptography ）都装进你的系统 Python 环境。而 Ubuntu 22.04 的 python3-cryptography 包是经过严格安全审计的， pip 安装的版本可能引入不兼容的 ABI 或安全漏洞。更重要的是， pip 安装的 Certbot 无法使用 --standalone 的高级特性（如 --preferred-challenges http 的精细控制），因为它缺少 snap 的沙盒化运行时环境。 pip 方案是给开发者做本地测试用的，不是给生产服务器用的。

3.3 standalone 命令详解：参数背后的每一个“为什么”

certbot certonly --standalone -d example.com 这条命令，每个参数都值得深究。

certonly ：
这是最关键的子命令。它告诉 Certbot：“我只要证书，不要你帮我配置任何 Web 服务器。” 这是 standalone 模式发挥最大价值的前提。如果你误用了 certbot --nginx -d example.com ，Certbot 会试图去修改你的 Nginx 配置，而此时你的 Nginx 可能根本没装，或者配置路径不对，导致整个流程中断。

--standalone ：
指定 Authenticator。它会启动一个内置的 HTTP 服务器。这个服务器默认监听 0.0.0.0:80 （所有 IPv4 接口）和 [::]:80 （所有 IPv6 接口）。如果你的服务器只有 IPv4，或者你想强制只用 IPv4（避免某些 IPv6 配置错误），可以加：

--preferred-challenges http --http-01-port 80

但这通常是多余的，默认行为就是最优的。

-d example.com ：
-d 是 --domain 的缩写，指定你要申请证书的域名。你可以一次申请多个：

certbot certonly --standalone -d example.com -d www.example.com -d api.example.com

所有域名必须能被 DNS 解析到同一台服务器。Certbot 会为每个 -d 发起一次独立的 http-01 挑战。

关键但常被忽略的参数：

• --email you@example.com ：
  指定你的邮箱。Let’s Encrypt 会用它来发送证书到期提醒（提前 20 天）。这是强制的，如果不加，Certbot 会交互式询问。建议始终加上，避免自动化脚本卡住。

• --agree-tos ：
  同意 Let’s Encrypt 的服务条款。这是强制的，否则 Certbot 会停止并要求你手动确认。

• --non-interactive ：
  禁用所有交互式提示。这对于写成脚本、放入 CI/CD 流水线至关重要。它和 --agree-tos 、 --email 一起，构成了全自动申请的黄金三件套。

一个生产就绪的完整命令：

sudo certbot certonly --standalone \
  --email admin@example.com \
  --agree-tos \
  --non-interactive \
  --redirect \
  -d example.com \
  -d www.example.com

其中 --redirect 是一个 Installer 参数，它会在证书申请成功后，自动生成一个 Nginx/Apache 的重定向配置，将所有 HTTP 请求 301 重定向到 HTTPS。它不冲突于 --standalone ，因为 --standalone 只管验证， --redirect 是验证成功后的“附加动作”。

4. 实操过程与核心环节实现：一次成功的全流程记录

4.1 第一次申请：从命令执行到证书落地的完整现场

让我们模拟一个真实的场景：你有一台全新的 Ubuntu 22.04 Server，IP 是 203.0.113.10 ，你已经注册了域名 myapp.dev ，并在 DNS 服务商处添加了 A 记录，指向 203.0.113.10 。现在，你要为 myapp.dev 申请第一张证书。

步骤 1：执行申请命令

sudo certbot certonly --standalone \
  --email contact@myapp.dev \
  --agree-tos \
  --non-interactive \
  -d myapp.dev

步骤 2：观察 Certbot 的实时输出（这是最重要的学习环节）

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for myapp.dev
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/myapp.dev/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/myapp.dev/privkey.pem
   Your cert will expire on 2024-09-15. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again.
 - If you like Certbot, please consider supporting our work by:
   ...

这段输出信息量极大：

• Plugins selected: Authenticator standalone, Installer None ：确认 Certbot 正确选择了 standalone 验证器，且没有 Installer。
• Performing the following challenges: http-01 challenge for myapp.dev ：它正在为你发起 http-01 挑战。
• Waiting for verification... ：Certbot 已启动内置 HTTP 服务器，正在等待 Let’s Encrypt 的验证服务器来访问 http://myapp.dev/.well-known/acme-challenge/xxx 。
• Cleaning up challenges ：验证成功，Certbot 自动关闭了内置服务器。

步骤 3：验证证书文件

sudo ls -l /etc/letsencrypt/live/myapp.dev/

你应该看到：

total 0
lrwxrwxrwx 1 root root 41 Jun 15 10:23 cert.pem -> ../../archive/myapp.dev/cert1.pem
lrwxrwxrwx 1 root root 42 Jun 15 10:23 chain.pem -> ../../archive/myapp.dev/chain1.pem
lrwxrwxrwx 1 root root 46 Jun 15 10:23 fullchain.pem -> ../../archive/myapp.dev/fullchain1.pem
lrwxrwxrwx 1 root root 44 Jun 15 10:23 privkey.pem -> ../../archive/myapp.dev/privkey1.pem

这些是符号链接，指向 /etc/letsencrypt/archive/ 下的真实文件。 fullchain.pem 是你的证书链（证书 + 中间证书）， privkey.pem 是私钥。它们的权限是 644 （所有者可读写，组和其他人只读），这是安全的，因为私钥文件本身在 archive 目录下，其权限是 600 （仅所有者可读写）。

步骤 4：测试证书有效性 不要急着配 Nginx，先用 OpenSSL 命令行验证：

openssl x509 -in /etc/letsencrypt/live/myapp.dev/cert.pem -text -noout | grep "Subject:"

输出应为：

        Subject: CN = myapp.dev

再检查证书链：

openssl verify -CAfile /etc/letsencrypt/live/myapp.dev/chain.pem /etc/letsencrypt/live/myapp.dev/cert.pem

输出应为：

/etc/letsencrypt/live/myapp.dev/cert.pem: OK

这证明证书格式正确，且能被 Let’s Encrypt 的根证书链验证。

4.2 泛域名证书申请：standalone 的能力边界与突破

网络热词里频繁出现 “certbot申请泛域名证书”，这是一个常见的误区。 --standalone 模式 无法 申请泛域名证书（ *.example.com ），因为泛域名证书必须使用 dns-01 挑战，它要求你通过修改 DNS 记录（添加 _acme-challenge.example.com 的 TXT 记录）来证明所有权。 --standalone 只支持 http-01 和 tls-alpn-01 挑战，两者都要求你能控制该域名的 HTTP 或 TLS 流量。

但是，standalone 可以作为泛域名申请流程中的一个“辅助角色”。
假设你想为 *.myapp.dev 申请证书，你有两个选择：

1. 直接用 --dns-cloudflare 等插件： 这是官方推荐方式，需要你提供 Cloudflare API Token。
2. 用 standalone 为一个主域名申请证书，再用 --expand 扩展： 这是 hack，但有效。

--expand 参数允许你用一张已存在的证书，添加新的域名。例如：

# 先用 standalone 申请一个主域名
sudo certbot certonly --standalone -d myapp.dev --email contact@myapp.dev --agree-tos --non-interactive
# 再用 --expand 添加泛域名（这步会失败，因为 standalone 无法验证泛域名）
# 所以你需要换一个验证器，比如 webroot
sudo certbot certonly --webroot -w /var/www/html --expand -d myapp.dev -d *.myapp.dev --email contact@myapp.dev --agree-tos --non-interactive

但请注意， --expand 要求你已有一个有效的、未过期的证书，且新旧证书的密钥类型（RSA 或 ECDSA）必须一致。这不是 standalone 的本职工作，而是它在整个 Certbot 生态中灵活协作的一个体现。

4.3 证书自动续期：让 standalone 成为永动机

Let’s Encrypt 的证书只有 90 天有效期，手动续期是灾难。Certbot 的 renew 子命令就是为此而生。它会扫描 /etc/letsencrypt/renewal/ 目录下的所有配置文件，检查哪些证书将在 30 天内过期，然后自动调用当初申请时使用的相同 Authenticator 和参数进行续期。

standalone 续期的特殊性：
renew 命令 不会 自动为你打开防火墙或清空 80 端口。它只会读取 /etc/letsencrypt/renewal/myapp.dev.conf 文件，里面记录了你当初用的是 --standalone 。所以，续期时，它依然会尝试绑定 80 端口。

因此，续期前的准备工作，和首次申请一模一样：

• 确保 ufw allow 80 。
• 确保 ss -tuln | grep ':80' 为空。
• 确保 DNS 解析依然有效。

创建一个可靠的续期脚本（ /usr/local/bin/renew-standalone.sh ）：

#!/bin/bash
# 这是一个为 standalone 模式定制的续期脚本
set -e

# 1. 清空 80 端口
sudo systemctl stop nginx apache2 caddy 2>/dev/null || true
sudo ss -tulnp | grep ':80' | awk '{print $7}' | cut -d',' -f2 | cut -d' ' -f2 | xargs -r kill -9 2>/dev/null || true

# 2. 确保防火墙放行
sudo ufw allow 80 2>/dev/null || true

# 3. 执行续期
sudo certbot renew --non-interactive --quiet --post-hook "systemctl reload nginx" 2>&1

# 4. 清理（可选）
# sudo systemctl start nginx 2>/dev/null || true

然后，将其加入 crontab，每周日凌晨 2:15 执行：

sudo crontab -e
# 添加这一行
15 2 * * 1 /usr/local/bin/renew-standalone.sh >> /var/log/certbot-renew.log 2>&1

--post-hook "systemctl reload nginx" 是关键。它表示：续期成功后，自动重载 Nginx，让新证书生效。这就是 standalone 的魅力——它只负责“生孩子”，而“养孩子”的事，交给你自己的脚本。

实操心得：我曾经在一个客户环境里，把 renew 命令直接放进 crontab，结果某次续期时，客户的开发人员正在用 nginx -t 测试配置，导致 nginx 进程短暂监听了 80 端口， certbot renew 失败。从此，我所有的续期脚本都强制包含“清空 80 端口”的步骤，哪怕多执行一次 kill -9 ，也比证书过期强。

5. 常见问题与排查技巧实录：那些年我们踩过的坑

5.1 “no required ssl certificate was sent” 错误的真相

这个错误信息，是 Let’s Encrypt 的 ACME 服务器返回的，意思是：“我发起了一个 http-01 挑战，但我没有收到你返回的、正确的验证字符串。” 它 不是 Certbot 的错误，而是 Certbot 和 Let’s Encrypt 之间的通信失败。排查必须从网络层开始。

排查流程图（文字版）：

1. 检查 Certbot 日志： sudo cat /var/log/letsencrypt/letsencrypt.log | tail -50 。查找 Failed authorization procedure 关键字，它会告诉你具体是哪个域名失败。
2. 在服务器本地测试： curl -I http://myapp.dev/.well-known/acme-challenge/test 。如果返回 404 ，说明 standalone 服务器没起来；如果返回 Connection refused ，说明 80 端口没被监听；如果返回 200 ，说明 standalone 工作正常，问题出在外部。
3. 从外部测试： 在另一台能上网的电脑上，执行 curl -I http://myapp.dev/.well-known/acme-challenge/test 。如果超时，说明防火墙或 DNS 有问题；如果返回 404 ，说明 standalone 服务器起来了，但 Let’s Encrypt 的请求被某种中间设备（如企业级防火墙、ISP 的透明代理）拦截或修改了。
4. 终极验证： 使用 Let’s Encrypt 的官方调试工具： https://check-your-website.server-daten.de/ 。输入你的域名，它会模拟 Let’s Encrypt 的验证过程，并给出详细的 HTTP 响应头和状态码。

一个经典案例：
客户报告 no required ssl certificate was sent 。我让他执行第 2 步， curl 返回 200 。执行第 3 步， curl 超时。我让他检查云服务器的安全组，发现他只放行了 80 端口的 Inbound ，但忘了 Outbound 规则。结果是，Let’s Encrypt 的服务器能发请求进来，但服务器的响应包（TCP ACK）被安全组规则丢弃了，导致连接半开。添加 All traffic 的 Outbound 规则后，问题解决。这个教训是： no required ssl certificate was sent 的根源，90% 在网络基础设施，而非 Certbot 本身。

5.2 “ImportError: can't connect to https url because the ssl module is not available.” 的根源与解法

这个错误，几乎 100% 出现在你自己写的 Python 脚本里，而不是 Certbot 里。它意味着你当前的 Python 解释器在编译时，没有链接到系统的 OpenSSL 库。

诊断：

python3 -c "import ssl; print(ssl.OPENSSL_VERSION)"

如果报错 ModuleNotFoundError: No module named 'ssl' ，或者 ImportError ，说明 Python 编译环境缺失。

Ubuntu 22.04 的标准解法：

# 重新安装 python3 的 dev 包和 openssl 包
sudo apt install --reinstall python3-dev libssl-dev build-essential -y
# 如果你用的是 pyenv 或 conda，需要重新编译或创建环境
# 对于 pyenv:
pyenv uninstall 3.10.12
pyenv install 3.10.12
# 对于 conda:
conda install -c conda-forge openssl

重要提示： 这个错误和 Certbot 的 snap 版本完全无关。snap 版本的 Certbot 是一个独立的、自包含的二进制，它自带所有依赖。所以，如果你在运行 certbot 命令时看到这个错误，那一定是你误用了 pip install certbot ，并且你的 pip 环境坏了。此时，唯一的解法是卸载 pip 版本的 certbot，然后用 snap 重新安装。

5.3 standalone 模式下 Nginx 配置的“零配置”最佳实践

很多新手以为，用 standalone 申请了证书，就得手动去改 Nginx 的 server 块。其实，有一个更优雅、更不易出错的方式：利用 Certbot 的 --deploy-hook 。

原理： --deploy-hook 是一个在每次证书成功续期（或首次申请）后，都会执行的 shell 命令。你可以用它来自动更新 Nginx 配置。

步骤：

1. 创建一个通用的 Nginx 配置模板 /etc/nginx/sites-available/ssl-template ：

server {
    listen 443 ssl http2;
    server_name {{DOMAIN}};
    ssl_certificate /etc/letsencrypt/live/{{DOMAIN}}/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/{{DOMAIN}}/privkey.pem;
    # ... 其他 SSL 优化配置
}

2. 创建一个部署脚本 /usr/local/bin/deploy-nginx.sh ：

#!/bin/bash
# $1 是域名，$2 是证书路径
DOMAIN=$1
# 用 sed 替换模板中的 {{DOMAIN}}
sudo sed "s/{{DOMAIN}}/$DOMAIN/g" /etc/nginx/sites-available/ssl-template | sudo tee /etc/nginx/sites-enabled/$DOMAIN > /dev/null
sudo nginx -t && sudo systemctl reload nginx

3. 在申请证书时，带上这个 hook：

sudo certbot certonly --standalone \
  --deploy-hook "/usr/local/bin/deploy-nginx.sh {domain}" \
  -d myapp.dev \
  --email contact@myapp.dev \
  --agree-tos \
  --non-interactive

这样，无论是首次申请还是后续续期，Nginx 配置都会被自动创建和重载。 {domain} 是 Certbot 的内置变量，会被自动替换为当前处理的域名。

注意事项： --deploy-hook 是在 --post-hook 之后执行的。 --post-hook 用于服务重载， --deploy-hook 用于配置文件生成。两者结合，才能实现真正的“零干预”HTTPS 部署。

5.4 standalone 与 Windows SSL/TLS 协议信息泄露漏洞（CVE-2016-2183）的无关性澄清