HTTPS終于搞懂了！

相信很多人，對(duì) https 的過程弄不清楚，只是知道 https 是安全加密的，背后的原理，過程并不清楚

筆者曾經(jīng)也是對(duì) https 的過程并不清楚，一知半解，而且最可氣的是每次面試，面試官很可能就問你這個(gè)問題

每次都答不對(duì)或者答的面試官不滿意，說來說去，還是自己沒有真正理解

其實(shí) https 的原理過程，并沒有那么復(fù)雜，只是有些文章沒有說清楚，這樣的文章看多了，就迷糊了。

在了解 https 原理的過程之前，我們先來了解一下加密的知識(shí)

一 加密知識(shí)

加密按照加密方式，可以分為以下三種方式

1.1 單向加密

也叫做不可逆加密，對(duì)明文的加密產(chǎn)生一個(gè)密文，并不能再通過密文，解出來對(duì)應(yīng)的明文

一般用于產(chǎn)生消息摘要，密鑰加密等，常見的單向加密有：

MD5 : 相信這個(gè)大家都都熟悉了，一個(gè)明文，md5 以后，對(duì)應(yīng)一個(gè)唯一的密文

SHA : 其中又分為 sha192 , sha256

特點(diǎn)：

不可逆

輸入一樣，輸出必然相同

1.2 對(duì)稱加密

對(duì)稱加密，用一個(gè)密鑰，對(duì)明文進(jìn)行加密，同理，同這把密鑰，也可以對(duì)密文進(jìn)行解密

也就是說加密和解密，可以用同一個(gè)密鑰

這種加密方法就是 對(duì)稱加密

常用的對(duì)稱加密方法有：

DES

3DES

AES

特點(diǎn)：

加密方和解密使用同一密鑰

加密解密的速度比較快

1.3 非對(duì)稱加密

我們知道，對(duì)稱加密使用同一把密鑰，相反，非對(duì)稱加密，使用公鑰和私鑰進(jìn)行加密解密

可以使用私鑰加密，公鑰進(jìn)行解密，同理，也可以使用公鑰加密，私鑰進(jìn)行解密

常見非對(duì)稱加密方式的有：

RSA

DSA

我們平時(shí)最常用的就是 RSA

特點(diǎn)：

使用兩把密鑰進(jìn)行加密和解密，即公鑰和私鑰

公鑰加密私鑰解密，私鑰加密公鑰可以解密

加密或者解密，速度非常慢

私鑰和公鑰是成對(duì)出現(xiàn)的

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

二 加密知識(shí)總結(jié)

** 單向加密：** 不可逆，只要輸入的內(nèi)容一樣，輸出的密文一定是一樣的，有任何修改， 產(chǎn)生的密文都是不同的

** 對(duì)稱加密：** 加密和解密使用同一把密鑰，加密解密速度特別快

非對(duì)稱加密：使用公鑰和私鑰進(jìn)行加密和解密，公鑰加密私鑰解，私鑰加密公鑰解。加密解密的過程非常慢

所謂公鑰，就是可以公開給別人的

所謂私鑰，就是不可以公開給別人，是自己私有保留的。

注：以上內(nèi)容，純粹是加密的知識(shí)，和 https 沒有任何關(guān)系。下面我們開始講解 https 的過程。我們先看一個(gè)需求

解決了這個(gè)需求，就明白了 https 的過程了。

從一個(gè)需求開始

假設(shè)有這樣一個(gè)需求：小明和小花需要通信，少男少女寫情書嘛，肯定不想讓別人看到，所以需要安全的通信。

問題一：小明如何安全的把內(nèi)容傳給小花？

通過上面的加密知識(shí)的學(xué)習(xí)，我們很容易就想到，把通信的內(nèi)容，給加密了就行了啊

答案是對(duì)的，把通信的內(nèi)容給加密就行了。

問題二：使用哪種加密方式加密呢？

單向加密肯定不行，小花收到信，解不出來，這戀愛沒法談

對(duì)稱加密可以，小花只要有密鑰，就可以把內(nèi)容解出來

非對(duì)稱加密也可以，小明用自己的私鑰加密，小花拿到小明的公鑰，也可以把內(nèi)容解出來

問題三：對(duì)稱加密，非對(duì)稱加密都可以，到底使用哪種呢？

通過上面的加密知識(shí)的學(xué)習(xí)，我們知道

對(duì)稱加密速度快，非對(duì)稱加密速度慢

那么對(duì)于小明，小花這倆人來說，經(jīng)常一聊就是幾個(gè)小時(shí)，數(shù)據(jù)是非常多的

如果使用非對(duì)稱加密，那估計(jì)得郁悶死，因?yàn)榧用芤猜?，解密也慢，這倆人肯定不會(huì)用非對(duì)稱加密，要是我，我也不用，急死個(gè)人。

那么答案就是，使用對(duì)稱加密方式，因?yàn)榧用芸彀?，小明小花，都持有同一把密鑰，雙方互相都能解密出來對(duì)方發(fā)的信。

總結(jié)：小明和小花通信，使用對(duì)稱加密，假如密鑰是 S , 雙方都使用同一把密鑰 S 進(jìn)行加密，解密

這樣小明和小花就能愉快的通信了，而且內(nèi)容是加密的，加密解密的速度也很快，這很美好。

但是這樣有一個(gè)隱患，就是密鑰 S ， 在傳輸?shù)倪^程中，不小心被 老王 截獲了

造成的后果就是：小明，小花以及老王，都有相同的密鑰 S 了

那么，小明和小花之間沒有秘密可言了，他們發(fā)的信，老王都能解開看，看完再加密，再發(fā)給小花，這還得了。

那么如何解決 密鑰S 在傳輸?shù)倪^程中，被別人截獲的情況呢？

有人說，可以對(duì)稱加密方式對(duì)密鑰S 進(jìn)行加密， 再傳輸，那么此時(shí)的密鑰S1 也是有被截獲的風(fēng)險(xiǎn)啊

那就再對(duì) S1 進(jìn)行加密，再傳輸...... ， 這樣就無窮盡了?？隙ㄊ切胁荒艿摹?/p>

上面的方法肯定是不行了，現(xiàn)在的問題，變成了：小明如何把 密鑰S 安全的傳給小花， 這是不是和之前的問題一小明如何安全的把內(nèi)容傳給小花？類似

所以，小明和小花如何要安全的通信，就需要使用對(duì)稱加密 把信件內(nèi)容加密傳輸

那么就得先解決一個(gè)問題：小明如何安全的把密鑰S 傳輸給小花？

問題四：小明如何安全的把密鑰S 傳輸給小花？

如果密鑰S 的傳輸過程不安全，那么后面的通信就是不安全的，反之，如何密鑰S 能安全的傳輸給小花，那么后面的通信就是安全的。

如果這是領(lǐng)導(dǎo)交待給我們這樣一個(gè)活，我們使用自己學(xué)到的上面的加密知識(shí)，應(yīng)該怎么解決呢？

通過上面的加密知識(shí)的學(xué)習(xí)，是不是有下面這樣一個(gè)安全的加密傳輸方式

小明使用非對(duì)稱加密進(jìn)行通信，首先小明生成了自己的一對(duì)私鑰和公鑰，為了方便，分別叫做 privateKey, publicKey

小明把 publicKey 給了小花

方法一小明用自己的 privateKey，對(duì) 密鑰S 進(jìn)行加密，加密后的密文 S0 傳輸給小花，小花用 publicKey 對(duì) S0 解密出來 密鑰S

方法二小花用 publicKey 對(duì) 密鑰S 進(jìn)行加密，加密后的密文 S0 傳輸給小明，小明用 privatekey 對(duì) S0 解密出來 密鑰S

上面，方法一 是不可行的，因?yàn)樾∶鞯?publicKey 是公開的，誰都可以下載，也就是說，老王也有小明的 publicKey，也可以對(duì) S0 進(jìn)行解密出來 密鑰S

方法二是可行的，因?yàn)?privateKey 只有小明有，小花用小明的公鑰進(jìn)行加密，只有小明能解開，其它任何人都解不開

所以上面的解決方案就是：

使用非對(duì)稱加密 方式，對(duì) 密鑰S 進(jìn)行加密，進(jìn)行傳輸

有人說，不對(duì)啊，非對(duì)稱加密 性能不好，加密解密特別慢，要不剛一開始，小明，小花直接使用非對(duì)稱加密 進(jìn)行通信，不就行了嘛

說的是對(duì)的，不過我們這里只是使用非對(duì)稱加密 對(duì) 密鑰S 進(jìn)行加密，這個(gè)數(shù)據(jù)量很小的，而且密鑰S 安全的傳輸給對(duì)方之后

后面的通信就直接使用對(duì)稱加密了，這樣效率就高了，而非對(duì)稱加密只是在開始協(xié)商怎么安全傳輸密鑰S 的階段使用了，此階段完成后，就不再需要使用了。

通過上面可知：非對(duì)稱加密有這樣的特性

我只要拿到誰的公鑰，我和誰通信，就是安全的

比如，你有一對(duì)私鑰和公鑰，我只要拿到你的公鑰，然后用你的公鑰進(jìn)行加密傳輸內(nèi)容，只有你自己能解開，因?yàn)樗借€只有你自己有

如下：

反過來，小明用自己的私鑰加密，其它人使用小明的公鑰解密，這個(gè)過程的作用是什么的呢？

答案是：驗(yàn)證身份的。

只要小明用自己的私鑰加密，其它人用小明的公鑰如果能解開，那么證明這封信一定以及肯定是小明寫的

比如你需要發(fā)一個(gè)通知，但是又要確保這個(gè)通知一定是你發(fā)的，為了怕別人在中間涂改（比如古代假傳圣旨，就是沒有做好身份驗(yàn)證）

你可以用你的私鑰對(duì)通知進(jìn)行加密，其它人想看的話，通過下載你的公鑰，進(jìn)行解密，能解密出來，說明通知一定是你發(fā)的。

因?yàn)槠渌巳绻谥虚g涂改，但是又沒有你的私鑰重新加密，所以是行不通的。

總結(jié) ：通過以上的描述，我們解決了好幾個(gè)問題，經(jīng)過了以下幾個(gè)過程。

小明和小花為了安全的通信，采用加密方式，對(duì)內(nèi)容進(jìn)行加密傳輸

對(duì)比來對(duì)比去，只能選對(duì)稱加密這種加密方式，對(duì)內(nèi)容進(jìn)行加密傳輸

但是對(duì)稱加密的密鑰S ，傳輸過程不安全，容易被老王竊取，怎么辦呢

小明想到了非對(duì)稱加密方式，于是就生成了一對(duì)私鑰公鑰，并且把公鑰給了小花

小花就用公鑰對(duì)密鑰S 進(jìn)行加密，傳給小明

因?yàn)槭怯昧诵∶鞯墓€加密的，又因?yàn)樗借€只有小明自己有，所以，只有小明能解密。這個(gè)過程哪怕老王截獲了密文，也解密不了

這樣，小明用自己的私鑰解密出來了 密鑰S

此時(shí) 小明和小花就用對(duì)稱加密， 密鑰S ， 進(jìn)行愉快的通信了，比如商量彩禮給多少，酒席在哪辦，蜜月在哪度

這樣，這個(gè)通信過程就是安全的了。

上面的過程很完美，但是道高一尺，魔高一丈啊，老王腦子靈光特別好使啊，又想出來一招

既然你倆用非對(duì)稱加密，我截取到密文也解密不了，那就換個(gè)法子。

如果小花在獲取小明的公鑰的過程，出了問題，比如小花獲取的不是小明的公鑰，而且老王的公鑰呢（此時(shí)小花還以為手里的公鑰是小明的呢）

會(huì)發(fā)生什么？先看一下圖（也就是所謂的中間人攻擊）

根據(jù)上圖，老王，也叫做中間人，上圖就是中間人攻擊，流程如下：

小花在獲取小明公鑰的過程中，被老王給掉包成了自己的公鑰，發(fā)給了小花

小花誤以為手里的公鑰是小明的 (其實(shí)是老王的公鑰了)，所以就用老王的公鑰對(duì)密鑰S 進(jìn)行加密，得到密文S0

密文S0 發(fā)給小明的過程中，被老王攔截，老王就用自己的私鑰解密，得到了密鑰S

老王得到密鑰S 后，自己備份一份，再把此 密鑰S，用小明的公鑰加密，得到密文S1, 發(fā)給小明

小明得到 密文S1 后，用自己的私鑰解密，得到 密鑰S

以后，小明和小花，就用對(duì)稱加密方式， 密鑰S 進(jìn)行通信了

他倆還以為很安全，其實(shí)通信的內(nèi)容早就被老王先看了一遍了。還是不安全

啊啊啊，要瘋了，為了通信安全，我們就加密，但是加密的密鑰傳輸又不安全了

為了密鑰傳輸安全，我們生產(chǎn)了私鑰公鑰對(duì)，把公鑰給小花，小花用公鑰對(duì)密鑰加密再傳輸

這樣就只有小明能解密了，沒曾想，公鑰的傳輸又不安全了。

談個(gè)戀愛好難啊，老王啊，干的都叫啥事啊。。。

出了問題，總得解決啊，現(xiàn)在是傳輸公鑰的過程，又不安全了

這和上面的問題 怎么把信件內(nèi)容安全的傳輸給對(duì)方？以及怎``么把密鑰安全的傳輸給對(duì)方？`` 是類似的

現(xiàn)在這個(gè)問題是：怎么把公鑰安全的傳輸給對(duì)方？

感覺進(jìn)入到了死循環(huán)了，不管是把 信件內(nèi)容安全傳輸，還是把密鑰安全傳輸，還是把 公鑰安全安全傳輸

本質(zhì)都是類似的，只不過傳輸?shù)臇|西不一樣，采用的方法不一樣

問題五：小明如何安全的把自己的公鑰傳輸給小花

經(jīng)過上面我們解決的問題可以知道

如何安全的把通信內(nèi)容傳輸給對(duì)方？

解決方法：我們用對(duì)稱加密的方式進(jìn)行通信

如何安全的把密鑰S 安全的傳輸給對(duì)方 ？

解決方法：采用非對(duì)稱加密方式，小明把自己的公鑰給小花

小花用小明的公鑰對(duì)密鑰S 加密傳給小明，小明用自己的私鑰解密

這個(gè)過程只有小明能解密，所以是安全的

現(xiàn)在新的問題是：公鑰如何安全傳輸給對(duì)方 ？

難道再用對(duì)稱或者非對(duì)稱加密？都不對(duì)。這樣已經(jīng)行不通了。

想象一下，生活中，我們有個(gè)矛盾，有個(gè)問題，我們最相信的是誰，肯定是政府啊

現(xiàn)在我從小明那下載公鑰已經(jīng)不靠譜了，已經(jīng)不安全了

到底我應(yīng)該相信誰呢？到底從誰那獲取的公鑰是小明真正的公鑰呢？

所以，我們也搞一個(gè)機(jī)構(gòu)，我們大家都相信這個(gè)機(jī)構(gòu)，反正我就是無條件百分百相信這個(gè)機(jī)構(gòu)，這是規(guī)定。

我們把這個(gè)機(jī)構(gòu)起一個(gè)名字，叫做 CA 機(jī)構(gòu)

好了，現(xiàn)在我們把問題拋給了 CA 機(jī)構(gòu)，小花也好，小麗也好，小美也好，只要獲取小明的公鑰，都從 CA 那里獲取

CA 機(jī)構(gòu)哪來的小明的公鑰呢？肯定是小明給的啊，對(duì)于小明來說，反正我已經(jīng)把我的公鑰給你 CA 了，你 CA 機(jī)構(gòu)就得保證安全的傳輸給別人

這 CA 也是夠倒霉的，你們搞不定的活，全拋給了我，又不是我和小花談戀愛。。。

抱怨歸抱怨，CA 是怎么解決的呢？

答案是 數(shù)字證書 ， 怎么又出來一個(gè)名字，數(shù)字證書是個(gè)什么鬼，是不是已經(jīng)繞暈了，不要急，這個(gè)時(shí)候暈了，再回過過頭再看看前面的寫的

多看看幾遍，別忘了，筆者也是看了 N 多遍，自己問自己問題，自己來嘗試解決，才搞明白這個(gè)過程的。

先來說一個(gè)結(jié)論：數(shù)字證書就是解決公鑰傳輸問題的

重要的事件重復(fù)三遍 ：數(shù)字證書就是解決公鑰傳輸問題的，數(shù)字證書就是解決公鑰傳輸問題的，數(shù)字證書就是解決公鑰傳輸問題的

在說數(shù)字證書之前，我們先解決這樣一個(gè)問題

問題六：信件的傳輸過程中，如何保證內(nèi)容不被篡改，即信息的完整性？

結(jié)合前面學(xué)到的加密知識(shí)，我們可以用單向加密算法，我們以 md5 加密算法舉例

小明給小花寫完信后，用 md5 對(duì)信件的內(nèi)容作一次加密運(yùn)算，得到一個(gè)唯一的字符串，我們把這個(gè)字符串起個(gè)名，叫做摘要

小明在信件的底部，寫上單向加密算法 md5, 以及 md5 對(duì)信件內(nèi)容運(yùn)算出來的摘要，一塊發(fā)給小花

小花收到信后，看到信件底部是 md5 算法，于是就用 md5 對(duì)信件內(nèi)容進(jìn)行加密算法，得到 新的摘要

小花將 新的摘要 和信件底部附加的 摘要 進(jìn)行對(duì)比，如果相等，說明信件沒有被人改過

如果不相等，說明信件內(nèi)容被別人改過了。

如下圖表示此過程。

但就是上面這個(gè)過程，也是有問題的，如果老王又出現(xiàn)了呢

首先老王拿到信了，把信給改了

老王用 md5 算法 ，重新把信件內(nèi)容給 md5 一下，得到新的加密串

老五把新的加密串，放在信件底部，發(fā)給了小花

此時(shí)小花收到信后，是沒辦法判斷出來，信件是不是被篡改過的。

如下圖表示：

所以，單純的使用單向加密算法 ，生成摘要，是不能保證內(nèi)容的完整性的

那么如何才能保證信件的完整性，不被人篡改呢？

答案是，簽名

又出來一個(gè)名詞，簽名，本文的名詞太多了。

通過前面學(xué)習(xí)，我們知道，非對(duì)稱加密，有 2 個(gè)作用，其中一個(gè)就是身份認(rèn)證

還是上面的例子我， 我們改一下：

小明用 md5 對(duì)信件內(nèi)容進(jìn)行運(yùn)算，得到一個(gè)字符串，我們起名叫摘要

小明用自己的私鑰對(duì)摘要進(jìn)行加密運(yùn)算，得到另一個(gè)字符串，我們起名叫簽名

將 md5, 摘要， 簽名一塊發(fā)給小花

小花用小明的公鑰對(duì)簽名進(jìn)行解密，到得信件摘要，假如為 d1

小花用 md5 對(duì)信件內(nèi)容進(jìn)行運(yùn)算，得到信件摘要，假如為 d2

對(duì)比 d1 和 d2 是否相等，相等說明信件內(nèi)容沒有被篡改過

d1 和 d2 不相等，說明信件內(nèi)容被篡改過。

此時(shí)，這個(gè)過程就是安全的了

如果老王再次截取了信件，老王可以修改信件內(nèi)容，再次用 md5 算出一個(gè)新的摘要出來

但是簽名，老王是修改不了的。因?yàn)楹灻怯玫男∶鞯乃借€加密的，就算老王能解密出來

老王是沒有辦法生成新的簽名的，因?yàn)樾∶鞯乃借€只有小明自己有。

而且小花收到信后，是用小明的公鑰進(jìn)行對(duì)簽名解密的，老王假如用自己的私鑰對(duì)摘要進(jìn)行加密生成新的簽名

小花用小明的公鑰是解密不了的。

此時(shí)再來進(jìn)行一時(shí)概念的定義

摘要：md5（或者其它單向加密算法），對(duì)內(nèi)容進(jìn)行加密出來的字符串，就叫做摘要

簽名：小明用私鑰對(duì)摘要進(jìn)行加密，加密出來簽字串，就叫做簽名

驗(yàn)簽：小花用小明的公鑰，對(duì)簽名進(jìn)行解密操作，解密出來的摘要和原來的對(duì)比，就叫做驗(yàn)簽

問題七：數(shù)字證書是怎么由來的？

數(shù)字證書是由 CA 機(jī)構(gòu)頒發(fā)的，首先小明如果想要有一個(gè)數(shù)字證書，就需要向 CA 機(jī)構(gòu)申請(qǐng)

CA 機(jī)構(gòu)就會(huì)給小明頒發(fā)一張數(shù)字證書，里面包含了

公鑰：小明的公鑰

頒發(fā)者：CA（證書認(rèn)證機(jī)構(gòu)）

有效期：證書的使用期限

摘要算法：指定的摘要算法，用來計(jì)算證書的摘要

指紋：也就是證書的摘要，保證證書的完整性

簽名算法：用于生成簽名，確保證書是由 CA 簽發(fā)

序列號(hào)：證書的唯一標(biāo)識(shí)

知道了證書里面包含的內(nèi)容，我們了解一下證書是如何產(chǎn)生的？

將小明的公鑰，頒發(fā)者，有效期，摘要算法 ，哈希算法寫入證書

CA 根據(jù)證書中的指定的哈希算法，計(jì)算出整個(gè)證書的摘要，即 digest

CA 根據(jù)簽名算法以及上一步計(jì)算出來的摘要，CA用自己的私鑰對(duì)摘要進(jìn)行加密，生成 CA 的簽名，即 signature

最后把摘要，簽名以及證書的基本信息，一起發(fā)布，就得到了小明的證書

問題八：數(shù)字證書的作用

從上面我們知道，數(shù)字證書就是解決公鑰傳輸問題的，同時(shí)我們也知道，數(shù)字證書就是一個(gè)文件

既然數(shù)字證書是用來解決公鑰的安全傳輸?shù)?，那么到底如何解決傳輸問題的呢

現(xiàn)在小明有了自己的證書了，我們就不會(huì)公開傳輸公鑰了，只需要傳輸證書就行了

那么，小明和小花現(xiàn)在需要安全的通信，那么流程是怎么樣的呢？如下

小明把自己的數(shù)字證書發(fā)送給小花

擔(dān)心證書被老王掉包，小花需要對(duì)證書進(jìn)行驗(yàn)證，驗(yàn)證什么呢？

其實(shí)就是驗(yàn)證此數(shù)字到底是不是 CA 機(jī)構(gòu)頒發(fā)的，不是 CA 機(jī)構(gòu)頒發(fā)的證書，我們就認(rèn)為傳輸是不安全的。

驗(yàn)證數(shù)字證書是不是 CA 頒發(fā)的，需要有 CA的公鑰 。。。（為啥需要 CA 的公鑰啊，因?yàn)樽C書上的簽名，是 CA 的私鑰加密的啊，只有 CA 的公鑰才能解密?。?/p>

啊啊啊，受不了啦，搞了半天怎么又需要公鑰，我們講了半天的數(shù)字證書，就是為了傳輸公鑰的

所以，換成下面的描述會(huì)好點(diǎn)

驗(yàn)證數(shù)字證書是不是 CA 頻發(fā)的，需要 CA 的數(shù)字證書（因?yàn)槔锩嬗?CA 的公鑰）

那我們?nèi)ツ睦镎?CA 的數(shù)字證書呢？從上面的描述，我們知道了，需要一個(gè)數(shù)字證書，就向 CA 申請(qǐng)，CA 給我們頒發(fā)。

那么 CA 機(jī)構(gòu)自己的數(shù)字證書哪來的呢？答案是也是自己給自己頒發(fā)的，那么我們從哪里獲取呢？

如果從網(wǎng)上，或者從其它服務(wù)器下載，又有可能會(huì)被掉包，又不安全了。

這真的是個(gè)傷心的故事，但是今天兔哥非要把這個(gè)故事講完。

從網(wǎng)上下載或者從其它服務(wù)器下載數(shù)字證書，都不安全的，那么怎么樣才是安全的呢？

答案就是：你的電腦安裝操作系統(tǒng)的時(shí)候，操作系統(tǒng)里面，就已經(jīng)內(nèi)置了非常多的 CA 機(jī)構(gòu)的數(shù)字證書了

也就說，只要你安裝了操作系統(tǒng)，不管是 windows, linux, 或者 mac , 或者你剛買的電腦，里面都已經(jīng)有了 CA 機(jī)構(gòu)的數(shù)字證書了

這個(gè)是可以相信的，是真的 CA 機(jī)構(gòu)的數(shù)字證書，不會(huì)有假。（除非你安裝的是盜版的操作系統(tǒng)，所以我們盡量用正版操作系統(tǒng)）

上面的過程真的是復(fù)雜啊，兔哥也是花了很久才搞明白的，知道這塊面試會(huì)坑很多人，其實(shí) https 過程不知道，也沒啥關(guān)系

也不影響你寫代碼，但是那些面試官就死愛問這塊，好像他們能搞懂這個(gè)過程很了不起似的，你問點(diǎn)設(shè)計(jì)模式它不香嘛。

不過話說回來，兔哥在寫自己的HelloWorld 技術(shù)社區(qū)的時(shí)候，配置 https ，數(shù)字證書，不懂這些，還真的不好搞啊

寫文章不容易，尤其是寫這篇文章，為了寫的更容易懂點(diǎn)，花了不少精力，能看到這塊的，幫忙給個(gè)關(guān)注吧

尤其是幫忙宣傳一下兔哥的HelloWorld 技術(shù)社區(qū), 同一個(gè)世界，同一行代碼，我們的域名是：www.helloworld.net

我們的電腦，天生就有 CA 的數(shù)字證書，而且是真的。天生的。上天定的，上天最大

那么我們就可以對(duì)數(shù)字證書進(jìn)行辨別真?zhèn)瘟恕?/p>

問題九：對(duì)數(shù)字證書的驗(yàn)證

從上面可以知道：

小花收到了小明的數(shù)字證書，首先要對(duì)數(shù)字證書進(jìn)行驗(yàn)證，就是驗(yàn)證此數(shù)字證書是不是 CA 頒發(fā)的

因?yàn)槲覀儾僮飨到y(tǒng)里面內(nèi)置了所有 CA 機(jī)構(gòu)的數(shù)字證書，所以，我們就可以對(duì)數(shù)字證書進(jìn)行驗(yàn)證

在說流程之前，先來簡單的復(fù)習(xí)一下前面的，摘要和簽名怎么來的

摘要 = md5 (證書內(nèi)容) ：單向加密算法，比如 md5，對(duì)證書整個(gè)內(nèi)容進(jìn)行加密，得到摘要，也叫做證書的指紋

簽名 = privateKey (摘要) : 私鑰對(duì)上一步摘要加密，產(chǎn)生簽名

數(shù)字證書的驗(yàn)證流程如下：

小花用內(nèi)置的 CA 的數(shù)字證書，得到 CA 的公鑰

小明發(fā)過來的數(shù)字證書，我們假如叫做 C ， 小花用 CA 的公鑰對(duì) C 證書里面的簽名進(jìn)行解密，得到摘要 D

小花根據(jù) C 證書里面的摘要算法，假如是 md5，小花用 md5 對(duì)證書整個(gè)內(nèi)容進(jìn)行計(jì)算，得到摘要 D1

小花對(duì)比摘要 D 和摘要 D1 是否相等

如果 D == D1 ，那么說明此證書就是 CA 頒發(fā)的

如果 D != D1 ， 那么說明此證書不是 CA 頒發(fā)的，是有風(fēng)險(xiǎn)的，不安全的

假如證書驗(yàn)證通過，就說明此證書的確是 CA 頒發(fā)的，此時(shí)小花就可以從數(shù)字證書中拿到小明的公鑰了

因?yàn)樾∶髟谏暾?qǐng)數(shù)字證書時(shí)，數(shù)字證書中所有者是小明，CA 是會(huì)驗(yàn)證小明的身份的，所以數(shù)字證書中小明的公鑰是真實(shí)的

由至此，我們總算完成了一件事：小明正確的把自己的公鑰安全的傳輸給了小花

這件事的成立 ，接下來我們的工作就好做多了。接下來，我們看一下具體的傳輸過程

問題十 ：完整的傳輸過程

下面我們看一下小明再次給小花通信，就和前面的不一樣了，我們來看下：

小明把寫完的信，在信的底部，附加上摘要算法，假如是 MD5， 以及通過 MD5 算出來的摘要

小明用自己的私鑰，對(duì)上一步的摘要進(jìn)行加密，得到簽名

小明把摘要算法，摘要，簽名都附加到信件底部以后，再把自己的數(shù)字證書，一起發(fā)送給小花

小花收到信后，首先用自己的 CA 數(shù)字證書，拿到 CA 公鑰，再用 CA 公鑰對(duì)數(shù)字證書進(jìn)行驗(yàn)證（也就是上面我們講的流程）

數(shù)字證書驗(yàn)證通過后，說明證書就是 CA 頒發(fā)的，沒有被篡改

小花就從證書中拿到了小明的公鑰

有了小明的公鑰，接下來的過程，就是對(duì)信件內(nèi)容進(jìn)行驗(yàn)證了

對(duì)信件內(nèi)容的驗(yàn)證流程如下（前面其實(shí)我們講過）

小花用小明的公鑰，對(duì)信件的簽名進(jìn)行解密，得到信件的摘要 D1

小花用摘要算法，對(duì)信件進(jìn)行運(yùn)算，得到信件的摘要 D2

小花對(duì)比 D1 是否等于 D2

如果不相等，說明信件被人篡改過，不安全

如果相等，說明，信件內(nèi)容沒有被篡改過

相等的情況，小花就拿到了信件的內(nèi)容

總結(jié)：

以上所有的內(nèi)容，是數(shù)字證書，加密解密，簽名，驗(yàn)簽的過程，還沒有正式講 https 的過程呢。

有了以上的知識(shí)，我們講起來 https 就容易的多了。下面我們看一張圖

我們以訪問 www.helloworld.net 網(wǎng)站為例，講解 https 的過程

此過程分為 3 個(gè)階段，我們?cè)谙旅婷枋龃?3 個(gè)階段

訪問 www.helloworld.net 的過程階段如下

網(wǎng)站申請(qǐng)證書階段

網(wǎng)站向 CA 機(jī)構(gòu)申請(qǐng)數(shù)字證書（需要提交一些材料，比如域名）

CA 向證書中寫入摘要算法，域名，網(wǎng)站的公鑰等重要信息

CA 根據(jù)證書中寫入的摘要算法，計(jì)算出證書的摘要

CA 用自己的私鑰對(duì)摘要進(jìn)行加密，計(jì)算出簽名

CA 生成一張數(shù)字證書，頒發(fā)給了 www.helloworld.net

網(wǎng)站的管理員，把證書放在自己的服務(wù)器上

瀏覽器驗(yàn)證證書階段

瀏覽器在地址欄中輸入 https://www.helloworld.net，并回車

服務(wù)器將數(shù)字證書發(fā)送給瀏覽器

瀏覽器用操作系統(tǒng)內(nèi)置的 CA 的數(shù)字證書，拿到 CA 的公鑰

瀏覽器用 CA 公鑰對(duì) www.helloworld.net 的數(shù)字證書進(jìn)行驗(yàn)簽

具體就是，瀏覽器用 CA 公鑰，對(duì) helloworld 的數(shù)字證書中的簽名進(jìn)行解密，得到摘要 D1

瀏覽器根據(jù) helloworld 數(shù)字證書中的摘要算法，計(jì)算出證書的摘要 D2

對(duì)比 D1 和 D2 是否相等。

如果不相等，說明證書被掉包了

如果相等，說明證書驗(yàn)證通過了。

協(xié)商對(duì)稱加密密鑰階段

瀏覽器驗(yàn)證數(shù)字證書通過以后

瀏覽器拿到數(shù)字證書中的公鑰，也就是 www.helloworld.net 網(wǎng)站的公鑰

瀏覽器有了網(wǎng)站的公鑰后，就用公鑰進(jìn)行對(duì)密鑰S 進(jìn)行加密，加密以后的密文發(fā)送給服務(wù)器

服務(wù)器收到密文后，用自己的私鑰進(jìn)行解密，得到密鑰S

此后瀏覽器，服務(wù)器雙方就用密鑰S 進(jìn)行對(duì)稱加密的通信了。

終止所述，終于講完了，花了整整一天的時(shí)間

過程那么多，其實(shí)抓住幾個(gè)關(guān)鍵的問題是很簡單的，本質(zhì)上還是兩個(gè)人，如何安全高效的進(jìn)行通信

我們?cè)俅魏唵蔚目偨Y(jié)一下，采用一問一答的方式，我覺得比較好

問題一：小明和小花安全的通信，怎么做？

答：通過加密

問題二：通過哪種加密方式通信，更高效？

答：對(duì)稱加密

因?yàn)?，單向加密，沒辦法解密，不行

非對(duì)稱加密，太慢，也不行

只有對(duì)稱加密，速度快

問題三：采用對(duì)稱加密，密鑰 S 怎么安全傳輸？

答：小花使用小明的公鑰，對(duì)密鑰S 進(jìn)行加密，傳給小明

小明用自己的私鑰解密

問題四：小明如何安全的把自己的公鑰傳輸給小花？

答：使用數(shù)字證書

具體就是 小明向 CA 申請(qǐng)一個(gè)自己的數(shù)字證書，把自己的公鑰放在證書中

小明將數(shù)字證書發(fā)送給小花

問題五：小花如何驗(yàn)證數(shù)字證書的真實(shí)性？

答：小花用操作系統(tǒng)內(nèi)置的 CA 的數(shù)字證書，拿到 CA 的公鑰，用 CA 的公鑰，對(duì)數(shù)字證書進(jìn)行驗(yàn)簽

驗(yàn)簽通過，說明數(shù)字證書是真的。

以上幾個(gè)問題，希望讀者多問問自己，如果是自己，應(yīng)該怎么解決這個(gè)問題。

審核編輯 ：李倩