细读HTTPS -- 公钥基础设施PKI

细读HTTPS – 公钥基础设施PKI

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

下面就参照这张图分别来介绍下各个部分的含义.

订阅人

订阅人（或者说最终实体）是指那些需要证书来提供安全服务的团体。互联网方面主要是指网络公司。

证书

证书是一个包含公钥、订阅人相关信息以及证书颁发者数字签名的数字文件，，也就是一个让我们可以交换、存储和使用公钥的壳。因此，证书成为了整个PKI体系的基础组成元素。
证书的生命周期在订阅人准备证书签名申请（certificate signing request，CSR）文件，并将它提交给所选CA的时候就开始了。CSR文件的主要目的是携带公钥信息，并且证明订阅人拥有对应的私钥（通过签名来证明）。
不同类型的证书申请：

域名验证（domain validated，DV）证书

DV证书需要CA验证订阅人对域名的所有权之后才能进行签发。

组织验证（organization validated，OV）证书

OV证书会对身份和真实性进行验证。直到采用了Baseline Requirements之后，OV证书的验证流程才标准化起来，但是在如何签发OV证书以及如何将这些信息编码到证书中等方面，依旧存在很多前后不一致的情况。

扩展验证（extended validation，EV）证书

EV证书以更加严格的要求验证身份和真实性。它是为了解决OV证书缺乏的前后一致性而引入的，所以EV证书的验证流程非常详细，几乎不会出现前后不一致的情况。

DV证书的签发是全自动的，所以非常快，它的签发时间主要取决于DNS管理员确认邮件所需的时间；而EV证书则相反，可能需要几天甚至几周才能拿到。

证书字段

• 版本：证书一共有3个版本号，分别用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 public-key info）结构呈现（主要是算法ID，可选参数以及公钥本身）。
  另外证书有可扩展的字段…

证书链

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

证书吊销

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

证书吊销列表 - CRL

证书吊销列表（certificate revocation list，CRL）是一组未过期、但是却已经被吊销的证书序列号列表，CA维护了一个或多个这样的列表。每一张证书都需要在CRL分发点（CRLdistribution point）扩展中包含对应的CRL地址。CRL最大的问题在于它越来越大，实时查询起来会非常慢。

在线证书状态协议 - OCSP

在线证书状态协议（online certificate status protocol，OCSP）允许信赖方获得一张证书的吊销信息。OCSP服务器通常称为OCSP响应程序，OCSP响应程序的地址编码在颁发机构信息访问（authority information access，AIA）证书扩展中。OCSP支持实时查询并且解决了CRL最大的缺点，但是并没有解决所有的吊销问题：因为OCSP的使用带来了性能、隐私方面的问题和新的漏洞。其中一部分问题可以通过OCSP stapling技术来解决，它允许服务器在TLS握手的过程中直接嵌入OCSP响应。

信赖方

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

• Apple：Apple维护的根证书库主要是给iOS和OS X平台使用②，如果某个CA希望加入到Apple的根证书库里面的话，就需要通过权威机构审计并且对Apple的客户有商业价值。
• Chrome：在Linux上，Chrome使用Mozilla的根证书库（通过NSS网络库），除此之外Chrome都是依赖操作系统提供的证书库。
• Microsoft：Microsoft维护的根证书库主要是给Windows桌面版、服务器版以及移动手机平台使用。④同样，如果要加入，需要至少一年的审计并且提供一份能够为Microsoft的用户群带来商业价值的说明。
• Mozilla：Mozilla为自己的产品维护了一个公开透明的根证书库⑤并且大部分Linux版本都使用Mozilla的根证书库。

证书颁发机构 – CA

证书颁发机构（certification authority，CA）是当前互联网信任模型最重要的部分，他们可以签发任何域名的证书，所以是非常权威的。表面上看来似乎是一门稳赚的生意，前提是你的根证书要内置到尽可能多的设备中。