激动！终于把https里的弯弯绕绕搞清楚了

在刚进入网络安全这块，接触最多的就是加密算法，又分对称非对称，公私秘钥，根秘钥，加解密，证书，数字签名，随机数发生器等等。

大多时候都是一知半解的在记忆这些东西，直到深入研究了https的原理以后，有一种顿悟的感觉，终于把这些名词一次性全部理顺了。

下面我会讲把我已经融会贯通后的知识点，用最精简最通俗的语言描述https的原理，希望大家能通过这些文字，在理解了https的原理同时，也能一次性把我开始提到的那些网络安全高频词汇都能整明白。

这里涉及到三个角色，1⃣️客户端；2⃣️服务器端；3⃣️证书机构。毫无疑问，场景就是客户端需要通过https访问服务器端咯。

证书机构有一对属于自己的公私钥，服务器端也有。如何生成秘钥对的呢？是通过随机数发生器。具体通过何种算法生成，后续在其他的文章再展开。

服务器端会拿着自己的公钥到证书机构，类似做一个身份的认证。认证机构会颁发一个证书，这个证书包含重点信息：1.服务器端的名称；2.服务器的公钥；3.认证机构用自己私钥加密的电子签名；4.签名所用到的算法，比如md5等。这里的每一项在后面的握手中都要用到。

同时证书机构会将自己的公钥放到客户端，用来解开证书中被认证机构私钥加密过的电子签名。证书机构会将颁发的证书配置到服务器端。其实认证机构作为了一个信用担保人，两边设置自己独有的信息，以便后面互相的身份认证。

这样所有的条件都ready了，下面看一下客户端和服务器是如何进行握手的。

1. 客户端向服务器发送证书请求；

2.服务器端将内置的证书发送给客户端；

3.客户端拿到证书后，它需求确认这个证书的合法性。它会拿认证机构提前放在它那里的公钥解开电子签名，于是它获得了证书的电子签名；然后，它再通过证书提供的签名用到的算法md5对证书进行运算，获得了另一份电子签名（有时候也称摘要）。它会对之前用公钥解开的电子签名和自己算出的电子签名进行比较。如果是一摸一样的，那就通过验证；

4.客户端从证书中拿到附在上面的公钥（这个公钥匙服务器端提供的，最早是在申请证书时，提供给认证机构的，证书生成的时候，是附在了证书上），对自己要发送的内容进行加密；

5.客户端和服务器端就开始了缠绵！！

这里有个点非常重要：如果服务器端在向证书机构申请证书时，证书机构只用自己的私钥加密了一下服务器端的公钥生成了证书，后果会怎么样？看上去，好像是当客户端向服务器端申请证书时，客户端可以用提前放在它那里的认证机构给的公钥解开被认证机构私钥加密过的证书，拿到服务器端的公钥，就可以开始和服务器端进行通信了。但是，要知道认证机构的秘钥对是非对称的，只要是它颁发的证书，它的公钥都能解开。意味着，如果中间人也从认证机构申请到了证书，他可以从中间替换掉这个证书。于是，客户端就会拿到中间人的公钥，和中间人进行通讯，中间人会再用真的证书里的公钥进行再加密，继续转给服务器端，假装自己是客户端。所以，这就是电子签名存在的意义。因为当证书里的电子签名会被认证机构的私钥加密，这个电子签名只能被认证机构的公钥解开。如果，中间人从中作梗，直接将自己的证书给到客户端，客户端收到证书后，首先会看证书名，这个名字不是客户端请求的，就没办法通过验证。有人会说，那中间人改一下自己的证书名不就行了吗？注意，中间人这个证书也是通过专业的证书机构做过认证的。一旦改了证书里面任何内容，签名也要重新生成，中间人可以这样操作，但是等到证书到达用户端，只有认证机构用私钥加密的签名才能被用户端解开。中间人又没有认证机构私钥，中间人自己生成的签名是无法被用户端验证的。所以伪造带签名的证书是不可能的。

这里还有七个问题没被解决：

1.证书机构的公钥如何放到客户端？

2.证书机构又是如何将证书配置到服务器端？

3.在握手环节中，有三次随机数的传输，前两次没被加密，第三次是用服务器端的公钥加密了。为啥不知道进行第三次，前两次的随机数的作用是？

4.随机数是如何生成秘钥对的？

5.证书机构的公私钥是如何保证安全性的？

6.哪些服务器端可以申请自己的证书？证书机构是如何判断是否可以颁发给他们？

7.证书那么多，证书颁发机构和服务器端以及用户之间怎么进行管理的？

这些问题，在后续的文章中，我会一一解答！