3、数字证书与PKI体系归纳总结
3.1 数字证书到底长什么样？
一个X.509数字证书，说白了就是一张“网络身份证”。我刚开始搞TLS的时候，觉得证书就是个加密文件，后来被中间人搞了一次才明白——证书里的每个字段都可能被攻击者利用。
证书的核心字段就这几类：
| 字段 | 含义 | 审计关注点 |
|---|---|---|
| Subject（主题） | 证书持有者身份，比如域名、组织 | 域名是否匹配？有没有通配符滥用？ |
| Issuer（颁发者） | 签发该证书的CA名称 | CA是谁？是不是受信任的根？ |
| Validity（有效期） | 起止时间 | 是否过期？是否被篡改？ |
| Subject Public Key Info | 公钥算法和公钥值 | 密钥长度够不够（RSA 2048+）？ |
| Signature Algorithm | 签名算法 | 是否用SHA-1等弱算法？ |
| Extensions（扩展） | 用途约束、SAN、密钥用法等 | 有没有Basic Constraints标记CA？ |
我个人习惯用 openssl x509 -in cert.pem -text -noout 来快速查看这些字段。有一次在生产环境审计，发现一张证书的SAN字段居然写了三个无关域名——明显是内部测试证书被误用了。
避坑指南： 我曾经遇到一个案例，攻击者自签了一张根证书并在受害者设备上安装，之后所有HTTPS流量都被透明代理解密。检查证书的Issuer字段就能发现问题——它不在操作系统的信任列表里。
3.2 PKI体系：谁在背后撑腰？
PKI（公钥基础设施）不是单个东西，而是一整套流程。它回答三个问题：谁发的证书？怎么验证？出了事怎么办？
典型的PKI由这几部分组成：
- CA（证书颁发机构）：签发证书，也负责吊销。
- RA（注册机构）：审核申请者身份，CA只管签发。
- 证书库：存放公钥证书，比如LDAP或HTTP。
- CRL/OCSP：吊销状态查询——很多人漏掉这个检查。
我做一个项目时，客户只验证了证书签名，却没检查CRL。结果一张被泄露的私钥签发的证书照样能通过验证。嗯，检测中间人攻击时，吊销状态不能省。
真正安全的TLS握手，必须同时验证：签名完整性 + 域名匹配 + 有效期 + 吊销状态 + 证书链可信。
3.3 证书链：信任是怎么传递的？
你想想看，如果每个网站都用自签证书，浏览器就得存几十亿条公钥。不可能。所以CA们搞了个链式信任：
- 根证书：操作系统内置，自签名，极其宝贵。
- 中间证书：由根CA签发，数量很多。
- 服务器证书：由中间CA签发，最终被浏览器访问的。
浏览器收到服务器证书后，会向上找颁发者，一直追到根。中间任何一个环节被伪造，整个链就断了。攻击者要做中间人，最常见的办法就是插入一个“假中间证书”。
# 查看完整的证书链（服务器返回的，不包括根）
openssl s_client -connect example.com:443 -showcerts
注意：这个命令输出的第一张是服务器证书，后面是中间证书。根证书不会在网络中传输，客户端本地必须有。
3.4 中间人攻击如何利用PKI弱点？
攻击者打PKI的主意，不外乎这几个路子：
- 伪造根证书：通过社会工程让用户安装恶意根证书。浏览器信任它，以后所有从该CA签发的“服务器证书”都是假的了。
- 窃取CA私钥：比如2011年DigiNotar事件，攻击者拿到了中间CA的私钥，给*.google.com签发合法证书。
- 利用未吊销的证书：证书被盗后CA已经吊销，但客户端不检查CRL或OCSP，那就等于没吊销。
- 通配符+弱域名验证：*.example.com能匹配任意子域名，如果攻击者能拿到example.com的域名控制权……
重要： 审计检测时，一定要确认客户端是否启用了证书透明度（CT）。如果服务器证书没有被记录到公共CT日志，那它就有被伪造的嫌疑。我见过一个内网中间人工具，就是用自签证书绕过了CT检查。
3.5 审计检测的核心要点
我们把上面说的揉到一起，总结成一张检查清单：
- 证书链完整性——服务器返回的证书链是否完整？缺中间证书会让验证失败或降级。
- 域名匹配——Subject CN或SAN是否与请求的域名完全一致？通配符是否合理？
- 信任锚点——根证书是否在系统默认信任库中？有没有额外安装的“企业根”？
- 吊销状态——OCSP stapling支持吗？如果不行，客户端是否主动查询OCSP/CRL？
- 证书有效性——时间范围、签名算法、密钥强度。SHA-1证书直接拉黑。
- 证书透明度——SCT（签名证书时间戳）是否嵌入证书或通过OCSP扩展传递？
记得有一次我审计一个金融App，发现它只验证了证书签名，没检查是否被吊销。巧了，那段时间正好有家CA被爆出为未核实域名颁发证书……赶紧给团队打了个补丁。
实用命令速查：
检查OCSP响应：
查看CT日志提交情况：可以解析证书扩展中的
检查OCSP响应：
openssl ocsp -issuer intermediate.pem -cert server.pem -url http://ocsp.example.com查看CT日志提交情况：可以解析证书扩展中的
signed certificate timestamps 区域。
说到底，PKI就是人和机器之间的一套信任游戏。中间人攻击的成败，往往就取决于验证链条上最薄弱的那个环节。作为审计人员，我们要做的就是把每个环节都拧紧。