HTTPS中的数字证书认证过程解析

RSA非对称加密的2个用途：加密和签名

加密（防窃听）

RSA非对称加密会用到一对密钥，分别称为公钥和私钥，公钥加密之后的数据可以通过私钥来进行解密，私钥加密的数据也同样可以用对应的公钥进行解密。在web数据传输过程中，由于客户端和服务器端是多对一的关系，因此可以让所有的客户端持有相同的公钥，服务器持有私钥，这样一来就能方便地实现数据的加密传输。

在网络传输过程中，一旦客户端发送的用公钥加密过的数据被第三方截获，由于第三方没有服务器上的私钥，因此无法对客户端发送的加密数据进行解密从而获得明文，这样就起到了防窃听的作用。

签名（防篡改）

由于私钥只在某一个体手中，因此可以通过这一点来进行身份识别。比如用户A和B分别有一对密钥中的私钥和公钥，现在A向B发送消息abc，可进行如下操作：A用私钥对该文本进行加密之后变成密文#￥%，并附加上原文，组合成文本#￥%:abc(冒号起分隔作用，并无其他含义，具体实现中可自行处理)一起发送，B接收到该文本之后利用公钥对密文进行解密，将得到的解密后文本与传送过来的文本abc之间进行比对，如果一切正常，那么公钥解密之后的文本就是私钥加密之前的文本abc，比对结果一致，因此可以说明这段abc文本确实是A发送过来的，因为只有A才有对文本进行签名的私钥。能得到这个结论的前提是——A所用的私钥跟B所用的公钥确实是一对。

假如在传送途中有人篡改了abc，改成aaa，由于中间人没有A所持有的私钥，因此无法对篡改之后的数据生成新的正确签名，那么B在收到数据之后用公钥进行解密，再与传送的文本进行比对的话就不会一致。或者中间人篡改了数据之后用另一私钥对篡改之后的数据进行签名，同样由于B没有中间人的私钥对应的公钥，因此比对也不会一致。记住一点：B的公钥所对应的私钥只在A的手中，因此比对一致就说明该文本来自A。

HTTPS如何保证安全？

简要说明一下，假设现在有一对密钥（公钥和私钥），如果客户端持有公钥，服务器持有该公钥对应的私钥，那么根据我们前面论述的RSA非对称加密的作用，客户端和服务器通过这一对密钥进行数据的加密传输不会有问题，即数据不会被第三方窃听。

如何保证客户端所持有的公钥就是某合法服务器声明的公钥？

即服务器端如何安全地把它的公钥下发给客户端（这里的客户端一般指的是浏览器）。如果不能保证这一点，那么客户端发送的信息就有可能存在被窃听的风险，因为客户端用此公钥加密的数据可以被其对应的私钥拥有者获取，而该私钥并不在客户端所认为的服务器上。 相当于攻击者给了客户端一个它自己的公钥，让客户端认为这个公钥是某合法服务器的公钥，于是客户端用此公钥对数据进行加密传送，攻击者将此加密数据截获并用自己的私钥进行解密。由于客户端用来加密的公钥就是攻击者给客户端的，因此攻击者能够获取解密之后的明文，从而窃取客户端的信息。

可采用一个权威机构进行证书的颁发，所谓证书就是包含了服务器声明的公钥以及组织名称等信息，这里我们只考虑最关键的公钥信息。该权威机构会对申请证书的组织进行审核，确保其身份合法，然后将服务器公钥信息发布给客户端，客户端可利用该公钥与对应的服务器进行通信。整个过程可归纳为以下几步：

1.服务器生成一对密钥，私钥自己留着，公钥交给数字证书认证机构（CA）
2.CA进行审核，并用CA自己的私钥对服务器提供的公钥进行签名（参照上文RSA签名）
3.客户端从CA获取证书（即获取服务器端公钥），从而拿到了服务器端的公钥。

如何保证客户端拿到的证书确实是权威机构（CA）颁发的证书？

要保证这一点，上面第2步中的CA用自己的私钥对服务器提供的公钥进行签名就起到了作用。为确保该证书确实是CA颁发的，因此需要用到上面论述的RSA签名防篡改的功能。客户端需要用CA的公钥对签名的证书进行验证，比对一致，说明该服务器公钥确实是CA颁发的。（不知道此时读者是否能想到CA发给客户端的证书信息不只有服务器的公钥，还有CA对此公钥进行的签名。）而CA又作为权威机构保证该公钥的确是服务器端提供的，从而可以确认该证书中的公钥确实是合法服务器端提供的。

那么问题又来了：

如何保证客户端所持有的CA公钥确实是CA的私钥所对应的公钥？

也就是说CA的公钥必须要安全地转交给客户端，这真是一个先有鸡还是先有蛋的问题。幸运的是，CA的公钥一般来说由浏览器开发商内置在浏览器的内部。于是，CA的公钥就安全地转交给了客户端（浏览器）。

也许你又要问了，万一我的浏览器就有问题呢？那我只能说：兄弟，少用盗版，实在不行，卸载重装吧。好吧，开个玩笑^_

由此可见：所谓的安全的HTTP，其实也是要建立在信任的机制上。

总结

整个过程涉及2对公私密钥对:

• 一对由服务器产生，用于加密
• 一对由CA产生，用于签名。

整个过程还涉及2个信任：

• 客户端信任CA颁发的证书中的公钥就是合法服务器的公钥
• 客户端信任浏览器内置的CA公钥就是与CA私钥对应的公钥

最后要说明的是，由于非对称加密算法的效率不高，非对称加密在HTTPS中只是用来对对称加密密钥进行协商的过程才使用，在两端协商完对称加密的密钥之后，数据的加密传输均采用对称加密的方式。

您的关注是我不断创作的动力源泉！期待认识更多的朋友，一起交流Java相关技术栈，共同进步！阅读更多技术文章，可关注我的公众号：codecrazy4j

阿斌哥的博客