从证书角度再带你深入了解一下Https

通过昨天的一篇文章，大家已经了解到Https是如何加密的了，其加密过程中有一个很关键的步骤是：服务器向浏览器发送网站公匙。下面我们将针对这一步进行详细的分析。

服务器向浏览器发送网站公匙，既然是网络传播，那么就存在公匙被黑客掉包的问题。

如果黑客拦截目标服务器网站发送的的公匙消息，向浏览器发送一个自己生成的公匙，再拦截到浏览器向服务器发送的密匙，那么就可以用自己的私匙来解密浏览器端发送过来的密匙，从而得到对称加密密匙，从而浏览器和服务器之间的通信在黑客严重就变成明文传递了。

所以由服务端直接向浏览器端发送公匙是行不通的，这里就需要引入第三方机构来帮我们传递公匙了。

我们假设有一个权威的第三方机构，我们称它为数字证书签发机构（CA），数字证书签发机构也有自己的一对非对称加密的公匙和私匙。

服务器端会把生成的公匙告诉数字证书签发机构，数字证书签发机构使用自己的私匙对服务器端的公匙进行加密，然后为服务器端生成一个数字证书，数字证书中包含刚刚生成的密匙。

这样浏览器端就可以根据数字证书签发机构的公匙来解密数字证书中的密匙，如果能够解密成功，就证明证书没有被掉包。这样浏览器端就能得到服务器端的公匙了。

这样还有一个新的问题，数字证书签发机构不会只给某个网站颁发证书，如果给某个黑客网站也颁发了一个证书，那么黑客就可以把自己网站的证书伪装成目标服务器网站的证书发送给浏览器。因为黑客网站和目标服务器网站都是同一家数字证书签发机构颁发的证书，使用同一套加密算法，所以浏览器端也能够成功解密黑客证书中的密匙，浏览器端会认为收到的证书没有被掉包。这样的话，因为浏览器端使用了黑客的公匙，所以黑客可以轻松的获取到浏览器和服务器之间通信的对称密匙。

所以数字证书签发机构再颁发证书的时候都会带上网站的基本信息，包括网站网址，有效期等，还有一个签名。

说到签名还需要引入一下摘要，摘要是证书中明文信息（除签名外所有信息）的Hash值（或者证书中约定的算法），获得摘要后，再使用数字证书签发机构的私匙加密摘要，生成签名，添加在数字证书中。

浏览器端收到证书后，会先校验证书中的网站基本信息，证书有效期、证书中网站地址是否与正在访问的地址一致等。然后将证书中的签名使用数字证书签发机构的公匙解密，与证书中的明文信息的Hash值（或者证书中约定的算法）进行对比，如果不一致，那么证书就被掉包了。

既然已经有了签名能帮我们验证证书的合法性，那么对公匙进行加密是不是就显得没有意义了呢？没错，有了签名验证，证书中的公匙就可以明文传递了。

说了这么多，基本上服务器公匙传递、证书下发、签名校验过程都说完了。可能有人还会有疑问，浏览器是怎么获取数字证书签发机构的公匙的？

答案就是浏览器本身会预装一些受信赖的机构的证书，这些证书中包含它们的公匙。

所以说大家可以看到上面我对这个机构的描述了，权威，什么叫权威，就是我们值得信赖的机构，我们所谓的安全通信都是基于这个机构的，如果这个机构出现了问题，那么所有的东西都是白搭。

最后总结一下Https加密：

通信双方使用对称加密算法

对称加密算法的密匙使用非对称加密算法传递

非对称加密算法的公匙传递借助第三方数字证书签发机构

到这里对于Https加密的分享就结束了，希望大家看完这两篇文章能有所收获。