有了公开密钥算法之后，我们就可以通过他人的公开密钥与其安全通信，但是还有一些悬而未决的问题：如何与那些从未谋面的人进行沟通？如何存储和吊销密钥？最重要的是，如何让现实世界中数以百万计的服务器、几十亿人和设备之间安全通信？这个问题非常的复杂，而公钥基础设施（public key infrastructure，PKI）就是为解决此问题而建立的。

1、互联网公钥基础设施 Internet PKI

对大多数人来说，PKI就是互联网公钥基础设施。实际上PKI的含义更宽泛，因为其原本是为了别的用途而开发的。

因此更准确的说法是，由PKIX工作组为适应PKI在互联网上的使用而提出的互联网公钥基础设施（Internet PKI）；

另外一个最近常被用到的词是Web PKI，主要关注在浏览器上如何使用和验证证书。

在本书中，除非某些特定场合确实有必要区分这两个概念以外，我说的PKI都表示互联网公钥基础设施。

PKI的目标就是实现不同成员在不见面的情况下进行安全通信，我们当前采用的模型是基于可信的第三方机构，也就是证书颁发机构（certification authority或certificate authority，CA）签发的证书。

订阅人（或者说最终实体）是指那些需要证书来提供安全服务的团体。

登记机构（registration authority，RA）主要是完成一些证书签发的相关管理工作

证书颁发机构（certification authority，CA）是指我们都信任的证书颁发机构，它会在确认申请用户的身份之后签发证书。同时CA会在线提供其所签发证书的最新吊销信息，这样信赖方就可以验证证书是否仍然有效。

信赖方（relying party）是指那些证书使用者。技术上来说，一般是指那些执行证书验证的网页浏览器、其他程序以及操作系统。他们是通过维护根可信证书库来执行验证的，这些证书库包含某些CA的最终可信证书（信任密钥，trust anchor）。更广泛地说，信赖方是指那些需要通过证书在互联网上进行安全通信的最终用户。

在PKI里面，信任只是技术层面上的概念，它仅仅意味着证书可以通过处于可信证书库中的某个CA的验证，但这并不意味着我们可以信任证书订阅人的一切

2、标准

X.509，它是一种公钥基础设施的国际标准

X.509经PKIX工作组的改造，适合在互联网上使用

PKIX工作组成立于1995年秋天，目标是建立支持基于X.509公钥基础设施的互联网标准。

PKIX工作组产出的最重要的文档是RFC 5280，它描述了证书格式、可信证书链的建立，以及证书吊销列表（CRL）的格式。

PKIX工作组在2013年10月结束了自己的使命。

CA/Browser论坛（CAB论坛）是由证书颁发机构、浏览器厂商以及其他有相关权益的团体自发形成的组织，目标是建立和推行证书颁发和处理的标准

一开始，CAB论坛是为了确定增强型证书（EV证书）的颁发标准而创建的，在2007年EV证书诞生了。

CAB论坛最开始只是一些松散的组织，但是随后他们改变了关注的焦点并且在2012年改组。同年，CAB论坛发布了Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates（《公共可信证书的颁发和管理基本要求》），简称为Baseline Requirements。

CAB论坛虽然只列了大约40个证书颁发机构，但是Baseline Requirements适用于所有的证书颁发机构；这份文件被纳入到针对证书颁发机构的WebTrust审计程序中①，而有些根证书库运营商（比如Mozilla）就明确要求CA必须符合这份标准。

2012年9月份成立的IETF’s Web PKI工作组，目的是描述PKI在Web上如何真正工作起来。②这个组织的目的是为Web PKI信任模型、吊销实践、证书中各字段和扩展的用法、证书吊销列表和OCSP响应制定参考文献

3、证书

证书是一个包含公钥、订阅人相关信息以及证书颁发者数字签名的数字文件，也就是一个让我们可以交换、存储和使用公钥的壳

常见的SSL证书格式

DER：Distinguished Encoding Rules的缩写，二进制编码的证书格式，相当于PEM格式的二进制版本，证书后缀有: .DER .CER .CRT，主要用于Java平台
PEM: Privacy Enhanced Mail的缩写，Base64编码的证书格式，是将二进制版本Base64编码后，以”—–BEGIN…”开头,“—–END…”结尾。证书后缀有：.PEM .CER .CRT，主要用于Apache和Nginx。
PKCS#7: PKCS（Public-Key Cryptography Standards）标准中的PKCS#7（Cryptographic Message Syntax Standard）。它不包含私钥，并将证书链和用户证书单独存放。证书后缀有: .P7B .P7C .SPC，主要用于Tomcat和Windows Server。
PKCS#12：PKCS（Public-Key Cryptography Standards）标准中的PKCS#12（Personal Information Exchange Syntax Standard）。它包含私钥，证书链，用户证书，并设置了密码。证书后缀有: .P12 .PFX，主要用于Windows Server。
JKS:JavaKeyStore的缩写，它包含私钥，证书链，用户证书，并设置了密码。证书后缀是.jks。主要用于Tomcat。

证书字段

版本

分别用0、1、2编码表示版本1、版本2和版本3
版本1只支持简单的字段，版本2增加了两个标识符（新增的字段），而版本3则增加了扩展功能。
现在大部分的证书都采用版本3的格式

序列号

每个CA用来唯一标识其所签发的证书
现在序列号需要是无序的（无法被预测）而且至少包括20位的熵。

签名算法

指明证书签名所用的算法，需要放到证书里面，这样才能被证书签名保护

颁发者

颁发者（issuer）字段包括了证书颁发者的可分辨名称（distinguished name，DN），
这个字段比较复杂，根据不同的实体会包含许多部分。举例来说，Verisign根证书的可分辨名称是/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority；它包括了国家、组织和组织单位三个部分。

有效期

证书的有效期包括开始日期和结束日期，在这段时间内证书是有效的

使用者

使用者是实体的可分辨名称，和公钥一起用于证书的签发。
在自签名证书里，使用者（subject）和颁发者（issuer）字段的可分辨名称是一样的。
在最开始，可分辨名称里面的公用名（common name，CN）主要用于服务器主机名（例如/CN=www.example.com用于www.example.com域名的证书），但是如何为一个证书匹配多个主机名就变得比较麻烦了。
如今，使用者字段已经废弃，转而使用使用者可选名称扩展。

公钥

这个字段包含了公钥，以使用者公钥信息（subject public-key info）结构呈现（主要是算法ID，可选参数以及公钥本身）

补充：

在版本2里面新增了两个字段，分别是颁发者唯一 ID（issuer unique ID）和使用者唯一ID（subject unique ID）。

在版本3里面使用授权密钥标识符（authority key identifier）和使用者密钥标识符（subject key identifier）扩展代替了版本2的颁发者唯一ID和使用者唯一ID。

证书扩展

为了让原本死板的证书格式变得更加灵活，版本3引入了证书扩展

每一个扩展都包括唯一的对象标识符（object identifier，OID）、关键扩展标识器以及ASN.1格式的值

如果将某个扩展设置为关键扩展，那么客户端必须能够解析和处理这个扩展，否则就应该拒绝整张证书。

使用者可选名称

使用者可选名称扩展就是为了替换使用者字段，它支持通过DNS名称、IP地址和URI来将多个身份绑定在一起。

名称约束

限制CA签发证书的对象，这样命名空间就在可控范围内
例如，它允许一个组织可以拥有一个二级CA，而这个CA只能签发这个公司所拥有的那些域名下的证书。有了这个限制，这类CA就不会影响整个生态系统了（例如，CA不能签发任意网站的证书）
大部分CA都将其设置为非关键扩展，而Baseline Requirements也明确表示允许这么处理。主要原因是有一些产品无法解析名称限制这个扩展，如果标记为关键扩展，就会导致这些产品拒绝此类证书。

基础约束

基础约束扩展用来表明证书是否为CA证书，同时通过路径长度（path length）约束字段，来限制二级CA证书路径的深度（例如限制CA证书是否可以签发更深一层的CA证书以及能签发多少层）。
理论上，所有的CA证书都必须包含这个扩展；
而实际情况是，有一些使用版本1协议的根证书还在使用中，它们是没有任何扩展功能的。

密钥用法

该扩展定义了证书中密钥可以使用的场景，这些场景已经定义好了，可以通过设置来让证书支持某个场景。
例如CA证书一般都设置了证书签名者（certificate signer）和CRL签名者（CRL signer）。

扩展密钥用法

为了更加灵活地支持和限制公钥的使用场景
该扩展可以通过OID支持更多的场景。
例如最终实体证书一般都拥有id-kp-serverAuth和id-kp-clientAuth两个OID，代码签名证书使用id-kp-codeSigning OID等。
虽然RFC 5280表明扩展密钥用法（extended key usage，EKU）只能用在最终实体证书上，但在实际中我们会看到中间CA也会带上这个扩展，从而让它签发出来的证书也带上这个限制。
Baseline Requirements还特别要求在使用EKU限制中间CA的同时还应当考虑使用名称限制。

证书策略

该扩展包含了一个或多个策略，
每个策略都包括一个OID和可选限定符（qualifier）。
限定符一般包括一个URI，从这个URI可以获得完整的策略说明。
Baseline Requirements要求每一张最终实体证书需要包括至少一条策略信息，来表明该证书是在何种条款下签发的。
另外这个扩展还能表明证书的验证类型。

CRL分发点

该扩展用来确定证书吊销列表（certificate revocation list，CRL）的LDAP或者HTTP URI地址。
按照Baseline Requirements，每一张证书都至少需要包括CRL或者OCSP吊销信息。

颁发机构信息访问

颁发机构信息访问表明如何访问签发CA 提供的额外信息和服务，
其中之一就是OCSP响应程序的HTTP URI地址。信赖方可以使用这个服务来实时检测证书的吊销信息。
另外还有一些证书包含了签发CA的URI地址，有了这个地址，即便服务器返回的证书链中缺少了签发CA的证书，客户端也可以通过下载签发CA重新构建证书链

使用者密钥标识符

该扩展包含了唯一的值，可以用来识别包含特别公钥的证书，一般建议使用公钥本身来建立这个标识符（例如通过散列）。
所有的CA证书都必须包含这个扩展，并且它的值要与CA所签发出来的证书上的授权密钥标识符的值一样。

授权密钥标识符

签发此证书的CA的唯一标识符，通常用于在构建证书链时找到颁发者的证书

补充：

RFC 5280还定义了几个很少使用到的扩展，它们分别是增量CRL分发点、禁止任意策略、颁发者可选名称、策略限制、策略映射、使用者目录属性、使用者信息访问。

4、证书链

在大多数情况下，仅仅有最终实体证书是无法进行有效性验证的，所以在实践中，服务器需要提供证书链才能一步步地最终验证到可信根证书，如图3-2所示。证书链的使用可能出于安全、技术和管理等方面的原因。

保证根证书安全

根CA不仅对拥有它的组织很重要，对整个生态来说同样至关重要。
首先是它有巨大的经济价值，因为很多根证书库已经不再更新了，所以以前那些已经被广泛使用的根CA是不可替代的。
再者，如果根CA的私钥被泄露，那么就可以签发任意域名的虚假证书。
另外如果根CA会被吊销掉，所有使用这个CA签发出来的证书的网站都会无法访问。
现在仍然还有很多CA直接使用他们的根证书直接签发最终实体证书，这其实是非常危险的。
Baseline Requirements限制所有的根证书密钥只能由人手动执行命令（自动化是不允许的），也就是说根证书密钥必须离线保存。
虽然还有很多依旧在使用的旧系统有这个漏洞，但是直接由根证书签发最终实体证书是不允许的。

交叉证书

交叉证书是可以让新的CA立即投入运营的唯一方式。
因为想要在短期内让新的根证书部署得足够广泛是不可能的，
所以新的CA都会找已经进行广泛内置的CA对他们的根密钥进行签名。
随着时间的流逝，那些老的设备会逐渐淘汰掉，新的CA才能最终独立使用。

划分

CA在将它的操作分散给很多二级CA的同时有可能会带来更多的风险。
例如不同的二级CA用于签发不同的证书类型，或者由不同的业务部门使用。
与根证书不同的是，二级CA一般都是在线的，而且使用自动化系统签发证书。

委派

还有一些情况是CA希望给外部其他组织签发一个二级CA。
例如一家大的公司可能希望可以自己签发它所拥有的那些域名的证书（这种方式通常比去维护私有CA，并确保所有设备都内置这个CA来说成本更低）。
有时候一些组织希望能够完全保管这个二级CA，这时候CA就会从技术上限制这个二级CA只能签发某些域名；
其他情况下CA依旧可以控制二级CA签发出来的证书。

补充：

服务器一次只能提供一条证书链，而实际上可能存在多条可信路径。
以交叉证书为例，一条可信路径可以一直到CA的主要根证书，另外一条则是到可选根证书上。
CA有时候会为同样的密钥签发多张证书，例如现在最常使用的签名算法是SHA1，因为安全原因正在逐步迁移到SHA256，
CA可以使用同样的密钥签发出不同签名的新证书。如果信赖方恰好有两张这样的证书，那么就可以构建出两条不同的可信路径。
路径的建立让整个事情变复杂了，而且导致了很多问题。
服务器必须提供完整并且有效的证书链，但是因为人员的疏忽或者各种各样的配置问题，导致证书链的配置总是有问题（例如需要在不同的地方配置服务器证书和证书链剩余的部分）。
根据SSL Pulse的数据，大概有5.9%的服务器配置的证书链是不完整的。
另外，因为标准的模糊、不完整以及相互矛盾，客户端在建立和验证路径上不可避免地出现了很多安全问题。
历史上有很多验证库在验证签发CA属于哪个根CA这类简单问题上都出现过问题。
如今最常使用的那些库并不是从一开始就安全的，也是经历过各种问题，打上了各种补丁后才慢慢经受住了实践的考验。

5、信赖方

信赖方为了能够验证证书，必须收集信任的所有根CA证书。
大多数的操作系统都提供一个根证书库，从而在一开始启动的时候就能够建立信任。
几乎所有的软件开发者都重用了底层操作系统提供的根证书库，唯一的例外是Mozilla，为了保证不同平台的兼容性，它维护了自己的根证书库。

6、证书颁发机构

证书颁发机构（certification authority，CA）是当前互联网信任模型最重要的部分，他们可以签发任何域名的证书，所以是非常权威的。

表面上看来似乎是一门稳赚的生意，前提是你的根证书要内置到尽可能多的设备中。那么具体需要做什么才能成为一个公开的CA？

(1) 建立CA组织。

a. 在PKI和CA的运营上非常专业。
b. 需要设计一个健壮、安全、隔离的网络，以便在支持商业运作的同时，能够保护根证书以及二级证书密钥的安全。
c. 支持证书生命周期管理流程。
d. 符合Baseline Requirements的规定。
e. 符合EV SSL证书指导规范。
f. 提供全球化的CRL和OCSP基础服务。

(2) 符合当地法律，这意味着可能需要按照当地的法规要求获取相应许可证。

(3) 通过根证书库认可的那些审计。

(4) 将你的根证书内置到尽可能多的设备、软件中。

(5) 找个已经内置的CA完成交叉证书，之后就可以开始运作了。

7、证书生命周期

证书的生命周期在订阅人准备证书签名申请（certificate signing request，CSR）文件，并将它提交给所选CA的时候就开始了。

CSR文件的主要目的是携带公钥信息，并且证明订阅人拥有对应的私钥（通过签名来证明）。
CSR还设计携带额外的元数据，但实际中并非所有的都用到了。
CA一般都会覆盖CSR文件的一些内容并且将其他信息内置到证书里面。

CA会根据不同类型的证书申请，执行不同的验证流程。

域名验证（domain validated，DV）证书需要CA验证订阅人对域名的所有权之后才能进行签发。大多数情况下CA会发送一封确认邮件给域名的管理邮箱，管理员通过之后（按照邮件里面的步骤和链接）CA就会签发证书。如果无法通过邮件确认，那么CA通过别的通信手段（例如电话或者邮寄信件）或者合理的方式证明订阅人对域名的所有权之后就可以签发证书。签发IP地址证书的步骤也是类似的。
组织验证（organization validated，OV）证书会对身份和真实性进行验证。直到采用了Baseline Requirements之后，OV证书的验证流程才标准化起来，但是在如何签发OV证书以及如何将这些信息编码到证书中等方面，依旧存在很多前后不一致的情况。
扩展验证（extended validation，EV）证书以更加严格的要求验证身份和真实性。它是为了解决OV证书缺乏的前后一致性而引入的，所以EV证书的验证流程非常详细，几乎不会出现前后不一致的情况。

CA在验证成功之后就会签发证书。除了证书本身，CA还会提供所有的中间证书，从而构建证书链到对应的根证书上，当然对一些主流的平台也会介绍如何进行配置。

在证书有效期范围内，申请者可以在他们的生产环境中使用该证书。如果证书对应的私钥泄露了，那么就需要吊销证书。这个过程和证书的签发有点类似。有一种说法叫作补签证书，不过从技术角度看，不存在补签证书一说：如果一张证书被吊销了，那么就需要按照证书申请签发流程换一张新证书。

8、吊销

当出现私钥泄露或者不再需要使用的时候，我们就需要吊销证书。但是这里存在误用的风险。吊销协议和流程的设计是为了确保证书是有效的，否则就需要将吊销情况通知信赖方。现在有下面两种证书吊销标准。

证书吊销列表（certificate revocation list，CRL）是一组未过期、但是却已经被吊销的证书序列号列表，CA维护了一个或多个这样的列表。每一张证书都需要在CRL分发点（CRL distribution point）扩展中包含对应的CRL地址。CRL最大的问题在于它越来越大，实时查询起来会非常慢。
在线证书状态协议（online certificate status protocol，OCSP）允许信赖方获得一张证书的吊销信息。OCSP服务器通常称为OCSP响应程序，OCSP响应程序的地址编码在颁发机构信息访问（authority information access，AIA）证书扩展中。OCSP支持实时查询并且解决了CRL最大的缺点，但是并没有解决所有的吊销问题：因为OCSP的使用带来了性能、隐私方面的问题和新的漏洞。其中一部分问题可以通过OCSP stapling技术来解决，它允许服务器在TLS握手的过程中直接嵌入OCSP响应。

第三章 公钥基础设施