數字證書申請過程:作業系統中本就存在機構的證書，其中有機構的公鑰，現在我生成乙個公鑰，把自己的公鑰和個人資訊用機構公鑰加密然後發給機構，然後機構用自己的私鑰解密，然後機構把我的資料用hash演算法生成乙個字串，摘取其中的部分資訊再用機構私鑰加密就成了數字簽名，把數字簽名，個人資訊，公鑰，頒發機構資訊等等組成了數字證書，然後交給我並且給我乙個我生成的公鑰對應的私鑰。(萬一給機構公鑰和資訊的途中被黑客掉包怎麼辦？檢查一下機構返回的證書的公鑰是否是自己當時給的公鑰和資訊就可以了)
https大致過程:
瀏覽器:發出請求（將客戶端所支援的ssl最高版本，以及支援的密碼組合，加密演算法以及金鑰長度等資訊傳送給伺服器)。
伺服器:把能與客戶端匹配的ssl最高版本以及最佳匹配的密碼組合資訊，伺服器端證書發給瀏覽器。
然後瀏覽器驗證證書:
瀏覽器讀取證書中的issuer(發布機構)比如為"ca" ，瀏覽器在作業系統中受信任的發布機構的證書中去找ca的證書，如果找不到，那說明證書的發布機構是個水貨發布機構，證書可能有問題，瀏覽器會給出乙個錯誤資訊。找到的話瀏覽器就從作業系統中取出ca證書的公鑰對伺服器發來的證書中的數字簽名解密生成乙個字元竄，並且瀏覽器也將伺服器發來的證書的資訊進行hash演算法生成乙個字元竄，如果兩個相同則伺服器發來的證書內容沒有被修改過，確認是伺服器的證書，但沒證明對方是伺服器，可能是黑客從擷取了伺服器的證書併發了過來。黑客不可能偽造證書，比如用黑客的公鑰和伺服器的資訊組成證書，合法機構不會頒發給他的，因為他不是伺服器。而黑客可以亂修改伺服器發來的證書內容，但是通過hash可以知道是否被修改。
然後瀏覽器驗證對方身份:
瀏覽器:生成乙個字元竄用伺服器公鑰加密後發給對方(用來證明對方是伺服器)，然後伺服器用私鑰解出這個字串，然後伺服器不直接加密收到的字串，而是加密這個字串的乙個hash值，然後發給瀏覽器。瀏覽器也計算自己發出的字元竄的hash值，並用伺服器公鑰解出伺服器發來的hash值，如果相同則對方確實是有伺服器的私鑰的，所以證明了是伺服器。其實也可以是黑客擷取到伺服器返回給瀏覽器的資訊後再發給瀏覽器但是黑客起不到什麼作用，但肯定是有發到伺服器的，因為用伺服器私鑰才能知道字元竄內容，相當於瀏覽器發給伺服器後，黑客對伺服器返回來的資料再原封不動的給瀏覽器，相當於搬運工。
驗證「伺服器」的身份後，「瀏覽器」生成乙個對稱加密演算法和金鑰，用於後面的通訊的加密和解密。這個對稱加密演算法和金鑰，「瀏覽器」會用伺服器公鑰加密後傳送給「伺服器」，別人截獲了也沒用，因為只有「伺服器」手中有可以解密的私鑰。這樣，後面「伺服器」和「客戶」就都可以用對稱加密演算法來加密和解密通訊內容了。
總體來說https過程:瀏覽器請求，伺服器發證書過來，瀏覽器驗證證書內容，瀏覽器驗證對方身份，生成對稱加密演算法。
先用公鑰加密技術通訊再用對稱加密技術通訊。
注：這裡所說的瀏覽器可以換成客戶，應用程式等。
關於金鑰和數字證書
前些天逛技術網，偶爾看到一篇國外關於金鑰的通俗易懂的詳解文章，當時對具體的細節還是有點模糊搞不清楚，so昨天惡補了一下，今天簡單整理一下自己的收穫，以備以後回顧。1.鮑勃有兩把鑰匙，一把是公鑰，另一把是私鑰。2.鮑勃把公鑰送給他的朋友們 帕蒂 道格 蘇珊 每人一把。3.蘇珊給鮑勃寫信，寫完後用鮑勃的...
HTTPS的數字證書驗證原理
網路請求方式通常分為兩種，分別是http請求和https請求，其中http的傳輸屬於明文傳輸，在傳輸的過程中容易被人擷取並且 其中的內容，而https是一種在http的基礎上加了ssl tls層 安全套接層 的安全的超文字傳輸協議，其傳輸的內容是通過加密得到的，所以說是一種安全的傳輸 說到加密演算法...
HTTPS（一） 公鑰 私鑰 數字證書
傳統的http方式在網路傳輸時，傳輸資料都是明文的，很容易出現資料被監聽和竊取的情況 另外，傳輸的資料還有可能被一些別有用心的人篡改，導致瀏覽器與伺服器之間收發的內容不一致 也就是說，使用http明文傳輸至少存在著 資料被監聽 以及 資料被篡改 這兩大風險，因此http是一種不安全的協議。既然htt...