所有的概念都基于一個非常重要的基礎：
rsa 非對稱加密算法 ：
- 在加解密上，兩個秘鑰是對等的 任何一個可以加密，另一個可以用來解密。
- 用openssl創建一個秘鑰，然后可用該秘鑰可以生成另一個秘鑰。 但是反過來不可以。所以創建的秘鑰叫私鑰，而根據私鑰生成的秘鑰叫公鑰。
- 一個私鑰只能對應一個公鑰。
先感受下幾個概念
PKI。
PKI是公鑰基礎設施（Public Key Infrastructure) 包括PKI策略、軟硬件系統、證書機構CA、注冊機構RA、證書發布系統和PKI應用等。
我們關注就倆東西： PKCS 證書機構CA 。前者是定義加密算法，簽名，證書相關的各種事情采用的協議。后者可以為我們頒發權威的證書。
PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美國RSA數據安全公司及其合作伙伴制定的一組公鑰密碼學標準，其中包括證書申請、證書更新、證書作廢表發布、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。RSA算法可以做加密、解密、簽名、驗證，還有RSA的密鑰對存儲。這些都需要標準來規范，如何輸入，如何輸出，如何存儲等。
PKCS。全稱是公鑰密碼學標準， 目前共發布過 15 個標準，這些標準都是協議。總結一下 就是對加密算法，簽名，證書協議的描述。下面列舉一些常用的協議，這些協議在本文都會對應上。
PKCS#1定義了RSA公鑰函數的基本格式標準，特別是數字簽名。它定義了數字簽名如何計算，包括待簽名數據和簽
名本身的格式；它也定義了RSA公/私鑰的語法。
PKCS#10：證書請求語法標準。證書請求包含了一個唯一識別名、公鑰和可選的一組屬性，它們一起被請求證書的實
體簽名。
PKCS#7 是一種將數據加密和簽名（正式名稱是“enveloping”）的技術標準。 它描述數字證書的語法和其他加密
消息——尤其是，數據加密和數字簽名的方法，也包含了算法。但PKCS#7不包含私鑰信息。
PKCS#8：私鑰信息語法標準。PKCS#8定義了私鑰信息語法和加密私鑰語法，其中私鑰加密使用了PKCS#5標準。
PKCS#12：個人信息交換語法標準。PKCS#12定義了個人身份信息（包括私鑰、證書、各種秘密和擴展字段）的格
式。簡單來說，PKCS#12 定義了一個用于保存私鑰和對應公鑰證書的文件格式，并由對稱密鑰加密保護。PKCS#12
通常采用PFX,P12作為文件擴展名。 PKCS#12文件可以存放多個證書，并由密碼保護。
這些協議具體的實現就體現在openssl等工具中， 以及jdk工具keytool jdk java第三方庫bouncycastle。
比如用openssl 如何生成公/私鑰(PKCS#1)、簽名(PKCS#1 )、簽名請求文件（KCS#10）、 帶口令的私鑰（PKCS#8）。 含私鑰的證書（PKCS#12）、證書庫（PKCS#12）
其中涉及到算法的基礎協議PKCS#1等，由于涉及到密碼學原理所以我們并不需要深究它，只要知道怎么做就可以了。
現實中我們要解決這樣一種情況:
客戶端和服務器之間的數據要進行加密。需要兩個達成同一個對稱秘鑰加密才行，那么這個秘鑰如何生成，并在兩邊都能拿到，并保證傳輸過程中不被泄露。 這就用到非對稱加密了。 后續的傳輸，就能用這個 對稱秘鑰來加密和解密了。
還有這樣一個問題：
就是客戶端如何判斷服務端是否是合法的服務端。這就需要服務端有個id來證明它，而這個id 就是證書，而且必須是權威機構頒發的才能算是合法的。
因為客戶端即瀏覽器，認定證書合法的規則必須通過第三方來確認 即ca頒發的證書。否則就我可能進了一個假網站。
而這兩個問題 都是ssl協議要解決的內容。
所以ssl協議做了兩件事情，一是驗證身份，二是協商對稱秘鑰，并安全的傳輸。 而實現這個過程的關鍵數據模型就是證書， 通過證書中的ca對證書的簽名，實現了身份驗證，通過證書中的公鑰，實現對對稱秘鑰加密，從而實現數據保密。 其實還順手做了一件事情就是通過解密簽名比對hash，保證了數據完整性。
明白ssl協議 首先明白幾個重要的概念：
證書： 顧名思義就是提供了一種在Internet上驗證通信實體身份的方式，數字證書不是數字身份證，由權威公正的第三方機構，即CA（例如中國各地方的CA公司）中心簽發的證書， 就是可以認定是合法身份的。客戶端不需要證書。 證書是用來驗證服務端的。
一般的證書都是x509格式證書，這是一種標準的證書，可以和其他證書類型互相轉換。完整來說證書包含，證書的內容，包括 版本號， 證書序列號， hash算法， 發行者名稱，有效期， 公鑰算法，公鑰，簽名（證書原文以及原文hash一起簽名）而這個內容以及格式 都是標準化的，即x509格式 是一種標準的格式。
簽名: 就用私鑰對一段數據進行加密，得到的密文。 這一段數據在證書的應用上就是 對證書原文+原文hash進行簽名。
誰簽的名，就是用誰的私鑰進行加密。就像身份證一樣， 合法的身份證我們都依據是政府簽的，才不是假證， 那就是瀏覽器會有政府的公鑰，通過校驗（解密）簽名，如果能夠解密，就可以確定這個就是政府的簽名。就對了。
hash算法：對原始數據進行某種形式的信息提取，被提取出的信息就被稱作原始數據的消息摘要。比如，MD5和SHA-1及其大量的變體。 hash算法具有不可逆性，無法從摘要中恢復出任何的原始消息。長度總是固定的。MD5算法摘要的消息有128個比特位，SHA-1算法摘要的消息最終有160比特位的輸出。
ca機構： 權威證書頒發機構，瀏覽器存有ca的公鑰，瀏覽器以此公鑰來驗證服務端證書的合法性。
證書的獲取： 生成證書申請文件.csr（涉及到PKCS#10定義的規范）后向ca機構申請。 或者自己直接通過生成私鑰就可以一步到位生成自簽名證書。 自簽名證書就是用自己的私鑰來簽名證書。
那么為了體現到證書身份認證、數據完整、保密性三大特性，證書的簡化模型可以認為包含以下兩個要素：服務器公鑰，ca的簽名（被ca私鑰加密過的證書原文+原文hash），
身份認證：
瀏覽器存有ca公鑰，用ca公鑰解密網站發給你的證書中的簽名。如果能解密，說明該證書由ca頒發，證書合法。 否則瀏覽器就會報警告，問你是否信任這個證書，也就是這個網站。這時候的證書可以是任何人簽發的，可以自己簽發的。 但是中間人攻擊。 完全偽造新的證書， 這就沒有辦法了。 所以還是信任證書的時候要謹慎。
數據完整：
如果你信任該證書的話，這時候就會用證書中的公鑰去解密簽名，如果是ca簽發的證書，那么之前就已經通過ca的公鑰去解密簽名了。 然后得到證書hash，然后在瀏覽器重新對證書做hash，兩者比對一致的話，說明證書數據沒有被篡改。
保密性：
使用證書的公鑰對對稱秘鑰加密保證傳輸安全，對稱秘鑰生成后，后續的傳輸會通過對稱秘鑰來在服務端和客戶端的加解密。
那么ssl協議的具體過程就是：
客戶端請求建立SSL連接，將協議版本，隨機數，支持的一套加密規則，壓縮方法 發給服務器。
服務器收到客戶端請求后，確定協議版本如果不一致則關閉通信。如果一致則生成隨機數，確定的加密方法，返回證書給客戶端。證書里面包含了網站地址， 公鑰，原文hash 簽名 以及證書的頒發機構等信息
獲得網站證書之后 瀏覽器先驗證證書的合法性，再生成一個隨機數，然后把對稱密鑰（三個隨機數通過一個密鑰導出器生成），編碼改變通知，前面發送的所有內容的hash值 。 用服務器公鑰加密以上內容，發送給服務器。 那個hash值是用來服務器校驗這個階段的數據完整性。
4.網站接收瀏覽器發來的數據之后 使用自己的私鑰校驗簽名，并對原文進行hash 與解密出的hash 做比對檢查完整性。然后發送編碼改變通知，服務器握手結束通知（所有內容做hash ）。 發送給客戶端校驗。
5 客戶端校驗，校驗成功后，之后就用 對稱秘鑰進行通信了。
總共的過程是 c-s-c- s-c 四次握手。
四次握手簡單來說分別是：
1.請求獲取證書
2.服務端返回證書，客戶端驗證了證書的合法性和完整性，同時生成了對稱秘鑰。
3.客戶端把加密的 對稱秘鑰發給服務器。服務器檢查真實性和完整性。
4.服務端返回握手結束通知，客戶端再檢查一次真實性和完整性。
前兩次握手是明文， 后兩次握手是密文。 所以都要檢查身份真實性和數據完整性。
ca的作用：
ca起到一個權威中間人的角色，如果脫離了ca， 那么證書還是證書，還能加密，保證數據完整性。 但是無法應用在客戶端去認定服務器身份合法這個場景下。
??
下面就詳細說下 脫離了ca簽發的證書的應用：
??
自簽名證書：
證書如果沒有權威機構的簽名，就是沒有權威機構給你簽發身份證。 那么這時候身份認證的場景變了。
這時候的認證場景就變成了，不再是某個官方權威說了算，而是假設第一次碰到這個證書，會認為，這個證書與之捆綁的實體之間是合法的并做記錄。如果當這個實體下次捆綁了另一個證書，那么就是非法的。
這種情況常用于android中安裝和校驗app的時候，會先假設第一次安裝的是合法的應用，認定這個app證書中的公鑰是合法的公鑰。然后通過自簽名的證書，校驗簽名，就能實現后續安裝是否合法以及完整性。
android中的如何對app進行身份認定和不被篡改：
android系統在安裝app時候會進行校驗applicationId，applicationId 不同會認定為不同應用。相同應用，第二次安裝會校驗證書是否和之前app的證書相同，如果相同則兩個包很可能來自同一個身份。 如果證書不同，也就是該包被另一個身份用自己的私鑰重新簽名過，就會拒絕安裝。 然后通過公鑰來解密簽名，如果能解密，說明身份是ok的。否則拒絕安裝。比對解密簽名后的hash 與apk包內的cert.sf文件(該文件是apk內所有文件生成的hash文件)是否一致，如果相同則認定為沒有被篡改。
android在提交應用商店的問題：
應用商店也會校驗 后續的上傳和第一次上傳時的證書，以及類似上述的后續的一系列校驗。防止合法的開發者平臺被盜后，上傳非法應用。
android在接入第三方sdk的問題：
接入第三方sdk 會提交applicationId 和 sha1 值。 這個sha1值就是對 證書原文的簽名后的sha1，也就是證書指紋。這個證書是證書庫里最初的那個證書（x509格式），而不是對apk簽名后生成的證書(PKCS#7)。一般的證書簽名的主體是證書原文本身，而對apk簽名還額外會對apk所有文件生成的hash值文件（cert.sf）進行一次簽名。
第三方平臺會記錄 applicationId 與sha1 的對應關系。 當有假冒app試圖接入時候，由于會對app內的PKCS#7證書轉換為原始的x509格式證書，重新生成sha1值，與用戶提交sha1 比對， 如果相同則說明證書很可能是ok的。 因為sha1就是證書的指紋。 之后就會通過證書中的公鑰來校驗簽名，從而最終確認身份合法性以及信息完整性。
第三方平臺之所以需要用戶去提交證書指紋sha1值，多了這一步，就意味著你的證書是可以更換的，一旦更換了證書，就必須提交新的指紋給我，然后我來做匹配。而應用商店沒有這個功能， 一旦你的證書的私鑰丟了， 那就必須重新建一個新的app。
總結來看證書的身份認定機制：
在ssl協議下，這種場景是 瀏覽器用于認定合法的服務器身份。 在自簽名證書下，需要用戶選擇是否信任該證書。
在android app采用自簽名證書的場景下， 證書起到了 假設第一次的證書合法，公鑰合法，后續如果證書不一致或不能夠完成簽名校驗，就是非法。
證書庫：
證書庫應該滿足PKCS#12協議。 但是jdk提供了制作證書的工具keytool 可以生成keystore類型的證書庫，后綴為jks。 keystore pk12可以通過keytool命令互相轉換。
證書庫是個證書的容器， 可以用來創建數字證書。 在keystore證書庫中，所有的數字證書是以一條一條(采用別名alias區別)的形式存入證書庫的。證書庫中的證書格式為pk12，即包含私鑰。 如果導出證書的話， 可以導出為x509不包含私鑰的格式 或者pk12包含私鑰的證書。 也可以也可以用-import參數加一個證書或證書鏈到信任證書。
android中一般都采用讀取證書庫的方式，通過證書庫來創建一個證書，通過alias來區分。 所以在簽名的時候，一個alias是一個證書，不同的alias是不同的證書，不要搞錯了。
幾個關系：
證書和非對稱加密算法的關系：
證書代表一個身份的主體，包含了非對稱秘鑰體系中的公鑰，以及用私鑰對證書簽名。這種組織結構，把非對稱加密算法從加密的功能，拓寬到了用于身份認證，信息完整性上。這體現在了證書的作用。 本質還是利用了非對稱加密算法的特性。
ssl協議和證書的關系。
因為證書解決了客戶端對服務器的身份認證（自簽名證書除外），同時也解決了加密，和信息完整性，所以ssl協議基于證書來實現。
