李守中是开源软件理念坚定的支持者，所以译本虽不是软件，但依旧仿照开源软件的协议发布:
如果读者发现作品中有错误的地方，劳请来信指出。任何提高作品质量的建议李守中都将虚心接纳。
下载 Easy-RSA v3.08 Release 压缩包，解压后在 doc 目录下即可获取全部项目文档。
根据 EasyRSA v3.08 Intro-To-PKI 文档翻译而来。
李守中在翻译 EasyRSA v3 系列文档的过程中发现，很多句子对于程序行为的描述有些模糊。
所以，李守中将不加提示地根据软件行为意译原文档中多数的句子；对于意译困难的句子，李守中会加入以 译者注 为开始标记的文本来帮助读者理解；对于意译之后依旧无法准确描述目标行为的句子，李守中将不加提示地扩充文档的内容。
有能力的读者可以从此链接 easyrsa_v3.08_doc.zip 下载英文原文与本文做对照。
本文档旨在简要介绍 PKI (公钥基础设施) 的工作原理。
为避免混淆，Easy-RSA 文档中将使用以下术语。为方便起见，可以用短格式代替长格式:
openssl req -text -noout -in <req_file>.req 来查看解析后的 CSR 信息。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，并以此判断收到的文件是否和源文件相同。
终端实体不需要完整的 CA 设置，只需要能创建私钥文件和 CSR 文件即可。私钥不会在除此终端实体之外的任何地方使用，并且永远不会离开该系统。明智的做法是使用强密码保护此私钥，因为如果私钥丢失或被盗，那么获取了私钥攻击者就可以以证书持有人的身份传输数据。
在密钥对被生成以后，CSR 文件将会被与它一同生成的私钥签名。这个 CSR 文件将会被发往 CA 并由 CA 使用 CA 的私钥对 CSR 文件签名，签名操作完成后会生成用户需要的证书文件。
译者注: 有读者问为什么要给 CSR 签名。要解释这个问题，首先得理解加密和签名的区别。加密是为了防止信息被第三方获取，而签名则是为了防止信息被篡改。
公钥加密，私钥解密，正常流程，很好理解。然而，私钥加密，公钥解密，这个操作也能完成。但是这样做的话，相当于所有拥有公钥的人都可以解密被私钥加密过的信息。此时，信息加密就变得没有意义了。但是，这个逆向操作的意义在于，因为非对称加密算法的密钥是成对存在的，用私钥加密过的信息被发出后，只有用与这个私钥对应的公钥才能正确解密被加密的信息，而私钥是不公开的。这就意味着，信息的发送方无法否认这条信息是他自己发出的。理解了这个不可否认性，下面的内容就好理解了。
公钥公开，私钥不公开的前提下。加密是指用公钥加密字符串，这个字符串只有私钥才能解密。而签名是指，计算原信息的 hash 值并用私钥加密这个值 (这个被加密过的 hash 值叫数字签名)，在发送原信息时，把数字签名放在原信息的后面和原信息一同发出。接收方判断信息是否被篡改的手段是，接收方收到原信息和数字签名之后，再计算一遍原信息的 hash 值；然后用公钥解密随信息一同发来的数字签名，得到发送方计算的 hash 值；两个值如果不同，则说明数据被篡改。
现在，回到为什么要给 CSR 签名的问题。本质上也是为了防止有人冒充申请人的身份。CSR 文件如果没有被篡改过，那么用 CSR 文件中记录的公钥解密数字签名之后，会得到发送方计算出的 hash 值；接收方再计算一遍收到的信息的 hash 值；两值比对，应该相同。如果两值不同，说明 CSR 文件被人篡改过，拒绝给这个文件签名。
CA 对 CSR 文件签名后，将生成一个证书文件。在此步骤中，CA 的私钥用于对终端实体发来的 CSR 文件进行数字签名。这样一来任何信任 CA 证书的系统都可以隐式地信任新颁发的证书。然后将此签名证书发送回请求实体。签出的证书对安全性不敏感，可以通过明文传输方法发送。
为两个终端实体创建密钥对，向 CA 发送请求，然后收到 CA 签出证书和 CA 自己的证书的副本后，两个终端实体可以相互进行身份验证。此过程中不要求这两个实体之前直接交换过任何类型的安全信息。
在 TLS 握手的过程中，连接的每一方都会向对方显示自己的证书链。两方根据各自的 CA 证书副本检查接收到的证书的有效性。通过信任 CA 根证书，可以对与其对话的对等方进行身份验证。
一方使用自己的私钥对一些数据进行签名，然后连同自己的证书一起发给另一方；另一方使用 CA 证书中的公钥分析对方发来的证书，确认发来的证书未被修改；然后从对方的证书中获取对方的公钥，解密被私钥加密过的数据，并进行 hash 值对比。然后另一方再进行同样的操作，以此证明双方确实是证书所标识的实体。因为私钥不公开，只有私钥的持有方才能发出对应公钥可以解密的数据，所以这样可以确定双方的身份。