基于 PKI 的数字证书身份认证体系

最新推荐文章于 2025-04-29 21:12:43 发布

小迪的挽钟

最新推荐文章于 2025-04-29 21:12:43 发布

阅读量999

点赞数 16

CC 4.0 BY-SA版权

文章标签：网络服务器 java 网络安全安全 linux 运维

本文链接：https://blog.csdn.net/anddddoooo/article/details/145781256

公钥基础设施（PKI）通过使用公钥技术和数字证书来提供系统信息安全服务，并负责验证数字证书持有者身份的一种体系。PKI基于非对称加密算法，其中公钥用于加密和解密数据，而私钥用于解密和签名数据。

对称加密

客户端和服务端使用同一个密钥key对数据进行加密解密，流程如下：

客户端使用密钥 key 加密数据发送给服务端。
服务端接收到加密的数据之后使用同一个密钥 key 解密成明文进行阅读。

非对称加密

服务端生成密钥对（公钥和私钥），并将公钥发给客户端，此时客户端只知道密钥对中的公钥，然后客户端使用此公钥加密一个会话密钥 Session Key 发送给服务端，服务端使用私钥解密数据成明文 Session Key。来实现后续的对称加密，具体流程如下：

客户端向服务端发送通信请求。
服务端向客户端发送密钥对中的公钥。
客户端生成会话密钥 Session Key，并将此 Session Key 进行公钥加密后发送给服务端。
服务端使用私钥解密，拿到 Session Key 之后，向客户端发送成功拿到会话密钥的响应。
客户端和服务端从此使用 Session Key 加密通信。

非对称加密的作用就是协商会话密钥Session Key。

数字签名

数字签名用于验证数据包传输过程中是否被篡改。服务端发送数据包给客户端，同时将数据包中的消息使用 hash 算法运算出散列值，然后将散列值使用私钥加密后放到数据包中，客户端接收的数据包后，使用公钥解密出散列值，然后使用相同的 hash 算法对数据包中的消息进行运算，然后将 hash 运算得到的散列值和公钥解密的散列值做比对，如果一样表明数据包没被篡改。

服务端将即将要发送数据包中的消息进行 hash 运算得到散列值，然后将此散列值进行私钥加密。
客户端接收到此加密数据包后。
- 公钥解密数据包中的加密部分得到散列值。
- hash 运算数据包中的消息得到散列值。
- 将以上得到的两个散列值做比对以验证数据包中的消息是否被篡改。

此种情况，一般用于客户端验证服务端发送的数据是否被篡改，而不能用于服务端验证客户端的数据是否被篡改，因为客户端没有私钥。

中间人攻击

中间人伪装成服务端与客户端建立会话，同时伪装成客户端与服务端建立会话，从而客户端与服务器进行通信过程中，中间人能够监控客户端与服务端之间的通信，流程如下：

客户端向服务端发送通信请求。
中间人截获客户端的请求，并将自身伪造成客户端要访问的目标服务。
中间人将截获的请求发送到服务端，服务端响应后中间人将响应信息发给客户端。

在此情况下，中间人可在此会话中任意篡改客户端发送的数据包，非对称加密和数字签名都不能防止中间人攻击，因为中间人能够伪造密钥对来与客户端通信。

数字证书

也成为“公钥证书”，用于识别公钥所有者的电子文档。在中间人攻击过程中，客户端误把中间人当作正常的服务器，是因为客户端没有校验与中间人建立会话的证书。使用数字证书可以防御中间人攻击。

证书通常包括：

可识别信息，例如证书持有者的姓名、证书的序列号及其到期日期。
公钥副本。
颁发 CA 的数字签名，用于证明真实性。

证书颁发机构 CA

创建和颁发数字证书的可信第三方组织。客户端校验目标服务器发来的证书需要证书颁发机构 CA 的介入。

从广义上讲，CA 有两种类型：

根 CA： PKI 层次结构中最值得信赖的 CA 类型。根 CA 的证书是自签名的，这意味着它是通过自己的数字签名进行身份验证的。这些 CA 构成了信任的基础，因为它们的证书用于创建、签署和向从属 CA 或直接向终端实体颁发证书。
从属 CA：由根 CA 或链中更高层的从属 CA 认证的组织。从属 CA 颁发的证书带有根 CA 的签名，因此继承了信任。链中的每个证书都负责认证下一个证书的真实性，从而从上到下创建持续可靠的信任路径。

从属 CA 继承了根 CA 的信任，因为从属 CA 证书中携带根 CA 对它的数字签名。

证书链

下图为 https 的通信流程，其实就是证书校验+非对称加密。此标题下要讲解下图中浏览器判断证书的具体过程。

直接举个例子来解释浏览器是如何验证证书的：我们访问 https://www.bilibili.com 网站，此网站会返回的证书链包含两个证书，我们查看此证书的详细内容，如下图：

证书链所含如下：

*.bilibili.com 的证书是用来证明 bilibili 服务器身份的 web 证书。
GlobalSign RSA OV SSL CA 2018 从属 CA 信任证书。

其中，*.bilibili.com 的证书是用来证明 bilibili 服务器身份的 web 证书，GlobalSign RSA OV SSL CA 2018这个证书是用来证明*.bilibili.com这个证书是有效的，那么 GlobalSign RSA OV SSL CA 2018 这个证书也需要有其他证书来证明其有效性，这样的证书存在于我们的系统中，当我们的电脑安装完成操作系统的时候，这样的证书已经初始化在了我们的操作系统中，如下图就是初始化的根 CA 证书，他们在证书链的最顶端，GlobalSign RSA OV SSL CA 2018 这个证书就是下图中存在的某个证书验证其有效性的：

综上所述：

GlobalSign Root CA 存在于我们的系统上，它验证了 GlobalSign RSA OV SSL CA 2018 这个证书的合法性。
GlobalSign RSA OV SSL CA 2018 这个证书验证了 *.bilibili.com 这个证书的合法性。
*.bilibili.com 证书用于 web 通信，此证书对应的密钥对就是客户端与服务端进行 https 非对称加密的密钥对。

证书校验

首先 *.bilibili.com 这个证书存在一个签名值，如下图：

生成此签名值所需要的私钥就是 GlobalSign RSA OV SSL CA 2018 这个证书对应的私钥，校验此签名值需要我们使用 GlobalSign RSA OV SSL CA 2018 这个证书对应的公钥，这个公钥就存在于GlobalSign RSA OV SSL CA 2018里面，如下图：

由此，使用这个公钥去验证 *.bilibili.com 证书中的签名，来对 *.bilibili.com 证书进行完整性校验，接下来使用相同的方式使用GlobalSign Root CA 证书内的公钥对 GlobalSign RSA OV SSL CA 2018 证书内的签名进行完整性校验，即可完成签名校验。

注：GlobalSign Root CA 这个证书内的签名值使用的私钥就是 GlobalSign Root CA 证书自己的私钥，具体情况如下：

*.bilibili.com 证书中的签名所使用的私钥是 GlobalSign RSA OV SSL CA 2018 证书对应的私钥。
- 因此 *.bilibili.com 证书需要使用 GlobalSign RSA OV SSL CA 2018 证书的公钥进行完整性校验。
GlobalSign RSA OV SSL CA 2018 证书中的签名所使用的私钥是 GlobalSign Root CA 证书对应的私钥。
- 因此 GlobalSign RSA OV SSL CA 2018 证书需要使用 GlobalSign Root CA 证书的公钥进行完整性校验。
GlobalSign Root CA 这个证书内的签名值使用的私钥就是 GlobalSign Root CA 这个证书自己的私钥。
- 此 GlobalSign Root CA 证书位于证书链的顶端，它存在于系统之中，不需要其他证书来对其进行校验。

下图则表示证书之间的签名关系：

由此存在于我们操作系统上的根信任证书将信任传递到 web 证书，使我们能验证 web 证书的合法性。

总结：

*.bilibili.com 证书
- 用于进行非对称加密通信的证书（此证书对应的密钥对进行非对称加密会话的建立）。
中间 CA：GlobalSign RSA OV SSL CA 2018 证书
- 此证书用于*.bilibili.com 证书的完整性校验（证书内部的公钥能够进行完整性校验）。
根 CA：GlobalSign Root CA 证书
- 此证书用于 GlobalSign RSA OV SSL CA 2018 证书的完整性校验（证书内部的公钥能够进行完整性校验）。