运维123 - acme.sh
type: channel
link: https://www.sddts.cn/index.php/category/acme-sh/
description: acme.sh
items: acme.sh 通配符证书验证失败排查复盘
items: ACME DNS 验证与自定义递归服务器作用分析
items: acme.sh 跨 DNS 服务商多域名证书申请指南

acme.sh 通配符证书验证失败排查复盘
type: item
date: 2026-03-02T02:08:34+00:00
description: acme.sh 通配符证书验证失败排查复盘一、事件概述1. 事件背景在主机 root@156.226.176.52 上使用 acme.sh 签发 op123.ren 及其多子域通配符证书时，DNS 验证失败，报错提示在 _acme-challenge.n9e.op123.ren 处未找到 TXT 记录。2. 影响范围A. 影响功能无法为以下域名签发或续期证书：op123.ren、.op123.ren、.ngrok.op123.ren、.tools.op123.ren、.atzlinux.op123.ren、.api.op123.ren、.mcp.op123.ren、*.n9e.op123.ren。B. 影响时长自执行命令至根因确认并给出修复方案为止。C. 严重程度证书无法签发会导致上述域名无法使用有效的 HTTPS，属配置类问题，修复后即可恢复。3. 执行命令与报错执行命令为：/root/.acme.sh/acme.sh --issue -d op123.ren -d "*.op123.ren" \ -d "*.ngrok.op123.ren" -d "*.tools.op123.ren" -d "*.atzlinux.op123.ren" \ -d "*.api.op123.ren" -d "*.mcp.op123.ren" -d "*.n9e.op123.ren" \ --dns dns_tencent --challenge-alias sddts.cn --force报错摘要：Invalid status. Verification error details: No TXT record found at _acme-challenge.n9e.op123.renRemoving DNS records 时仅删除了 _acme-challenge.sddts.cn 的 TXT 记录伴随 libcurl error code 3 等次要错误二、事件时间线1. 问题发生用户执行上述 acme.sh 命令，使用腾讯云 DNS API（dns_tencent）与挑战别名（challenge-alias sddts.cn），期望在 sddts.cn 所在 DNS 写入一条 TXT 完成所有域名验证。2. 问题定位通过分析报错与 acme.sh 官方文档可知：使用 --challenge-alias 时，acme.sh 只会把验证用 TXT 写在 _acme-challenge.sddts.cnLet's Encrypt 仍会按域名逐个查询 _acme-challenge.<域名>因此必须在 op123.ren 的 DNS 中，为每个参与签发的（子）域名预先配置 CNAME：_acme-challenge.<该域名> 指向 _acme-challenge.sddts.cn报错指向 _acme-challenge.n9e.op123.ren，说明该名的 CNAME 缺失或指向错误。3. 根因确认用户执行 dig 验证：dig _acme-challenge.n9e.op123.ren CNAME +short返回结果为：_acmhe-challenge.sddts.cn.（多了一个字母 h）。正确目标应为 _acme-challenge.sddts.cn.。CNAME 目标拼写错误，导致 Let's Encrypt 跟随 CNAME 后查询的是 _acmhe-challenge.sddts.cn 的 TXT，而 acme.sh 实际写入的是 _acme-challenge.sddts.cn，因此验证失败。4. 解决方案在 op123.ren 的 DNS 中，将 _acme-challenge.n9e.op123.ren 的 CNAME 目标从 _acmhe-challenge.sddts.cn. 修改为 _acme-challenge.sddts.cn.，等待解析生效后重新执行 acme.sh 签发命令。三、问题分析1. 直接原因Let's Encrypt 在查询 _acme-challenge.n9e.op123.ren 时，通过 CNAME 被指向 _acmhe-challenge.sddts.cn，在该处无法获得 acme.sh 写入的 TXT（TXT 实际在 _acme-challenge.sddts.cn），因此报「No TXT record found at _acme-challenge.n9e.op123.ren」。2. 根本原因（5 Whys 分析）A. 为什么会出现这个问题？CNAME 记录的目标主机名配置错误，写成了 _acmhe-challenge.sddts.cn 而非 _acme-challenge.s…

ACME DNS 验证与自定义递归服务器作用分析
type: item
date: 2026-01-29T07:49:35+00:00
description: ACME DNS 验证与自定义递归服务器作用分析一、问题背景1. 核心疑问在使用 acme.sh 的 DNS 验证方式申请域名证书时，用户可以指定自定义的递归 DNS 服务器。这引发了一个疑问：ACME 服务器是通过互联网的公共 DNS 进行域名验证的，用户指定的 DNS 服务器能起到什么作用？2. 涉及组件ACME 协议：自动化证书管理环境协议acme.sh：Shell 脚本实现的 ACME 客户端DNS 验证：ACME 挑战-响应验证方式之一递归 DNS 服务器：负责递归查询域名解析的服务器二、ACME DNS 验证机制1. 验证流程概述sequenceDiagram participant Client as acme.sh 客户端 participant DNS as DNS 服务商 participant Propagation as DNS 传播 participant ACME as ACME 服务器 (Let's Encrypt) participant PublicDNS as 公共 DNS Client->>DNS: 1. 申请证书 Client->>DNS: 2. 添加 TXT 记录 _acme-challenge.example.com DNS-->>Client: 确认添加成功 Note over Client,ACME: 等待 DNS 传播完成 Client->>PublicDNS: 3. 轮询检测 TXT 记录 (使用指定 DNS 服务器) PublicDNS-->>Client: 仍不可见 Client->>PublicDNS: 继续轮询... PublicDNS-->>Client: 记录已可见 Client->>ACME: 4. 通知 ACME 服务器验证 ACME->>PublicDNS: 5. 从多个位置查询 TXT 记录 PublicDNS-->>ACME: 返回 TXT 记录值 ACME-->>Client: 6. 验证通过，颁发证书 Client->>DNS: 7. 清理 TXT 记录2. ACME 服务器的验证行为A. 多位置验证ACME 服务器（如 Let's Encrypt）从全球多个位置验证 DNS 记录：验证源分布：美国、欧洲、亚太等地使用的 DNS：公共递归服务器（如 Google 8.8.8.8、Cloudflare 1.1.1.1）验证逻辑：必须从多个位置都能查询到正确的 TXT 记录B. 权威性验证路径ACME 服务器 → 公共递归 DNS → 权威 DNS → DNS 记录验证关键点：ACME 服务器不使用用户指定的 DNS 服务器进行验证。三、自定义 DNS 服务器的作用1. 本地预检测机制用户指定的 DNS 服务器仅用于 acme.sh 本地的预检测，不影响 ACME 服务器的验证过程。A. 问题场景时间轴： T0: 用户添加 TXT 记录到 DNS 服务商 T1: DNS 服务商更新权威记录 T2: 记录传播到部分 DNS 服务器 T3: 记录全球可见 acme.sh 在 T2 时刻触发验证 → ACME 服务器可能看不到记录 → 验证失败B. 解决方案# 方式 1：固定等待时间（粗暴） acme.sh --issue --dns dns_cf -d example.com --dnssleep 120 # 方式 2：指定 DNS 服务器进行智能检测 export ACME_DNS_SERVER="8.8.8.8" acme.sh --issue --dns dns_cf -d example.com2. 工作原理对比graph TB subgraph "方式 1：固定等待" A1[添加 TXT 记录] -->|等待 120 秒| B1[触发 ACME 验证] B1 --> C1{ACME 服务器查询} C1 -->|成功| D1[颁发证书] C1 -->|失败| E1[重试] end subgraph "方式 2：智能检测" A2[添加 TXT 记录] -->|轮询检测| B2[使用指定 DNS 查询] B2 -->|未检测到| B2 B2 -->|检测到| C2[触发 ACME 验证] C2 --> D2[颁发证书] end3. 具体配置示例A. 使用公共递归 DNS# 使用 Google DNS 进行预检测 export ACME_DNS_SERVER="8.8.8.8:53" # 使用 Cloudflare DNS export ACME_DNS_SERVER="1.1.1.1:53" # 使用国内 DNS（加速检测） export ACME_DNS_SERVER="223.5.5.5:53"B. 使用权威 DNS# 直接查询权威 DNS 服务器，…

acme.sh 跨 DNS 服务商多域名证书申请指南
type: item
date: 2026-01-29T07:00:25+00:00
description: acme.sh 跨 DNS 服务商多域名证书申请指南一、概述1. 问题背景在实际使用场景中，用户可能拥有多个分散在不同 DNS 服务商的域名。例如：a.com 及其子域名的 DNS 解析托管在阿里云b.com 及其子域名的 DNS 解析托管在腾讯云 DNSPod用户希望生成一张 SSL 证书，同时覆盖 a.com、.a.com、b.com、.b.com 这些域名。2. 核心结论重要提示：acme.sh 官方不支持在单个证书中混合使用多个 DNS 服务商的 API。这是 acme.sh 的设计限制，而非配置问题。二、技术原理1. acme.sh 的工作原理acme.sh 使用 ACME 协议申请证书，支持 DNS-01 验证方式。在 DNS-01 验证中，acme.sh 需要在每个域名的 DNS 解析中添加一条 TXT 记录，证明申请者对该域名的控制权。2. 多 DNS API 的技术限制当申请一个包含多个域名的证书时，acme.sh 会为所有域名使用相同的 DNS API 插件。这是因为：acme.sh 的证书申请命令只接受一个 --dns 参数每个域名的 DNS 验证必须通过该指定的 DNS API 完成如果域名不在该 DNS 服务商处，API 调用将失败graph TD A[acme.sh 申请证书] --> B{指定 DNS API} B -->|阿里云 API| C[验证 a.com] B -->|阿里云 API| D[验证 b.com 失败] C --> E[证书申请失败] D --> E三、解决方案方案一：分别为每个域名生成独立证书（推荐）1. 方案说明为每个 DNS 服务商处的域名分别生成证书，这是最简单、最可靠的方式。2. 阿里云域名证书申请A. 获取阿里云 API 密钥登录阿里云控制台进入访问控制（RAM）-> 用户创建新用户或使用现有用户为用户添加 DNS 管理权限创建 AccessKey，记录 AccessKey ID 和 AccessKey SecretB. 配置环境变量export Ali_Key="your_aliyun_access_key_id" export Ali_Secret="your_aliyun_access_key_secret"C. 申请证书acme.sh --issue --dns dns_ali \ -d a.com \ -d *.a.com3. 腾讯云域名证书申请A. 获取腾讯云 API 密钥登录腾讯云控制台进入访问管理 -> API 密钥管理创建密钥，记录 SecretId 和 SecretKeyB. 配置环境变量export DP_Id="your_tencent_secret_id" export DP_Key="your_tencent_secret_key"C. 申请证书acme.sh --issue --dns dns_dp \ -d b.com \ -d *.b.com4. 优点与缺点优点：配置简单，不易出错证书续期互不影响灵活性高，可独立管理符合最佳实践缺点：需要管理多个证书文件Web 服务器需要配置多个证书方案二：统一 DNS 服务商1. 方案说明将所有域名的 DNS 解析迁移到同一个服务商，然后使用单个证书覆盖所有域名。2. 实施步骤A. 选择目标 DNS 服务商根据需求选择阿里云或腾讯云作为统一 DNS 服务商。B. 迁移 DNS 解析在目标 DNS 服务商添加域名复制所有 DNS 记录到新服务商修改域名 NS 记录，指向新的 DNS 服务器等待 DNS 生效（通常需要 24-48 小时）C. 申请统一证书# 假设全部迁移到阿里云 export Ali_Key="your_aliyun_access_key_id" export Ali_Secret="your_aliyun_access_key_secret" acme.sh --issue --dns dns_ali \ -d a.com \ -d *.a.com \ -d b.com \ -d *.b.com3. 优点与缺点优点：单一证书管理简单减少证书续期任务缺点：需要迁移 DNS 服务迁移过程可能影响服务失去多云冗余优势方案三：DNS 别名模式（不推荐）1. 方案说明acme.sh 支持 DNS 别名模式，但配置复杂，不建议普通用户使用。2. 技术原理DNS 别名模式允许通过 CNAME 记录，将一个域名的 ACME 挑战记录指向另一个域名。这样：a.com 的 ACME 挑战通过阿里云 DNS 验证b.com 的 ACME 挑战通过 CNAME 指向 a.com，间接通过阿里云验证3. 配置复杂度需要手动配置 CNAME 记录需要理解 ACME 协议细节故障排查困难四、最佳实践1. 证书管…