1 译者总注

李守中是开源软件理念坚定的支持者，所以译本虽不是软件，但依旧仿照开源软件的协议发布:

• 无担保：本文作者不保证作品内容准确无误，亦不承担任何由于使用此文档所导致的损失。
• 自由使用：任何人都可以自由地 阅读/链接/打印 此文档，无需任何附加条件。
• 名誉权：任何人都可以自由地 转载/引用/再创作 此文档，但必须保留作者署名并注明出处。

如果读者发现作品中有错误的地方，劳请来信指出。任何提高作品质量的建议李守中都将虚心接纳。

更多文章可于 李守中的主页 在线浏览。

原文档来源：

• 下载 Easy-RSA v3.08 Release 压缩包，解压后在 doc 目录下即可获取全部项目文档。
• 根据 EasyRSA v3.08 Intro-To-PKI 文档翻译而来。

李守中在翻译 EasyRSA v3 系列文档的过程中发现，很多句子对于程序行为的描述有些模糊。

所以，李守中将不加提示地根据软件行为意译原文档中多数的句子；对于意译困难的句子，李守中会加入以 译者注 为开始标记的文本来帮助读者理解；对于意译之后依旧无法准确描述目标行为的句子，李守中将不加提示地扩充文档的内容。

有能力的读者可以从此链接 easyrsa_v3.08_doc.zip 下载英文原文与本文做对照。

---

2 （原文档开头部分）

本文档旨在简要介绍 PKI ( 公钥基础设施 ) 的工作原理。

---

3 使用的术语 ( Terminology Used )

为避免混淆，Easy-RSA 文档中将使用以下术语。为方便起见，可以用短格式代替长格式:

• PKI: Public Key Infrastructure 公钥基础设置。PKI 由用户 ( 使用PKI的人或机构 )，认证机构 ( Certification Authority, CA) ( 颁发证书的人或机构 )，仓库 ( 保存证书的数据库，但证书通常被直接放在文件系统里 ) 组成。其中，认证机构 CA 进行这几种操作: 代用户生成密钥对 ( 当然可以由用户自己生成 )，验证注册公钥的用户的身份，生成并颁发证书，作废证书。另外，验证注册公钥的用户的身份这个操作可以由注册机构 ( Registration Authority, RA ) 来完成。使用 PKI 的其目在于创造、管理、分配、使用、存储以及撤销数字证书。
• CA: Certificate Authority 认证机构。CA 会有一个自己的私钥文件和证书文件。私钥文件用来签发证书，证书文件用于下发给用户，以验证私钥签名。
• request: Certificate Sign Request, CSR, 证书签名请求文件。 译者注: 这个文件多以 .req 为拓展名，其他文档中的"证书请求文件"，"请求文件"都是指 CSR 文件。 这是要发给 CA 并让其用自己的私钥签名的文件。CSR 文件中包含了生成此文件的 Subject ( 主体 ) 的身份信息、公钥等文件，想看完整的信息可以用 ‘openssl req -text -noout -in <req_file>.req’ 来查看解析后的 CSR 信息。
• cert: Certificate 证书。证书是一个已经被签名的 Certificate Sign Request 文件。证书中包含了公钥、一些描述证书自身的信息和来自 CA 的数字签名。
• keypair: 密钥对。顾名思义，keypair 指两个文件，公钥和私钥。私钥不可公开，公钥可随意公开。通信时，私钥所有者可以用私钥解密公钥加密过的文件。在使用 Easy-RSA 的过程中，私钥文件会被单独直接存储在文件中，而公钥则被包含在 CSR 文件与从 CSR 文件签出的证书中。

---

4 认证机构 ( CA )

PKI 的核心组件是 CA ( Certificate Authority 认证机构 )，它也是 PKI 组件中对安全性最敏感的部分。CA 私钥被用于签发证书，所以 CA 私钥的安全性对保障 PKI 体系的安全至关重要。因此，非常建议将承担 CA 功能的 PKI 独立出来，单独放在一个系统上，这个系统只承载 CA 一个功能，以此来保证使用期间的安全性。不建议让承担 CA 功能的 PKI 再承担诸如生成终端证书等工作。

PKI 被初始化之后，第一个步骤就是建立 CA。根据安全需要，可以在在被锁定的帐户下、在专用系统中、甚至在完全离线的系统中进行证书管理的操作，或者使用可移动设备来提高安全性 ( 毕竟，如果系统或 PKI 不在线，就不会遭受在线入侵 )。创建 CA 的步骤在其他文档中描述。创建新 CA 时，将创建 CA 密钥对 ( 私钥和自签名的证书文件 )，以及相应的目录结构。

CA 一旦完成创建，就可以马上从其他 终端实体 接收 CSR。这些终端实体会根据传输到 CA 的 CSR 文件被签发 X.509 标准的证书， 终端实体 的类型可以是 VPN 服务端或客户端，web 或者 email 系统。CSR 文件和根据 CSR 文件签发的证书文件对安全性并不敏感，它们可以在任意的介质中被存储与传输。但出于安全考虑，CA 在收到 CSR 文件时，最好验证一下收到的 CSR 文件是否与发件人手中的 CSR 文件相同。比如，可以计算发件人和收件人手中 CSR 文件的 checksum，并以此判断收到的文件是否和源文件相同。

---

5 密钥对和证书请求 ( Keypairs and requests )

终端实体不需要完整的 CA 设置，只需要能创建私钥文件和 CSR 文件即可。私钥不会在除此终端实体之外的任何地方使用，并且永远不会离开该系统。明智的做法是使用强密码保护此私钥，因为如果私钥丢失或被盗，那么获取了私钥攻击者就可以以证书持有人的身份传输数据。

在密钥对被生成以后，CSR 文件将会被与它一同生成的私钥签名。这个 CSR 文件将会被发往 CA 并由 CA 使用 CA 的私钥对 CSR 文件签名，签名操作完成后会生成用户需要的证书文件。

译者注: 有读者问为什么要给 CSR 签名。要解释这个问题，首先得理解加密和签名的区别。加密是为了防止信息被第三方获取，而签名则是为了防止信息被篡改。

公钥加密，私钥解密，正常流程，很好理解。然而，私钥加密，公钥解密，这个操作也能完成。但是这样做的话，相当于所有拥有公钥的人都可以解密被私钥加密过的信息。此时，信息加密就变得没有意义了。但是，这个逆向操作的意义在于，因为非对称加密算法的密钥是成对存在的，用私钥加密过的信息被发出后，只有用与这个私钥对应的公钥才能正确解密被加密的信息，而私钥是不公开的。这就意味着，信息的发送方无法否认这条信息是他自己发出的。理解了这个不可否认性，下面的内容就好理解了。

公钥公开，私钥不公开的前提下。加密是指用公钥加密字符串，这个字符串只有私钥才能解密。而签名是指，计算原信息的 hash 值并用私钥加密这个值 ( 这个被加密过的 hash 值叫数字签名 )，在发送原信息时，把数字签名放在原信息的后面和原信息一同发出。接收方判断信息是否被篡改的手段是，接收方收到原信息和数字签名之后，再计算一遍原信息的 hash 值；然后用公钥解密随信息一同发来的数字签名，得到发送方计算的 hash 值；两个值如果不同，则说明数据被篡改。

现在，回到为什么要给 CSR 签名的问题。本质上也是为了防止有人冒充申请人的身份。CSR 文件如果没有被篡改过，那么用 CSR 文件中记录的公钥解密数字签名之后，会得到发送方计算出的 hash 值；接收方再计算一遍收到的信息的 hash 值；两值比对，应该相同。如果两值不同，说明 CSR 文件被人篡改过，拒绝给这个文件签名。

---

6 证书请求是如何变成证书的 ( How requests become certificates )

CA 对 CSR 文件签名后，将生成一个证书文件。在此步骤中，CA 的私钥用于对终端实体发来的 CSR 文件进行数字签名。这样一来任何信任 CA 证书的系统都可以隐式地信任新颁发的证书。然后将此签名证书发送回请求实体。签出的证书对安全性不敏感，可以通过明文传输方法发送。

---

7 验证签发的证书 ( Verifying an issued certificate )

为两个终端实体创建密钥对，向 CA 发送请求，然后收到 CA 签出证书和 CA 自己的证书的副本后，两个终端实体可以相互进行身份验证。此过程中不要求这两个实体之前直接交换过任何类型的安全信息。

在 TLS 握手的过程中，连接的每一方都会向对方显示自己的证书链。两方根据各自的 CA 证书副本检查接收到的证书的有效性。通过信任 CA 根证书，可以对与其对话的对等方进行身份验证。

一方使用自己的私钥对一些数据进行签名，然后连同自己的证书一起发给另一方；另一方使用 CA 证书中的公钥分析对方发来的证书，确认发来的证书未被修改；然后从对方的证书中获取对方的公钥，解密被私钥加密过的数据，并进行 hash 值对比。然后另一方再进行同样的操作，以此证明双方确实是证书所标识的实体。因为私钥不公开，只有私钥的持有方才能发出对应公钥可以解密的数据，所以这样可以确定双方的身份。