所有的概念都基于一個非常重要的基礎：
rsa 非對稱加密算法 ：
- 在加解密上，兩個秘鑰是對等的 任何一個可以加密堂氯，另一個可以用來解密蔑担。
- 用openssl創(chuàng)建一個秘鑰，然后可用該秘鑰可以生成另一個秘鑰咽白。 但是反過來不可以啤握。所以創(chuàng)建的秘鑰叫私鑰，而根據私鑰生成的秘鑰叫公鑰晶框。
- 一個私鑰只能對應一個公鑰排抬。
先感受下幾個概念
PKI。
PKI是公鑰基礎設施（Public Key Infrastructure) 包括PKI策略授段、軟硬件系統(tǒng)蹲蒲、證書機構CA、注冊機構RA侵贵、證書發(fā)布系統(tǒng)和PKI應用等届搁。
我們關注就倆東西： PKCS 證書機構CA 。前者是定義加密算法窍育，簽名卡睦，證書相關的各種事情采用的協(xié)議。后者可以為我們頒發(fā)權威的證書漱抓。
PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美國RSA數據安全公司及其合作伙伴制定的一組公鑰密碼學標準表锻，其中包括證書申請、證書更新辽旋、證書作廢表發(fā)布浩嫌、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協(xié)議补胚。RSA算法可以做加密码耐、解密、簽名溶其、驗證骚腥，還有RSA的密鑰對存儲。這些都需要標準來規(guī)范瓶逃，如何輸入束铭，如何輸出，如何存儲等厢绝。
PKCS契沫。全稱是公鑰密碼學標準， 目前共發(fā)布過 15 個標準昔汉，這些標準都是協(xié)議懈万。總結一下 就是對加密算法，簽名会通，證書協(xié)議的描述口予。下面列舉一些常用的協(xié)議，這些協(xié)議在本文都會對應上涕侈。
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文件可以存放多個證書东涡，并由密碼保護冯吓。
這些協(xié)議具體的實現就體現在openssl等工具中， 以及jdk工具keytool jdk java第三方庫bouncycastle疮跑。
比如用openssl 如何生成公/私鑰(PKCS#1)组贺、簽名(PKCS#1 )、簽名請求文件（KCS#10）祖娘、 帶口令的私鑰（PKCS#8）失尖。 含私鑰的證書（PKCS#12）、證書庫（PKCS#12）
其中涉及到算法的基礎協(xié)議PKCS#1等，由于涉及到密碼學原理所以我們并不需要深究它雹仿，只要知道怎么做就可以了增热。
現實中我們要解決這樣一種情況:
客戶端和服務器之間的數據要進行加密。需要兩個達成同一個對稱秘鑰加密才行胧辽，那么這個秘鑰如何生成峻仇，并在兩邊都能拿到，并保證傳輸過程中不被泄露邑商。 這就用到非對稱加密了摄咆。 后續(xù)的傳輸，就能用這個 對稱秘鑰來加密和解密了人断。
還有這樣一個問題：
就是客戶端如何判斷服務端是否是合法的服務端吭从。這就需要服務端有個id來證明它，而這個id 就是證書恶迈，而且必須是權威機構頒發(fā)的才能算是合法的涩金。
因為客戶端即瀏覽器，認定證書合法的規(guī)則必須通過第三方來確認 即ca頒發(fā)的證書暇仲。否則就我可能進了一個假網站步做。
而這兩個問題 都是ssl協(xié)議要解決的內容。
所以ssl協(xié)議做了兩件事情奈附，一是驗證身份全度，二是協(xié)商對稱秘鑰，并安全的傳輸斥滤。 而實現這個過程的關鍵數據模型就是證書将鸵， 通過證書中的ca對證書的簽名，實現了身份驗證佑颇，通過證書中的公鑰顶掉，實現對對稱秘鑰加密，從而實現數據保密漩符。 其實還順手做了一件事情就是通過解密簽名比對hash一喘，保證了數據完整性。
明白ssl協(xié)議 首先明白幾個重要的概念：
證書： 顧名思義就是提供了一種在Internet上驗證通信實體身份的方式嗜暴，數字證書不是數字身份證凸克，由權威公正的第三方機構，即CA（例如中國各地方的CA公司）中心簽發(fā)的證書闷沥， 就是可以認定是合法身份的萎战。客戶端不需要證書舆逃。 證書是用來驗證服務端的蚂维。
一般的證書都是x509格式證書戳粒，這是一種標準的證書，可以和其他證書類型互相轉換虫啥。完整來說證書包含蔚约，證書的內容，包括 版本號涂籽， 證書序列號苹祟， hash算法， 發(fā)行者名稱评雌，有效期树枫， 公鑰算法，公鑰景东，簽名（證書原文以及原文hash一起簽名）而這個內容以及格式 都是標準化的砂轻，即x509格式 是一種標準的格式。
簽名: 就用私鑰對一段數據進行加密斤吐，得到的密文搔涝。 這一段數據在證書的應用上就是 對證書原文+原文hash進行簽名。
誰簽的名曲初，就是用誰的私鑰進行加密体谒。就像身份證一樣， 合法的身份證我們都依據是政府簽的臼婆，才不是假證， 那就是瀏覽器會有政府的公鑰幌绍，通過校驗（解密）簽名颁褂，如果能夠解密，就可以確定這個就是政府的簽名傀广。就對了颁独。
hash算法：對原始數據進行某種形式的信息提取，被提取出的信息就被稱作原始數據的消息摘要伪冰。比如誓酒，MD5和SHA-1及其大量的變體。 hash算法具有不可逆性贮聂，無法從摘要中恢復出任何的原始消息靠柑。長度總是固定的。MD5算法摘要的消息有128個比特位吓懈，SHA-1算法摘要的消息最終有160比特位的輸出歼冰。
ca機構： 權威證書頒發(fā)機構，瀏覽器存有ca的公鑰耻警，瀏覽器以此公鑰來驗證服務端證書的合法性隔嫡。
證書的獲鹊榕隆： 生成證書申請文件.csr（涉及到PKCS#10定義的規(guī)范）后向ca機構申請。 或者自己直接通過生成私鑰就可以一步到位生成自簽名證書腮恩。 自簽名證書就是用自己的私鑰來簽名證書笋庄。
那么為了體現到證書身份認證、數據完整梁钾、保密性三大特性义矛，證書的簡化模型可以認為包含以下兩個要素：服務器公鑰，ca的簽名（被ca私鑰加密過的證書原文+原文hash）缸榛，
身份認證：
瀏覽器存有ca公鑰吝羞，用ca公鑰解密網站發(fā)給你的證書中的簽名。如果能解密内颗，說明該證書由ca頒發(fā)钧排，證書合法。 否則瀏覽器就會報警告均澳，問你是否信任這個證書恨溜，也就是這個網站。這時候的證書可以是任何人簽發(fā)的找前，可以自己簽發(fā)的糟袁。 但是中間人攻擊。 完全偽造新的證書躺盛， 這就沒有辦法了项戴。 所以還是信任證書的時候要謹慎。
數據完整：
如果你信任該證書的話槽惫，這時候就會用證書中的公鑰去解密簽名周叮，如果是ca簽發(fā)的證書，那么之前就已經通過ca的公鑰去解密簽名了界斜。 然后得到證書hash仿耽，然后在瀏覽器重新對證書做hash，兩者比對一致的話各薇，說明證書數據沒有被篡改项贺。
保密性：
使用證書的公鑰對對稱秘鑰加密保證傳輸安全，對稱秘鑰生成后峭判，后續(xù)的傳輸會通過對稱秘鑰來在服務端和客戶端的加解密开缎。
那么ssl協(xié)議的具體過程就是：
客戶端請求建立SSL連接，將協(xié)議版本朝抖，隨機數啥箭，支持的一套加密規(guī)則，壓縮方法 發(fā)給服務器治宣。
服務器收到客戶端請求后急侥，確定協(xié)議版本如果不一致則關閉通信砌滞。如果一致則生成隨機數，確定的加密方法坏怪，返回證書給客戶端贝润。證書里面包含了網站地址， 公鑰铝宵，原文hash 簽名 以及證書的頒發(fā)機構等信息
獲得網站證書之后 瀏覽器先驗證證書的合法性打掘，再生成一個隨機數，然后把對稱密鑰（三個隨機數通過一個密鑰導出器生成）鹏秋，編碼改變通知尊蚁，前面發(fā)送的所有內容的hash值 。 用服務器公鑰加密以上內容侣夷，發(fā)送給服務器横朋。 那個hash值是用來服務器校驗這個階段的數據完整性。
4.網站接收瀏覽器發(fā)來的數據之后 使用自己的私鑰校驗簽名百拓，并對原文進行hash 與解密出的hash 做比對檢查完整性琴锭。然后發(fā)送編碼改變通知，服務器握手結束通知（所有內容做hash ）衙传。 發(fā)送給客戶端校驗决帖。
5 客戶端校驗，校驗成功后蓖捶，之后就用 對稱秘鑰進行通信了地回。
總共的過程是 c-s-c- s-c 四次握手。
四次握手簡單來說分別是：
1.請求獲取證書
2.服務端返回證書俊鱼，客戶端驗證了證書的合法性和完整性落君，同時生成了對稱秘鑰。
3.客戶端把加密的 對稱秘鑰發(fā)給服務器亭引。服務器檢查真實性和完整性。
4.服務端返回握手結束通知皮获，客戶端再檢查一次真實性和完整性焙蚓。
前兩次握手是明文， 后兩次握手是密文洒宝。 所以都要檢查身份真實性和數據完整性购公。
ca的作用：
ca起到一個權威中間人的角色，如果脫離了ca雁歌， 那么證書還是證書宏浩，還能加密，保證數據完整性靠瞎。 但是無法應用在客戶端去認定服務器身份合法這個場景下比庄。
??
下面就詳細說下 脫離了ca簽發(fā)的證書的應用：
??
自簽名證書：
證書如果沒有權威機構的簽名求妹，就是沒有權威機構給你簽發(fā)身份證。 那么這時候身份認證的場景變了佳窑。
這時候的認證場景就變成了制恍，不再是某個官方權威說了算，而是假設第一次碰到這個證書神凑，會認為净神，這個證書與之捆綁的實體之間是合法的并做記錄。如果當這個實體下次捆綁了另一個證書溉委，那么就是非法的鹃唯。
這種情況常用于android中安裝和校驗app的時候，會先假設第一次安裝的是合法的應用瓣喊，認定這個app證書中的公鑰是合法的公鑰坡慌。然后通過自簽名的證書，校驗簽名型宝，就能實現后續(xù)安裝是否合法以及完整性八匠。
android中的如何對app進行身份認定和不被篡改：
android系統(tǒng)在安裝app時候會進行校驗applicationId，applicationId 不同會認定為不同應用趴酣。相同應用梨树，第二次安裝會校驗證書是否和之前app的證書相同，如果相同則兩個包很可能來自同一個身份岖寞。 如果證書不同抡四，也就是該包被另一個身份用自己的私鑰重新簽名過，就會拒絕安裝仗谆。 然后通過公鑰來解密簽名指巡，如果能解密，說明身份是ok的隶垮。否則拒絕安裝藻雪。比對解密簽名后的hash 與apk包內的cert.sf文件(該文件是apk內所有文件生成的hash文件)是否一致，如果相同則認定為沒有被篡改狸吞。
android在提交應用商店的問題：
應用商店也會校驗 后續(xù)的上傳和第一次上傳時的證書勉耀，以及類似上述的后續(xù)的一系列校驗。防止合法的開發(fā)者平臺被盜后蹋偏，上傳非法應用便斥。
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協(xié)議下，這種場景是 瀏覽器用于認定合法的服務器身份劲装。 在自簽名證書下胧沫，需要用戶選擇是否信任該證書。
在android app采用自簽名證書的場景下占业， 證書起到了 假設第一次的證書合法绒怨，公鑰合法，后續(xù)如果證書不一致或不能夠完成簽名校驗谦疾，就是非法南蹂。
證書庫：
證書庫應該滿足PKCS#12協(xié)議。 但是jdk提供了制作證書的工具keytool 可以生成keystore類型的證書庫念恍，后綴為jks碎紊。 keystore pk12可以通過keytool命令互相轉換。
證書庫是個證書的容器樊诺， 可以用來創(chuàng)建數字證書。 在keystore證書庫中音同，所有的數字證書是以一條一條(采用別名alias區(qū)別)的形式存入證書庫的词爬。證書庫中的證書格式為pk12，即包含私鑰权均。 如果導出證書的話顿膨， 可以導出為x509不包含私鑰的格式 或者pk12包含私鑰的證書锅锨。 也可以也可以用-import參數加一個證書或證書鏈到信任證書。
android中一般都采用讀取證書庫的方式恋沃，通過證書庫來創(chuàng)建一個證書必搞，通過alias來區(qū)分。 所以在簽名的時候囊咏，一個alias是一個證書恕洲，不同的alias是不同的證書，不要搞錯了梅割。
幾個關系：
證書和非對稱加密算法的關系：
證書代表一個身份的主體霜第，包含了非對稱秘鑰體系中的公鑰，以及用私鑰對證書簽名户辞。這種組織結構泌类，把非對稱加密算法從加密的功能，拓寬到了用于身份認證底燎，信息完整性上刃榨。這體現在了證書的作用。 本質還是利用了非對稱加密算法的特性双仍。
ssl協(xié)議和證書的關系枢希。
因為證書解決了客戶端對服務器的身份認證（自簽名證書除外），同時也解決了加密殊校，和信息完整性晴玖，所以ssl協(xié)議基于證書來實現。
