运维123 - 证书
type: channel
link: https://www.sddts.cn/index.php/tag/%E8%AF%81%E4%B9%A6/
items: X509 证书交叉签名工作原理深度解析
items: Let's Encrypt 交叉签名：免费兼容老系统的策略分析
items: 网站证书从担心到不担心：证书链信任机制深度解析
items: acme.sh 跨 DNS 服务商多域名证书申请指南

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. …

网站证书从担心到不担心：证书链信任机制深度解析
type: item
date: 2026-02-03T07:52:38+00:00
description: 网站证书从担心到不担心：证书链信任机制深度解析一、背景：为什么会担心证书到期？假设一个网站域名是 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 证书续…

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