LiteSSL ACME DNS-01 鉴权漏洞技术分析一、事件概述1. 事件背景2026 年 1 月，用户 00oo00 在 V2EX 社区披露了 LiteSSL ACME 服务存在严重的鉴权漏洞，该漏洞允许攻击者盗签他人已通过 DNS-01 验证的泛域名证书。LiteSSL 是 TrustAsia（亚洲诚信）推出的免费 ACME 证书服务。2. 影响范围A. 影响用户数初步排查涉及 100 多张证书B. 影响时长从服务上线至漏洞披露，持续数月C. 影响功能所有通过 DNS-01 方式验证的域名证书（包括泛域名证书和普通域名证书）3. 严重程度P1 级安全漏洞（CA 信任体系核心问题）二、漏洞原理1. 直接原因LiteSSL 的 DNS-01 challenges 验证缓存机制存在两个关键缺陷：验证缓存有效期过长（30 天）未验证签发请求是否来自同一 ACME 账户2. 根本原因分析graph TD A[攻击者发现目标域名] --> B[查询证书透明度日志] B --> C[找到目标域名的过往证书记录] C --> D[使用自己的 ACME 账户申请相同域名] D --> E{服务器检查缓存} E -->|缓存有效 30天| F[跳过 DNS 验证] E -->|缓存失效| G[要求 DNS 验证] F --> H[成功签发证书] G --> I[验证失败]3. 技术细节A. 正常 ACME DNS-01 验证流程sequenceDiagram participant C as ACME 客户端 participant S as ACME 服务器 participant D as DNS 服务器 C->>S: 请求域名授权 S->>C: 返回 DNS-01 挑战 C->>D: 更新 TXT 记录 C->>S: 通知验证就绪 S->>D: 查询 TXT 记录 D-->>S: 返回验证记录 S->>C: 验证通过，授权状态 VALIDB. 漏洞利用流程sequenceDiagram participant A1 as 攻击者 A (原账户) participant S as ACME 服务器 participant D as DNS 服务器 participant A2 as 攻击者 B (新账户) A1->>S: 申请 example.com 证书 S->>D: DNS-01 验证 D-->>S: 验证成功 S-->>A1: 签发证书 Note over S: 缓存验证结果 30 天 A2->>S: 使用新账户申请 example.com S->>S: 检查缓存 Note over S: 找到有效缓存 未检查账户一致性 S-->>A2: 直接签发证书C. IP 获取问题除核心鉴权漏洞外，还存在辅助问题：速率限制基于错误获取的内网 IP（10.254.14.70）将反向代理服务器的内网 IP 当做客户端 IP三、厂商响应1. 应急响应时间线时间事件T+0V2EX 帖子发布，漏洞披露T+2hTrustAsia 官方回应，关闭证书签发接口T+4h定位问题，开始吊销错误签发的证书T+12h完成受影响证书吊销（100+ 张）T+24hMozilla Bugzilla 报告发布T+36h问题修复，根因分析同步2. 处理措施A. 立即措施关闭 LiteSSL 证书签发接口将所有 ACME 授权域名状态从 VALID 重置为 REVOKED吊销所有受影响的证书（遵循 CAB/F 24 小时要求）B. 根本修复修复 DNS-01 验证缓存的账户隔离问题缩短验证缓存有效期修复 IP 获取逻辑C. 透明披露在 Mozilla Bugzilla 发布初步报告在 V2EX 原帖持续更新处理进展计划后续发布根因分析四、技术深度分析1. 漏洞本质A. EAB 绑定问题LiteSSL 使用 EAB（External Account Binding）标识账户验证缓存与 EAB 绑定，但未校验请求账户与缓存账户的一致性导致任何账户都可以利用其他账户的验证缓存B. 缓存策略缺陷30 天的缓存有效期远超行业标准Let's Encrypt 通常为 30 天，但配合账户隔离机制长有效期扩大了攻击窗口2. 实际攻击场景A. 攻击前提目标域名必须曾在 LiteSSL 签发过证书目标域名使用 DNS-01 方式验证验证缓存仍在有效期内B. 攻击限制无法用于任意域名（必须有过往签发记录）无法获取原证书的私钥需要配合其他攻击手段（如 DNS 劫持）才能实现中间人攻击3. 与历史事件对比事件CA问题后果DigiNotar (2011)DigiNotar恶意签发伪造证书CA 破产，根证书被吊销StartCom (2016)StartCom签发流程不规范被 Chrome/Firefox 移除信任TrustAsia (2026)TrustAsiaACME 验证缓存隔离失效主动披露，快速修复五、安全影响评估1. 直接影响A. 受影响证书类型仅影响通过 ACME 协议签发的免费证书商业证书和 API 签发的证书不受影响主要影响使用 DNS-01 验证的域名B. 攻击者能做什么为他人域名申请新证书证书私钥由攻击者控制可用于搭建钓鱼网站配合 DNS 劫持可实现中间人攻击C. 攻击者不能做什么无法获取原证书的私钥无法吊销他人的合法证书无法影响未在 LiteSSL 签发过的域名2. 间接影响A. 信任体系冲击CA 的核心职责是确保签发证书的鉴权准确性此漏洞违反了 CA/Browser Forum 基线要求可能影响 TrustAsia 的品牌信誉B. 生态影响用户对免费 ACME 服务的信任度下降引发对其他 CA 类似问题的担忧强调了证书透明度（CT）日志的重要性六、经验总结1. 厂商做得好的地方A. 响应及时收到通知后 2 小时内关闭服务24 小时内完成证书吊销积极与社区沟通B. 处理透明在原贴持续更新进展主动披露 Mozilla Bugzilla 报告承认问题，不推诿责任C. 修复彻底从审慎角度，重置所有授权状态计划发布详细根因分析考虑建立 SRC 安全响应中心2. 需要改进的地方A. 设计缺陷缓存机制未考虑账户隔离缓存有效期设置过长IP 获取逻辑存在基础错误B. 测试不足此类基础鉴权问题应在测试阶段发现缺少安全审计和渗透测试未充分考虑 ACME 协议的安全边界C. 监控缺失缺少异常签发行为监控没有证书透明度日志的自动监控告警3. 行业启示A. CA 运营教训免费服务和付费服务需同等安全标准ACME 协议实现需严格遵循 RFC 规范信任是 CA 的核心资产，一旦破坏难以恢复B. 安全开发建议鉴权系统需进行威胁建模缓存机制必须考虑权限边界多层防御：缓存隔离 + 速率限制 + 异常检测C. 社区监督价值白帽子披露对生态安全至关重要透明的漏洞披露流程有助于建立信任社区反馈渠道的有效性（邮件、在线客服）七、技术建议1. 对用户A. 立即行动检查是否使用 LiteSSL 签发的证书如受影响，按 TrustAsia 指引重新申请证书监控证书透明度日志，检测异常签发B. 长期措施启用证书透明度监控（如 Cloudflare CT Monitor）使用信誉良好的 CA（Let's Encrypt、DigiCert 等）定期审查证书来源和有效期2. 对 CA 运营者A. ACME 实现建议严格按照 RFC 8555 实现鉴权逻辑验证缓存必须与账户强绑定缩短缓存有效期或实现即时失效机制B. 安全加固graph LR A[ACME 请求] --> B{账户验证} B -->|失败| C[拒绝请求] B -->|成功| D{缓存检查} D -->|命中且账户匹配| E{缓存时效} D -->|未命中或账户不匹配| F[强制 DNS 验证] E -->|有效| G[使用缓存] E -->|失效| F F --> H[更新缓存] H --> I[签发证书] G --> IC. 监控告警监控同一域名的多账户签发行为异常证书签发行为告警定期审计证书透明度日志3. 对 ACME 客户端开发者A. 安全最佳实践为每个用户使用独立的 EAB避免共享 EAB 给多用户使用实现 ARI（ACME Renewal Information）特性B. 集成建议优先支持直连 ACME 模式如需代理模式，确保严格的账户隔离支持证书自动更新和吊销八、相关技术标准1. ACME 协议规范RFC 8555：ACME 协议定义RFC 8737：ACME 账户绑定外部账户RFC 8738：批量证书申请2. CA/Browser Forum 基线要求版本 1.8.0：域名验证要求证书透明度要求密钥泄露响应要求3. 证书透明度（CT）RFC 6962：证书透明度协议所有公开信任的证书必须录入 CT 日志用户可通过 crt.sh 等服务查询证书记录参考资料V2EX 原帖：LiteSSL 鉴权漏洞 可随意盗签他人泛域名证书Mozilla Bugzilla 报告：TrustAsia LiteSSL Security IncidentRFC 8555: ACME Protocol证书透明度日志查询