之前對HTTPS通信過程有過瞭解，HTTPS是應用HTTP協議使用SSL加密的版本，在TCP和HTTP之間增加SSL協議。通過握手階段認證雙方身份，協商對稱秘鑰對通信信息進行加密。此處只描述常用的伺服器單向驗證，大致過程簡要描述如下： 0：事先Web伺服器把自己的公鑰和Web信息提交給權威CA，CA ...
之前對HTTPS通信過程有過瞭解，HTTPS是應用HTTP協議使用SSL加密的版本，在TCP和HTTP之間增加SSL協議。通過握手階段認證雙方身份，協商對稱秘鑰對通信信息進行加密。此處只描述常用的伺服器單向驗證，大致過程簡要描述如下：
0：事先Web伺服器把自己的公鑰和Web信息提交給權威CA，CA確認後，用自己的私鑰將Web信息以及公鑰的文摘簽名，製成數字證書交給Web伺服器；
客戶端Web瀏覽器事先安裝被信任的權威CA的根證書（未簽名證書或者自簽名證書）
1：客戶端向伺服器發起連接請求，協商使用的SSL版本、非對稱加密演算法、對稱加密演算法以及摘要生成演算法，雙方達成共識
2：Web伺服器向客戶端發送自己的數字證書，客戶端用CA的根證書解密，證明Web伺服器身份真實，同時證明伺服器公鑰正確
3：客戶端用伺服器公鑰加密一個隨機數，作為通信收發數據的對稱秘鑰，發送給伺服器
4：伺服器用自己的私鑰解密，拿到對稱秘鑰，返回ACK
5：客戶端和伺服器使用對稱秘鑰開始通信
到學習MySQL的SSL連接配置時產生一個疑問，HTTPS有CA作為可信第三方，負責確認伺服器身份，而MySQL連接通信只2方，沒聽說還有個CA從中協調啊，那還怎麼SSL啊？
通過網上查資料，發現自己對SSL相關的很多概念理解不是很準確，對之前CA的驗證方式理解不對。首先明確一些概念：
公私鑰對：非對稱加密演算法，公鑰和私鑰成對出現，用公鑰加密用私鑰解密，用私鑰加密用公鑰解密
CA：證書頒發機構，通信雙方可信的第三方。自己有公私鑰對，網站想證明自己真實可信，但用戶不相信自己，只相信CA說的，於是網站提交自己的信息和公鑰給CA，CA核實網站信息和提交的公鑰，覺得靠譜，於是簽名，製成證書，交給網站成為一個資質。
簽名：別人不知道我的私鑰，但是知道我的公鑰。怎麼證明這文件是我認證的呢？我用自己的私鑰加密，別人用我的公鑰解密成功，那肯定知道是我加密的，別人幹不了。具體一點，先對文本內容計算散列值，然後對這個散列值用自己的私鑰加密。（別人對文本內容計算散列值，然後用我的私鑰解密得到的值做對比，一致證明簽名OK）
證書：包含3部分，通信方具體信息（地點、功能變數名稱、組織、擁有者等）、通信方的公鑰、權威CA的簽名。（具體信息和公鑰計算散列值，然後對這個散列值用自己的私鑰加密）
根證書：權威CA也有自己的證書（畢竟需要CA的公鑰來驗證網站證書真偽），那CA的證書誰簽名啊？畢竟沒有更高一級了，所以根證書是未簽名的或者是自簽名的，沒人給這個證書背書了，所以叫做根，是信任鏈的起點，都可以理解了。
再看MySQL的SSL連接配置，思考SSL通信過程，就可以理解為什麼需要這些文件了（此處描述SSL單向驗證模式）
MySQL伺服器端要配置3個文件：ssl-ca.pem, ssl-key.pem, ssl-cert.pem
客戶端連接時需要文件：ssl-ca.pem
ssl-ca.pem就充當了可信的第三方，CA根證書，文件里包含了CA的信息和公鑰，客戶端和伺服器都有。
1.客戶端向MySQL伺服器發起連接請求，雙方協商加密演算法、SSL版本等
2.伺服器向客戶端發來自己的證書（ssl-cert.pem的內容，CA簽名的），客戶端用ssl-ca.pem的公鑰解密，確認伺服器身份和公鑰真實。
3.客戶端產生隨機數作為對稱加密的秘鑰，用伺服器公鑰加密，發送給伺服器
4.伺服器用自己的私鑰（ssl-key.pem）解密，拿到這個隨機數，返回ACK
5.雙方用隨機數做密鑰，以對稱加密方式通信
舉一反三，其他應用層協議使用SSL通信時，也是一樣的套路了。如果有哪些地方不准確，請留言指正，感謝。
