当前位置：首页 > article >正文

HTTPS__CA证书与签名

article 2025/1/4 19:04:50

1. 数字签名

对一个数字摘要做加密，即数字签名。
签名流程：

先把一段数据通过散列函数(摘要算法) 形成散列值(数据摘要)。

接着使用签名者的私钥来加密散列值。（签名者也持有属于自己的公钥Q 和私钥 Q’'）

之后将数据和已经加密了的散列值(即签名) 拼接起来，形成数字签名的数据。
经过数字签名的数据，即可以验证原本的数据有没有被篡改：

先对原始数据使用相同的散列函数，形成散列值。

将加密后的签名，使用签名者的公钥进行解密，形成解密后的散列值。

然后进行对比，如过二者相等，则证明原始数据没有被修改过，反之被篡改。
数字签名与普通加密不同的是，即便签名过程中，数据被篡改了，连同签名被替换为中间人自己的私钥。但是用户在验证时，只认可签名者的公钥，而公钥 Q 都是内置在客户端内。而私钥 Q’’ 只有签名者拥有，也就意味着只有签名有签名的能力。

HTTPS 回归上篇文章，采用多种方案(非对称加密 + 对称加密)，最终还是无法保证安全问题，而这一切都是因为客户端无法甄别自己收到的公钥是否是合法的，因此我们就必须围绕这个问题展开去探索解决方案。

实际上，客户端向服务器发起请求后，服务器响应给客户端的内容不仅仅只有公钥，还有 “证书”。证书的诸多字段如下图所示：

而为了防止中间人篡改证书中的公钥，同时也对这份证书携带了签名，即对整份证书的明文数据先做hash散列，形成数据摘要，然后再使用签名者的私钥进行加密，最后将签名附加在证书中。
证书从哪来？谁给的？

一家企业内部产品，如果想使用 HTTPS 协议，那么其负责人需要先向CA机构申请证书，审核完毕后给申请者颁发有效期限的证书，之后将申请到的证书内置到 HTTPS 的服务端。

当客户端向服务端发起请求时，需要向客户端响应返回证书，以表请求的合法性。

流程图如下：

需要注意的是，申请认证时提交的公钥，即后续返回给客户端的公钥；而客户端收到证书后，直接从证书中提取公钥，那么只要证书是合法的，提取出来的公钥即合法；所有的浏览器(客户端)，一般都要内置可信的CA机构或者授权的子机构的公钥，方便用户根据CA机构的公钥验证数据的合法性。

在这里插入图片描述

对于这种方案，中间人同样有能力截获第一次请求响应的证书。但是 ta 无法对证书中的公钥进行篡改，因为如果篡改，客户端通过CA机构的公钥验证即可发现数据被篡改，进而终止通信，而这的本质即：用户不认可除了CA机构以外的其它公钥。而中间人也无法在篡改完证书明文后，进行二次签名，因为只有CA机构拥有签名所需的私钥。

即便中间人也去CA机构申请一份真的证书，但是证书明文中包含了域名等服务端认证信息，而域名是具有唯一性的，当用户在验证证书的同时，也可以通过观察证书记录的域名，与自己访问的域名是否一致来判断证书的真假。因此该方案同样行不通。

因此，无论是明文、签名，中间人都不具备篡改能力，也不具备替换证书的能力。