安全數字證書

公鑰，私鑰：
存在於非對稱加密中
密鑰：
存在於對稱加密中

cer文件裏面保存着公鑰以及用戶的一些信息（其實就是下面說到的數字證書）
P12（pfx）文件（cer的備份，供其它人使用，因其它人沒有私鑰，全部p12中也把私鑰放裏面了）= CER文件 + 私鑰

公鑰密碼體制：
分爲三部分：
1.公鑰
2.私鑰
3.加密解密算法
加密解密過程：
加密：
加密算法+公鑰+內容(或者說明文)=密文（加密過程須要用到公鑰）
解密：
解密算法+私鑰+密文=明文（解密過程須要用到解密算法和私鑰）
公鑰加密的內容，只能由私鑰進行解密。
公鑰與算法都是公開的；
私鑰是保密的。
對稱加密算法：
加密和解密都是使用的同一個密鑰（區別於公鑰密碼體制）
密鑰須要作好保密，不能對外公開。
密鑰：
通常是一個字符串或數字，供加解密算法使用。
非對稱加密算法：
加密使用的密鑰和解密使用的密鑰是不相同的。（例如上面的公鑰密碼體制）
RSA:
RSA是一種公鑰密碼體制，公鑰公開，私鑰保密，它的加密解密算法是公開的。
公鑰加密的內容只能由私鑰解密；
私鑰加密的內容只能由公鑰解密。（這兩點可讓客戶端對服務器的真實性進行確認，如後面的例子）
RSA的這一對公鑰、私鑰均可以用來加密和解密
而且一方加密的內容能夠由而且只能由對方進行解密。
簽名和加密：
簽名：
在信息後面再加上一段內容，能夠證實信息沒有被修改過。
作法：
發送方：
對信息作一個hash計算（md5）獲得一個hash值加到信息中
把這個hash值加密後做爲一個簽名和信息一塊兒發出去。
接收方：
對信息附帶的hash值進行解密
從新計算信息的hash值，並和上面的hash值對比
若是一致，則內容沒有被修改過。（由於不相同的內容計算出來的hash值不會相同）
爲了防止別人修改信息內容同時也修改hash值讓他們匹配，所以：
hash值通常會加密後再和信息一塊兒發送。
一個加密通訊過程的演化：
假設「服務器」和「客戶」要在網絡上通訊，打算使用RSA對通訊進行加密以保證談話內容的安全，
「服務器」須要對外發布公鑰(算法不須要公佈，RSA的算法你們都知道)，本身留着私鑰。
「客戶」經過某些途徑拿到了「服務器」發佈的公鑰，客戶並不知道私鑰。
加密演化過程：
1.
正常演示：
「客戶」->「服務器」：你好
「服務器」->「客戶」：你好，我是服務器
別人冒充是「服務器」後：
「客戶」->「黑客」：你好 // 黑客在「客戶」和「服務器」之間的某個路由器上截獲「客戶」發給服務器的信息，而後本身冒充「服務器」
「黑客」->「客戶」：你好，我是服務器
所以「客戶」在接到消息後，並不能確定這個消息就是由「服務器」發出的。
解決方法：
由於只有服務器有私鑰，因此若是隻要可以確認對方有私鑰，那麼對方就是「服務器」
2.
正常演示：
「客戶」->「服務器」：你好
「服務器」->「客戶」：你好，我是服務器
「客戶」->「服務器」：向我證實你就是服務器
「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
/*
{} 表示RSA加密後的內容，[ | ]表示用什麼密鑰和算法進行加密，後面的示例中都用這種表示方式，
例如上面的 {你好，我是服務器}[私鑰|RSA] 就表示用私鑰對「你好，我是服務器」進行加密後的結果。
*/
這裏服務器是如何證實本身是服務器的呢？
1.首先這是使用RSA加密體制
2.用戶有服務器發佈的公鑰
3.服務器保留密鑰
4.服務器經過把明文與使用密鑰加密後的密文一塊兒發送給用戶
5.用戶經過使用服務器公佈的公鑰對收到的密文解密並對比收到的明文，一致則證實該服務器是持有私鑰的，而且是本身持有的公鑰對應的服務器
6.保證原理：
私鑰加密的內容只能由公鑰解密
別人冒充是「服務器」後：
「黑客」->「客戶」：你好，我是服務器
「客戶」->「黑客」：向我證實你就是服務器
「黑客」->「客戶」：你好，我是服務器 {你好，我是服務器}[？？？|RSA]
//這裏黑客沒法冒充，由於他不知道私鑰，沒法用私鑰加密某個字符串後發送給客戶去驗證。
「客戶」->「黑客」：？？？？
//因爲「黑客」沒有「服務器」的私鑰，所以它發送過去的內容，「客戶」是沒法經過服務器的公鑰解密的，所以能夠認定對方是個冒牌貨！
3.
經過2，能夠確保服務器的真實性，可是在通訊期間，內容在網絡上仍是沒法保密的（即時使用了RSA）：
正常演示：
「客戶」->「服務器」：你好
「服務器」->「客戶」：你好，我是服務器
「客戶」->「服務器」：向我證實你就是服務器
「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[公鑰|RSA]
「服務器」->「客戶」：{你的餘額是100元}[私鑰|RSA]
問題來了：
{你的餘額是100元}[私鑰]，{你的餘額是100元}這個是「服務器」用私鑰加密後的內容，
因爲公鑰是發佈出去的，全部人都知道公鑰，
除了「客戶」，其它的人也能夠用公鑰對{你的餘額是100元}[私鑰]進行解密，
所以服務器使用私鑰向客戶發送密文是沒有意義的，是沒法保密的；
並且服務器也不能用公鑰對明文加密發給客戶端，由於客戶端沒有私鑰拿到數據也解不開。
通常解決方案：
引入對稱加密
4.
正常演示：
「客戶」->「服務器」：你好
「服務器」->「客戶」：你好，我是服務器
「客戶」->「服務器」：向我證實你就是服務器
「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
「客戶」->「服務器」：{咱們後面的通訊過程，用對稱加密來進行，這裏是對稱加密算法和密鑰}[公鑰|RSA]
//藍色字體的部分是對稱加密的算法和密鑰的具體內容，客戶把它們發送給服務器。（至關於項目裏面傳給後臺的key）
「服務器」->「客戶」：{OK，收到！}[密鑰|對稱加密算法]
「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[密鑰|對稱加密算法]
「服務器」->「客戶」：{你的餘額是100元}[密鑰|對稱加密算法]
/*
「客戶」在確認了「服務器」的身份後，「客戶」本身選擇一個對稱加密算法和一個密鑰，把這個對稱加密算法和密鑰一塊兒用公鑰加密後發送給「服務器」。
注意，因爲對稱加密算法和密鑰是用公鑰加密的，就算這個加密後的內容被「黑客」截獲了，因爲沒有私鑰，「黑客」也無從知道對稱加密算法和密鑰的內容。
*/
總結：
RSA加密算法在這個通訊過程當中所起到的做用主要有兩個：
1.由於私鑰只有「服務器」擁有，所以「客戶」能夠經過判斷對方是否有私鑰來判斷對方是不是「服務器」。
2.客戶端經過RSA的掩護，安全的和服務器商量好一個對稱加密算法和密鑰來保證後面通訊過程內容的安全。
服務器如何對外發布公鑰：
有問題的作法：
a)把公鑰放到互聯網的某個地方的一個下載地址，事先給「客戶」去下載。
或
b)每次和「客戶」開始通訊時，「服務器」把公鑰發給「客戶」。

對於a：
「客戶」沒法肯定這個下載地址是否是「服務器」發佈的
對於b：
任何人均可以本身生成一對公鑰和私鑰，他只要向「客戶」發送他本身的公鑰就能夠冒充「服務器」了。示意以下：
「客戶」->「黑客」：你好
//黑客截獲「客戶」發給「服務器」的消息
「黑客」->「客戶」：你好，我是服務器，這個是個人公鑰
//黑客本身生成一對公鑰和私鑰，把公鑰發給「客戶」，本身保留私鑰
「客戶」->「黑客」：向我證實你就是服務器
「黑客」->「客戶」：你好，我是服務器 {你好，我是服務器}[黑客本身的私鑰|RSA]
//客戶收到「黑客」用私鑰加密的信息後，是能夠用「黑客」發給本身的公鑰解密的，從而會誤認爲「黑客」是「服務器」
問題根源：
你們均可以生成公鑰、私鑰對，沒法確認公鑰對究竟是誰的
若是收到「黑客」冒充「服務器」發過來的公鑰，通過某種檢查，若是可以發現這個公鑰不是「服務器」的就行了（這個是重點）
解決方案：
引入數字證書：
一個數字證書包含如下內容：
1.證書的發佈機構
2.證書的有效期
3.公鑰
4.證書全部者（Subject）
5.簽名所使用的算法
6.指紋以及指紋算法
數字證書能夠保證數字證書裏的公鑰確實是這個證書的全部者(Subject)的，
或者證書能夠用來確認對方的身份
即：
拿到一個數字證書，咱們能夠判斷出這個數字證書究竟是誰的

續上加密演化（使用數字證書）：
5.
「客戶」->「服務器」：你好
「服務器」->「客戶」：你好，我是服務器，這裏是個人數字證書
//這裏用證書代替了公鑰
「客戶」->「服務器」：向我證實你就是服務器
「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
/*
「服務器」把本身的證書發給了「客戶」，而不是發送公鑰
這和上面服務器發佈公鑰方式b有什麼區別呢？
不一樣在於：
正如上面所但願的，要是客戶能知道這個公鑰是否是服務器發佈的就行了，
「客戶」能夠根據證書校驗這個證書究竟是不是「服務器」的，
也就是能校驗這個證書的全部者是否是「服務器」，
從而確認這個證書中的公鑰的確是「服務器」的（校驗方式在下面講解）
後面的過程和之前是同樣：
「客戶」讓「服務器」證實本身的身份，
「服務器」用私鑰加密一段內容連同明文一塊兒發給「客戶」，
「客戶」把加密內容用數字證書中的公鑰解密後和明文對比，
若是一致，那麼對方就確實是「服務器」，
而後雙方協商一個對稱加密來保證通訊過程的安全。
到這裏，整個過程就完整了
*/
通信加密完整過程：
1. 「客戶」向服務端發送一個通訊請求：
「客戶」->「服務器」：你好
2. 「服務器」向客戶發送本身的數字證書。證書中有一個公鑰用來加密信息，私鑰由「服務器」持有
「服務器」->「客戶」：你好，我是服務器，這裏是個人數字證書
3.「客戶」收到「服務器」的證書後，它會去驗證這個數字證書究竟是不是「服務器」的，數字證書有沒有什麼問題，數字證書若是檢查沒有問題，就說明數字證書中的公鑰確實是「服務器」的。
（驗證方式下面講解）
4.檢查數字證書後，「客戶」會明文發送一個隨機的字符串給「服務器」，讓「服務器」用私鑰去加密，服務器把加密的結果返回給「客戶」，「客戶」用公鑰解密這個返回結果，若是解密結果與以前生成的隨機字符串一致，那說明對方確實是私鑰的持有者，或者說對方確實是「服務器」。
「客戶」->「服務器」：向我證實你就是服務器，這是一個隨機字符串
//前面的例子中爲了方便解釋，用的是「你好」等內容，實際狀況下通常是隨機生成的一個字符串。
「服務器」->「客戶」：{一個隨機字符串}[私鑰|RSA]
5. 驗證「服務器」的身份後，「客戶」生成一個對稱加密算法和密鑰，用於後面的通訊的加密和解密。這個對稱加密算法和密鑰，「客戶」會用公鑰加密後發送給「服務器」，別人截獲了也沒用，由於只有「服務器」手中有能夠解密的私鑰。這樣，後面「服務器」和「客戶」就均可以用對稱加密算法來加密和解密通訊內容了。
「客戶」->「服務器」：{咱們後面的通訊過程，用對稱加密來進行，這裏是對稱加密算法和密鑰}[公鑰|RSA]
「服務器」->「客戶」：{OK，已經收到你發來的對稱加密算法和密鑰！有什麼能夠幫到你的？}[密鑰|對稱加密算法]
「客戶」->「服務器」：{個人賬號是aaa，密碼是123，把個人餘額的信息發給我看看}[密鑰|對稱加密算法]
「服務器」->「客戶」：{你好，你的餘額是100元}[密鑰|對稱加密算法]
…… //繼續其它的通訊
強化版：
問題1：
對於步驟4來講，其實對於服務器來講是有威脅的，由於4中的字符串是未加任何處理的，黑客也能夠發送一些簡單有規律的字符串給「服務器」加密，從而尋找加密的規律，有可能威脅到私鑰的安全
解決方案：
「服務器」並非真正的加密這個字符串自己，而是把這個字符串進行一個hash計算，加密這個字符串的hash值(不加密原來的字符串)後發送給「客戶」，「客戶」收到後解密這個hash值並本身計算字符串的hash值而後進行對比是否一致，一樣也能肯定對方是不是「服務器」。
問題2：
在雙方的通訊過程當中，「黑客」能夠截獲發送的加密了的內容，雖然他沒法解密這個內容，可是他能夠搗亂，例如把信息原封不動的發送屢次，擾亂通訊過程。
解決方案：
能夠給通訊的內容加上一個序號或者一個隨機的值，若是「客戶」或者「服務器」接收到的信息中有以前出現過的序號或者隨機值，那麼說明有人在通訊過程當中重發信息內容進行搗亂，雙方會馬上中止通訊。
問題3：
在雙方的通訊過程當中，「黑客」除了簡單的重複發送截獲的消息以外，還能夠修改截獲後的密文修改後再發送，由於修改的是密文，雖然不能徹底控制消息解密後的內容，可是仍然會破壞解密後的密文。
解決方案：
在每次發送信息時，先對信息的內容進行一個hash計算得出一個hash值，將信息的內容和這個hash值一塊兒加密後發送。接收方在收到後進行解密獲得明文的內容和hash值，而後接收方再本身對收到信息內容作一次hash計算，與收到的hash值進行對比看是否匹配，
若是匹配就說明信息在傳輸過程當中沒有被修改過。
若是不匹配說明中途有人故意對加密數據進行了修改，馬上中斷通話過程後作其它處理。
證書的構成和原理：
構成的部分（大部份內容）：
1.Issuer (證書的發佈機構)
指明這個證書是哪一個公司建立的(只是建立證書，不是指證書的使用者)
2.Valid from , Valid to (證書的有效期)
過了有效期限，證書就會做廢，不能使用了。
3.Public key (公鑰)
4.Subject (主題)
這個證書是發佈給誰的，或者說證書的全部者，通常是某我的或者某個公司名稱、機構的名稱、公司網站的網址等
5.Signature algorithm (簽名所使用的算法)
這個數字證書的數字簽名所使用的加密算法，這樣就可使用證書發佈機構的證書裏面的公鑰，根據這個算法對指紋進行解密。指紋的加密結果就是數字簽名
6.Thumbprint, Thumbprint algorithm (指紋以及指紋算法)
保證證書的完整性的，也就是說確保證書沒有被修改過，
原理就是在發佈證書時，發佈者根據指紋算法(一個hash算法)計算整個證書的hash值(指紋)並和證書放在一塊兒，使用者在打開證書時，本身也根據指紋算法計算一下證書的hash值(指紋)
這個指紋會使用"SecureTrust CA"這個證書機構的私鑰用簽名算法(Signature algorithm)加密後和證書放在一塊兒，所以修改證書內容後一併修改hash值也無論用，由於沒有私鑰
（就像上面
「服務器」->「客戶」：你好，我是服務器 {你好，我是服務器}[私鑰|RSA]
這裏服務器是如何證實本身是服務器的呢？
1.首先這是使用RSA加密體制
2.用戶有服務器發佈的公鑰
3.服務器保留密鑰
4.服務器經過把明文與使用密鑰加密後的密文一塊兒發送給用戶
5.用戶經過使用服務器公佈的公鑰對收到的密文解密並對比收到的明文，一致則證實該服務器是持有私鑰的，而且是本身持有的公鑰對應的服務器
6.保證原理：
私鑰加密的內容只能由公鑰解密
這種RSA方式證實本身就是你想要的服務器同樣）
/*
爲了保證安全，在證書的發佈機構發佈證書時，證書的指紋和指紋算法，都會加密後再和證書放到一塊兒發佈，以防有人修改指紋後僞造相應的數字證書。（就像上面黑客想僞造本身就是服務器同樣）
這裏問題又來了，證書的指紋和指紋算法用什麼加密呢？他們是用證書發佈機構的私鑰進行加密的。能夠用證書發佈機構的公鑰對指紋和指紋算法解密，也就是說證書發佈機構除了給別人發佈證書外，他本身自己也有本身的證書。
證書發佈機構的證書是哪裏來的呢？？？
這個證書發佈機構的數字證書(通常由他本身生成)在咱們的操做系統剛安裝好時(例如windows xp等操做系統)，這些證書發佈機構的數字證書就已經被微軟(或者其它操做系統的開發機構)安裝在操做系統中了
（這裏能夠像上面同樣理解爲操做系統就是客戶，證書發佈機構就是服務器，操做系統裏面的證書就是服務器給客戶發送的數字證書讓客戶驗證本身就是正確的服務器，
也就是讓操做系統拿系統存在的數字證書（有公鑰）驗證這個證書發佈機構就是真實的證書發佈機構（經過拿公鑰對指紋解密對比本身計算出來的指紋是否同樣而判斷該證書真實性））
因爲操做系統中有這些機構發佈的數字證書，也就是有公鑰能夠對他們給公司生成的數字證書指紋解密驗證該證書的有效性了。
這些證書發佈機構本身持有與他本身的數字證書對應的私鑰，他會用這個私鑰加密全部他發佈的證書的指紋做爲數字簽名。
*/
如何向證書的發佈機構去申請證書：
證書發佈機構發佈證書時，把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式寫到證書裏面，
而後用一個指紋算法計算出這些數字證書內容的一個指紋，
並把指紋和指紋算法用本身的私鑰進行加密，而後和證書的內容一塊兒發佈，
同時證書發佈機構還會給一個咱們公司的私鑰給到咱們
把證書投入使用，咱們在通訊過程開始時會把證書發給對方，對方如何檢查這個證書的確是合法的而且是咱們公司的證書呢？
首先應用程序(對方通訊用的程序，例如IE、OUTLook等)讀取證書中的Issuer(發佈機構)爲"SecureTrust CA" ，
而後會在操做系統中受信任的發佈機構的證書中去找"SecureTrust CA"的證書，
若是找不到，那說明證書的發佈機構是個水貨發佈機構，證書可能有問題，程序會給出一個錯誤信息。
若是在系統中找到了"SecureTrust CA"的證書，那麼應用程序就會從證書中取出"SecureTrust CA"的公鑰，
而後對咱們"ABC Company"公司的證書裏面的指紋和指紋算法用這個公鑰進行解密，
而後使用這個指紋算法計算"ABC Company"證書的指紋，將這個計算的指紋與放在證書中的指紋對比，
若是一致，說明"ABC Company"的證書確定沒有被修改過而且證書是"SecureTrust CA" 發佈的，證書中的公鑰確定是"ABC Company"的。
對方而後就能夠放心的使用這個公鑰和咱們"ABC Company"進行通訊了。
/*這部分須要根據上下文理解清楚*/

證書發佈機構：
其實全部的公司均可以發佈證書，可是本身發佈的證書不被權威機構承認，
微軟在它的操做系統中，並不會信任咱們這個證書發佈機構，
當應用程序在檢查證書的合法信的時候，一看證書的發佈機構並非操做系統所信任的發佈機構，就會拋出錯誤信息。
也就是說windows操做系統中不會預先安裝好咱們這個證書發佈機構的證書

 

iOS對cer操做：