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

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

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

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

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

一 加密知識

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

1.1 單向加密

也叫做不可逆加密，對明文的加密產生一個密文，并不能再通過密文，解出來對應的明文

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

MD5 : 相信這個大家都都熟悉了，一個明文，md5 以后，對應一個唯一的密文

SHA : 其中又分為 sha192 , sha256

特點：

不可逆

輸入一樣，輸出必然相同

1.2 對稱加密

對稱加密，用一個密鑰，對明文進行加密，同理，同這把密鑰，也可以對密文進行解密

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

這種加密方法就是 對稱加密

常用的對稱加密方法有：

DES

3DES

AES

特點：

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

加密解密的速度比較快

1.3 非對稱加密

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

可以使用私鑰加密，公鑰進行解密，同理，也可以使用公鑰加密，私鑰進行解密

常見非對稱加密方式的有：

RSA

DSA

我們平時最常用的就是 RSA

特點：

使用兩把密鑰進行加密和解密，即公鑰和私鑰

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

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

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

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

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

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

二 加密知識總結

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

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

非對稱加密：使用公鑰和私鑰進行加密和解密，公鑰加密私鑰解，私鑰加密公鑰解。加密解密的過程非常慢

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

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

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

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

從一個需求開始

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

問題一：小明如何安全的把內容傳給小花？

通過上面的加密知識的學習，我們很容易就想到，把通信的內容，給加密了就行了啊

答案是對的，把通信的內容給加密就行了。

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

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

對稱加密可以，小花只要有密鑰，就可以把內容解出來

非對稱加密也可以，小明用自己的私鑰加密，小花拿到小明的公鑰，也可以把內容解出來

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

通過上面的加密知識的學習，我們知道

對稱加密速度快，非對稱加密速度慢

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

如果使用非對稱加密，那估計得郁悶死，因為加密也慢，解密也慢，這倆人肯定不會用非對稱加密，要是我，我也不用，急死個人。

那么答案就是，使用對稱加密方式，因為加密快啊，小明小花，都持有同一把密鑰，雙方互相都能解密出來對方發(fā)的信。

總結：小明和小花通信，使用對稱加密，假如密鑰是 S , 雙方都使用同一把密鑰 S 進行加密，解密

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

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

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

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

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

有人說，可以對稱加密方式對密鑰S 進行加密， 再傳輸，那么此時的密鑰S1 也是有被截獲的風險啊

那就再對 S1 進行加密，再傳輸...... ， 這樣就無窮盡了?？隙ㄊ切胁荒艿?。

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

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

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

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

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

如果這是領導交待給我們這樣一個活，我們使用自己學到的上面的加密知識，應該怎么解決呢？

通過上面的加密知識的學習，是不是有下面這樣一個安全的加密傳輸方式

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

小明把 publicKey 給了小花

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

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

上面，方法一 是不可行的，因為小明的 publicKey 是公開的，誰都可以下載，也就是說，老王也有小明的 publicKey，也可以對 S0 進行解密出來 密鑰S

方法二是可行的，因為 privateKey 只有小明有，小花用小明的公鑰進行加密，只有小明能解開，其它任何人都解不開

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

使用非對稱加密 方式，對 密鑰S 進行加密，進行傳輸

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

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

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

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

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

比如，你有一對私鑰和公鑰，我只要拿到你的公鑰，然后用你的公鑰進行加密傳輸內容，只有你自己能解開，因為私鑰只有你自己有

如下：

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

答案是：驗證身份的。

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

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

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

因為其它人如果在中間涂改，但是又沒有你的私鑰重新加密，所以是行不通的。

總結 ：通過以上的描述，我們解決了好幾個問題，經過了以下幾個過程。

小明和小花為了安全的通信，采用加密方式，對內容進行加密傳輸

對比來對比去，只能選對稱加密這種加密方式，對內容進行加密傳輸

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

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

小花就用公鑰對密鑰S 進行加密，傳給小明

因為是用了小明的公鑰加密的，又因為私鑰只有小明自己有，所以，只有小明能解密。這個過程哪怕老王截獲了密文，也解密不了

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

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

這樣，這個通信過程就是安全的了。

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

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

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

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

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

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

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

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

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

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

以后，小明和小花，就用對稱加密方式， 密鑰S 進行通信了

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

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

為了密鑰傳輸安全，我們生產了私鑰公鑰對，把公鑰給小花，小花用公鑰對密鑰加密再傳輸

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

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

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

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

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

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

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

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

經過上面我們解決的問題可以知道

如何安全的把通信內容傳輸給對方？

解決方法：我們用對稱加密的方式進行通信

如何安全的把密鑰S 安全的傳輸給對方 ？

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

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

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

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

難道再用對稱或者非對稱加密？都不對。這樣已經行不通了。

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

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

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

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

我們把這個機構起一個名字，叫做 CA 機構

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

CA 機構哪來的小明的公鑰呢？肯定是小明給的啊，對于小明來說，反正我已經把我的公鑰給你 CA 了，你 CA 機構就得保證安全的傳輸給別人

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

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

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

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

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

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

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

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

結合前面學到的加密知識，我們可以用單向加密算法，我們以 md5 加密算法舉例

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

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

小花收到信后，看到信件底部是 md5 算法，于是就用 md5 對信件內容進行加密算法，得到 新的摘要

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

如果不相等，說明信件內容被別人改過了。

如下圖表示此過程。

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

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

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

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

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

如下圖表示：

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

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

答案是，簽名

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

通過前面學習，我們知道，非對稱加密，有 2 個作用，其中一個就是身份認證

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

小明用 md5 對信件內容進行運算，得到一個字符串，我們起名叫摘要

小明用自己的私鑰對摘要進行加密運算，得到另一個字符串，我們起名叫簽名

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

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

小花用 md5 對信件內容進行運算，得到信件摘要，假如為 d2

對比 d1 和 d2 是否相等，相等說明信件內容沒有被篡改過

d1 和 d2 不相等，說明信件內容被篡改過。

此時，這個過程就是安全的了

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

但是簽名，老王是修改不了的。因為簽名是用的小明的私鑰加密的，就算老王能解密出來

老王是沒有辦法生成新的簽名的，因為小明的私鑰只有小明自己有。

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

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

此時再來進行一時概念的定義

摘要：md5（或者其它單向加密算法），對內容進行加密出來的字符串，就叫做摘要

簽名：小明用私鑰對摘要進行加密，加密出來簽字串，就叫做簽名

驗簽：小花用小明的公鑰，對簽名進行解密操作，解密出來的摘要和原來的對比，就叫做驗簽

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

數(shù)字證書是由 CA 機構頒發(fā)的，首先小明如果想要有一個數(shù)字證書，就需要向 CA 機構申請

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

公鑰：小明的公鑰

頒發(fā)者：CA（證書認證機構）

有效期：證書的使用期限

摘要算法：指定的摘要算法，用來計算證書的摘要

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

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

序列號：證書的唯一標識

知道了證書里面包含的內容，我們了解一下證書是如何產生的？

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

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

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

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

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

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

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

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

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

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

擔心證書被老王掉包，小花需要對證書進行驗證，驗證什么呢？

其實就是驗證此數(shù)字到底是不是 CA 機構頒發(fā)的，不是 CA 機構頒發(fā)的證書，我們就認為傳輸是不安全的。

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

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

所以，換成下面的描述會好點

驗證數(shù)字證書是不是 CA 頻發(fā)的，需要 CA 的數(shù)字證書（因為里面有 CA 的公鑰）

那我們去哪里找 CA 的數(shù)字證書呢？從上面的描述，我們知道了，需要一個數(shù)字證書，就向 CA 申請，CA 給我們頒發(fā)。

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

如果從網上，或者從其它服務器下載，又有可能會被掉包，又不安全了。

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

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

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

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

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

上面的過程真的是復雜啊，兔哥也是花了很久才搞明白的，知道這塊面試會坑很多人，其實 https 過程不知道，也沒啥關系

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

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

寫文章不容易，尤其是寫這篇文章，為了寫的更容易懂點，花了不少精力，能看到這塊的，幫忙給個關注吧

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

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

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

問題九：對數(shù)字證書的驗證

從上面可以知道：

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

因為我們操作系統(tǒng)里面內置了所有 CA 機構的數(shù)字證書，所以，我們就可以對數(shù)字證書進行驗證

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

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

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

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

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

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

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

小花對比摘要 D 和摘要 D1 是否相等

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

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

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

因為小明在申請數(shù)字證書時，數(shù)字證書中所有者是小明，CA 是會驗證小明的身份的，所以數(shù)字證書中小明的公鑰是真實的

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

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

問題十 ：完整的傳輸過程

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

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

小明用自己的私鑰，對上一步的摘要進行加密，得到簽名

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

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

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

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

有了小明的公鑰，接下來的過程，就是對信件內容進行驗證了

對信件內容的驗證流程如下（前面其實我們講過）

小花用小明的公鑰，對信件的簽名進行解密，得到信件的摘要 D1

小花用摘要算法，對信件進行運算，得到信件的摘要 D2

小花對比 D1 是否等于 D2

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

如果相等，說明，信件內容沒有被篡改過

相等的情況，小花就拿到了信件的內容

總結：

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

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

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

此過程分為 3 個階段，我們在下面描述此 3 個階段

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

網站申請證書階段

網站向 CA 機構申請數(shù)字證書（需要提交一些材料，比如域名）

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

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

CA 用自己的私鑰對摘要進行加密，計算出簽名

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

網站的管理員，把證書放在自己的服務器上

瀏覽器驗證證書階段

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

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

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

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

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

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

對比 D1 和 D2 是否相等。

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

如果相等，說明證書驗證通過了。

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

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

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

瀏覽器有了網站的公鑰后，就用公鑰進行對密鑰S 進行加密，加密以后的密文發(fā)送給服務器

服務器收到密文后，用自己的私鑰進行解密，得到密鑰S

此后瀏覽器，服務器雙方就用密鑰S 進行對稱加密的通信了。

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

過程那么多，其實抓住幾個關鍵的問題是很簡單的，本質上還是兩個人，如何安全高效的進行通信

我們再次簡單的總結一下，采用一問一答的方式，我覺得比較好

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

答：通過加密

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

答：對稱加密

因為，單向加密，沒辦法解密，不行

非對稱加密，太慢，也不行

只有對稱加密，速度快

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

答：小花使用小明的公鑰，對密鑰S 進行加密，傳給小明

小明用自己的私鑰解密

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

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

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

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

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

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

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

以上幾個問題，希望讀者多問問自己，如果是自己，應該怎么解決這個問題。

審核編輯 ：李倩