服務端與用戶端建立https通信的過程：
一、認證：用戶端第一次通路服務端時，要求服務端證明自己可被信任
1.證書：由服務端申請、第三方CA頒發的，存放在服務端的證書；
證書包含：服務端的公鑰、服務端的基本資訊（明文）、CA的資訊、簽名（對服務端公鑰、基本資訊摘要進行hash計算得到hash值，然後使用CA的秘鑰對該hash值進行加密後的密文）
2.證書作用：當用戶端通路服務端時，服務端發送證書（給用戶端檢查）證明自己已在第三方CA登記，可被信任。
參考：https://www.cnblogs.com/handsomeBoys/p/6556336.html
https://blog.csdn.net/lwwl12/article/details/80691746 CA、根證書與數字證書
https://www.cnblogs.com/fps2tao/p/10036910.html
https://segmentfault.com/a/1190000002554673
注意：
2.1 用戶端如何驗證服務端發送的證書，證明服務端可被信任
用戶端需要事先安裝第三方CA的根證書（CA中心頒發給CA中心自己的證書），該根證書下的所有證書都将被用戶端信任。
用戶端拿到服務端的證書後，讀驗證書中的相關的明文資訊，采用相同的散列函數計算得到資訊摘要，
然後利用對應 CA 的公鑰（CA根證書）解密簽名，得到服務端公鑰及其他資訊；解密得到的資訊與證書中公開的資訊對比（？），如果一緻，則可以确認證書合法（即服務端被信任 ，服務端的公鑰是其真實的公鑰）
2.2 用戶端可以要求驗證服務端，同樣，服務端也可以要求驗證用戶端 （這種情況較少，如金融服務要求驗證用戶端）
原理基本相同，用戶端有自己CA憑證，通路服務端時，發送自己CA憑證給服務端檢查。
2.3 證書可以有第三方頒發，也可以由服務端自己制作（服務端自己頒發給自己的）。
OpenSSL
二、密鑰商定（TLS握手）
1.密鑰商定：對稱加密 + 非對稱加密
得到通信加密的秘鑰。
參考：https://www.cnblogs.com/xiohao/p/9054355.html
2.開始使用商定的密鑰https加密通信
附錄： https 完整的認證+密鑰商定過程
參考：https://segmentfault.com/a/1190000002554673
假設A與B通信，A是用戶端，B是伺服器端
----------- 加密後的消息放在方括号[]裡，以突出明文消息的差別。雙方的處理動作的說明用圓括号（）括起。
A：我想和你安全的通話，我這裡的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。
這是我的證書，裡面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。
目前沒有别的可說的了。
A：（檢視證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告并斷開連接配接，這一步保證了B的公鑰的真實性）
（産生一份秘密消息，這份秘密消息處理後将用作加密密鑰，加密初始化向量（IV）和hmac的密鑰。将這份秘密消息-協定中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發給B）
注意，下面我就要用加密的辦法給你發消息了！
（将秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）
[我說完了]
B：（用自己的私鑰将ClientKeyExchange中的秘密消息解密出來，然後将秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）
注意，我也要開始用加密的辦法給你發消息了！
[我說完了]
A: [我的秘密是...]
B: [其它人不會聽到的...]