1. 概述

上一篇博客的最后，我们指出了非对称密钥加密体系中同样存在公钥交换的问题。即在公钥体系中，公钥并不是简单的通过网络就可以交换的，因为这样很容易受到中间人攻击。所以如何安全的交换公钥就成了业界需要解决的问题。

公钥基础设施（Public Key Infrastructure, PKI）技术在解决这个问题上引起了极大的关注，并迅速成为 Internet 上现代安全机制的焦点中心。PKI 不是一个简单的算法或思想，而是需要大量经费、精力和决心才能建立、维护与促进的技术方案。PKI 几乎是所有加密系统的必经之路。

PKI 与非对称密钥加密密切相关，包括消息摘要、数字签名和加密服务。要支持这些服务，最重要的是 PKI 中的数字证书技术。

2. 数字证书

2.1. 简介

正如前面所说，公钥交换是个问题。经过大量思考，人们提出了数字证书（digital certificates）的革命性思想。

在概念上，数字证书相当于身份证这样的证件。专家的意思很明显，你不是很难知道另一个人的公钥是什么嘛，那我就把每个人的公钥和其类似于身份证的证件关联在一起，这样就很方便知道该公钥的归属了。

更具体来讲，数字证书其实就是一个计算机文件，就像身份证是一个具体的卡片一样。身份证记录了个人的姓名、性别、出生日期等等信息，而数字证书记录了个人和一个公钥的关联关系。

身份证由国家统一批准，那显然数字证书也需要一个各方都信任的机构颁发。假如身份证不是国家颁发而是某个小铺子给你的，你还敢用吗。

前面说过，数字证书记录了用户和对应公钥的关联。因此数字证书里面肯定要有用户名和用户的公钥，除此之外数字证书还有什么呢？不妨随便打开一个 https 的网站，然后点地址栏左边那个小锁的图标，然后点 Certificate ，你就可以看到这个网站的数字证书，例如下面就是我的网站的数字证书页面：

可以看到有很多的信息，例如版本号、序列号、颁发者和使用者等等。那个颁发者到底是谁呢？是哪个阿猫阿狗嘛？下面就来详细看看。

2.2. 证书机构

证书机构（Certification Authority, CA）就是可以签发数字证书的信任机构。而谁又能成为证书机构呢？通常证书机构是一些著名的组织，例如世界上最著名的证书机构是 VeriSign 与 Entrust 。这些组织一定是大家都信任的，这样他们才有权向个人和组织签发数字证书，使其可以在非对称密钥加密的应用程序中使用这些证书。看上面的图片中，我的网站的数字证书的颁发者是 Encryption Everywhere ，其隶属于著名的机构 DigiCert 。

2.3. 数字证书的具体内容

下来可以看看数字证书的一些具体的内容。数字证书的结构在 Satyam 标准中定义。国际电信联盟于 1988 年推出这个标准，当时其被命名为 X. 509 标准，后来该标准于 1993 年和 1995 年做了两次修订。所以现在最常用的应该是 X. 509V3。可以在上图看到，我的数字证书的版本就是 V3 。下图展示了三个版本的基本情况。

可以看到最开始的版本 1 定义了一些基本内容，而版本 2 多了两个条目，分别是颁发者 ID 和 主体人（使用者）ID，目的是为了处理颁发者和使用者的名字出现重复的情况。版本 3 则新增了很多扩展信息。最后一条是 CA 自己的数字签名，这在每个版本中都有。下表展示了最初的版本 1 中的信息条目。

2.4. 数字证书的申请与生成

现在来说一说 CA 到底是怎么生成数字证书的吧。

第一步是密钥生成，假设我想向 CA 申请一个数字证书，那么当然要先把自己的私钥-公钥对生成好。

第二步是注册，我需要把我的公钥和有关我自己的各种信息发送给 CA 。证书请求的格式已经标准化，称为证书签名请求（Certificate Signing Request, CSR）。这是一个公钥加密标准（Public Key Cryptography Standards, PKCS）。CSR 也被称为 PKCS#10 。

第三步是验证，CA 收到信息后当然要验证我的信息，以保证这些信息可以接受。例如用户是一个组织，CA 可能会检查营业记录、历史文件和信用证明等。如果是个人用户，只需要一些简单的验证即可，例如电子邮箱、电话号码等。然后 CA 还要验证的是，我确实有发送过去的公钥对应的私钥，也就是验证那个公钥的有效性。这一步称为私钥的拥有证明（Proof Of Possession, POP）。具体怎么做呢，有很多办法。例如可以要求用户再发送一份被其签名的证书签名请求，这样 CA 可以尝试用公钥来验证这份被签名的请求，如果验证成功则说明用户确实有对应的私钥。或者 CA 可以用公钥直接把申请好的证书加密，然后发送给用户，这样用户只有确实有私钥才能解开这个证书。

第四步是证书生成，CA 验证完成后用程序生成 X. 509 标准的证书，并将证书发给用户，然后在自己的数据库中存储一份副本。

当然啦，上面说的这些过程是教科书式的，那在现实中一个申请者的视角会是什么样呢？例如我为了给我的网站部署 HTTPS ，必须要给我的网站申请一个数字证书，那我得选一个 CA ，然后去 CA 的网站申请，当然，这是要钱的。其实说了这么多，CA 可不是一个什么慈善机构，其也是商业公司，在帮助构建现代网络的信任体系的同时也会通过收费来平衡自己的支出，而收费的数字证书基本都在 1000 元以上每年，真是够贵的。幸好还有一些不收钱的 CA 哈哈，所以你得找那些仅存的不收钱的 CA 申请证书，登录 CA 的网站后点击对应的申请链接，然后填一些自己的信息例如姓名电话等，过几天你的证书就会申请好啦。

2.5. 验证数字证书

好了，我的数字证书申请好了，在下次别人想和我通信然后请求我的公钥的时候，我就可以直接把我的数字证书发过去。那现在又有了一个问题，别人怎么知道你的证书是有效的呢？前面说了所谓的数字证书其实也就是一个文件，那我完全可以伪造一个数字证书啊，然后里面写上该数字证书被某个权威机构签发。

当然这是做不到的，因为 CA 签发的数字证书一定被 CA 自己签名了。还记得前面讲数字证书的结构的时候，我们说每个版本的 X. 509 标准都有一个重要的信息，就是 CA 自己的签名信息吗。简单来讲，CA 成功生成数字证书后，会对除最后一个字段（CA 自己的签名）外的所有字段计算消息摘要，然后用 CA 自己的私钥将该消息摘要签名并放到最后一个字段中。

这样，当任何一个用户收到这个数字证书的时候，就可以通过这个数字签名来验证该数字证书的有效性。具体来讲，数字证书里面的 签名算法标识符 字段已经记录了 CA 签名时使用的消息摘要算法，然后用户使用同样的消息摘要算法计算一下除了最后一个字段外的所有字段的消息摘要。之后使用 CA 的公钥将最后一个字段的数字签名解开，对比一下两个消息摘要信息，如果相同就说明这个数字证书一定是该 CA 签发的。

这就又又又引出了一个问题，我怎么知道这个数字证书的签发 CA 的公钥呢？我通过数字证书知道一个普通用户或机构的公钥，那类似的，我当然也通过 CA 的数字证书来知道该 CA 的公钥。那问题又来了，CA 自己的数字证书从哪来？

2.6. 证书信任链

首先明确一个概念，世界上有很多不同的 CA ，他们构成了一个层次结构，如下图：

左上角的证书是网站自己的证书，这个证书由一个中间CA签发，即图中的 Issuer's(CA) Distinguished Name，我们的证书被这个CA的私钥签过名并一同存储在证书中。那么为了验证证书的有效性，我们就需要中间CA的公钥。所以通常网站会把这个中间CA的证书也一并发给你，即图中中间的证书。有了这个证书就可以验证网站的证书是否有效了。

更进一步，这个中间CA的证书的有效性也需要验证。可以看到这个证书是由根CA签发的。和之前一样，网站同时把这个根CA的证书也发了过来，这样就可以验证中间证书的有效性。

最后也是最关键的一步，从图中可以看到，根证书是自签名的，即这个证书被自己签发，并用自己的私钥进行了签名。所以说在验证自签名证书的有效性的时候需要使用证书自己的公钥来验证自己的数字签名。这样如何保证根证书的有效性？其实在你安装操作系统或者浏览器的时候，一些根证书会同时被安装在系统里，而你在安装操作系统和浏览器的时候就相当于默认信任了这些预安装的根证书。由于根证书处于这个证书的层级结构的顶层，所以可以想到根证书尤其是那些大家都信任的CA颁发的根证书的数量是很有限的，所以才能全部预先附带在操作系统和浏览器里。

这样，从预先安装的根证书，到中间证书，最终到网站的证书的有效性全部被验证了，从此你就可以放心的和网站进行加密通信了，这也就是证书信任链这个词的含义！

在 Win10 中，按下 Win + R 键然后运行 certmgr.msc 来查看系统已经安装的证书列表：

3. 总结

好了，必须具备的知识终于讲完了。可以看到，上边所有的这些，包括数字证书、CA、证书吊销状态等等等等技术，一起构成了我们所说的公钥基础设施 PKI ，当然还有很多没有介绍到的技术。

我们终于解决了证明我是我的这个问题，通过数字签名与数字证书，成功的构建起了架在虚拟的互联网上的信任机制。