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, "证书已过期" # 查找颁发者证书 for issuer_cert in lookup_cert_by_name(cert.issuer): # 检查颁发者证书有效期 if now < issuer_cert.not_before or now > issuer_cert.not_after: continue # 验证签名 if validate_signature(cert.data, cert.signature, issuer_cert.public_key): # 检查是否为根证书 if cert.issuer is None: if is_trusted_root_ca(cert): return True, "证书有效" else: return False, "未知的根CA" # 递归验证颁发者证书 return validate(issuer_cert) return False, "找不到父证书"3. 验证关键点通过颁发者名称查找颁发者证书使用颁发者的公钥验证数字签名递归向上验证，直到找到受信任的根证书四、交叉签名原理1. 核心概念交叉签名的核心思想是：同一个证书（具有相同的主体名称和公钥）可以被多个不同的颁发者签名，从而建立多条独立的信任链。A. 关键发现证书验证过程中，只有两个字段是必需的：颁发者名称（用于查找颁发者证书）公钥（用于验证数字签名）证书的其他元数据（如有效期、序列号、指纹等）在验证过程中不会被使用。2. 交叉签名示例A. 标准证书链graph LR A[www.example.com] -->|由Z1签发| B[My Encrypt Authority Z1] B -->|由Root Sep21签发| C[My Encrypt Root Sep21] C -->|自签名| CB. 添加交叉签名后的证书链graph TB subgraph 原有信任链 A1[www.example.com] -->|由Z1签发| B1[My Encrypt Authority Z1] B1 -->|由Root Sep21签发| C1[My Encrypt Root Sep21] C1 -->|自签名| C1 end subgraph 新增信任链 A2[www.example.com] -->|由Z1签发| B2[My Encrypt Authority Z1] B2 -->|由Y4签发| C2[Their Encrypt Y4] C2 -->|自签名| C2 end B1 -.相同名称和公钥.- B2C. 证书数据示例原有中间证书：{ "name": "My Encrypt Authority Z1", "issuer": ["My Encrypt Root Sep21"], "sig": "DEFG", "public_key": 3456 }交叉签名中间证书：{ "name": "My Encrypt Authority Z1", "issuer": ["Their Encrypt Y4"], "sig": "HGYE", "public_key": 3456 }注意两个证书具有相同的名称和公钥，但颁发者不同，因此数字签名也不同。3. 为什么交叉签名有效验证代码只关心：能否通过名称找到颁发者证书颁发者证书的公钥能否验证数字签名因此，即使创建一个具有相同名称和公钥的新证书（由不同颁发者签发），也能建立一条完全有效的信任链。4. 实际应用案例：Let's EncryptLet's Encrypt 的 R3 中间证书就是一个典型的交叉签名案例：graph TB R3[R3 中间证书] -->|由DST Root CA X3签发| DST[DST Root CA X3] R3 -->|由ISRG Root X1签发| ISRG[ISRG Root X1] DST -->|自签名| DST ISRG -->|自签名| ISRGR3 证书实际上只携带一个数字签名，但可以追溯到两个不同的根证书。这是因为存在两个 R3 证书实例：一个由 DST Root CA X3 签发一个由 ISRG Root X1 签发两个实例具有相同的名称和公钥，但由不同的根 CA 签发。五、TLS 握手中的证书验证1. 证书传递过程在 TLS 握手过程中，服务器不仅发送自己的证书，还会发送中间证书链。sequenceDiagram participant C as 客户端 participant S as 服务器 S->>C: 发送服务器证书 S->>C: 发送中间证书 C->>C: 使用中间证书验证服务器证书 C->>C: 查找本地受信任根证书 C->>C: 使用根证书验证中间证书 alt 验证成功 C->>S: 继续TLS握手 else 验证失败 C->>S: 终止连接 end2. 证书链选择策略客户端通常按照以下策略选择验证路径：优先使用服务器提供的中间证书在本地证书存储中查找匹配的根证书使用找到的根证书完成验证通过发送中间证书，服务器可以引导客户端使用特定的验证路径，无需客户端进行额外的网络请求。3. 路径长度约束某些中间证书设置了路径长度约束（Path Length Constraint），限制其可以签发的子证书层级。例如，R3 证书的路径长度约束为 0，意味着它不能签发有效的子证书。六、交叉签名的实际意义1. 用途场景A. 根证书过渡当旧的根证书即将过期时，可以通过交叉签名将信任迁移到新的根证书，无需重新颁发所有终端证书。B. 扩大兼容性使证书能被更多平台和设备信任，特别是那些只信任特定根 CA 的老系统。C. 容灾备份提供多条信任路径，提高证书验证的可靠性。2. 安全考虑A. 任何人都可以添加父证书由于证书的公钥和名称是公开的，理论上任何人都可以创建一个具有相同名称和公钥的证书，并由自己的 CA 签发。但只要用户的系统不信任这个新 CA，这条链就不会被接受。B. 信任的根基整个系统的安全性最终依赖于用户系统中受信任根证书的管理。3. 交叉签名术语的误导性"交叉签名"这个术语可能会让人误解为一个证书上有多个签名。实际上：一个证书只能携带一个数字签名交叉签名通过创建多个具有相同名称和公钥但由不同颁发者签发的证书实例来实现七、常见问题解答1. 什么是交叉签名证书交叉签名证书是指由多个证书颁发机构签发的、具有相同主体名称和公钥的证书集合。这使得同一个证书可以通过多条信任路径进行验证。2. 什么是 OCSP 签名证书OCSP（Online Certificate Status Protocol）签名证书是一种特殊证书，由受信任的 CA 颁发，用于 OCSP 响应器对证书状态查询进行数字签名。3. TLS 证书和签名证书的区别TLS 证书：用于建立加密通信通道，确保服务器身份和数据传输安全签名证书：用于对数字内容（如代码、文档、其他证书）进行签名，验证内容的完整性和真实性4. OCSP 的风险隐私风险：客户端需要向第三方服务器查询证书状态，可能暴露用户行为可用性风险：如果 OCSP 服务器宕机，可能导致证书验证失败性能影响：需要额外的网络请求，可能延长连接建立时间5. OCSP 的优势实时性：提供近实时的证书撤销状态查询高效性：相比下载完整的 CRL（证书撤销列表），带宽占用更小精确性：可以精确查询单个证书的状态6. 如何验证 OCSP客户端从证书的 AIA（Authority Information Access）字段提取 OCSP URL，向 OCSP 响应器发送签名请求，响应器返回"良好"、"已撤销"或"未知"状态。可以使用 openssl ocsp 等工具进行手动检查。参考资料How cross signing works with X509 certificates
Let's Encrypt 交叉签名：免费兼容老系统的策略分析
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. 影响范围评估2021 年前：交叉签名让全球数百万老设备能够访问使用 Let's Encrypt 证书的网站2021 年后：随着设备自然淘汰，影响逐渐减少2024 年后：绝大多数用户已使用现代设备，不再依赖交叉签名3. 解决方案对于仍受影响的系统：系统更新：升级操作系统以获取 ISRG Root X1手动导入：手动安装 ISRG Root X1 证书替代方案：使用其他仍提供交叉签名的 CA六、策略的成效与局限1. 成效分析A. 技术成效实现了新 CA 的快速冷启动保障了数年间的老设备兼容性平滑过渡到自有根证书B. 社会成效推动 HTTPS 从奢侈品变为标配降低了网站安全化的经济门槛促进了互联网加密基础设施的民主化C. 数据指标颁发证书数量：超过 30 亿张活跃证书覆盖网站数量：全球超过 3 亿个网站HTTPS 普及率：从 2015 年的约 40% 提升至 2024 年的超过 90%2. 局限性A. 临时性交叉签名本质上是一种过渡方案依赖第三方 CA 的商业决策存在明确的有效期限制B. 最终终止2024 年 6 月，Let's Encrypt 完全停止交叉签名老设备最终仍需升级或替换不再提供新的兼容性解决方案七、技术细节1. 证书链结构传统链（2021年前）网站证书 ↓ (由 R3 签发) R3 中间证书 ↓ (由 DST Root CA X3 交叉签名) DST Root CA X3 (IdenTrust)现代链（2021年后）网站证书 ↓ (由 R3 签发) R3 中间证书 ↓ (由 ISRG Root X1 签名) ISRG Root X1 (Let's Encrypt)2. 客户端验证逻辑现代浏览器和操作系统的证书验证逻辑：优先选择最短的有效证书链检查根证书是否在本地信任存储中验证每个证书的签名和有效期八、行业影响与启示1. 对 CA 行业的影响打破了传统 CA 的高价垄断证明了免费 CA 的商业可行性推动了证书颁发模式的创新2. 对互联网安全的启示基础安全设施可以公益化运营技术创新可以大幅降低安全成本行业协作可以加速安全普及3. 未来展望随着交叉签名的终止，Let's Encrypt 已完成其历史使命：ISRG Root X1 已被所有主流系统信任老设备自然淘汰，兼容性问题逐渐消失免费证书成为互联网基础设施的一部分九、总结Let's Encrypt 的交叉签名策略是一次成功的行业创新，通过零成本获取第三方根证书的信任支持，实现了免费 CA 的快速普及。这一策略不仅解决了技术难题，更重要的是证明了公益化安全基础设施的可行性，为互联网安全带来了深远影响。随着 2024 年交叉签名服务的完全终止，Let's Encrypt 已从依赖第三方信任的新兴 CA，成长为拥有独立信任基础、服务全球数亿网站的互联网基础设施提供者。这一转变，标志着免费 SSL/TLS 证书时代的真正成熟。参考资料Let's Encrypt 证书兼容性文档DST Root CA X3 过期说明（中文）Let's Encrypt 证书链（官方）缩短 Let's Encrypt 信任链交叉签名技术原理解析Let's Encrypt 社区：交叉签名终止讨论2024 年 Let's Encrypt 证书链变更影响Let's Encrypt 与 IdenTrust 延长交叉签名的分析X2-by-X1 交叉签名根证书讨论2021 年部分旧 Android 设备不再支持 Let's Encrypt 证书
网站证书从担心到不担心：证书链信任机制深度解析
网站证书从担心到不担心：证书链信任机制深度解析一、背景：为什么会担心证书到期？假设一个网站域名是 www.baidu.com，由第三方客户通过 curl 进行调用。通过 sitecertcheck 工具检查发现，该网站的证书链中的中间证书有效期到 2028 年。问题来了：到了 2028 年，用户的 curl 调用是否依然有效呢？证书过期后会不会导致 HTTPS 连接失败？这是一个常见的担心，尤其是对于需要长期稳定运行的系统集成场景。二、证书链结构分析2.1 www.baidu.com 的证书链使用 sitecertcheck 工具检查 www.baidu.com 的证书链，发现其证书链包含 3 级证书：graph TB subgraph "客户端信任库" Root[根证书 GlobalSign Root CA 系统预置信任] end subgraph "服务器返回的证书链" Server[#1 服务器证书 CN=baidu.com 📅 2026-08-10到期 188天] Inter1[#2 中间证书 GlobalSign RSA OV SSL CA 2018 📅 2028-11-21到期 1021天] Inter2[#3 中间证书 GlobalSign Root CA - R3 📅 2028-01-28到期 724天] end Server -->|签发| Inter1 Inter1 -->|签发| Inter2 Inter2 -->|签发| Root style Server fill:#e3f2fd style Inter1 fill:#fff3e0 style Inter2 fill:#fff3e0 style Root fill:#e8f5e92.2 证书链关键信息摘要级别证书类型主题有效期截止剩余天数#1服务器证书CN=baidu.com2026-08-10188天#2中间证书GlobalSign RSA OV SSL CA 20182028-11-211021天#3中间证书GlobalSign Root CA - R32028-01-28724天可以看到，证书链中的 中间证书 最晚将在 2028 年到期。这正是我们担心的焦点。三、证书验证流程当客户端（如 curl）访问 www.baidu.com 时，SSL/TLS 握手和证书验证的完整流程如下：sequenceDiagram participant C as 客户端 (curl) participant S as 服务器 (www.baidu.com) participant T as 系统信任库 (/etc/ssl/cert.pem) Note over C,S: TLS握手开始 C->>S: 1. ClientHello（支持的加密套件） S->>C: 2. ServerHello + 证书链 （3个证书：服务器+2个中间证书） Note over C: 证书链验证开始 C->>C: 3. 验证证书#1签名 （使用证书#2的公钥） C->>C: 4. 验证证书#2签名 （使用证书#3的公钥） C->>T: 5. 查找根证书 （查询：GlobalSign Root CA - R3） T-->>C: 6. 返回匹配的根证书 （有效期至2029-03-18） C->>C: 7. 验证证书#3签名 （使用根证书公钥） Note over C: ✅ 信任链验证通过 C->>S: 8. 建立加密连接核心验证步骤证书链完整性验证：逐级验证每个证书的数字签名，确保证书由上级 CA 合法签发信任锚点查找：在系统信任库（如 /etc/ssl/cert.pem）中查找根证书有效期检查：确认当前时间在所有证书的有效期内验证结果通过 sitecertcheck 检查，当前验证结果为：✅ 证书链验证：通过✅ 系统信任：匹配根证书 #97（GlobalSign Root CA - R3）✅ 根证书有效期：2029-03-18（剩余 1139 天）四、为什么不用担心 2028 年到期？4.1 系统信任库中的 GlobalSign 根证书通过 sitecertcheck listca 命令查看系统信任库，发现系统中预置了 多个 GlobalSign 根证书，有效期各不相同：序号根证书有效期截止剩余天数#34/#35GlobalSign2038-01-194367天#64GlobalSign2034-12-103231天#97GlobalSign Root CA - R32029-03-181139天#101GlobalSign Root CA2028-01-28724天关键发现：系统中有 GlobalSign 根证书的有效期可达 2038 年，远远超过当前中间证书的到期时间。4.2 证书续签机制当中间证书在 2028 年到期时，会发生什么？graph LR subgraph "2026年 当前状态" A[baidu.com服务器证书 有效期至2026-08] end subgraph "2028年 证书续签" B[中间证书即将到期 2028-01 & 2028-11] C[续签新证书] end subgraph "系统信任库（持续更新）" D1[GlobalSign Root CA - R3 有效期至2029年] D2[GlobalSign Root CA 有效期至2038年] D3[其他GlobalSign根证书 有效期至2038年] end A -->|2026年前续签| C C -->|可选择签发| D1 C -->|可选择签发| D2 C -->|可选择签发| D3 style A fill:#ffebee style B fill:#fff9c4 style C fill:#e1f5fe style D1 fill:#e8f5e9 style D2 fill:#e8f5e9 style D3 fill:#e8f5e9 Note1[💡 关键点： 系统信任库中有多个 GlobalSign根证书可用] style Note1 fill:#f3e5f5证书续签的完整流程提前续签：网站运营者会在证书到期前（通常提前几个月）向 CA（GlobalSign）申请续签新证书更换信任链：新签发的证书可以选择指向有效期更长的根证书（如有效期至 2038 年的 GlobalSign 根证书）无缝切换：客户端系统中已经预置了有效期至 2038 年的 GlobalSign 根证书，新证书链会自动被系统信任向下兼容：curl 等客户端工具会自动使用新的证书链进行验证，无需任何配置更改4.3 为什么客户端不受影响？关键在于：根证书预置：操作系统和浏览器在出厂时就预置了主流 CA 的根证书根证书长期有效：根证书的有效期通常为 20-30 年，远超中间证书和服务器证书透明更新：当服务器更新证书时，客户端自动使用新的证书链，整个过程对用户透明多根证书冗余：同一个 CA（如 GlobalSign）会维护多个根证书，确保平滑过渡五、结论✅ 无须担心：证书到期问题可以通过续签机制妥善解决核心要点证书链是分层的：服务器证书 → 中间证书 → 根证书根证书预置在系统中：客户端系统信任库中预置了多个有效期长的根证书证书到期前可续签：网站运营者会在证书到期前续签，并可选择指向有效期更长的根证书客户端自动适配：只要系统信任库保持更新，证书验证就能持续有效，无需用户干预最终答案到了 2028 年，curl 调用是否依然有效？是的，依然有效。因为：网站会在 2028 年前续签新证书新证书会指向有效期至 2038 年的根证书客户端系统中已经有该根证书，自动信任新证书链整个过程对 curl 等客户端完全透明附录附录 A：sitecertcheck 完整输出（证书链检查）以下是使用 sitecertcheck www.baidu.com 命令的完整输出：(base) jacky@JackydeMac-Pro:/tmp$ sitecertcheck www.baidu.com [INFO] 正在测试 2 个系统CA证书路径... [INFO] 测试路径: /etc/ssl/cert.pem [SUCCESS] ✓ 找到可用的CA证书文件: /etc/ssl/cert.pem 正在测试系统 CA 证书路径... 测试了 1 个路径，找到 1 个可用 ✓ /etc/ssl/cert.pem [SUCCESS] 测试完成 [INFO] 正在检查 www.baidu.com:443 的SSL证书... 正在检查 www.baidu.com:443 的SSL证书... 证书链中共有 3 个证书 序号 类型 起始时间 结束时间 剩余天数 状态 ------------------------------------------------------------------------------------------------------ 1 服务器证书 2025-07-09 07:01:02 2026-08-10 07:01:01 188 有效 ====================================================================================================== 主题: CN=baidu.com O=Beijing Baidu Netcom Science Technology Co., Ltd L=beijing ST=beijing C=CN 颁发者: CN=GlobalSign RSA OV SSL CA 2018 O=GlobalSign nv-sa C=BE 序列号: 27025959261604984493724308777 签名算法: SHA256-RSA 公钥: RSA 2048 位 ====================================================================================================== 2 中间证书 2018-11-21 00:00:00 2028-11-21 00:00:00 1021 有效 ====================================================================================================== 主题: CN=GlobalSign RSA OV SSL CA 2018 O=GlobalSign nv-sa C=BE 颁发者: CN=GlobalSign OU=GlobalSign Root CA - R3 O=GlobalSign 序列号: 153000603918210013455007253847 签名算法: SHA256-RSA 公钥: RSA 2048 位 ====================================================================================================== 3 中间证书 2018-09-19 00:00:00 2028-01-28 12:00:00 724 有效 ====================================================================================================== 主题: CN=GlobalSign OU=GlobalSign Root CA - R3 O=GlobalSign 颁发者: CN=GlobalSign Root CA OU=Root CA O=GlobalSign nv-sa C=BE 序列号: 153000549611226544087872427626 签名算法: SHA256-RSA 公钥: RSA 2048 位 ====================================================================================================== 验证摘要: -------------------------------------------------- 证书链验证: ✓ 通过 系统信任: ✓ 受信任 匹配的系统根证书: #[97] (listca) 主题: CN=GlobalSign, OU=GlobalSign Root CA - R3, O=GlobalSign 颁发者: CN=GlobalSign, OU=GlobalSign Root CA - R3, O=GlobalSign 过期时间: 2029-03-18 10:00:00 剩余天数: 1139 位置: /etc/ssl/cert.pem -------------------------------------------------- [SUCCESS] 检查完成 证书 #1: 主题: CN=baidu.com, O=Beijing Baidu Netcom Science Technology Co., Ltd, L=beijing, ST=beijing, C=CN 颁发者: CN=GlobalSign RSA OV SSL CA 2018, O=GlobalSign nv-sa, C=BE 有效期: 起始时间: 2025-07-09 07:01:02 结束时间: 2026-08-10 07:01:01 证书 #2: 主题: CN=GlobalSign RSA OV SSL CA 2018, O=GlobalSign nv-sa, C=BE 颁发者: CN=GlobalSign, OU=GlobalSign Root CA - R3, O=GlobalSign 有效期: 起始时间: 2018-11-21 00:00:00 结束时间: 2028-11-21 00:00:00 证书 #3: 主题: CN=GlobalSign, OU=GlobalSign Root CA - R3, O=GlobalSign 颁发者: CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE 有效期: 起始时间: 2018-09-19 00:00:00 结束时间: 2028-01-28 12:00:00 [SUCCESS] 共输出 3 个证书附录 B：系统根证书列表（GlobalSign 相关）以下是使用 sitecertcheck listca | grep GlobalSign 命令查看系统中 GlobalSign 相关根证书的输出：(base) jacky@JackydeMac-Pro:/tmp$ sitecertcheck listca | grep GlobalSign [INFO] 正在获取系统CA根证书... [INFO] 共找到 113 个系统CA证书 [SUCCESS] 共显示 103 个证书 34 GlobalSign GlobalSign 2012-11-13 00:00:00 2038-01-19 03:14:07 9198 4367 35 GlobalSign GlobalSign 2012-11-13 00:00:00 2038-01-19 03:14:07 9198 4367 64 GlobalSign GlobalSign 2014-12-10 00:00:00 2034-12-10 00:00:00 7305 3231 97 GlobalSign GlobalSign 2009-03-18 10:00:00 2029-03-18 10:00:00 7305 1139 101 GlobalSign Root CA GlobalSign Root CA 1998-09-01 12:00:00 2028-01-28 12:00:00 10741 724从输出可以看到，系统中存在 5 个 GlobalSign 根证书，其中：#34 和 #35：有效期至 2038-01-19，剩余 4367 天（约 12 年）#64：有效期至 2034-12-10，剩余 3231 天（约 9 年）#97：有效期至 2029-03-18，剩余 1139 天（约 3 年），当前使用的根证书#101：有效期至 2028-01-28，剩余 724 天（约 2 年）这些根证书为未来的证书续签提供了充足的选择空间。
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. 证书管理建议A. 使用独立证书推荐为每个 DNS 服务商处的域名使用独立证书，这是官方推荐的方式。B. 自动续期配置acme.sh 默认配置自动续期，无需额外操作：# 查看已安装的证书 acme.sh --list # 查看证书续期cron任务 crontab -l | grep acme.shC. 证书部署申请成功后，acme.sh 会自动保存证书，可以通过以下命令部署：acme.sh --install-cert -d a.com \ --cert-file /path/to/cert.pem \ --key-file /path/to/key.pem \ --fullchain-file /path/to/fullchain.pem \ --reloadcmd "service nginx reload"2. 安全建议A. API 密钥权限最小化为 acme.sh 创建专用的 API 密钥，仅授予 DNS 管理权限，避免使用主账号密钥。B. 定期轮换密钥建议每 3-6 个月更换一次 API 密钥。C. 监控证书有效期虽然 acme.sh 会自动续期，但仍建议配置监控告警，确保证书正常续期。3. 故障排查A. 常见问题问题 1：DNS API 验证失败# 检查 API 密钥是否正确 echo $Ali_Key echo $Ali_Secret # 手动测试 DNS API curl "https://alidns.aliyuncs.com/"问题 2：证书申请超时检查网络连接确认 DNS 服务商 API 可用增加等待时间参数：--dnssleep 300问题 3：域名验证失败确认域名已在对应 DNS 服务商处检查 API 密钥是否有该域名的管理权限B. 日志查看# 查看 acme.sh 日志 acme.sh --issue --dns dns_ali -d a.com -d *.a.com --debug五、实际案例案例：Web 服务器多证书配置1. Nginx 配置示例当使用多个证书时，需要在 Nginx 中为每个域名配置对应的证书：# a.com 使用阿里云申请的证书 server { listen 443 ssl; server_name a.com *.a.com; ssl_certificate /path/to/a.com.fullchain.pem; ssl_certificate_key /path/to/a.com.key.pem; # 其他配置... } # b.com 使用腾讯云申请的证书 server { listen 443 ssl; server_name b.com *.b.com; ssl_certificate /path/to/b.com.fullchain.pem; ssl_certificate_key /path/to/b.com.key.pem; # 其他配置... }2. Apache 配置示例 ServerName a.com ServerAlias *.a.com SSLEngine on SSLCertificateFile /path/to/a.com.cert.pem SSLCertificateKeyFile /path/to/a.com.key.pem SSLCertificateChainFile /path/to/a.com.chain.pem ServerName b.com ServerAlias *.b.com SSLEngine on SSLCertificateFile /path/to/b.com.cert.pem SSLCertificateKeyFile /path/to/b.com.key.pem SSLCertificateChainFile /path/to/b.com.chain.pem 六、总结1. 核心要点acme.sh 不支持在单个证书中混合使用多个 DNS API推荐为每个 DNS 服务商处的域名分别生成证书证书自动续期功能由 acme.sh 内置处理多证书配置在 Web 服务器中简单易行2. 推荐方案最佳实践：使用方案一，分别为每个 DNS 服务商申请独立证书。这种方式：配置简单，维护容易符合 acme.sh 的设计理念证书续期互不影响灵活性最高3. 参考资料参考资料acme.sh 官方 GitHub 仓库如何同时使用 CloudFlare 和 DNSPod 的两个域名？Issue #2791acme.sh 支持多个 DNS 服务商讨论 - Let's Encrypt 社区acme.sh 自动解析并申请证书 - DNSPod 官方文档使用 acme.sh 为在腾讯云（DNSPod）解析的域名自动申请证书 - 腾讯云使用 acme.sh 与阿里云 DNS 自动签发免费数字证书 - Kubecc Blogacme.sh 多域名最佳实践教程