問題描述
今天在思考為應用服務上傳TLS/SSL證書時候，了解到證書文件由兩種. cer和pfx， cer只是包含公鑰的證書，可以發布給公眾查看。而pfx是包含私鑰的證書，對公眾不透明。 如果需要生成pfx證書，則必須在生成/申請cer的同一台機器上安裝cer證書后，通過導出的方式導出為pfx證書。然后可以把pfx證書復制到其他機器中使用。
基於以上的情況，產生了一個疑問： 在Azure App Service為自定義域名購買的證書為pfx證書。那通過https訪問的時候，客戶端瀏覽器是如何拿到私鑰的呢？ 在查尋了HTTPS的請求流程 -- 證書的簽名和驗證過程后，明白了
關鍵點：瀏覽器會通過上傳的pfx證書中的公鑰加密一個隨機生成的密鑰，而后早服務器端通過pfx中的私鑰來解密客戶端的密鑰。
HTTPS請求流程 （證書的簽名及驗證過程）
首先我們先思考下面幾個問題：
- 客戶端如何進行簽名的？
- 簽名的驗證是在哪，服務端？客戶端？
- 如何驗證簽名？
首先我們說下使用HTTPS的作用，主要有三個：
- 驗證服務器或客戶端的身份合法
- 報文加密
- 驗證數據完整性
采用HTTPS可以有效抵御中間人攻擊、報文監聽攻擊和報文篡改攻擊。不過，針對報文監聽這種攻擊的抵御不是絕對的，HTTPS是基於TLS的HTTP，可以將HTTP請求的URL path、request header、request body等內容加密，由於轉發需要提供IP及端口信息，所以監聽者還是能夠監聽到目的IP（甚至域名）、目的端口、源IP、源端口、報文大小、通信時間等信息的。
HTTPS為了兼顧安全與效率，同時使用了對稱加密和非對稱加密。數據是被對稱加密傳輸的，對稱加密過程需要客戶端的一個密鑰，為了確保能把該密鑰安全傳輸到服務器端，采用非對稱加密對該密鑰進行加密傳輸，總的來說，對數據進行對稱加密，對稱加密所要使用的密鑰通過非對稱加密傳輸。
HTTPS在傳輸的過程中會涉及到三個密鑰：
1、服務器端的公鑰和私鑰，用來進行非對稱加密
2、客戶端生成的隨機密鑰，用來進行對稱加密
一個HTTPS請求實際上包含了兩次HTTP傳輸，可以細分為7步。
1、客戶端向服務器發起HTTPS請求，攜帶客戶端SSL/TLS信息，服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存着私鑰，將公鑰下發到客戶端。
2、客戶端收到服務器端的公鑰之后，會對公鑰進行檢查，驗證其合法性，如果發現發現公鑰有問題，那么HTTPS傳輸就無法繼續。公鑰的驗證：在設備中存儲了全球公認的知名CA的公鑰。當客戶端接收到服務器的數字證書的時候，會通過系統中內置的CA公鑰進行解密，如果解密成功說明公鑰是有效的，否則就是不受信任的證書。
3、如果公鑰合格，那么客戶端會生成一個隨機值，這個隨機值就是用於進行對稱加密的密鑰，我們將該密鑰稱之為client key，即客戶端密鑰，這樣在概念上和服務器端的密鑰容易進行區分。然后用服務器的公鑰對客戶端密鑰進行非對稱加密，這樣客戶端密鑰就變成密文了，至此，HTTPS中的第一次HTTP請求結束。
4、客戶端會發起HTTPS中的第二個HTTP請求，將加密之后的客戶端密鑰發送給服務器。
5、服務器接收到客戶端發來的密文之后，會用自己的私鑰對其進行非對稱解密，解密之后的明文就是客戶端密鑰，然后用客戶端密鑰對數據進行對稱加密，這樣數據就變成了密文。
6、然后服務器將加密后的密文發送給客戶端。
7、客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發送的數據。這樣HTTPS中的第二個HTTP請求結束，整個HTTPS傳輸完成。
原文地址：
HTTPS請求流程（證書的簽名及驗證過程）： https://blog.csdn.net/gsn1125227/article/details/98594039