keytool加密演算法

① 如何給Android應用程序簽名

Android系統要求所有的程序經過數字簽名才能安裝，如果沒有可用的數字簽名，系統將不許安裝運行此程序。不管是模擬器還是真實手機。因此，在設備或者是模擬器上運行調試程序之前，必須為應用程序設置數字簽名。·所有的程序都必須簽名，沒有被簽名的程序，系統將不能安裝。
·可使用自簽署證書簽署應用程序，無須授權憑證。
·系統僅僅會在安裝的時候測試簽名證書的有效期，如果應用程序的簽名是在安裝之後才到期，那麼應用程序仍然可以正常啟用。
·可以使用標准工具-Keytool and Jarsigner-生成密鑰，來簽名應用程序的.apk文件。
Android SDK 工具可以在調試時給應用程序簽名。ADT插件和Ant編譯工具都提供了兩種簽名模式-debug模式和release模式
·debug模式下，編譯工具使用JDK中的通用程序Keytool通過已知方法和密碼創建秘鎖和密鑰。每次編譯的時候，工具使用debug密鑰簽名應用程序的.apk文件。因為密碼是已知的，工具不需要在每次編譯的時候提示輸入密鎖和密鑰。
·當應用程序調試完畢准備要發布release版本時，可以在release模式下編譯。release模式下，編譯工具不會將.apk文件簽名。需要自己用Keytool生成密鑰和密鎖，再用JDK中的Jarsigner工具給.apk文件簽名。簽名基本設置 首先設置java_HOME環境變數，告訴SDK如何找到Keytool，或者可以在Windows 系統環境變數PATH變數中添加Keytool的JDK路徑。
在發布release版本時，從Package面版上按選中你的project，按滑鼠右鍵，依次選擇Android Tools、Export Application Package。或者可以點擊Manifest Editor，overview 頁面上的「Exporting the unsigned .apk」連接 ，導出未簽名apk文件。保存.apk文件後，用Jarsigner及自己的密鑰給apk文件簽名，如果沒有密鑰， 可以用Keystore創建密鑰和密鎖。如果已經有一個密鑰了，如公共密鑰，就可以給.apk文件簽名了。也可以把上面這個完整的步驟寫成一個bat文件，這樣需要簽名的時候只要運行這個bat就可以了。下面給出一個完整的bat文件示例：
@Rem android簽名程序 //注釋指令
@Rem echo是顯示指令 格式：echo [{on|off}] [message]
@echo **********************************************************
@Rem 文件是否存在命令格式：if exist 路徑+文件名 命令
@if exist d:sign/MyFirstApp.keystore goto sign
@echo 創建簽名文件MyFirstApp.keystore
@Rem keytool命令格式：-genkey產生簽名 -alias別名 -keyalg加密演算法 -validity有效天數 -keystore生產簽名文件名稱
keytool -genkey -alias MyFirstApp.keystore -keyalg RSA -validity 40000 -keystore MyFirstApp.keystore
@echo 開始簽名：
@Rem jarsigner命令格式：-verbose輸出詳細信息 -keystore密鑰庫位置 -signedjar要生成的文件 要簽名的文件 密鑰庫文件
jarsigner -verbose -keystore MyFirstApp.keystore -signedjar MyFirstApp_signed.apk MyFirstApp.apk MyFirstApp.keystore@goto over:sign@echo 開始簽名：
jarsigner -verbose -keystore MyFirstApp.keystore -signedjar MyFirstApp_signed.apk MyFirstApp.apk MyFirstApp.keystore：over@echo ********************MyFirstApp.apk 簽名完成************************pause================以上是一個給應用簽名的完整bat文件，在運行這個bat文件時，還需要按照屏幕提示的步驟輸入一些必要信息，最後生成一個簽名後的文件是：MyFirstApp_signed.apk。簽名完成以後最好再把這個文件壓縮一下，使用Android SDK安裝路徑下tools文件夾里的zipalign進行壓縮，以剛才這個文件為例，也可以寫成一個bat文件，示例如下：
D:\soft\android-sdk-windows\tools\zipalign -c -v 4 MyFirstApp_zip.apkpause================上面的D:\soft\android-sdk-windows用你的實際Android SDK安裝路徑代替。按照以上步驟簽名、壓縮就完成了，最後把壓縮後的那個文件(比如例子中的MyFirstApp_zip.apk文件)復制到手機上就可以正常的安裝運行了。

② 互聯網上的加密原理

互聯網上的加密方式主要分為對稱加密和非對稱加密二種，

採用單鑰密碼系統的加密方法，同一個密鑰可以同時用作信息的加密和解密，這種加密方法稱為對稱加密，也稱為單密鑰加密。
需要對加密和解密使用相同密鑰的加密演算法。由於其速度快，對稱性加密通常在消息發送方需要加密大量數據時使用。對稱性加密也稱為密鑰加密。
所謂對稱，就是採用這種加密方法的雙方使用方式用同樣的密鑰進行加密和解密。密鑰是控制加密及解密過程的指令。演算法是一組規則，規定如何進行加密和解密。
加密的安全性不僅取決於加密演算法本身，密鑰管理的安全性更是重要。因為加密和解密都使用同一個密鑰，如何把密鑰安全地傳遞到解密者手上就成了必須要解決的問題。
常用的對稱加密有：DES、IDEA、RC2、RC4、SKIPJACK、RC5、AES演算法等

非對稱加密演算法需要二個秘鑰，公開密鑰（publickey）和私有密鑰（privatekey）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。因為加密和解密使用的是兩個不同的密鑰，所以這種演算法叫作非對稱加密演算法。

明白了互聯網上的加密原理之後，下面來看看瀏覽器與伺服器交互時，瀏覽器想將數據加密後再發送給伺服器，那麼該怎麼做呢？伺服器首先要向瀏覽器出示一份數字證書，瀏覽器看到數字證書後，就可以使用數字證書裡面的公鑰加密數據，所以要想做瀏覽器和伺服器的加密數據傳輸，那麼首先得針對伺服器生成一份數字證書。然後再配置一下伺服器，讓伺服器收到瀏覽器的請求之後，會向瀏覽器出示它的數字證書。

SUN公司提供了製作證書的工具keytool， 在JDK 1.4以後的版本中都包含了這一工具，它的位置為<JAVA_HOME>\bin\keytool.exe

使用keytool生成一個名字為tomcat的證書，存放在.keystore這個密鑰庫中

③ 關於公私鑰、各種證書、https基本概念掃盲

最近實習需要寫一些生成證書的腳本，藉此機會順便搞清楚了許多關於證書這塊的疑惑。說到這一塊東西，名詞多到爆炸，對稱加密、非對稱加密、密鑰、密鑰庫、公鑰、私鑰、CA、證書、數字簽名、ssh、https、ssl、keytool、openssl、PKCS、X.509以及令人眼花繚亂的文件後綴名，cer、crt、pem、keystore、jks、key、p12、pfx...

先聽我講個故事，這次我們不用Bob和Alice,聽完之後再去看這些概念，絕壁恍然大悟。

故事背景: 這是2018年，為了能夠安全的進行通信，假設每個人都有倆把鎖，一個叫A鎖，一個叫B鎖，這倆把鎖和一般的鎖有點區別，每把鎖上即帶有自己的鎖孔又帶有另一把鎖的鑰匙，因此A鎖和B鎖既是鎖又是鑰匙。 A鎖和B鎖唯一配對，A鎖鎖住之後，只有B鎖可以打開，同樣B鎖鎖住之後，只有A鎖可以打開 。其中一把鎖是公開的，而一把鎖則自己保管，不公開。假設默認A鎖是公開的，B鎖是私有的。

故事內容: 阿里巴巴子弟小學的小明想給隔壁班的小花寫封表白信，為了不被別人看到，他將信放入在信箱中，並用小花的A鎖將信箱鎖住，因為小花的B鎖(同是A鎖的鑰匙)只有小花自己有，所以除了小花以外的任何人拿到信件，都無法看到信件內容。同樣小花要給小明寫信，那麼也要用小明的A鎖對信件內容進行保護。

小明與小花通過就這樣聊了有一段時間，後來小花覺得差不多了，可以進入秀恩愛的階段了，跟小明說，以後寫信別tm加密了，又不是銀行卡密碼，被人看到又能怎麼樣呢？只要看了之後別瞎改就行了。於是小明在寫完信後，把信里每個字的拼音首字母拼湊了一個字元串，並取名為 消息摘要 ，然後僅僅將消息摘要放入信箱，用自己的B鎖鎖住這個信箱。雖然信件本身沒有放入安全的信箱，但小明作為一個情書高手，隨便一封信都是上萬字，如果其他人對信件內容做任何改變，那麼拼音首字母組成的字元串幾乎肯定會改變，因此小花拿到信件後，先用小明的A鎖(B鎖的鑰匙)打開信箱，拿到小明的摘要,然後小花再對信件內容做同樣的處理(即計算信件每個字的拼音首字母，實際上不會用這么簡單的演算法，而是會用不可逆的hash演算法)，計算出的字元串值如與小明的信息摘要一致，說明這封信就是小明寫給自己的，沒有被任何人篡改。

故事高潮: 事情並沒有那麼簡單，小花發現小明只是在信件里對自己熱情似火，平常見了面連聲招呼都不打，一副不認識的樣子。終於有一天小花忍不住了，當面質問小明，小明卻說，我什麼時候給你寫情書了，自作多情吧...於是小花把昨天剛收到的情書狠狠甩在了小明臉上:「上面落款不是你小明嗎？怎麼了,慫了？」小明一看上面還真是自己的名字，但是自己寫沒寫信自己還不知道嗎？小明把自己的作業本拿給小花，並叫自己的同桌做筆跡鑒定，小花發現筆跡的確不大像，看來是有人惡作劇，冒充小明給自己寫情書，哎，好尷尬啊。。。

故事講完了，文章開頭涉及的所有概念都與信息的安全傳輸有關，可以說，一切都是為了安全。關於通信安全，我們通常有三個基本的需求

我們以上面的故事為例說一下這三點安全需求，一開始小明與小花通過A鎖( 對應公鑰 )加密,B鎖( 對應私鑰 )解密的通信方式即符合第一點，信件內容本身被加密，而因為公私鑰唯一配對，只有配對的密鑰才可以解密，因此很難被第三人破解。

之後，為了秀恩愛，他們採用了B鎖( 私鑰 )加密，A鎖( 公鑰 )解密的通信方式，其中用私鑰對消息摘要加密後的字元串稱為 數字簽名 ,這樣雖然信件可以被人直接看到，但如果被人篡改掉後可以輕易發現數據被篡改。本來以為滿足第一條和第二條就可以安全的通信了，但最後才發現小明根本不是小明！為什麼會出現這樣的問題？因為「小明」說他是小明，小花就以為他是小明，他沒有提供任何證明自己真的是小明的認證。因此要想安全通信，我們還需要一個權威第三方的機構來做身份認證,這個機構就是CA機構，通過認證後，CA機構會頒發權威的證書，而有了證書就可以證明身份，就不會出現身份被假冒的情況。而認證的過程則需要向CA機構提供自己的身份信息以及私鑰。

對稱加密就是通信雙方或多方採用的密鑰是一樣的。加解密速度快，但不夠安全。因為一旦密鑰泄露，誰都可以對數據進行解密。非對稱加密就是當然就是通信雙方使用的密鑰不同。而公鑰和私鑰就是非對稱加密的一種方式。比較常用的對稱加密演算法如
AES、DES，非對稱加密比較常見的則有sha256,RSA。
非對稱加密演算法有倆個密鑰，一個公鑰，一個私鑰。公鑰和私鑰必須配對出現，一對公鑰和一個私鑰統稱為一個 密鑰 ，而 密鑰庫 中可以存放多個密鑰，即多對公私鑰。

如果你用github的話，應該注意到github鏈接有倆種方式。一種是https,一種是ssh,通過https經常需要輸密碼，而通過ssh則不需要。回憶你設置ssh的步驟，本地生成了一個密鑰對，並將公鑰上傳到了github。每次傳輸用自動本地私鑰加密，伺服器用你上傳的公鑰解密，就不需要手動輸入密碼了。

keytool和openssl是倆個證書管理工具.keytool是java JDK自帶的證書管理工具，使用keytool可以生成密鑰，創建證書。只要裝了jdk,並正確設置了環境變數，就可以之間通過命令行執行keytool命令來管理證書。
openssl則是一個開源的安全套接字層密碼庫，功能比keytool更加豐富。

PKCS全稱Public-Key Cryptography Standards 即公鑰標准，PKCS已經發布了15個標准。
PKCS#12 包含了公鑰和私鑰的二進制格式的證書形式，以pfx作為證書文件後綴
X.509 則是一個通用的證書標准，規定了證書應該包含哪些內容，X.509通常有倆種編碼方式，一種是二進制編碼，另一種是base64編碼
X.509#DER 二進制格式證書，常用後綴.cer .crt
X.509#PEM 文本格式證書，常用後綴.pem

因為http是明文傳輸，非常不安全，因此又提出了ssl(Secure Sockets Layer即安全套接字)層協議，即在原來的基礎上又加了一層協議用於保障安全傳輸,可以認為https=ssl+http。很多人剛開始接觸https，用瀏覽器F12打開控制台後。可能發現數據仍然沒有加密。要注意https是 傳輸層加密 ，瀏覽器F12控制台你看到的還是應用層的數據。
因為本文主要是概念掃盲，幫助理解，因此關於這部分具體細節不作介紹。

.keystore和.jks和.truststore都是java用來存放密鑰的文件
.key nginx中私鑰文件
而不同的證書文件後綴都是為了區分不同種類的證書的，主要有倆個分類維度

④ 如何指定 https的加密演算法

一般採用SHA 256 RSA加密演算法，如果需要ECC演算法，好像證書頒發機構GDCA也可以指定演算法，你把自己的需求問下他們技術客服。

⑤ APK簽名機制原理詳解

眾所周知，Android系統在安裝Apk的過程中，會對Apk進行簽名校驗，校驗通過後才能安裝成功。那你知道簽名校驗的機制是什麼？具體校驗的是什麼內容嗎？申請第三方SDK（如微信支付）時填入的SAH1值是什絕頌高么？目前眾多的快速批量打包方案又是如何繞過簽名檢驗的？

我將通過一系列的文章來解開這些疑惑：

這篇文章先來介紹Apk簽名相關的基本知識。

要知道簽名是什麼，先來看為什麼需要簽名 。大家都知道，在消息通信時，必須至少解決兩個問題：一是確保消息來源的真實性，二是確保消息不會被第三方篡改。在安裝Apk時，同樣需要確保Apk來源的真實性，以及Apk沒有被第三方篡改。如何解決這兩個問題呢？方法就是開發者對Apk進行簽名：在Apk中寫入一個「指紋」。指紋寫入以後，Apk中有任何修改，都會導致這個指紋無效，Android系統在安裝Apk進行簽名校驗時就會不通過，從而保證了安全性。

要了解如何實現簽名，需要了解兩個基本概念：數字摘要和數字證書。

簡單來說，就是對一個任意長度的數據，通過一個Hash演算法計算後，都可以得到一個固定長度的二進制數據，這個數據就稱為「摘要」。摘要具有下面的幾個特徵：

前面已經說到，可以通過簽名來確保數據來源的可靠性和數據的不可篡改性。簽名就是在摘要的基礎上再進行一次加密，對摘要加密後的數據就可以當作數字簽名，在安裝Apk需要對簽名進行驗證，驗證通過才能繼續安裝。

這里有兩個過程：簽名過程 和 校驗過程。

先來說 簽名過程：

再來看 校驗過程：

這里有一個前提：接收方必須要知道發送方的公鑰和所使用的演算法。如果數字簽名和公鑰一起被篡改，接收方無法得知，還是會校驗通過。如何保證公鑰的可靠性呢？答案是數字證書，數字證書是身份認證機構（Certificate Authority）頒發的，包含了以下信息：

接收方收到消息後，先向CA驗證證書的合法性（根據證書的簽名、綁定的域名等信息。CA機構是權威的，可以保證這個過程的可靠性。）再進行簽名校驗。

需要注意的是，Apk的證書通常的自簽名的，也就是由開發者自己製作，沒有向CA機構申請。Android在安裝Apk時並沒有校驗證書本身的合法性，只是從證書中提取公鑰和加密演算法，這也正是對第三方Apk重新簽名後，還能夠繼續在沒有安裝這個Apk的系統中繼續安裝的原因。

我們在對Apk簽名時並沒有直接指定私鑰、公鑰和數字證書，而是使用keystore文件，這些信息都包含在了keystore文件中。根據編碼不同，keystore文件分為很多種，Android使用的是Java標准keystore格式JKS(Java Key Storage)，所以通過Android Studio導出的keystore文件是以.jks結尾的。

keystore使用的證書標準是X.509，X.509標准也有多種編碼格式，常用的有兩種：pem（Privacy Enhanced Mail）和der（Distinguished Encoding Rules）。jks使用的是der格式，Android也支持直接使用pem格式的證書進行簽名，我們下面會介紹。

兩種證書編碼格式的區別：

X.509證書格式：

Android提供了兩種對Apk的簽名方式，一種是基於JAR的簽名方式，另一種是基於Apk的簽名方式，它們的主要區別在於使用的簽名文件不一樣：jarsigner使用keystore文件進行簽名；apksigner除了並尺支持使用keystore文件進行簽名外，還支持直接指定pem證書文件和私鑰進行簽名。

不知道大家有沒有注意一個問題，我們通過櫻御keytool或者AS生成一個keystore的時候（ 簽署您的應用 ），除了要輸入keystore的密碼外，還要輸入一個alias和key的密碼。在簽名時，除了要指定keystore文件和密碼外，也要指定alias和key的密碼，這是為什麼呢？

原因是keystore是一個密鑰庫，也就是說它可以存儲多對密鑰和證書，keystore的密碼是用於保護keystore本身的，一對密鑰和證書是通過alias來區分的。從這里可以看出jarsigner是支持使用多個證書對Apk進行簽名的。apksigner也同樣支持，關於apksigner的使用介紹可以參考官方文檔 apksigner 。

ok，簽名的基本概念和校驗過程就介紹到這里，關於JAR簽名和V2簽名機制的詳細介紹，參考下面兩篇文章：

⑥ 一文弄懂關於證書，簽名，ssl，android包簽名機制。

所有的概念都基於一個非常重要的基礎：

rsa 非對稱加密演算法 ：

先感受下幾個概念

PKI。

PKI是公鑰基礎設施（Public Key Infrastructure) 包括PKI策略、軟硬體系統、證書機構CA、注冊機構RA、證書發布系統和PKI應用等。

我們關注就倆東西： PKCS 證書機構CA 。前者是定義加密演算法，簽名，證書相關的各種事情採用的協議。後者可以為我們頒發權威的證書。

PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美國RSA數據安全公司及其合作夥伴制定的一組公鑰密碼學標准，其中包括證書申請、證書更新、證書作廢表發布、擴展證書內容以及數字簽名、數字信封的格式等方面的一系列相關協議。RSA演算法可以做加密、解密、簽名、驗證，還有RSA的密鑰對存儲。這些都需要標准來規范，如何輸入，如何輸出，如何存儲等。

PKCS。全稱是公鑰密碼學標准， 目前共發布過 15 個標准，這些標准都是協議。總結一下 就是對加密演算法，簽名，證書協議的描述。下面列舉一些常用的協議，這些協議在本文都會對應上。

這些協議具體的實現就體現在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協議的具體過程就是：

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協議基於證書來實現。