密码学基础（五）：证书体系

1. 数字证书常见标准：

1. 符合 PKI ITU-T X509 标准，传统标准（.DER .PEM .CER .CRT）
2. 符合 PKCS#7 加密消息语法标准(.P7B .P7C .SPC .P7R)
3. 符合 PKCS#10 证书请求标准(.p10)
4. 符合 PKCS#12 个人信息交换标准（.pfx *.p12）

X509是数字证书的基本规范，而 P7 和 P12 则是两个实现规范，P7 用于数字信封，P12 则是带有私钥的证书实现规范。

1. x509

基本的证书格式，包含 TBSCertificate、签名算法、签名值；

TBSCertificate 表示待签名的证书，由用户公钥、用户标识符组成、颁发者信息、有效期、版本号、证书序列号、证书有效期等信息，其结构如下：

x509证书

2. PKCS#7

Public Key Cryptography Standards #7，Cryptographic Message Syntax Standard；

PKCS#7 一般把证书分成两个文件，一个公钥、一个私钥，有 PEM 和 DER 两种编码方式。

PEM 比较多见，是纯文本的，一般用于分发公钥，看到的是一串可见的字符串，通常以.crt，.cer，.key为文件后缀。DER是二进制编码；

PKCS#7 一般主要用来做数字信封。

3. PKCS#10

Certification Request Standard，证书请求语法，如 iOS 中的 .certSigningRequest 文件；

4. PKCS#12

Public Key Cryptography Standards #12，Personal Information Exchange Syntax Standard 个人证书交换语法标准。

一种文件打包格式，为存储和发布用户和服务器私钥、公钥和证书指定了一个可移植的格式，是一种二进制格式，通常以 .pfx 或 .p12 为文件后缀名。

使用OpenSSL的 pkcs12 命令可以创建、解析和读取这些文件。

P12 是把证书压成一个文件，xxx.pfx 。主要是考虑分发证书，私钥是要绝对保密的，不能随便以文本方式散播。

所以 P7 格式不适合分发，.pfx/.p12 中可以加密码保护，所以相对安全些；

5. PKCS系列标准

实际上 PKCS#7、PKCS#10、PKCS#12都是PKCS系列标准的一部分。相互之间并不是替代的关系，而是对不同使用场景的定义。

2. 证书编码格式

PEM 和 DER 两种编码格式；

1. PEM

Privacy Enhanced Mail，查看内容，以"-----BEGIN..."开头，以"-----END..."结尾。

查看PEM格式证书的信息：

openssl x509 -in certificate.pem -text -noout

Apache和*NIX服务器偏向于使用这种编码格式。

.pem 是一种容器格式，可能仅包含公钥证书，也可以包含完整的证书链（包括公玥，私钥，和根证书）。也可能用来编码 CSR文件。

如下图的 pem 就包含两张证书，intermediate CA 和 user 的证书：

image.png

使用文本编辑器打开：

image.png

2. DER

Distinguished Encoding Rules ，打开看是二进制格式，不可读。

查看DER格式证书的信息：

openssl x509 -in certificate.der -inform der -text -noout

Java和Windows服务器偏向于使用这种编码格式。

3. 各种后缀含义

文件的内容和后缀没有必然的关系，但是一般使用这些后缀来表示这是什么文件。

1. JKS

Java Key Store(JKS)。

2. CSR

.csr 是证书请求文件，是由 RFC 2986定义的PKCS10格式，包含部分/全部的请求证书的信息，比如，主题, 机构，国家等，并且包含了请求证书的公玥，这些被CA中心签名后返回一张证书，返回的证书是公钥证书（只包含公玥不含私钥）。

查看的办法：

openssl req -noout -text -in my.csr

DER格式的话加上-inform der

3. CER

一般指使用 DER 格式的证书。

4. CRT

证书文件。可以是 PEM 格式。

5. KEY

.key 其实就是一个pem格式只包含私玥的文件，.key 作为文件名只是作为一个明显的别名。通常用来存放一个公钥或者私钥。

查看KEY的办法：

openssl rsa -in mykey.key -text -noout

如果是DER格式的话，同理应该这样了：

openssl rsa -in mykey.key -text -noout -inform der

这是使用 RSA 算法生成的key这么查看，DSA 算法生成的使用dsa参数。

6. CRL

证书吊销列表 (Certification Revocation List)，是一种包含撤销的证书列表的签名数据结构。

什么是 CRL ：

CRL CRL周期性发送

7. pem

.pem 是一种容器格式，可能仅包含公钥证书，也可以包含完整的证书链（包括公玥，私钥，和根证书）。也可能用来编码 CSR文件。

8 .pkcs12 .pfx .p12

pkcs 即 RSA 定义的 公玥密码学( Public-Key Cryptography Standards)标准，有多个标准 pkcs12只是其一，是描述个人信息交换语法标准。 有的文件直接使用其作为文件后缀名。这种文件包含公钥和私钥证书对，跟pem文件不同的是，它的内容是完全加密的。 用openssl可以把其转换成包含公玥和私玥的 .pem 文件。命令： openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes

9. der

其实 .der 不是一种文件格式。der 是ASN.1 众多编码方案中的一个，使用der编码方案编码的pem文件。der 编码是使用二进制编码，一般pem文件使用的是base64进行编码，所以完全可以把der编码的文件转换成pem文件，命令： openssl x509 -inform der -in to-convert.der -out converted.pem 使用der编码的pem文件，后缀名可以为.der，也可以为以下格式：

10 .cert .cer .crt

pem或者der编码格式的证书文件，这些文件后缀名都会被windows 资源管理器认为是证书文件。有趣的是, .pem 反而不会被认为是证书文件。

4. 证书体系的演变过程

1. 签名的产生

是指使用某种算法计算出元数据的哈希值，以此确保元数据没有被篡改，最初的签名算法采用摘要算法，证书体系中的签名采用摘要算法+ 非对称加密的方式进行签名；

2. 证书的产生

因为黑客可以修改元数据的同时修改摘要算法得出的哈希值，所以出现了证书，其目的是通过非对称加密来保证元数据的哈希值不被破解；

3. 证书的组成

证书分为 TBSCertificate（To-Be-Signed） 和 Certificate，即待签名的证书和签名过的证书。TBSCertificate 证书中包含拥有者的各种信息，同时还包含拥有者的公钥。我们一般说的证书是经过签名的，这种证书中除了包含 TBSCertificate ，还会包含签名使用的算法、签名值；

非对称加密效率较低，所以证书的签名一般先对 TBSCertificate 使用摘要算法得到固定长度的哈希值，然后使用私钥对这个哈希值进行非对称加密，最终得到签名，所以证书体系中的签名已经不是单纯的摘要算法了；

4. 证书的权威性隐患

最初的证书是自签名证书，拥有者使用自己的私钥对 TBSCertificate 进行签名，如果黑客攻击了证书发送者，并将证书上的公钥替换为自己的公钥，甚至直接将拥有者的私钥给窃取或者替换，那么接收者接收到的也是被篡改过的数据；

5. Root CA 机构的产生

自签名证书中，私人的私钥安全性隐患很大，因此才有了权威的 CA 机构，证书体系中默认 CA 机构的安全性不会被破解，所以理论上 CA 的私钥不会被窃取。CA 机构会对个人信息进行验证，并且使用自己的私钥对 TBSCertificate 证书进行签名之后颁发给申请者；

CA 机构的私钥理论上绝对安全，公钥会被嵌入到计算机基础体系中，如被嵌入到操作系统、浏览器中，所以浏览器可以直接使用 CA 的公钥对证书进行验签；

验签的流程就是先提取签名时使用的签名算法（signatureAlgorithm），这里主要是要知道签名时摘要算法采用的哪一种。然后提取出 TBSCertificate，使用摘要算法对 TBSCertificate 进行哈希，得到 Hash1。接着，使用 CA 公钥对签名值（signatureValue）进行解密，得到 Hash2，如果 Hash1 = Hash2，则证书校验成功；

至此，CA + 非对称加密 + 摘要算法就组成了证书体系；

6. intermediate CA 的产生

Root CA 基本上就那几个，他们的公钥会被嵌入到计算机基础体系中。如果直接使用 Root CA 的公钥进行签发，那么一旦 Root CA 的私钥发生变化，如撤销、过期等，牵连范围极大。

所以 intermediate CA 出现了， intermediate CA 作为 Root CA 的代理，先向 Root CA 申请证书，其流程和上面的基本一致， intermediate CA 将自己的信息和公钥发送给 Root CA ，Root CA 验证信息后颁发 TBSCertificate 并使用自己的私钥进行签名，最后颁发给 intermediate CA；

Root CA 只对 intermediate CA 颁发证书， intermediate CA 使用自己的私钥对申请者的证书进行签名，这样就实现了代理的作用；

5. 总结

一张图做总结：

1. 证书体系：

证书体系

2. 证书颁发/签名流程：

证书签名流程

3. 证书验签流程：

验签流程

解释：

1. User 自己（钥匙串证书助理、openssl）或者通过代理商（如阿里云）生成私钥，这个私钥可以导出公钥；
2. 提交自己的公钥和个人信息，生成 CSR Request 文件，发送给中间 CA；
3. 中间 CA 验证个人信息之后根据 CSR 生成 TBSCertificate，TBSCertificate 由各种信息（content）和申请者的公钥（publicKey）组成；
4. 中间 CA 首先对 TBSCertificate 进行摘要计算，然后用自己的私钥这个摘要结果进行非对称加密。打包待签名的证书、签名算法、签名值生成最终的证书颁发给申请者，即：Certificate = TBSCetificate(content, pubKey) + signatureAlgorithm(如SHA128WithRSA) + signatureValue(哈希值)；这个过程简化表示为：Cer-User = [（Public，content），Sign（Public，subject）]；
5. 中间 CA 同时要附上自己的证书形成证书链。而中间 CA 的证书是 Root CA 颁发的，其申请流程和 User 向中间 CA 申请证书的流程大同小异；
6. 中间 CA 将自己的公钥、信息打包生成 CSR Request 文件传递给 Root CA，Root CA 生成 TBSCetificate 之后进行签名并办法给 intermediate CA（步骤同4）；
7. Root CA 的公钥是作为基础组件被嵌入到浏览器、操作系统上，所以验签的流程都是使用上一级证书的公钥（颁发者issuer的公钥）来对签名进行验签操作；
8. 验证 User-Certificate 时，拿到 Intermedia-CA-Certificate 并提取出公钥、所使用的摘要算法。首先对 TBSCertificate 进行摘要计算得到 Hash1。然后使用中间 CA 公钥对签名进行解密，得到 Hash2。如果两个哈希值一样则该层证书验证成功；
9. 需要注意，颁发机构签名是对 subject 和 publicKey 一起进行签名的，即对 TBSCertificate 进行签名。否则中间人劫持证书之后将公钥替换成自己的公钥就能完成破解；
10. 验证完 User-Certificate，还需要验证 CA 的证书，此时和步骤 8 一致，只不过解密的公钥是根证书，直接从系统或者浏览器的根证书列表中获取；
11. 如果有 n 个 intermediate CA，那么证书链中就涉及到 n（CA） + 1 (user) + 1（Root CA）个证书；
12. 证书就是符合 X509 标准的文件，包含三个内容：tbsCertificate、signatureAlgorithm、signatureValue，而tbsCertificate 中包含了申请者、颁发者、有效期、证书序列号等信息，最重要的是包含了申请者的公钥；
13. tbsCertificate 表示 To-Be-Signed Certificate，等待被签名的证书。广义上的 Certificate 证书指的就是已经被签名过的证书，即包含未签名的证书、签名算法、签名值；

6. 参考文献

• x509 官方文档

• 《深入浅出密码学——常用加密技术原理与应用》

• 证书应用学习(一)——基础名词

• 证书应用学习(二)——PKCS10生成证书请求

• 证书应用学习(三)——CA签发证书流程

• iOS安全系列之一：HTTPS

• 《现代密码学-杨波-清华大学出版社》