运维123 - SSL
type: channel
link: https://www.sddts.cn/index.php/category/SSL/
items: acme.sh 通配符证书验证失败排查复盘
items: Let's Encrypt 发布 DNS-PERSIST-01：基于 DNS 的持久化挑战验证新模型
items: X509 证书交叉签名工作原理深度解析
items: Let's Encrypt 交叉签名：免费兼容老系统的策略分析
items: httpscheck SSL/TLS 证书检查工具设计
items: acme.sh 跨 DNS 服务商多域名证书申请指南
items: Certificate Inspector：基于 Playwright 的全链路 SSL 证书检测工具
items: LiteSSL ACME DNS-01 鉴权漏洞技术分析
items: TLS Shunt TLS流量分流器技术分析
items: 自建CA 手动生成rsa1024的证书并配置nginx实现嵌入式设备ssl加密

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…

Let's Encrypt 发布 DNS-PERSIST-01：基于 DNS 的持久化挑战验证新模型
type: item
date: 2026-02-19T02:08:50+00:00
description: Let's Encrypt 发布 DNS-PERSIST-01 新挑战类型简化证书自动化一、新闻概述1. 标题Let's Encrypt 发布 DNS-PERSIST-01：基于 DNS 的持久化挑战验证新模型2. 发布时间2026 年 2 月 18 日3. 来源Let's Encrypt 官方博客二、核心内容1. 事件摘要A. 主要内容Let's Encrypt 宣布正在实施支持一种全新的 ACME 挑战类型 DNS-PERSIST-01，该类型基于新的 IETF 草案规范。B. 核心亮点持久化授权记录，一次配置长期有效无需每次续期时更新 DNS 记录将授权直接绑定到 ACME 账户和 CA支持范围控制和可选过期时间特别适合 IoT 部署、多租户平台和批量证书操作场景2. 关键信息A. 版本信息基于 IETF 草案规范：draft-ietf-acme-dns-persist-00B. 重要数据CA/Browser Forum 投票 SC-088v3 于 2025 年 10 月全票通过IETF ACME 工作组于同月采纳该草案预计 2026 年第一季度末在测试环境推出生产环境预计 2026 年第二季度推出C. 涉及技术ACME 协议DNS TXT 记录验证Pebble（Let's Encrypt 的 CA 软件 Boulder 的迷你版本）lego-cli 客户端实现3. 背景介绍A. 传统 DNS-01 挑战DNS-01 挑战是 Let's Encrypt 提供的域名验证方式之一，特别适用于需要通配符证书或不愿将基础设施暴露到公网的用户。其工作原理是客户端在 DNS TXT 记录中发布 Let's Encrypt 生成的令牌，Let's Encrypt 通过查询 DNS 来验证域名控制权。B. 存在的问题传统 DNS-01 挑战虽然广泛支持且经过实战验证，但存在显著的运营成本：DNS 传播延迟导致验证等待时间每次续期都需要更新 DNS 记录自动化流程通常需要在基础设施中分发 DNS 凭据三、详细报道1. 主要内容A. DNS-01 的重复验证机制传统 DNS-01 挑战依赖 Let's Encrypt 生成的一次性令牌。ACME 客户端需要将包含该令牌的 TXT 记录发布到 _acme-challenge.<YOUR_DOMAIN>，Let's Encrypt 查询 DNS 确认值匹配。由于每次授权都需要新令牌，DNS 更新成为签发工作流程的必要环节。优势在于每次成功验证都提供了当前控制域名 DNS 的新证明。但在实践中，这意味着：DNS API 凭据存在于签发管道的某个位置验证尝试涉及等待 DNS 传播DNS 变更频繁发生——大型部署中可能每天多次B. DNS-PERSIST-01 的持久化授权机制DNS-PERSIST-01 采用不同的验证方法。它不是为每次签发发布新的挑战记录，而是发布一个持久的授权 TXT 记录，标识允许为此域名签发证书的 CA 和特定 ACME 账户。对于主机名 example.com，记录位于 _validation-persist.example.com：graph LR subgraph DNS_01["传统 DNS-01 流程"] A1[ACME 客户端] -->|每次签发/续期| B1[更新 _acme-challenge 记录] B1 --> C1[Let's Encrypt 验证] C1 -->|等待 DNS 传播| D1[颁发证书] end subgraph DNS_PERSIST_01["DNS-PERSIST-01 流程"] A2[ACME 客户端] -->|一次性配置| B2[设置 _validation-persist 记录] B2 --> C2[Let's Encrypt 验证] C2 -->|无需等待传播| D2[直接颁发证书] D2 -->|后续续期| D2 end记录格式示例：graph TB A["_validation-persist.example.com. IN TXT"] --> B["letsencrypt.org;"] A --> C["accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"] style A fill:#e1f5ff style B fill:#fff3cd style C fill:#fff3cd一旦该记录存在，就可以用于新的签发和所有后续续期，从操作上将 DNS 变更从关键路径中移除。2. 技术细节A. 安全权衡DNS-01 中的敏感资产是 DNS 写入权限。在许多部署中，DNS API 凭据分布在签发和续期管道中，增加了攻击者可能泄露它们的位置数量…

X509 证书交叉签名工作原理深度解析
type: item
date: 2026-02-04T21:43:48+00:00
description: X509 证书交叉签名工作原理深度解析一、概述1. 简介A. 是什么X.509 证书交叉签名（Cross Signing）是一种证书信任链技术，允许同一个证书通过多个不同的证书颁发机构（CA）进行签名，从而建立多条通向不同受信任根证书的验证路径。B. 为什么重要解决 CA 根证书过期问题：当旧的根证书即将过期时，可以通过交叉签名无缝迁移到新根证书扩大兼容性范围：使同一证书能被更多操作系统和浏览器信任简化证书管理：无需重新颁发终端用户证书即可完成信任链切换C. 学完能理解什么X.509 证书的基本结构和关键字段数字签名的工作原理和验证流程交叉签名的技术实现和实际应用TLS 握手过程中的证书验证机制2. 前置知识A. 必备技能基本的密码学概念（公钥加密、数字签名）了解 HTTPS 和 TLS 基础对证书颁发机构（CA）有基本认识B. 推荐知识ASN.1 编码格式PKI（公钥基础设施）体系二、证书格式基础1. 证书数据结构X.509 证书本质上是一个封装了公钥和元数据的数字信封。证书包含以下核心信息：主体信息（Subject）：证书持有者的名称、组织、国家等颁发者信息（Issuer）：签发此证书的 CA 信息公钥（Public Key）：证书持有者的公钥有效期（Validity）：证书的生效和失效时间数字签名（Signature）：颁发者对证书内容的数字签名2. 编码格式证书使用 ASN.1（Abstract Syntax Notation One）格式定义数据结构，通常采用 DER（Distinguished Encoding Rules）或 BER（Basic Encoding Rules）编码。以下是证书数据的简化 JSON 表示示例：{ "subject": { "common_name": "R3", "country": "US", "organization": "Let's Encrypt", "names": ["US", "Let's Encrypt", "R3"] }, "issuer": { "common_name": "DST Root CA X3", "organization": "Digital Signature Trust Co.", "names": ["Digital Signature Trust Co.", "DST Root CA X3"] }, "serial_number": "85078157426496920958827089468591623647", "not_before": "2020-10-07T19:21:40Z", "not_after": "2021-09-29T19:21:40Z", "sigalg": "SHA256WithRSA", "authority_key_id": "C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10", "subject_key_id": "14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6", "public_key": ["..."], "signature": ["..."] }三、数字签名工作原理1. 签名与验证机制数字签名使用非对称加密技术，确保证书的完整性和真实性。A. 签名过程CA 使用其私钥对证书数据生成数字签名签名附加在证书上，形成完整的证书文件B. 验证过程获取证书颁发者的公钥使用颁发者公钥验证证书上的数字签名如果验证通过，确认证书确实由该颁发者签发且未被篡改关键点：验证过程只需要颁发者的公钥，不需要其私钥。这使得任何人都可以验证证书的真实性。2. 证书验证流程graph TD A[开始验证证书] --> B[检查证书有效期] B -->|证书已过期| C[验证失败] B -->|证书有效| D[查找颁发者证书] D -->|找不到颁发者| E[验证失败] D -->|找到颁发者| F[使用颁发者公钥验证签名] F -->|签名无效| G[验证失败] F -->|签名有效| H[是否为根证书] H -->|是根证书| I[检查是否为受信任根CA] I -->|不受信任| J[验证失败] I -->|受信任| K[验证成功] H -->|非根证书| L[递归验证颁发者证书]A. 验证代码示例以下是一个简化的证书验证伪代码：def validate(cert): now = datetime.now() # 检查证书有效期 if now < cert.not_before or now > cert.not_after: return False, "证书已过期" # 查找颁发者证…

Let's Encrypt 交叉签名：免费兼容老系统的策略分析
type: item
date: 2026-02-04T21:22:10+00:00
description: Let's Encrypt 交叉签名：免费兼容老系统的策略分析一、概述1. 背景Let's Encrypt 作为互联网上最大的免费证书颁发机构，其成功不仅体现在免费提供 SSL/TLS 证书，更体现在通过创新的交叉签名策略，解决了新 CA 面临的信任分发难题，实现了零成本兼容老系统。2. 核心问题新成立的证书颁发机构面临的核心挑战是：其根证书尚未被操作系统和浏览器广泛信任。若无法解决此问题，即使用户获得了 Let's Encrypt 颁发的证书，老设备仍会显示证书错误。3. 解决方案概述Let's Encrypt 与 IdenTrust 合作，通过交叉签名技术，使自己的中间证书同时被 Let's Encrypt 自有的 ISRG Root X1 和 IdenTrust 广受信任的 DST Root CA X3 签名，从而实现双路径信任验证。二、交叉签名技术原理1. 基本概念交叉签名是一种证书信任机制，允许一个证书被多个根证书签名。这意味着客户端可以通过任何一条有效路径验证证书链，从而扩大兼容性范围。2. Let's Encrypt 的实现架构graph TD A[用户网站证书] -->|被签发| B[R3 中间证书] B -->|路径1| C[ISRG Root X1 Let's Encrypt 自有根 有效期至 2035] B -->|路径2| D[DST Root CA X3 IdenTrust 根 已过期] style D fill:#f9f,stroke:#333,stroke-width:2px style C fill:#bbf,stroke:#333,stroke-width:1px架构说明：R3 中间证书同时拥有两个签名路径 1：通向 Let's Encrypt 的自有根证书 ISRG Root X1路径 2：通向 IdenTrust 的 DST Root CA X3（已于 2021 年 9 月 30 日过期）3. 验证流程sequenceDiagram participant C as 客户端浏览器 participant S as HTTPS 服务器 participant I as 中间证书 R3 C->>S: 发起 HTTPS 连接 S-->>C: 返回证书链 C->>I: 验证证书链 alt 老设备（2016年前） I->>I: 使用 DST Root CA X3 路径验证 I-->>C: 验证成功（2021年前） else 现代设备 I->>I: 使用 ISRG Root X1 路径验证 I-->>C: 验证成功 end三、经济效益分析1. 传统 CA 成本结构传统证书颁发机构建立信任需要：向现有根 CA 购买交叉签名：数十万至数百万美元申请加入各大操作系统和浏览器的信任根程序：耗时数年维护根证书基础设施：高昂的运营成本2. Let's Encrypt 的零成本策略Let's Encrypt 通过以下方式实现零成本交叉签名：策略说明效果公益合作与 IdenTrust 达成公益性质的合作协议无需支付授权费用非排他性交叉签名不限制 Let's Encrypt 发展自有根保持独立性期限约定约定特定的交叉签名有效期明确过渡期3. 商业模式创新Let's Encrypt 的交叉签名策略证明了免费 CA 的可持续性：降低行业准入门槛推动 HTTPS 全网普及建立公益化的互联网基础设施四、时间线与演进1. 发展历程timeline title Let's Encrypt 交叉签名策略时间线 2015 : Let's Encrypt 成立 获得 ISRG Root X1 2015 : 与 IdenTrust 达成 交叉签名协议 2016-2020 : DST Root CA X3 交叉签名 保障老设备兼容 2021-09 : DST Root CA X3 过期 交叉签名失效 2024-06 : 停止提供任何交叉签名链 全面转向 ISRG Root X12. 关键节点2015 年：Let's Encrypt 与 IdenTrust 签署交叉签名协议2016 年：开始大规模颁发证书，交叉签名发挥作用2021 年 9 月 30 日：DST Root CA X3 根证书过期2024 年 6 月：Let's Encrypt 完全停止交叉签名服务五、兼容性影响1. 受影响的系统DST Root CA X3 交叉签名过期后，以下设备受到影响：设备类型受影响版本原因Android7.1.1 及更早版本未包含 ISRG Root X1Windows XP所有版本证书存储已过时macOS10.12.1 及更早版本未信任 ISRG Root X1iOS10 及更早版本根证书存储未更新Ubuntu14.04 及更早版本系统证书库过时2. …

httpscheck SSL/TLS 证书检查工具设计
type: item
date: 2026-02-01T22:15:09+00:00
description: httpscheck SSL/TLS 证书检查工具设计一、背景与目标1. 项目背景A. 业务场景SSL/TLS 证书是现代互联网安全的基石。证书管理不善会导致服务中断、安全漏洞等问题。系统管理员和开发人员需要一个可靠的工具来检查 HTTPS 证书的有效性、信任链状态和系统配置。B. 痛点分析OpenSSL 命令复杂，输出难以解析缺少中文友好的检查工具需要验证证书在系统中的实际信任状态跨平台检查工具匮乏2. 设计目标A. 功能目标完整的证书链验证证书有效期检查（过期、即将过期、有效）系统 CA 证书路径测试彩色终端输出B. 非功能目标跨平台支持（Linux、macOS、Windows）纯 Go 实现，无外部 OpenSSL 依赖静态编译，单文件部署高性能，支持超时控制二、总体设计1. 设计原则单一职责：每个包职责明确依赖倒置：通过共享类型打破循环依赖接口隔离：CLI 层与业务逻辑分离开闭原则：易于扩展新的检查功能2. 系统架构graph TB User[用户] --> CLI[CLI 层 cmd/] CLI --> Root[root.go 根命令] Root --> Chains[chains.go 证书链检查] Root --> CACert[cacert.go CA 路径测试] Root --> Output[output.go 简单输出] Chains --> Checker[pkg/checker/] CACert --> Checker Output --> Checker Checker --> CertUtil[pkg/certutil/] Checker --> Types[pkg/types/] CertUtil --> Types Checker --> Logger[pkg/logger/] Logger --> Stdout[(标准输出)]3. 模块说明模块文件职责CLI 层cmd/*.go命令行解析、参数处理、用户交互检查器pkg/checker/chains.go证书链获取、验证、系统信任检查证书工具pkg/certutil/*.go证书解析、格式化、系统 CA 路径类型定义pkg/types/types.go共享数据结构、枚举常量日志系统pkg/logger/logger.go彩色输出、日志级别控制4. 数据流sequenceDiagram participant U as 用户 participant C as CLI 层 participant K as Checker participant P as CertUtil participant L as Logger U->>C: 执行命令 C->>K: CheckChain() K->>K: retrieveCertificates() Note over K: 建立 TLS 连接 获取证书链 K->>P: ParseCertificate() Note over P: 解析证书信息 计算指纹 判断状态 P-->>K: CertificateInfo K->>K: verifyChain() Note over K: 验证证书链 检查系统信任 K-->>C: ChainCheckResult C->>P: FormatTable() P-->>C: 格式化字符串 C->>L: 输出 L-->>U: 彩色结果三、核心模块设计1. 类型系统A. 证书类型判断type CertType string const ( CertTypeServer CertType = "服务器证书" CertTypeIntermediate CertType = "中间证书" CertTypeRoot CertType = "根证书" )判断逻辑：服务器证书：链中的第一个证书根证书：链中最后一个且自签名中间证书：介于两者之间B. 证书状态判断type CertStatus string const ( CertStatusValid CertStatus = "有效" CertStatusExpired CertStatus = "已过期" CertStatusExpiring CertStatus = "即将过期" // < 30天 )阈值设定：30 天作为即将过期的警告阈值C. 核心数据结构type CertificateInfo struct { Index int Type CertType Subject pkix.Name SubjectStr string Issuer pkix.Name IssuerStr string NotBefore time.Time NotAfter time.Time DaysRemaining int SerialN…

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. 证书管…

Certificate Inspector：基于 Playwright 的全链路 SSL 证书检测工具
type: item
date: 2026-01-22T21:49:37+00:00
description: Certificate Inspector：基于 Playwright 的全链路 SSL 证书检测工具一、新闻概述1. 标题Certificate Inspector：使用 Playwright 捕获网页完整网络足迹的 SSL 证书检测工具2. 发布时间2025 年 1 月（GitHub 开源项目）3. 来源GitHub 开源仓库：shanselman/cert-inspector二、核心内容1. 事件摘要A. 主要内容Certificate Inspector 是一款基于 Node.js 和 Playwright 的 Web 工具，能够检测网页加载过程中所有域名的 SSL 证书和 DNS 记录。其核心创新在于使用无头浏览器捕获完整请求树，包括 JavaScript 动态加载的资源、广告、追踪器和 API 调用。B. 核心亮点完整请求树捕获：通过 Playwright 无头 Chromium 拦截所有网络请求多维度证书检测：SSL 详情、证书链、TLS 版本、HSTS 状态健康度仪表板：颜色编码状态、进度条可视化、按紧急程度排序多视图展示：详细表格、摘要卡片、时间线三种视图多种部署方式：独立可执行文件、Docker、Codespaces、本地开发2. 关键信息A. 技术栈后端：Node.js + Express浏览器自动化：Playwright（无头 Chromium）证书解析：Node.js 原生 tls 模块B. 开源协议MIT LicenseC. 部署选项Windows/macOS/Linux 可执行文件Docker 容器GitHub Codespaces（云端运行）本地开发环境3. 背景介绍A. 痛点分析传统 SSL 检测工具存在以下局限：仅检测主域名，无法发现第三方资源无法捕获 JavaScript 动态加载的连接无法识别隐藏的追踪器和 API 调用缺乏可视化的健康度评估B. 解决方案通过 Playwright 模拟真实用户访问，拦截所有网络请求，实现对网页完整网络足迹的全面检测。三、详细报道1. 主要功能A. 深度检测完整请求树捕获：使用无头 Chromium 加载页面并捕获所有网络请求DNS 查询：每个域名的 IPv4/IPv6 地址和 CNAME 记录SSL 证书详情：主题、颁发者、有效期、序列号、指纹证书链：查看完整的信任链TLS 版本：检测域名是否使用 TLS 1.2 或 1.3HSTS 状态：检查是否启用 Strict-Transport-Security响应时间：测量到每个域名的连接延迟B. 健康度仪表板颜色编码状态：绿色（健康）、黄色（即将过期，小于等于 30 天）、红色（已过期/无效）、灰色（无 HTTPS）进度条：证书健康状况的可视化分解按紧急程度排序：问题优先显示剩余天数：大号可扫描的数字显示C. 多视图展示详细视图：完整表格，可展开证书详情摘要视图：紧凑卡片网格，快速扫描时间线视图：证书过期的可视化时间线D. 工具与过滤器搜索：按域名过滤状态过滤：按健康状态显示/隐藏颁发者过滤：按证书颁发机构分组（Let's Encrypt、DigiCert 等）深色模式：护眼模式点击复制：域名、指纹、序列号导出：下载 JSON 或 CSV 格式结果2. 技术架构A. 系统组成graph TB User[用户浏览器] -->|访问| WebUI[Web 界面] WebUI -->|提交 URL| API[Express API 服务器] API -->|创建页面| Playwright[Playwright 无头浏览器] Playwright -->|加载页面| Target[目标网页] Playwright -->|拦截请求| Network[网络请求拦截器] Network -->|提取域名| DNS[DNS 解析器] Network -->|提取证书| TLS[TLS 证书解析器] DNS -->|返回结果| API TLS -->|返回结果| API API -->|返回数据| WebUIB. 核心工作流程sequenceDiagram participant U as 用户 participant W as Web 界面 participant P as Playwright participant T as 目标网页 participant D as DNS 解析 participant C as 证书检查 U->>W: 输入 URL W->>P: 创建浏览器上下文 P->>T: 加载目标页面 P->>P: 拦截所有网络请求 loop 每个请求 P->>D: 解析 DNS 记录 P->>C: 检查 SSL 证书 D-->>P: IP 地址、CNAME C-->>P: 证书详情、链、TLS 版本 e…

LiteSSL ACME DNS-01 鉴权漏洞技术分析
type: item
date: 2026-01-22T06:58:15+00:00
description: 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…

TLS Shunt TLS流量分流器技术分析
type: item
date: 2026-01-17T22:45:50+00:00
description: TLS Shunt TLS流量分流器技术分析一、概述1. 项目背景TLS Shunt Proxy 是一个专门用于分流 TLS 流量的工具，由 liberal-boy 开发并开源。该项目主要解决在同一端口上处理多种协议流量的需求，特别适用于 vmess + TLS + Web 方案实现，同时支持与 Trojan 共享端口。2. 核心功能A. SNI 分流根据 TLS Server Name Indication 扩展将流量分发到不同的虚拟主机B. HTTP 和无特征流量分流识别并分流 HTTP 流量和无特征的加密流量C. 静态网站服务内置静态网站服务器功能D. 自动证书管理支持从 LetsEncrypt 自动获取证书二、技术架构1. 工作原理graph LR A[客户端] -->|TLS 握手| B[TLS Shunt Proxy] B -->|SNI: vmess.example.com| C[VMess 后端] B -->|SNI: trojan.example.com| D[Trojan 后端] B -->|HTTP 流量| E[静态网站/代理] B -->|无特征流量| F[默认后端]2. 核心组件A. 监听模块支持 443 端口监听（HTTPS）支持 80 端口监听并重定向到 HTTPS可配置入站和出站缓冲区大小B. TLS 处理模块TLS 卸载：可选择是否解密 TLS 流量支持多种 TLS 协议版本（TLS 1.2、TLS 1.3）支持多种密钥类型（ed25519、p256、p384、rsa2048、rsa4096、rsa8192）C. 路由模块按 SNI 分流按 HTTP Path 分流按 ALPN 协议分流（HTTP/1.1、HTTP/2、h2c）D. 处理器模块proxyPass：流量转发fileServer：静态文件服务3. 流量识别流程sequenceDiagram participant C as 客户端 participant T as TLS Shunt participant V as VMess participant H as HTTP处理 participant S as 静态文件 C->>T: TLS 握手（携带 SNI） T->>T: 解析 SNI alt SNI = vmess.example.com T->>T: TLS 卸载 alt 流量是 HTTP T->>H: Path 匹配 H->>V: 转发到后端 H->>S: 静态文件服务 else 流量是 VMess T->>V: 直接转发 end else SNI = trojan.example.com T->>V: 不卸载 TLS，直接转发 end三、配置详解1. 基础配置# 监听地址 listen: 0.0.0.0:443 # HTTP 到 HTTPS 重定向 redirecthttps: 0.0.0.0:80 # 入站缓冲区大小（KB） inboundbuffersize: 4 # 出站缓冲区大小（KB） outboundbuffersize: 322. 虚拟主机配置每个虚拟主机对应一个 SNI，包含以下配置：A. TLS 卸载设置tlsoffloading: true # 是否解密 TLSB. 证书配置managedcert: false # 是否自动管理证书 keytype: p256 # 密钥类型 cert: /path/to/cert # 证书路径 key: /path/to/key # 私钥路径C. 协议配置alpn: h2,http/1.1 # ALPN 协议 protocols: tls12,tls13 # TLS 版本范围3. HTTP 流量处理http: paths: - path: /vmess/ws/ handler: proxyPass args: 127.0.0.1:40000 - path: /static/ trimprefix: /static handler: fileServer args: /var/www/static handler: fileServer args: /var/www/html4. HTTP/2 流量处理http2: - path: / handler: fileServer args: /var/www/rayfantasy - path: /vmess handler: proxyPass args: h2c://localhost:400025. 其他流量处理default: handler: proxyPass args: 127.0.0.1:40001四、部署方案1. 安装方法A. Linux AMD64 自动安装bash <(curl -L -s https…

自建CA 手动生成rsa1024的证书并配置nginx实现嵌入式设备ssl加密
type: item
date: 2024-05-09T02:43:00+00:00
description: 一、自建证书+nginx ssl配置使用openssl创建rsa1024根证书，并签发*.example.cn 30年有效期证书要使用 OpenSSL 创建一个 RSA 1024 位的根证书，并签发一个包含通配符的域名证书，可以按照以下步骤进行：（1）创建 RSA 1024 位的根证书（Root CA）：生成根密钥（私钥）：openssl genrsa -out root.key 1024生成自签名的根证书（公钥）：openssl req -x509 -new -nodes -key root.key -days 10950 -out root.crt在证书请求期间，填写相关证书信息。10950 天是根证书的有效期，约合30年。（2）创建通配符域名证书（Wildcard Certificate）：生成域名私钥：openssl genrsa -out domain.key 1024生成域名证书签名请求（CSR）：openssl req -new -key domain.key -out domain.csr在证书请求期间，填写通配符域名 *.example.cn 作为 Common Name (CN)。使用根证书签署域名证书：openssl x509 -req -in domain.csr -CA root.crt -CAkey root.key -CAcreateserial -out domain.crt -days 10950现在，您已经创建了包含通配符域名的证书 domain.crt，其有效期为30年，同时也拥有一个根证书 root.crt 用于签署该域名证书。确保在真实环境中使用更强大的密钥长度和更合适的证书有效期。此外，在生产环境中建议谨慎保管您的私钥和根证书，以防止密钥泄露或篡改。（3）如何调整nginx以允许rsa 1024的证书server { listen 192.168.23.225:3001 ssl; server_name example.cn; access_log /var/log/nginx/example.cn.a.log main; error_log /var/log/nginx/example.e.log; ssl_certificate /etc/nginx/cert.d/test/example.cn.crt; ssl_certificate_key /etc/nginx/cert.d/test/example.cn.key; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:AES128-SHA:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE; ssl_prefer_server_ciphers on; location / { proxy_pass http://example; proxy_set_header Host $host; proxy_http_version 1.1; proxy_read_timeout 120s; proxy_set_header X-real-ip $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } 二、TCP后端+Nginx Stream做完上面的配置后，后端是不通的，询问同事后端跑的啥业务，测试不通过，心底没底。后来得知，后端直接是TCP协议，用于接收物联网设备的数据。具体说，这个TCP已经实现了端到端AES对称加密，但是用户还想用SSL来一层非对称加密。而且指明了使用RSA 1024。然后，同事还给了一个方案，通过使用Nginx的Stream模块，加上SSL证书实现安全通信。这个吗，听说过stream作为TCP负载均衡，还真没听说过这个里面还有SSL。不过，经过搜索，还真有，而且在官网也看到了相关资料。走运的是，本来以为还得下载编译nginx模块，没想到直接带了。nginx version: nginx/1.22.0 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/…