📚 课程目录第3章 X.509证书标准

3. X.509证书标准：证书结构解析、证书版本与扩展域、关键字段

X.509证书，说白了就是数字世界的身份证。但跟咱们的身份证不一样，它里面装的东西可多得多。我刚开始接触PKI那会儿，打开一个证书文件，满眼都是ASN.1、OID、DER编码，说实话挺懵的。后来啃了几次RFC 5280，又在项目里被坑过几回，才算真正搞明白。

这一章，咱们就把X.509证书从头到脚拆开来看。你以后看到任何证书，都能一眼认出它是什么结构、哪个版本、关键字段在哪。

3.1 证书的整体结构

一个X.509证书，本质上是一个数字签名过的数据结构。它用ASN.1（抽象语法标记）定义，用DER（区分编码规则）序列化。但咱们不用纠结底层编码，先看逻辑结构。

我习惯把证书分成三个部分：

证书体（TBSCertificate）—— 要签名的内容，包含版本、序列号、签名算法、颁发者、有效期、主体、公钥、扩展等
签名算法标识—— 告诉你怎么验证这个签名
签名值—— CA用私钥对证书体做的数字签名

嗯，这里要注意：签名值覆盖的是整个证书体，不是证书文件本身。一旦证书体里任何一个字节变了，签名验证就会失败。我在项目中遇到过有人手动改证书里的域名，结果签名校验直接挂掉——这其实是个安全设计，防止篡改。

核心理解：证书 = 公开信息（证书体）+ 防伪标记（签名）。公开信息谁都能读，但签名只有CA能生成。

3.2 证书版本

X.509证书目前有三个版本。你想想看，一个标准从1988年用到今天，中间肯定经历了不少演进。

版本	字段值	发布时间	主要特点
v1	0	1988	基础结构，无扩展域
v2	1	1993	新增主体唯一标识、颁发者唯一标识（几乎没人用）
v3	2	1996	引入扩展域，现代PKI的标准选择

现在你看到的几乎所有证书都是v3。v1和v2基本绝迹了，除非你在某些老旧的硬件设备里还能翻到。我个人建议：新搭建的PKI系统，一律使用v3证书。为什么？因为扩展域太重要了，后面你会看到。

小技巧：用OpenSSL查看证书版本时，v3显示为"2"。别搞混了——字段值是0-based的。

3.3 关键字段详解

3.3.1 Subject（主体）

Subject字段标识证书持有者是谁。对于设备证书，它通常是一个设备ID或主机名。对于CA证书，它就是CA机构的名称。

Subject用DN（Distinguished Name，专有名称）来表示，由多个RDN（相对专有名称）组成。常见的RDN有：

CN（Common Name）—— 通用名称，设备证书里通常是域名或设备名
O（Organization）—— 组织名称
OU（Organizational Unit）—— 组织单位
C（Country）—— 国家代码，两位字母
L（Locality）—— 所在地
ST（State/Province）—— 省/州

举个例子，一个企业设备证书的Subject可能是这样：

CN=device-iot-001.internal.company.com
O=Company Inc.
OU=IoT Devices
C=CN
L=Shanghai

嗯，这里有个坑。以前很多人把域名直接放在CN里，浏览器也认。但现代浏览器和操作系统已经不再信任CN中的域名了，必须用SAN。我在项目中遇到过一台老设备，证书只配了CN没配SAN，结果所有现代浏览器都报域名不匹配——折腾了一天才找到原因。

3.3.2 Issuer（颁发者）

Issuer字段标识签发这张证书的CA是谁。它的格式跟Subject一样，也是DN。

对于自签名证书（比如根CA证书），Issuer和Subject是完全一样的。对于下级证书，Issuer是上级CA的Subject。

你想想看，这就形成了一个信任链：

根CA证书：Issuer = Subject（自己签自己）
中间CA证书：Issuer = 根CA的Subject
设备证书：Issuer = 中间CA的Subject

注意：Issuer字段只是一个名称标识，不是验证签名的依据。验证签名时，系统会用Issuer DN去查找对应的CA证书，然后用CA证书里的公钥来验证签名。如果Issuer DN写错了，系统就找不到正确的CA证书，验证就会失败。

3.3.3 SAN（Subject Alternative Name，主体备用名称）

SAN是v3扩展域里最重要的字段之一，没有它，现代PKI几乎没法用。

SAN的作用是告诉系统：这张证书到底为哪些域名、IP地址或标识服务。它支持多种类型：

类型	标识符	示例	常见用途
DNS	dNSName	api.example.com	Web服务器、API网关
IP	iPAddress	192.168.1.100	内网设备、路由器
URI	uniformResourceIdentifier	spiffe://trustdomain/workload	SPIFFE身份、微服务
电子邮件	rfc822Name	device@company.com	邮件证书
其他	otherName	1.3.6.1.4.1.12345.1	自定义设备标识

我建议你在企业设备PKI中，至少为每张设备证书配置一个DNS类型的SAN。如果设备有固定IP，再加一个IP类型的SAN。这样不管是按域名访问还是按IP访问，都能通过证书验证。

最佳实践：从2018年起，主流浏览器要求所有公开信任的证书必须包含SAN。虽然企业内网可以放宽要求，但我建议你从一开始就养成配SAN的习惯。省得以后出兼容性问题。

3.4 证书版本与扩展域

v3证书之所以能成为主流，全靠扩展域。扩展域是一个可选的字段集合，每个扩展都有三个属性：

扩展ID（OID）—— 唯一标识这个扩展是什么
关键性标志（Critical）—— true/false，告诉系统这个扩展必须被处理
扩展值—— 具体的数据

关键性标志是个很有意思的设计。如果某个扩展标记为Critical，但验证方不认识这个扩展，那验证方必须拒绝这张证书。如果标记为Non-Critical，不认识就跳过。

我见过有人把所有扩展都设成Critical，结果证书在老旧设备上全挂了。反过来，该设Critical的没设，比如Basic Constraints，又可能导致安全风险。

常见的v3扩展有：

扩展名称	OID	Critical?	作用
Basic Constraints	2.5.29.19	通常为true	标识是否为CA证书，以及路径长度限制
Key Usage	2.5.29.15	通常为true	限制密钥用途（数字签名、密钥加密等）
Extended Key Usage	2.5.29.37	通常为false	更细化的用途限制（服务器认证、客户端认证等）
Subject Alternative Name	2.5.29.17	通常为false	主体备用名称列表
Subject Key Identifier	2.5.29.14	通常为false	主体公钥的哈希，用于快速查找证书
Authority Key Identifier	2.5.29.35	通常为false	颁发者公钥的哈希，用于构建证书链

我的习惯：对于设备证书，我通常只配SAN、Key Usage（digitalSignature, keyEncipherment）、Extended Key Usage（serverAuth, clientAuth）。CA证书则必须配Basic Constraints（CA:TRUE）和Key Usage（keyCertSign, cRLSign）。

3.5 用OpenSSL看一张证书

光说不练假把式。咱们用OpenSSL实际看一张证书的结构：

openssl x509 -in device.crt -text -noout

输出会包含：

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0x1234567890abcdef
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Company Root CA, O=Company Inc., C=CN
        Validity
            Not Before: Jan  1 00:00:00 2024 GMT
            Not After : Dec 31 23:59:59 2025 GMT
        Subject: CN=device-iot-001.internal.company.com, O=Company Inc., OU=IoT
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:device-iot-001.internal.company.com
                IP:192.168.1.100
            X509v3 Key Usage:
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
    Signature Algorithm: sha256WithRSAEncryption
         [签名值，一堆十六进制数据]

看到没？版本是v3，Subject和Issuer都是DN格式，SAN里配了域名和IP，Key Usage和Extended Key Usage限制了用途。这就是一张典型的企业设备证书。

避坑指南：我曾经在生成证书时忘了加SAN，结果设备上线后所有TLS握手都失败。排查了半天才发现是证书里没有SAN，而客户端库强制要求SAN匹配。从那以后，我写脚本生成证书时都会自动加上SAN，哪怕只有一个域名。

3.6 小结

X.509证书的结构其实不复杂。记住三个核心：证书体（公开信息）+ 签名算法 + 签名值。v3版本靠扩展域提供了极大的灵活性，SAN解决了多域名问题，Key Usage和Extended Key Usage控制了密钥的使用范围。