❶ 數字證書的簽名哈希演算法跟指紋演算法都是指對摘要（指紋的）的編碼嗎
證書簽名使用的演算法是發布者自己規定的 使用自己的私鑰對證書編碼的哈希值進行加密 一般演算法為md5withrsa或者sha256withrsa。哈希演算法是唯一的 就是把證書編碼轉換為固定長度的2進制 這個過程不可逆 就是說無法通過哈希值還原證書編碼。指紋演算法就是哈希演算法 一般都是sh1。證書認證的流程是證書所有者把證書和指紋（證書的哈希值並用私鑰加密）發給用戶 用戶根據證書計算出一個哈希值 用公鑰解密指紋得到一個哈希值 看一下兩者是否相同 相同及證明證書未被篡改。演算法是由所有者的私鑰加密的。ca的作用是ca是可以認證一個證書鏈，源頭就是ca 一旦你信任了這個ca 就是信任了ca發布的證書，這樣你與ca發布的證書的所有者通信時可以根據證書鏈找到ca ca可信任了則這個發布者就是可信任的
❷ HTTPS加密原理
HTTP、HTTPS在我們日常開發中是經常會接觸到的。
我們也都知道，一般 android 應用開發，在請求 API 網路介面的時候，很多使用的都是 HTTP 協議；使用瀏覽器打開網頁，也是利用 HTTP 協議。看來 HTTP 真是使用廣泛啊，但是，HTTP 是不安全的。利用網路抓包工具就可以知道傳輸中的內容，一覽無余。比如我經常會使用 Fiddler 來抓包，搜集一些有趣的 API 介面。
那麼問題來了，如何保證 HTTP 的安全性呢？基本上所有的人都會脫口而出：使用 HTTPS 協議。99.9% 的人都知道 HTTPS 會將傳輸的內容進行加密，但是接著問具體加密的過程和步驟，很多人就啞口無言了。
為了防止出現這種尷尬的局面，所以今天你就要好好看看這篇的內容了。以後就可以裝個逼，哈哈！
先科普一下，加密演算法的類型基本上分為了兩種：
對稱加密的意思就是說雙方都有一個共同的密鑰，然後通過這個密鑰完成加密和解密，這種加密方式速度快，但是安全性不如非對稱加密好。
舉個例子，現在學霸小明這里有一道數學題的答案：123 。他想把答案傳給自己一直暗戀的小紅。所以他們雙方在考試開考前，約定了一把密鑰：456 。那麼小明就把答案內容經過密鑰加密，即 123 + 456 = 579 ，將 579 寫在小紙條上扔給小紅。如果此時別人撿到了小紙條，不知道他們是加密傳輸的，看到上面的 579 ，會誤以為答案就是 579 ；如果是小紅撿到了，她拿出密鑰解密，579 - 456 = 123 ，得到了正確的答案。
這就是所謂的對稱加密，加解密效率高，速度快，但是雙方任何一方不小心泄露了密鑰，那麼任何人都可以知道傳輸內容了。
講完了對稱加密，我們看看啥是非對稱加密。
非對稱加密就是有兩把密鑰，公鑰和私鑰。私鑰自己藏著，不告訴任何人；而公鑰可以公開給別人。
經過了上次作弊後，小紅發現了對稱加密如果密鑰泄露是一件可怕的事情。所以她和小明決定使用非對稱加密。小紅生成了一對公鑰和私鑰，然後把公鑰公開，小明就得到了公鑰。小明拿到公鑰後，把答案經過公鑰加密，然後傳輸給小紅，小紅再利用自己的私鑰進行解密，得到答案結果。如果在這個過程中，其他人得到傳輸的內容，而他們只有小紅公鑰，是沒有辦法進行解密的，所以也就得不到答案，只有小紅一個人可以解密。
因此，相比較對稱加密而言，非對稱加密安全性更高，但是加解密耗費的時間更長，速度慢。
對稱加密和非對稱加密的具體應用我還是深有體會的，因為所在的公司是做金融支付方面的，所以加解密基本上算是天天見了。
說完加密類型後，我們再來看看 HTTPS 。
我們先來看一個公式：
HTTPS = HTTP + SSL
從這個公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我們可以猜到，HTTPS 的加密就是在 SSL 中完成的。
所以我們的目的就是要搞懂在 SSL 中究竟幹了什麼見不得人的事了？
這就要從 CA 證書講起了。CA 證書其實就是數字證書，是由 CA 機構頒發的。至於 CA 機構的權威性，那麼是毋庸置疑的，所有人都是信任它的。CA 證書內一般會包含以下內容：
正好我們把客戶端如何校驗 CA 證書的步驟說下吧。
CA 證書中的 Hash 值，其實是用證書的私鑰進行加密後的值（證書的私鑰不在 CA 證書中）。然後客戶端得到證書後，利用證書中的公鑰去解密該 Hash 值，得到 Hash-a ；然後再利用證書內的簽名 Hash 演算法去生成一個 Hash-b 。最後比較 Hash-a 和 Hash-b 這兩個的值。如果相等，那麼證明了該證書是對的，服務端是可以被信任的；如果不相等，那麼就說明該證書是錯誤的，可能被篡改了，瀏覽器會給出相關提示，無法建立起 HTTPS 連接。除此之外，還會校驗 CA 證書的有效時間和域名匹配等。
接下來我們就來詳細講一下 HTTPS 中的 SSL 握手建立過程，假設現在有客戶端 A 和伺服器 B ：
到此，SSL 握手過程就講完了。可能上面的流程太過於復雜，我們簡單地來講：
我們可以發現，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點，又利用了對稱加密速度快，效率高的好處。真的是設計得非常精妙，令人贊不絕口。
好了，HTTPS 加密原理到這就講的差不多了，不知道電腦前的你有沒有看懂呢？
如果有哪裡不明白的地方，可以在底下留言交流。
bye ~~
❸ 一文弄懂關於證書，簽名，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協議基於證書來實現。