了解数据证书和数字签名

使用场景：客户端和服务端传输数据时，需要对数据进行加密。

示例：服务器自己创建一对公私钥（公钥加密的数据只能用对应的私钥解密，反之亦然），私钥由服务器自己保存（在在不泄露的前提下，私钥只有服务器自己有），服务器将公钥告知客户端，用于加密数据传输。

风险：服务器向客户端发送公钥时，被第三方拦截后，第三方可以知道服务器的公钥，自行创建公私钥对，然后传递给客户端使用属于第三方的公钥。 在客户端不知道公钥被替换的前提下，使用第三方的公钥对数据传输进行加密。 第三方仍然可以拦截，获取加密数据并使用自己的私钥对数据进行解密2012这是比特币私钥送人了，再对解密后的真实数据进行解密。 数据被篡改2012这是比特币私钥送人了，然后使用服务器的公钥加密数据发送给服务器。 最后，服务端收到的数据并不是客户端的真实数据，而是被篡改过的。

解决方案：添加数字证书

作用：数据证书包含2个关键点（1.加密服务器公钥 2.加密证书签名）

说明：数字证书颁发机构本身有对应的公私钥对。 没有人知道私钥，只能知道机构本身。 所有主流浏览器都支持公钥，并存储主要受信任的证书颁发机构的公钥。

证书签名：使用摘要算法对发送的内容进行摘要计算，对相应的摘要进行加密（使用CA私钥，用于后续验证证书可靠性），得到签名。

添加证书后的过程：服务端不再直接将公钥发送给客户端，而是将公钥发送给证书颁发机构。 证书颁发机构使用自己的私钥对申请证书时提供的公钥进行加密，并通过服务认证完成后，将证书发送给服务器。 当客户端请求时，服务器将申请的证书直接发送给客户端。 客户端根据其浏览器密钥中保存的证书对外公布证书，对加密后的公钥进行解密，得到服务器实际颁发的公钥。

问题：如果第三方自己生成一对公私钥，并将公钥发送给证书颁发机构生成证书，从受信任的证书颁发机构获取证书，然后替换服务器的证书发送给客户端？ 客户端仍然可以使用受信机构的公钥解密得到第三方的公钥。

说明：涉及证书的认证机制。 客户端收到证书后，不仅需要对证书加密后的服务器公钥信息进行解密（获取服务器公钥），还需要验证证书的真伪。 如果客户端收到的证书是第三方的假证书，那么在解密数字签名信息时就会出错，因为已知的CA公钥只能解密用相应CA组织的私钥加密的数字签名，没有人可以伪造它。

检查操作：

1.验证证书的真实性

浏览器获取数字证书时，首先查看颁发机构，然后查找相应颁发机构的证书，并获得颁发机构的公钥

，用这个公钥对加密后的MD5进行解密，从而得到这个证书的MD5值，称为Hash1。然后浏览器使用MD5算法对

此证书重新计算 MD5 以获得 Hash2。 然后比较Hash1和Hash2是否相等，如果相等，证明这个证书是

由发行机构发行且未被篡改。

2.验证持有人的真实性

检查证书持有者的身份。 这依赖于证书中包含的公钥。 此公钥是此证书所有者的公钥（注意，

这里指的是所有者，而不是持有者！ ),用这个公钥加密一条信息，发送给证书的持有者，如果持有者可以

如果加密后的信息被发回（可以用私钥加密，也可以明文加密，都无所谓），证明持有者有

证书对应的私钥，即持有者就是证书的拥有者。

（接收方收到用公钥加密后的信息，可以用私钥解密后发回或用私钥加密后发回）

3.验证证书所有者的名字

证书中所有者的名称是否与证书颁发机构（CA）注册的名称（Common Name）相同（对于服务器，域名是否相同）