之前對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通信時，也是一樣的套路了。如果有哪些地方不准確，請留言指正，感謝。
