通配符证书（.example.com）必须通过DNS-01验证实现自动化签发与续期，HTTP-01和webroot方式完全失效；需选用对应DNS服务商的certbot-dns-插件，配置最小权限凭据，显式指定插件及凭据路径执行certbot renew，并设置600权限的凭据文件。
通配符证书（*.example.com）不能靠 certbot --nginx 或 --webroot 直接搞定——它必须走 DNS-01 验证，且续期时若没预埋自动化逻辑，就会卡在手动加 TXT 记录那一步，根本谈不上“自动轮转”。
DNS-01 是唯一可行路径，HTTP-01 和 webroot 全部失效
通配符域名要求 Let’s Encrypt 对 _acme-challenge.example.com 进行权威 DNS 查询。这意味着：
-
--nginx插件依赖 HTTP 响应，不触碰 DNS，直接报错或静默失败 -
--webroot同样只写文件、不改 DNS，对*.example.com完全无效 - 哪怕你把所有子域名都列进
-d参数，只要含*，Certbot 就强制切换到 DNS-01 模式 - 本地测试用
--staging时也得走真实 DNS，否则验证必超时
certbot-dns-* 插件不是可选项，而是必需品
手动模式（--manual）虽然能签发，但每次续期都要人工干预，违背“自动化”初衷。真正能闭环的只有插件驱动的 DNS-01 流程：
- 选插件前先确认你的 DNS 服务商：阿里云用
certbot-dns-aliyun，Cloudflare 用certbot-dns-cloudflare，Route53 用certbot-dns-route53 - 插件需凭据（AK/SK、API Token），务必最小权限：只允许增删
_acme-challengeTXT 记录，禁止读取其他 DNS 记录 - 首次签发命令示例（以阿里云为例）：
certbot certonly --dns-aliyun --dns-aliyun-credentials ~/.secrets/certbot/aliyun.ini -d example.com -d *.example.com --agree-tos --email admin@example.com - 插件会自动创建 TXT、等待生效、删除 TXT，全程无交互
续期命令必须带插件参数，不能只跑 certbot renew
certbot renew 默认复用上次验证方式，但它不会记住你当初用了哪个 DNS 插件、凭据在哪。结果就是续期时提示 “No authenticator found”，或又退回手动流程。
正确做法是显式指定插件和凭据路径：
- 写死续期命令（推荐放入 cron）：
certbot renew --dns-aliyun --dns-aliyun-credentials ~/.secrets/certbot/aliyun.ini --deploy-hook "nginx -s reload" - 不要依赖
/etc/letsencrypt/renewal/*.conf自动加载插件——该文件不保存凭据路径，只存参数名 - 如果多个域名用不同 DNS 服务商，必须分组续期，或统一迁移到同一平台
-
--deploy-hook比--post-hook更可靠：它只在证书真正更新后触发，避免无效 reload
Nginx 配置里别硬编码通配符证书路径
通配符证书签发后，路径是 /etc/letsencrypt/live/example.com/，但 Nginx 的 ssl_certificate 不支持 glob 或变量匹配通配符域名本身——$server_name 解析出来是 api.example.com，不是 example.com。
所以实际配置只能固定引用根域证书：
- 所有子域名共用一个
server块，用server_name *.example.com example.com; -
ssl_certificate必须写死为/etc/letsencrypt/live/example.com/fullchain.pem，不能用变量拼接 - 确保该证书确实覆盖了你要服务的所有子域名（
certbot certificates可查 SAN 列表） - 如果后续新增子域名，只需重新运行签发命令追加
-d newsub.example.com，证书会自动扩展 SAN，无需改 Nginx
最易被忽略的一点：DNS 凭据文件（如 aliyun.ini）的权限必须是 600，且属主为运行 certbot 的用户；否则插件拒绝读取，续期静默失败，日志里只有一句 “Authentication failed”，连具体哪步出错都不提示。
