- 一 加密知識
- 1.1 單向加密
- 1.2 對稱加密
- 1.3 非對稱加密
- 二 加密知識總結
- 從一個需求開始
相信很多人，對 https 的過程弄不清楚，隻是知道 https 是安全加密的，背後的原理，過程并不清楚
筆者曾經也是對 https 的過程并不清楚，一知半解，而且最可氣的是每次面試，面試官很可能就問你這個問題
每次都答不對或者答的面試官不滿意，說來說去，還是自己沒有真正了解
其實 https 的原理過程，并沒有那麼複雜，隻是有些文章沒有說清楚，這樣的文章看多了，就迷糊了。
在了解 https 原理的過程之前，我們先來了解一下加密的知識
一 加密知識
加密按照加密方式，可以分為以下三種方式
1.1 單向加密
也叫做不可逆加密，對明文的加密産生一個密文，并不能再通過密文，解出來對應的明文
一般用于産生消息摘要，密鑰加密等，常見的單向加密有：
- MD5 : 相信這個大家都都熟悉了，一個明文，md5 以後，對應一個唯一的密文
- SHA : 其中又分為 sha192 , sha256
特點：
- 不可逆
- 輸入一樣，輸出必然相同
1.2 對稱加密
對稱加密，用一個密鑰，對明文進行加密，同理，同這把密鑰，也可以對密文進行解密
也就是說加密和解密，可以用同一個密鑰
這種加密方法就是 對稱加密
常用的對稱加密方法有：
- DES
- 3DES
- AES
特點：
- 加密方和解密使用同一密鑰
- 加密解密的速度比較快
1.3 非對稱加密
我們知道，對稱加密使用同一把密鑰，相反，非對稱加密，使用公鑰和私鑰進行加密解密
可以使用私鑰加密，公鑰進行解密，同理，也可以使用公鑰加密，私鑰進行解密
常見非對稱加密方式的有：
- RSA
- DSA
我們平時最常用的就是 RSA
特點：
- 使用兩把密鑰進行加密和解密，即公鑰和私鑰
- 公鑰加密私鑰解密，私鑰加密公鑰可以解密
- 加密或者解密，速度非常慢
- 私鑰和公鑰是成對出現的
二 加密知識總結
** 單向加密：** 不可逆，隻要輸入的内容一樣，輸出的密文一定是一樣的，有任何修改， 産生的密文都是不同的
** 對稱加密：** 加密和解密使用同一把密鑰，加密解密速度特别快
非對稱加密： 使用公鑰和私鑰進行加密和解密，公鑰加密私鑰解，私鑰加密公鑰解。加密解密的過程非常慢
所謂公鑰，就是可以公開給别人的
所謂私鑰，就是不可以公開給别人，是自己私有保留的。
注：以上内容，純粹是加密的知識，和 https 沒有任何關系。下面我們開始講解 https 的過程。我們先看一個需求
解決了這個需求，就明白了 https 的過程了。
從一個需求開始
假設有這樣一個需求：小明和小花需要通信，少男少女寫情書嘛，肯定不想讓别人看到，是以需要安全的通信。
問題一：小明如何安全的把内容傳給小花？
通過上面的加密知識的學習，我們很容易就想到，把通信的内容，給加密了就行了啊
答案是對的，把通信的内容給加密就行了。
問題二：使用哪種加密方式加密呢？
單向加密肯定不行，小花收到信，解不出來，這戀愛沒法談
對稱加密可以 ，小花隻要有密鑰，就可以把内容解出來
非對稱加密也可以 ，小明用自己的私鑰加密，小花拿到小明的公鑰，也可以把内容解出來
問題三：對稱加密，非對稱加密都可以，到底使用哪種呢？
通過上面的加密知識的學習，我們知道
對稱加密速度快，非對稱加密速度慢
那麼對于小明，小花這倆人來說，經常一聊就是幾個小時，資料是非常多的
如果使用非對稱加密，那估計得郁悶死，因為加密也慢，解密也慢，這倆人肯定不會用非對稱加密，要是我，我也不用，急死個人。
那麼答案就是，使用對稱加密方式 ，因為加密快啊，小明小花，都持有同一把密鑰，雙方互相都能解密出來對方發的信。
總結：小明和小花通信，使用對稱加密，假如密鑰是 S , 雙方都使用同一把密鑰 S 進行加密，解密
這樣小明和小花就能愉快的通信了，而且内容是加密的，加密解密的速度也很快，這很美好。
但是這樣有一個隐患，就是密鑰 S ， 在傳輸的過程中，不小心被 老王 截獲了
造成的後果就是：小明，小花以及老王，都有相同的密鑰 S 了
那麼，小明和小花之間沒有秘密可言了，他們發的信，老王都能解開看，看完再加密，再發給小花，這還得了。
那麼如何解決 密鑰S 在傳輸的過程中，被别人截獲的情況呢？
有人說，可以對稱加密方式對密鑰S 進行加密， 再傳輸，那麼此時的密鑰S1 也是有被截獲的風險啊
那就再對 S1 進行加密，再傳輸...... ， 這樣就無窮盡了。肯定是行不能的。
上面的方法肯定是不行了，現在的問題，變成了：小明如何把 密鑰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 進行加密，這個資料量很小的，而且密鑰S 安全的傳輸給對方之後
後面的通信就直接使用對稱加密了，這樣效率就高了，而非對稱加密隻是在開始協商怎麼安全傳輸密鑰S 的階段使用了，此階段完成後，就不再需要使用了。
通過上面可知：非對稱加密有這樣的特性
我隻要拿到誰的公鑰，我和誰通信，就是安全的
比如，你有一對私鑰和公鑰，我隻要拿到你的公鑰，然後用你的公鑰進行加密傳輸内容，隻有你自己能解開，因為私鑰隻有你自己有
如下：
反過來，小明用自己的私鑰加密，其它人使用小明的公鑰解密，這個過程的作用是什麼的呢？
答案是：驗證身份的。
隻要小明用自己的私鑰加密，其它人用小明的公鑰如果能解開，那麼證明這封信一定以及肯定是小明寫的
比如你需要發一個通知，但是又要確定這個通知一定是你發的，為了怕别人在中間塗改（比如古代假傳聖旨，就是沒有做好身份驗證）
你可以用你的私鑰對通知進行加密，其它人想看的話，通過下載下傳你的公鑰，進行解密，能解密出來，說明通知一定是你發的。
因為其它人如果在中間塗改，但是又沒有你的私鑰重新加密，是以是行不通的。
總結 ：通過以上的描述，我們解決了好幾個問題，經過了以下幾個過程。
- 小明和小花為了安全的通信，采用加密方式，對内容進行加密傳輸
- 對比來對比去，隻能選對稱加密這種加密方式，對内容進行加密傳輸
- 但是對稱加密的密鑰S ，傳輸過程不安全，容易被老王竊取，怎麼辦呢
- 小明想到了非對稱加密方式，于是就生成了一對私鑰公鑰，并且把公鑰給了小花
- 小花就用公鑰對密鑰S 進行加密，傳給小明
- 因為是用了小明的公鑰加密的，又因為私鑰隻有小明自己有，是以，隻有小明能解密。這個過程哪怕老王截獲了密文，也解密不了
- 這樣，小明用自己的私鑰解密出來了 密鑰S
- 此時 小明和小花就用對稱加密， 密鑰S ， 進行愉快的通信了，比如商量彩禮給多少，酒席在哪辦，蜜月在哪度
- 這樣，這個通信過程就是安全的了。
上面的過程很完美，但是道高一尺，魔高一丈啊，老王腦子靈光特别好使啊，又想出來一招
既然你倆用非對稱加密，我截取到密文也解密不了，那就換個法子。
如果小花在擷取小明的公鑰的過程，出了問題，比如小花擷取的不是小明的公鑰，而且老王的公鑰呢（此時小花還以為手裡的公鑰是小明的呢）
會發生什麼？先看一下圖（也就是所謂的中間人攻擊）
根據上圖，老王，也叫做中間人，上圖就是中間人攻擊，流程如下：
- 小花在擷取小明公鑰的過程中，被老王給掉包成了自己的公鑰，發給了小花
- 小花誤以為手裡的公鑰是小明的 (其實是老王的公鑰了)，是以就用老王的公鑰對密鑰S 進行加密，得到密文S0
- 密文S0 發給小明的過程中，被老王攔截，老王就用自己的私鑰解密，得到了密鑰S
- 老王得到密鑰S 後，自己備份一份，再把此 密鑰S，用小明的公鑰加密，得到密文S1, 發給小明
- 小明得到 密文S1 後，用自己的私鑰解密，得到 密鑰S
- 以後，小明和小花，就用對稱加密方式， 密鑰S 進行通信了
- 他倆還以為很安全，其實通信的内容早就被老王先看了一遍了。還是不安全
啊啊啊，要瘋了，為了通信安全，我們就加密，但是加密的密鑰傳輸又不安全了
為了密鑰傳輸安全，我們生産了私鑰公鑰對，把公鑰給小花，小花用公鑰對密鑰加密再傳輸
這樣就隻有小明能解密了，沒曾想，公鑰的傳輸又不安全了。
談個戀愛好難啊，老王啊，幹的都叫啥事啊。。。
出了問題，總得解決啊，現在是傳輸公鑰的過程，又不安全了
這和上面的問題 怎麼把信件内容安全的傳輸給對方？以及怎``麼把密鑰安全的傳輸給對方？`` 是類似的
現在這個問題是：怎麼把公鑰安全的傳輸給對方？
感覺進入到了死循環了，不管是把 信件内容安全傳輸，還是把密鑰安全傳輸，還是把 公鑰安全安全傳輸
本質都是類似的，隻不過傳輸的東西不一樣，采用的方法不一樣
問題五：小明如何安全的把自己的公鑰傳輸給小花
經過上面我們解決的問題可以知道
- 如何安全的把通信内容傳輸給對方？解決方法：我們用對稱加密的方式進行通信
- 如何安全的把密鑰S 安全的傳輸給對方 ？解決方法：采用非對稱加密方式，小明把自己的公鑰給小花小花用小明的公鑰對密鑰S 加密傳給小明，小明用自己的私鑰解密這個過程隻有小明能解密，是以是安全的
現在新的問題是：公鑰如何安全傳輸給對方 ？
難道再用對稱或者非對稱加密？都不對。這樣已經行不通了。
想象一下，生活中，我們有個沖突，有個問題，我們最相信的是誰，肯定是政府啊
現在我從小明那下載下傳公鑰已經不靠譜了，已經不安全了
到底我應該相信誰呢？到底從誰那擷取的公鑰是小明真正的公鑰呢？
是以，我們也搞一個機構，我們大家都相信這個機構，反正我就是無條件百分百相信這個機構，這是規定。
我們把這個機構起一個名字，叫做 CA 機構
好了，現在我們把問題抛給了 CA 機構，小花也好，小麗也好，小美也好，隻要擷取小明的公鑰，都從 CA 那裡擷取
CA 機構哪來的小明的公鑰呢？肯定是小明給的啊，對于小明來說，反正我已經把我的公鑰給你 CA 了，你 CA 機構就得保證安全的傳輸給别人
這 CA 也是夠倒黴的，你們搞不定的活，全抛給了我，又不是我和小花談戀愛。。。
抱怨歸抱怨，CA 是怎麼解決的呢？
答案是 數字證書 ， 怎麼又出來一個名字，數字證書是個什麼鬼，是不是已經繞暈了，不要急，這個時候暈了，再回過過頭再看看前面的寫的
多看看幾遍，别忘了，筆者也是看了 N 多遍，自己問自己問題，自己來嘗試解決，才搞明白這個過程的。
先來說一個結論：數字證書就是解決公鑰傳輸問題的
重要的事件重複三遍 ：數字證書就是解決公鑰傳輸問題的 ，數字證書就是解決公鑰傳輸問題的 ，數字證書就是解決公鑰傳輸問題的
在說數字證書之前，我們先解決這樣一個問題
問題六：信件的傳輸過程中，如何保證内容不被篡改，即資訊的完整性？
結合前面學到的加密知識，我們可以用單向加密算法，我們以 md5 加密算法舉例
- 小明給小花寫完信後，用 md5 對信件的内容作一次加密運算，得到一個唯一的字元串，我們把這個字元串起個名，叫做摘要
- 小明在信件的底部，寫上單向加密算法 md5, 以及 md5 對信件内容運算出來的摘要，一塊發給小花
- 小花收到信後，看到信件底部是 md5 算法，于是就用 md5 對信件内容進行加密算法，得到 新的摘要
- 小花将 新的摘要 和信件底部附加的 摘要 進行對比，如果相等，說明信件沒有被人改過
- 如果不相等，說明信件内容被别人改過了。
如下圖表示此過程。
但就是上面這個過程，也是有問題的，如果老王又出現了呢
- 首先老王拿到信了，把信給改了
- 老王用 md5 算法 ，重新把信件内容給 md5 一下，得到新的加密串
- 老五把新的加密串，放在信件底部，發給了小花
- 此時小花收到信後，是沒辦法判斷出來，信件是不是被篡改過的。
如下圖表示：
是以，單純的使用單向加密算法 ，生成摘要，是不能保證内容的完整性的
那麼如何才能保證信件的完整性，不被人篡改呢？
答案是，簽名
又出來一個名詞，簽名，本文的名詞太多了。
通過前面學習，我們知道，非對稱加密，有 2 個作用，其中一個就是身份認證
還是上面的例子我， 我們改一下：
- 小明用 md5 對信件内容進行運算，得到一個字元串，我們起名叫摘要
- 小明用自己的私鑰對摘要進行加密運算，得到另一個字元串，我們起名叫簽名
- 将 md5, 摘要， 簽名一塊發給小花
- 小花用小明的公鑰對簽名進行解密，到得信件摘要，假如為 d1
- 小花用 md5 對信件内容進行運算，得到信件摘要，假如為 d2
- 對比 d1 和 d2 是否相等，相等說明信件内容沒有被篡改過
- d1 和 d2 不相等，說明信件内容被篡改過。
此時，這個過程就是安全的了
如果老王再次截取了信件，老王可以修改信件内容，再次用 md5 算出一個新的摘要出來
但是簽名，老王是修改不了的。因為簽名是用的小明的私鑰加密的，就算老王能解密出來
老王是沒有辦法生成新的簽名的，因為小明的私鑰隻有小明自己有。
而且小花收到信後，是用小明的公鑰進行對簽名解密的，老王假如用自己的私鑰對摘要進行加密生成新的簽名
小花用小明的公鑰是解密不了的。
此時再來進行一時概念的定義
摘要 ：md5（或者其它單向加密算法），對内容進行加密出來的字元串，就叫做摘要
簽名 ：小明用私鑰對摘要進行加密，加密出來簽字串，就叫做簽名
驗簽 ：小花用小明的公鑰，對簽名進行解密操作，解密出來的摘要和原來的對比，就叫做驗簽
問題七：數字證書是怎麼由來的？
數字證書是由 CA 機構頒發的，首先小明如果想要有一個數字證書，就需要向 CA 機構申請
CA 機構就會給小明頒發一張數字證書，裡面包含了
- 公鑰：小明的公鑰
- 頒發者：CA（證書認證機構）
- 有效期：證書的使用期限
- 摘要算法：指定的摘要算法，用來計算證書的摘要
- 指紋：也就是證書的摘要，保證證書的完整性
- 簽名算法：用于生成簽名，確定證書是由 CA 簽發
- 序列号：證書的唯一辨別
知道了證書裡面包含的内容，我們了解一下證書是如何産生的？
- 将小明的公鑰，頒發者，有效期，摘要算法 ，雜湊演算法寫入證書
- CA 根據證書中的指定的雜湊演算法，計算出整個證書的摘要，即 digest
- CA 根據簽名算法以及上一步計算出來的摘要，CA用自己的私鑰對摘要進行加密，生成 CA 的簽名，即 signature
- 最後把摘要，簽名以及證書的基本資訊，一起釋出，就得到了小明的證書
問題八：數字證書的作用
從上面我們知道，數字證書就是解決公鑰傳輸問題的，同時我們也知道，數字證書就是一個檔案
既然數字證書是用來解決公鑰的安全傳輸的，那麼到底如何解決傳輸問題的呢
現在小明有了自己的證書了，我們就不會公開傳輸公鑰了，隻需要傳輸證書就行了
那麼，小明和小花現在需要安全的通信，那麼流程是怎麼樣的呢？如下
- 小明把自己的數字證書發送給小花
- 擔心證書被老王掉包，小花需要對證書進行驗證，驗證什麼呢？
- 其實就是驗證此數字到底是不是 CA 機構頒發的，不是 CA 機構頒發的證書，我們就認為傳輸是不安全的。
- 驗證數字證書是不是 CA 頒發的，需要有 CA的公鑰 。。。（為啥需要 CA 的公鑰啊，因為證書上的簽名，是 CA 的私鑰加密的啊，隻有 CA 的公鑰才能解密啊）啊啊啊，受不了啦，搞了半天怎麼又需要公鑰，我們講了半天的數字證書，就是為了傳輸公鑰的是以，換成下面的描述會好點驗證數字證書是不是 CA 頻發的，需要 CA 的數字證書（因為裡面有 CA 的公鑰）
- 那我們去哪裡找 CA 的數字證書呢？從上面的描述，我們知道了，需要一個數字證書，就向 CA 申請，CA 給我們頒發。
- 那麼 CA 機構自己的數字證書哪來的呢？答案是也是自己給自己頒發的，那麼我們從哪裡擷取呢？
- 如果從網上，或者從其它伺服器下載下傳，又有可能會被掉包，又不安全了。
- 這真的是個傷心的故事，但是今天兔哥非要把這個故事講完。
- 從網上下載下傳或者從其它伺服器下載下傳數字證書，都不安全的，那麼怎麼樣才是安全的呢？
- 答案就是：你的電腦安裝作業系統的時候，作業系統裡面，就已經内置了非常多的 CA 機構的數字證書了
- 也就說，隻要你安裝了作業系統，不管是 windows, linux, 或者 mac , 或者你剛買的電腦，裡面都已經有了 CA 機構的數字證書了
- 這個是可以相信的，是真的 CA 機構的數字證書，不會有假。（除非你安裝的是盜版的作業系統，是以我們盡量用正版作業系統）
上面的過程真的是複雜啊，兔哥也是花了很久才搞明白的，知道這塊面試會坑很多人，其實 https 過程不知道，也沒啥關系
也不影響你寫代碼，但是那些面試官就死愛問這塊，好像他們能搞懂這個過程很了不起似的，你問點設計模式它不香嘛。
- 我們的電腦，天生就有 CA 的數字證書，而且是真的。天生的。上天定的，上天最大那麼我們就可以對數字證書進行辨識真僞了。
問題九：對數字證書的驗證
從上面可以知道：
小花收到了小明的數字證書，首先要對數字證書進行驗證，就是驗證此數字證書是不是 CA 頒發的
因為我們作業系統裡面内置了所有 CA 機構的數字證書，是以，我們就可以對數字證書進行驗證
在說流程之前，先來簡單的複習一下前面的，摘要和簽名怎麼來的
摘要 = md5 (證書内容) ：單向加密算法，比如 md5，對證書整個内容進行加密，得到摘要，也叫做證書的指紋
簽名 = privateKey (摘要) : 私鑰對上一步摘要加密，産生簽名
數字證書的驗證流程如下：
- 小花用内置的 CA 的數字證書，得到 CA 的公鑰
- 小明發過來的數字證書，我們假如叫做 C ， 小花用 CA 的公鑰對 C 證書裡面的簽名進行解密，得到摘要 D
- 小花根據 C 證書裡面的摘要算法，假如是 md5，小花用 md5 對證書整個内容進行計算，得到摘要 D1
- 小花對比摘要 D 和摘要 D1 是否相等
- 如果 D == D1 ，那麼說明此證書就是 CA 頒發的
- 如果 D != D1 ， 那麼說明此證書不是 CA 頒發的，是有風險的，不安全的
假如證書驗證通過，就說明此證書的确是 CA 頒發的，此時小花就可以從數字證書中拿到小明的公鑰了
因為小明在申請數字證書時，數字證書中所有者是小明，CA 是會驗證小明的身份的，是以數字證書中小明的公鑰是真實的
由至此，我們總算完成了一件事：小明正确的把自己的公鑰安全的傳輸給了小花
這件事的成立 ，接下來我們的工作就好做多了。接下來，我們看一下具體的傳輸過程
問題十 ：完整的傳輸過程
下面我們看一下小明再次給小花通信，就和前面的不一樣了，我們來看下：
- 小明把寫完的信，在信的底部，附加上摘要算法，假如是 MD5， 以及通過 MD5 算出來的摘要
- 小明用自己的私鑰，對上一步的摘要進行加密，得到簽名
- 小明把摘要算法，摘要，簽名都附加到信件底部以後，再把自己的數字證書，一起發送給小花
- 小花收到信後，首先用自己的 CA 數字證書，拿到 CA 公鑰，再用 CA 公鑰對數字證書進行驗證（也就是上面我們講的流程）
- 數字證書驗證通過後，說明證書就是 CA 頒發的，沒有被篡改
- 小花就從證書中拿到了小明的公鑰
- 有了小明的公鑰，接下來的過程，就是對信件内容進行驗證了
對信件内容的驗證流程如下（前面其實我們講過）
- 小花用小明的公鑰，對信件的簽名進行解密，得到信件的摘要 D1
- 小花用摘要算法，對信件進行運算，得到信件的摘要 D2
- 小花對比 D1 是否等于 D2
- 如果不相等，說明信件被人篡改過，不安全
- 如果相等，說明，信件内容沒有被篡改過
- 相等的情況，小花就拿到了信件的内容
總結：
以上所有的内容，是數字證書，加密解密，簽名，驗簽的過程，還沒有正式講 https 的過程呢。
有了以上的知識，我們講起來 https 就容易的多了。下面我們看一張圖
我們以通路 www.helloworld.net 網站為例，講解 https 的過程
此過程分為 3 個階段，我們在下面描述此 3 個階段
通路 www.helloworld.net 的過程 階段如下
- 網站申請證書階段
- 網站向 CA 機構申請數字證書（需要送出一些材料，比如域名）
- CA 向證書中寫入摘要算法，域名，網站的公鑰等重要資訊
- CA 根據證書中寫入的摘要算法，計算出證書的摘要
- CA 用自己的私鑰對摘要進行加密，計算出簽名
- CA 生成一張數字證書，頒發給了 www.helloworld.net
- 網站的管理者，把證書放在自己的伺服器上
- 浏覽器驗證證書階段
- 浏覽器在位址欄中輸入 https://www.helloworld.net，并回車
- 伺服器将數字證書發送給浏覽器
- 浏覽器用作業系統内置的 CA 的數字證書，拿到 CA 的公鑰
- 浏覽器用 CA 公鑰對 www.helloworld.net 的數字證書進行驗簽
- 具體就是，浏覽器用 CA 公鑰，對 helloworld 的數字證書中的簽名進行解密，得到摘要 D1
- 浏覽器根據 helloworld 數字證書中的摘要算法，計算出證書的摘要 D2
- 對比 D1 和 D2 是否相等。
- 如果不相等，說明證書被掉包了
- 如果相等，說明證書驗證通過了。
- 協商對稱加密密鑰階段
- 浏覽器驗證數字證書通過以後
- 浏覽器拿到數字證書中的公鑰，也就是 www.helloworld.net 網站的公鑰
- 浏覽器有了網站的公鑰後，就用公鑰進行對密鑰S 進行加密，加密以後的密文發送給伺服器
- 伺服器收到密文後，用自己的私鑰進行解密，得到密鑰S
- 此後浏覽器，伺服器雙方就用密鑰S 進行對稱加密的通信了。
終止所述，終于講完了，花了整整一天的時間
過程那麼多，其實抓住幾個關鍵的問題是很簡單的，本質上還是兩個人，如何安全高效的進行通信
我們再次簡單的總結一下，采用一問一答的方式，我覺得比較好
問題一：小明和小花安全的通信，怎麼做？
答：通過加密
問題二：通過哪種加密方式通信，更高效？
答：對稱加密
因為，單向加密，沒辦法解密，不行
非對稱加密，太慢，也不行
隻有對稱加密，速度快
問題三：采用對稱加密，密鑰 S 怎麼安全傳輸？
答：小花使用小明的公鑰，對密鑰S 進行加密，傳給小明
小明用自己的私鑰解密
問題四：小明如何安全的把自己的公鑰傳輸給小花？
答：使用數字證書
具體就是 小明向 CA 申請一個自己的數字證書，把自己的公鑰放在證書中
小明将數字證書發送給小花
問題五：小花如何驗證數字證書的真實性？
答：小花用作業系統内置的 CA 的數字證書，拿到 CA 的公鑰，用 CA 的公鑰，對數字證書進行驗簽
驗簽通過，說明數字證書是真的。
以上幾個問題，希望讀者多問問自己，如果是自己，應該怎麼解決這個問題。