1. 证书基础概念：数字证书、X.509标准、证书链与信任锚、PKI概述

说实话，很多搞安全的人天天跟证书打交道，但真要问「数字证书到底是什么」，能讲清楚的不多。我刚开始做DevSecOps那会儿也踩过这个坑——以为证书就是个加密文件，直到一次生产环境证书链断裂，整个微服务集群全挂了，才老老实实把基础补上。

这一章咱们就把地基打牢。后面29章的所有轮换策略、合规检查、自动化脚本，都建立在这些概念之上。

1.1 数字证书：你到底是谁的凭证？

数字证书，说白了就是网络世界里的身份证。你拿着身份证去办业务，人家看的是公安部的章；浏览器访问HTTPS网站，看的是CA（证书颁发机构）的签名。

一个标准的数字证书包含以下核心信息：

• 主体信息：证书持有者是谁（域名、组织名、邮箱等）
• 公钥：持有者的公钥，用于加密或验签
• 颁发者信息：谁签发了这张证书
• 有效期：从哪天到哪天有效
• 签名算法：比如SHA256-RSA
• 数字签名：CA用私钥对上述内容做的签名

我记得有一次帮客户做安全审计，发现他们把私钥直接放在证书文件里一起分发。嗯，这相当于把银行卡密码写在身份证背面——证书轮换做得再好也没用。

1.2 X.509标准：证书界的通用语言

X.509是国际电信联盟（ITU-T）定义的公钥证书格式标准。目前主流版本是V3，几乎所有HTTPS、代码签名、邮件加密都在用。

V3版本引入了扩展字段，让证书能做更多事：

扩展字段	作用	我见过的坑
Subject Alternative Name (SAN)	指定证书适用的域名列表	只配了CN没配SAN，Chrome直接报错
Key Usage	限制公钥用途（数字签名、密钥加密等）	CA证书配了digitalSignature，导致无法签发子证书
Extended Key Usage (EKU)	更细粒度限制（服务器认证、客户端认证等）	代码签名证书被配成serverAuth，打包工具拒绝使用
Basic Constraints	标记是否为CA证书	中间CA没配CA:TRUE，整条链废了

1.3 证书链与信任锚：信任是怎么传递的？

你想想看，浏览器里预装了上百个根证书，但你的网站证书不是根CA直接签的，中间可能隔了两三层。这就是证书链。

证书链的结构通常是：

根证书（信任锚）
  └── 中间CA证书（由根CA签发）
        └── 中间CA证书2（由中间CA1签发）
              └── 服务器证书（由中间CA2签发）

验证过程是从下往上：

1. 用中间CA2的公钥验证服务器证书的签名
2. 用中间CA1的公钥验证中间CA2的签名
3. 用根证书的公钥验证中间CA1的签名
4. 根证书在信任存储里，验证结束

信任锚（Trust Anchor）就是这条链的起点。操作系统或浏览器内置的根证书就是信任锚。你自建CA的话，需要把自签根证书手动加到所有客户端的信任存储里——这也是内部PKI最麻烦的一步。

1.4 PKI概述：整个信任体系怎么运转？

公钥基础设施（PKI）不是某个软件，而是一整套体系。它包括：

• CA（证书颁发机构）：签发和吊销证书
• RA（注册机构）：验证申请者身份，把审核结果告诉CA
• 证书库：存放已签发证书的地方，通常是LDAP或HTTP服务器
• CRL/OCSP：证书吊销列表和在线证书状态协议，用来查证书是否被吊销
• 最终实体：持有证书和私钥的服务器或用户

下面这张图展示了PKI的核心流程：

1.5 为什么这些基础对证书轮换很重要？

你可能觉得这些概念太理论了。但实际做证书轮换时，每个点都会变成具体问题：

• 证书链不完整：轮换后新证书没带上中间CA，客户端验证失败
• 信任锚变更：根CA过期了，所有下级证书都得跟着换
• 扩展字段错误：新证书的SAN漏了某个域名，服务直接不可用
• 吊销检查：轮换后旧证书没及时吊销，被攻击者利用