5.4 数字证书

对于非对称加密算法和数字签名来说，很重要的一点就是公钥的分发。理论上任何人可以公开获取到对方的公钥。然而这个公钥有没有可能是伪造的呢？传输过程中有没有可能被篡改掉呢？一旦公钥自身出了问题，则整个建立在其上的安全体系的安全性将不复存在。

数字证书机制正是为了解决这个问题，它就像日常生活中的一个证书一样，可以证明所记录信息的合法性。比如证明某个公钥是某个实体（如组织或个人）的，并且确保一旦内容被篡改能被探测出来，从而实现对用户公钥的安全分发。

根据所保护公钥的用途，可以分为加密数字证书（Encryption Certificate）和签名验证数字证书（Signature Certificate）。前者往往用于保护用于加密信息的公钥；后者则保护用于进行解密签名进行身份验证的公钥。两种类型的公钥也可以同时放在同一证书 中。

一般情况下，证书需要由证书认证机构（Certification Authority，CA）来进行签发和背书。权威的证书认证机构包括DigiCert、GlobalSign、VeriSign等。用户也可以自行搭建本地CA系统，在私有网络中进行使用。

5.4.1　X.509证书规范

一般来说，一个数字证书内容可能包括基本数据（版本、序列号）、所签名对象信息（签名算法类型、签发者信息、有效期、被签发人、签发的公开密钥）、CA的数字签名，等等。

目前使用最广泛的标准为ITU和ISO联合制定的X.509的v3版本规范（RFC 5280），其中定义了如下证书信息域：

·版本号（Version Number）：规范的版本号，目前为版本3，值为0x2；

·序列号（Serial Number）：由CA维护的为它所颁发的每个证书分配的唯一的序列号，用来追踪和撤销证书。只要拥有签发者信息和序列号，就可以唯一标识一个证书，最大不能超过20个字节；

·签名算法（Signature Algorithm）：数字签名所采用的算法，如sha256WithRSAEncryption或ecdsa-with-SHA256；

·颁发者（Issuer）：颁发证书单位的标识信息，如“C=CN，ST=Beijing，L=Beijing，O=org.example.com，CN=ca.org.example.com”；

·有效期（Validity）：证书的有效期限，包括起止时间；

·主体（Subject）：证书拥有者的标识信息（Distinguished Name），如“C=CN，ST=Beijing，L=Beijing，CN=person.org.example.com”；

·主体的公钥信息（Subject Public Key Info）：所保护的公钥相关的信息：

·公钥算法（Public Key Algorithm）：公钥采用的算法；

·主体公钥（Subject Public Key）：公钥的内容。

·颁发者唯一号（Issuer Unique Identifier）：代表颁发者的唯一信息，仅2、3版本支持，可选；

·主体唯一号（Subject Unique Identifier）：代表拥有证书实体的唯一信息，仅2、3版本支持，可选；

·扩展（Extensions，可选）：可选的一些扩展。v3中可能包括：

·Subject Key Identifier：实体的密钥标识符，区分实体的多对密钥；

·Basic Constraints：一般指明是否属于CA；

·Authority Key Identifier：证书颁发者的公钥标识符；

·CRL Distribution Points：撤销文件的发布地址；

·Key Usage：证书的用途或功能信息。

此外，证书的颁发者还需要对证书内容利用自己的公钥添加签名，以防止别人对证书内容进行篡改。

5.4.2　证书格式

X.509规范中一般推荐使用PEM（Privacy Enhanced Mail）格式来存储证书相关的文件。证书文件的文件名后缀一般为.crt或.cer，对应私钥文件的文件名后缀一般为.key，证书请求文件的文件名后 缀为.csr。有时候也统一用.pem作为文件名后缀。

PEM格式采用文本方式进行存储，一般包括首尾标记和内容块，内容块采用Base64进行编码。

例如，一个PEM格式的示例证书文件如下所示：

---

-----BEGIN CERTIFICATE-----
MIICMzCCAdmgAwIBAgIQIhMiRzqkCljq3ZXnsl6EijAKBggqhkjOPQQDAjBmMQsw
CQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy
YW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFDASBgNVBAMTC2V4YW1wbGUu
Y29tMB4XDTE3MDQyNTAzMzAzN1oXDTI3MDQyMzAzMzAzN1owZjELMAkGA1UEBhMC
VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lzY28x
FDASBgNVBAoTC2V4YW1wbGUuY29tMRQwEgYDVQQDEwtleGFtcGxlLmNvbTBZMBMG
ByqGSM49AgEGCCqGSM49AwEHA0IABCkIHZ3mJCEPbIbUdh/Kz3zWW1C9wxnZOwfy
yrhr6aHwWREW3ZpMWKUcbsYup5kbouBc2dvMFUgoPBoaFYJ9D0SjaTBnMA4GA1Ud
DwEB/wQEAwIBpjAZBgNVHSUEEjAQBgRVHSUABggrBgEFBQcDATAPBgNVHRMBAf8E
BTADAQH/MCkGA1UdDgQiBCBIA/DmemwTGibbGe8uWjt5hnlE63SUsXuNKO9iGEhV
qDAKBggqhkjOPQQDAgNIADBFAiEAyoMO2BAQ3c9gBJOk1oSyXP70XRk4dTwXMF7q
R72ijLECIFKLANpgWFoMoo3W91uzJeUmnbJJt8Jlr00ByjurfAvv
-----END CERTIFICATE-----

---

可以通过OpenSSL工具来查看其内容：

---

# openssl x509 -in example.com-cert.pem -noout -text
Certificate:
   Data:
       Version: 3 (0x2)
       Serial Number:
           22:13:22:47:3a:a4:0a:58:ea:dd:95:e7:b2:5e:84:8a
   Signature Algorithm: ecdsa-with-SHA256
       Issuer: C=US, ST=California, L=San Francisco, O=example.com,
           CN=example.com
       Validity
           Not Before: Apr 25 03:30:37 2017 GMT
           Not After : Apr 23 03:30:37 2027 GMT
       Subject: C=US, ST=California, L=San Francisco, O=example.com,
           CN=example.com
       Subject Public Key Info:
           Public Key Algorithm: id-ecPublicKey
               Public-Key: (256 bit)
               pub:
                   04:29:08:1d:9d:e6:24:21:0f:6c:86:d4:76:1f:ca:
                   cf:7c:d6:5b:50:bd:c3:19:d9:3b:07:f2:ca:b8:6b:
                   e9:a1:f0:59:11:16:dd:9a:4c:58:a5:1c:6e:c6:2e:
                   a7:99:1b:a2:e0:5c:d9:db:cc:15:48:28:3c:1a:1a:
                   15:82:7d:0f:44
               ASN1 OID: prime256v1
       X509v3 extensions:
           X509v3 Key Usage: critical
               Digital Signature, Key Encipherment, Certificate Sign,
                   CRL Sign
           X509v3 Extended Key Usage:
               Any Extended Key Usage, TLS Web Server Authentication
           X509v3 Basic Constraints: critical
               CA:TRUE
           X509v3 Subject Key Identifier:
               48:03:F0:E6:7A:6C:13:1A:26:DB:19:EF:2E:5A:3B:79:86:
                   79:44:EB:74:94:B1:7B:8D:28:EF:62:18:48:55:A8
   Signature Algorithm: ecdsa-with-SHA256
       30:45:02:21:00:ca:83:0e:d8:10:10:dd:cf:60:04:93:a4:d6:
       84:b2:5c:fe:f4:5d:19:38:75:3c:17:30:5e:ea:47:bd:a2:8c:
       b1:02:20:52:8b:00:da:60:58:5a:0c:a2:8d:d6:f7:5b:b3:25:
       e5:26:9d:b2:49:b7:c2:65:af:4d:01:ca:3b:ab:7c:0b:ef

---

此外，还有DER（Distinguished Encoding Rules）格式，是采用二进制对证书进行保存，可以与PEM格式互相转换。

5.4.3　证书信任链

证书中记录了大量信息，其中最重要的包括“签发的公开密钥”和“CA数字签名”两个信息。因此，只要使用CA的公钥再次对这个证书进行签名比对，就能证明某个实体的公钥是否是合法的。

读者可能会想到，怎么证明用来验证对实体证书进行签名的CA公钥自身是否合法呢？毕竟在获取CA公钥的过程中，它也可能被篡改掉。

实际上，要想知道CA的公钥是否合法，一方面可以通过更上层的CA颁发的证书来进行认证；另一方面某些根CA（Root CA）可以通过预先分发证书来实现信任基础。例如，主流操作系统和浏览器里面，往往会提前预置一些权威CA的证书（通过自身的私钥签名，系统承认这些是合 法的证书）。之后所有基于这些CA认证过的中间层CA（Intermediate CA）和后继CA都会被验证合法。这样就从预先信任的根证书，经过中间层证书，到最底下的实体证书，构成一条完整的证书信任链。

某些时候用户在使用浏览器访问某些网站时，可能会被提示是否信任对方的证书。这说明该网站证书无法被当前系统中的证书信任链进行验证，需要进行额外检查。另外，当信任链上任一证书不可靠时，则依赖它的所有后继证书都将失去保障。

可见，证书作为公钥信任的基础，对其生命周期进行安全管理十分关键。下节将介绍的PKI体系提供了一套完整的证书管理的框架，包括生成、颁发、撤销过程等。

来源：我是码农，转载请保留出处和链接！

本文链接：http://www.54manong.com/?id=961

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })();

'); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();