Android簽名證書(.keystore)生成指南

注意??，這里的前提是已經(jīng)安裝了JDK 環(huán)境。

成都創(chuàng)新互聯(lián)公司專注于武陵源企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站設(shè)計,購物商城網(wǎng)站建設(shè)。武陵源網(wǎng)站建設(shè)公司,為武陵源等地區(qū)提供建站服務(wù)。全流程按需求定制設(shè)計，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)公司專業(yè)和態(tài)度為您提供的服務(wù)

/usr/libexec/java_home -V

然后我們先 cd 到這個路徑，因為要把證書生成在這個目錄下：

cd /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home

sudo keytool -genkey -alias 自定義名.keystore -keyalg RSA -sigalg SHA1WithRSA -validity 20000 -keysize 1024 -keystore 自定義名.keystore -v

之后根據(jù)提示輸入密碼和一些信息。

最后提示我們需要做一個遷移到 pkcs12 格式的操作，那么就照做。

sudo keytool -importkeystore -srckeystore animaluni.keystore -destkeystore animaluni.keystore -deststoretype pkcs12

可能會有權(quán)限的問題，所以都別忘了加 sudo 。

這時打開我們的 jdk 目錄，就可以看到生成的證書????了。真正用的肯定是不帶 .old 的版本。

keytool -list -v -keystore [所在路徑/]xxx.keystore

Android 簽名證書過期怎么辦？

Android中目前三種簽名，簽名過期的問題，在 Android 9.0 上新支持的 V3 簽名，已經(jīng)有解決的方案了。另外：

V1 簽名：遵基于 JAR 簽名。 單獨驗證 APK 壓縮包中的文件。

V2 簽名：APK 簽名方案 V2，在 Android 7.0 引入。是針對 APK 文件的驗證，將簽名信息寫入簽名塊中，增強了安全性和驗證效率。

V3 簽名：APK 簽名方案 V3，在 Android 9.0 引入。在簽名塊中又增加了新塊（attr），由更小的 level 塊，以鏈表的形式存儲多個證書。

在 V3 方案中，最舊的證書為新塊鏈表的根節(jié)點，以此對新證書簽名，確保新證書正確有效。

參考：? App 簽名過期或泄露怎么辦？

一文弄懂關(guān)于證書，簽名，ssl，android包簽名機制。

所有的概念都基于一個非常重要的基礎(chǔ)：

rsa 非對稱加密算法 ：

先感受下幾個概念

PKI。

PKI是公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure) 包括PKI策略、軟硬件系統(tǒng)、證書機構(gòu)CA、注冊機構(gòu)RA、證書發(fā)布系統(tǒng)和PKI應(yīng)用等。

我們關(guān)注就倆東西： PKCS 證書機構(gòu)CA 。前者是定義加密算法，簽名，證書相關(guān)的各種事情采用的協(xié)議。后者可以為我們頒發(fā)權(quán)威的證書。

PKCS ：

PKCS（The Public-Key Cryptography Standards ）是由美國RSA數(shù)據(jù)安全公司及其合作伙伴制定的一組公鑰密碼學(xué)標(biāo)準(zhǔn)，其中包括證書申請、證書更新、證書作廢表發(fā)布、擴(kuò)展證書內(nèi)容以及數(shù)字簽名、數(shù)字信封的格式等方面的一系列相關(guān)協(xié)議。RSA算法可以做加密、解密、簽名、驗證，還有RSA的密鑰對存儲。這些都需要標(biāo)準(zhǔn)來規(guī)范，如何輸入，如何輸出，如何存儲等。

PKCS。全稱是公鑰密碼學(xué)標(biāo)準(zhǔn)， 目前共發(fā)布過 15 個標(biāo)準(zhǔn)，這些標(biāo)準(zhǔn)都是協(xié)議。總結(jié)一下 就是對加密算法，簽名，證書協(xié)議的描述。下面列舉一些常用的協(xié)議，這些協(xié)議在本文都會對應(yīng)上。

這些協(xié)議具體的實現(xiàn)就體現(xiàn)在openssl等工具中， 以及jdk工具keytool jdk java第三方庫bouncycastle。

比如用openssl 如何生成公/私鑰(PKCS#1)、簽名(PKCS#1 )、簽名請求文件（KCS#10）、 帶口令的私鑰（PKCS#8）。 含私鑰的證書（PKCS#12）、證書庫（PKCS#12）

其中涉及到算法的基礎(chǔ)協(xié)議PKCS#1等，由于涉及到密碼學(xué)原理所以我們并不需要深究它，只要知道怎么做就可以了。

現(xiàn)實中我們要解決這樣一種情況:

客戶端和服務(wù)器之間的數(shù)據(jù)要進(jìn)行加密。需要兩個達(dá)成同一個對稱秘鑰加密才行，那么這個秘鑰如何生成，并在兩邊都能拿到，并保證傳輸過程中不被泄露。 這就用到非對稱加密了。 后續(xù)的傳輸，就能用這個 對稱秘鑰來加密和解密了。

還有這樣一個問題：

就是客戶端如何判斷服務(wù)端是否是合法的服務(wù)端。這就需要服務(wù)端有個id來證明它，而這個id 就是證書，而且必須是權(quán)威機構(gòu)頒發(fā)的才能算是合法的。

因為客戶端即瀏覽器，認(rèn)定證書合法的規(guī)則必須通過第三方來確認(rèn) 即ca頒發(fā)的證書。否則就我可能進(jìn)了一個假網(wǎng)站。

而這兩個問題 都是ssl協(xié)議要解決的內(nèi)容。

所以ssl協(xié)議做了兩件事情，一是驗證身份，二是協(xié)商對稱秘鑰，并安全的傳輸。 而實現(xiàn)這個過程的關(guān)鍵數(shù)據(jù)模型就是證書， 通過證書中的ca對證書的簽名，實現(xiàn)了身份驗證，通過證書中的公鑰，實現(xiàn)對對稱秘鑰加密，從而實現(xiàn)數(shù)據(jù)保密。 其實還順手做了一件事情就是通過解密簽名比對hash，保證了數(shù)據(jù)完整性。

明白ssl協(xié)議 首先明白幾個重要的概念：

證書： 顧名思義就是提供了一種在Internet上驗證通信實體身份的方式，數(shù)字證書不是數(shù)字身份證，由權(quán)威公正的第三方機構(gòu)，即CA（例如中國各地方的CA公司）中心簽發(fā)的證書， 就是可以認(rèn)定是合法身份的。客戶端不需要證書。 證書是用來驗證服務(wù)端的。

一般的證書都是x509格式證書，這是一種標(biāo)準(zhǔn)的證書，可以和其他證書類型互相轉(zhuǎn)換。完整來說證書包含，證書的內(nèi)容，包括 版本號， 證書序列號， hash算法， 發(fā)行者名稱，有效期， 公鑰算法，公鑰，簽名（證書原文以及原文hash一起簽名）而這個內(nèi)容以及格式 都是標(biāo)準(zhǔn)化的，即x509格式 是一種標(biāo)準(zhǔn)的格式。

簽名: 就用私鑰對一段數(shù)據(jù)進(jìn)行加密，得到的密文。 這一段數(shù)據(jù)在證書的應(yīng)用上就是 對證書原文+原文hash進(jìn)行簽名。

誰簽的名，就是用誰的私鑰進(jìn)行加密。就像身份證一樣， 合法的身份證我們都依據(jù)是政府簽的，才不是假證， 那就是瀏覽器會有政府的公鑰，通過校驗（解密）簽名，如果能夠解密，就可以確定這個就是政府的簽名。就對了。

hash算法 ：對原始數(shù)據(jù)進(jìn)行某種形式的信息提取，被提取出的信息就被稱作原始數(shù)據(jù)的消息摘要。比如，MD5和SHA-1及其大量的變體。 hash算法具有不可逆性，無法從摘要中恢復(fù)出任何的原始消息。長度總是固定的。MD5算法摘要的消息有128個比特位，SHA-1算法摘要的消息最終有160比特位的輸出。

ca機構(gòu)： 權(quán)威證書頒發(fā)機構(gòu)，瀏覽器存有ca的公鑰，瀏覽器以此公鑰來驗證服務(wù)端證書的合法性。

證書的獲取： 生成證書申請文件.csr（涉及到PKCS#10定義的規(guī)范）后向ca機構(gòu)申請。 或者自己直接通過生成私鑰就可以一步到位生成自簽名證書。 自簽名證書就是用自己的私鑰來簽名證書。

那么為了體現(xiàn)到 證書身份認(rèn)證、數(shù)據(jù)完整、保密性三大特性 ，證書的簡化模型可以認(rèn)為包含以下兩個要素：服務(wù)器公鑰，ca的簽名（被ca私鑰加密過的證書原文+原文hash），

身份認(rèn)證：

瀏覽器存有ca公鑰，用ca公鑰解密網(wǎng)站發(fā)給你的證書中的簽名。如果能解密，說明該證書由ca頒發(fā)，證書合法。 否則瀏覽器就會報警告，問你是否信任這個證書，也就是這個網(wǎng)站。這時候的證書可以是任何人簽發(fā)的，可以自己簽發(fā)的。 但是中間人攻擊。 完全偽造新的證書， 這就沒有辦法了。 所以還是信任證書的時候要謹(jǐn)慎。

數(shù)據(jù)完整：

如果你信任該證書的話，這時候就會用證書中的公鑰去解密簽名，如果是ca簽發(fā)的證書，那么之前就已經(jīng)通過ca的公鑰去解密簽名了。 然后得到證書hash，然后在瀏覽器重新對證書做hash，兩者比對一致的話，說明證書數(shù)據(jù)沒有被篡改。

保密性：

使用證書的公鑰對對稱秘鑰加密保證傳輸安全，對稱秘鑰生成后，后續(xù)的傳輸會通過對稱秘鑰來在服務(wù)端和客戶端的加解密。

那么ssl協(xié)議的具體過程就是：

4.網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后 使用自己的私鑰校驗簽名，并對原文進(jìn)行hash 與解密出的hash 做比對檢查完整性。然后發(fā)送編碼改變通知，服務(wù)器握手結(jié)束通知（所有內(nèi)容做hash ）。 發(fā)送給客戶端校驗。

5 客戶端校驗，校驗成功后，之后就用 對稱秘鑰進(jìn)行通信了。

總共的過程是 c-s-c- s-c 四次握手。

四次握手簡單來說分別是：

1.請求獲取證書

2.服務(wù)端返回證書，客戶端驗證了證書的合法性和完整性，同時生成了對稱秘鑰。

3.客戶端把加密的 對稱秘鑰發(fā)給服務(wù)器。服務(wù)器檢查真實性和完整性。

4.服務(wù)端返回握手結(jié)束通知，客戶端再檢查一次真實性和完整性。

前兩次握手是明文， 后兩次握手是密文。 所以都要檢查身份真實性和數(shù)據(jù)完整性。

ca的作用：

ca起到一個權(quán)威中間人的角色，如果脫離了ca， 那么證書還是證書，還能加密，保證數(shù)據(jù)完整性。 但是無法應(yīng)用在客戶端去認(rèn)定服務(wù)器身份合法這個場景下。

下面就詳細(xì)說下 脫離了ca簽發(fā)的證書的應(yīng)用：

自簽名證書：

證書如果沒有權(quán)威機構(gòu)的簽名，就是沒有權(quán)威機構(gòu)給你簽發(fā)身份證。 那么這時候身份認(rèn)證的場景變了。

這時候的認(rèn)證場景就變成了，不再是某個官方權(quán)威說了算，而是假設(shè)第一次碰到這個證書，會認(rèn)為，這個證書與之捆綁的實體之間是合法的并做記錄。如果當(dāng)這個實體下次捆綁了另一個證書，那么就是非法的。

這種情況常用于android中安裝和校驗app的時候，會先假設(shè)第一次安裝的是合法的應(yīng)用，認(rèn)定這個app證書中的公鑰是合法的公鑰。然后通過自簽名的證書，校驗簽名，就能實現(xiàn)后續(xù)安裝是否合法以及完整性。

android中的如何對app進(jìn)行身份認(rèn)定和不被篡改：

android系統(tǒng)在安裝app時候會進(jìn)行校驗applicationId，applicationId 不同會認(rèn)定為不同應(yīng)用。相同應(yīng)用，第二次安裝會校驗證書是否和之前app的證書相同，如果相同則兩個包很可能來自同一個身份。 如果證書不同，也就是該包被另一個身份用自己的私鑰重新簽名過，就會拒絕安裝。 然后通過公鑰來解密簽名，如果能解密，說明身份是ok的。否則拒絕安裝。比對解密簽名后的hash 與apk包內(nèi)的cert.sf文件(該文件是apk內(nèi)所有文件生成的hash文件)是否一致，如果相同則認(rèn)定為沒有被篡改。

android在提交應(yīng)用商店的問題：

應(yīng)用商店也會校驗 后續(xù)的上傳和第一次上傳時的證書，以及類似上述的后續(xù)的一系列校驗。防止合法的開發(fā)者平臺被盜后，上傳非法應(yīng)用。

android在接入第三方sdk的問題：

接入第三方sdk 會提交applicationId 和 sha1 值。 這個sha1值就是對 證書原文的簽名后的sha1，也就是證書指紋。這個證書是證書庫里最初的那個證書（x509格式），而不是對apk簽名后生成的證書(PKCS#7)。一般的證書簽名的主體是證書原文本身，而對apk簽名還額外會對apk所有文件生成的hash值文件（cert.sf）進(jìn)行一次簽名。

第三方平臺會記錄 applicationId 與sha1 的對應(yīng)關(guān)系。 當(dāng)有假冒app試圖接入時候，由于會對app內(nèi)的PKCS#7證書轉(zhuǎn)換為原始的x509格式證書，重新生成sha1值，與用戶提交sha1 比對， 如果相同則說明證書很可能是ok的。 因為sha1就是證書的指紋。 之后就會通過證書中的公鑰來校驗簽名，從而最終確認(rèn)身份合法性以及信息完整性。

第三方平臺之所以需要用戶去提交證書指紋sha1值，多了這一步，就意味著你的證書是可以更換的，一旦更換了證書，就必須提交新的指紋給我，然后我來做匹配。而應(yīng)用商店沒有這個功能， 一旦你的證書的私鑰丟了， 那就必須重新建一個新的app。

總結(jié)來看證書的身份認(rèn)定機制：

在ssl協(xié)議下，這種場景是 瀏覽器用于認(rèn)定合法的服務(wù)器身份。 在自簽名證書下，需要用戶選擇是否信任該證書。

在android app采用自簽名證書的場景下， 證書起到了 假設(shè)第一次的證書合法，公鑰合法，后續(xù)如果證書不一致或不能夠完成簽名校驗，就是非法。

證書庫：

證書庫應(yīng)該滿足PKCS#12協(xié)議。 但是jdk提供了制作證書的工具keytool 可以生成keystore類型的證書庫，后綴為jks。 keystore pk12可以通過keytool命令互相轉(zhuǎn)換。

證書庫是個證書的容器， 可以用來創(chuàng)建數(shù)字證書。 在keystore證書庫中，所有的數(shù)字證書是以一條一條(采用別名alias區(qū)別)的形式存入證書庫的。證書庫中的證書格式為pk12，即包含私鑰。 如果導(dǎo)出證書的話， 可以導(dǎo)出為x509不包含私鑰的格式 或者pk12包含私鑰的證書。 也可以也可以用-import參數(shù)加一個證書或證書鏈到信任證書。

android中一般都采用讀取證書庫的方式，通過證書庫來創(chuàng)建一個證書，通過alias來區(qū)分。 所以在簽名的時候，一個alias是一個證書，不同的alias是不同的證書，不要搞錯了。

幾個關(guān)系：

證書和非對稱加密算法的關(guān)系：

證書代表一個身份的主體，包含了非對稱秘鑰體系中的公鑰，以及用私鑰對證書簽名。這種組織結(jié)構(gòu)，把非對稱加密算法從加密的功能，拓寬到了用于身份認(rèn)證，信息完整性上。這體現(xiàn)在了證書的作用。 本質(zhì)還是利用了非對稱加密算法的特性。

ssl協(xié)議和證書的關(guān)系。

因為證書解決了客戶端對服務(wù)器的身份認(rèn)證（自簽名證書除外），同時也解決了加密，和信息完整性，所以ssl協(xié)議基于證書來實現(xiàn)。

Android簽名機制之簽名文件和數(shù)字證書的作用

Android簽名機制目的是確保app的可靠通信，其一，要確定消息的來源確實是其申明

的那個人；其二，要保證信息在傳遞的過程中不被第三方篡改，即使被篡改了，也可以

發(fā)覺出來。

所謂數(shù)字簽名，就是為了解決這兩個問題而產(chǎn)生的，它是對非對稱加密技術(shù)與數(shù)字摘要

技術(shù)的一個具體的應(yīng)用。

對于消息的發(fā)送者來說，先要生成一對公私鑰對，將公鑰給消息的接收者。

如果消息的發(fā)送者有一天想給消息接收者發(fā)消息，在發(fā)送的信息中，除了要包含原始的

消息外，還要加上另外一段消息。這段消息通過如下兩步生成：

1）對要發(fā)送的原始消息提取消息摘要；

2）對提取的信息摘要用自己的私鑰加密。

通過這兩步得出的消息，就是所謂的原始信息的數(shù)字簽名。

而對于信息的接收者來說，他所收到的信息，將包含兩個部分，一是原始的消息內(nèi)容，

二是附加的那段數(shù)字簽名。他將通過以下三步來驗證消息的真?zhèn)危?/p>

1）對原始消息部分提取消息摘要，注意這里使用的消息摘要算法要和發(fā)送方使用的一致；

2）對附加上的那段數(shù)字簽名，使用預(yù)先得到的公鑰解密；

3）比較前兩步所得到的兩段消息是否一致。如果一致，則表明消息確實是期望的發(fā)送者

發(fā)的，且內(nèi)容沒有被篡改過；相反，如果不一致，則表明傳送的過程中一定出了問題，

消息不可信。

通過這種所謂的數(shù)字簽名技術(shù)，確實可以有效解決可靠通信的問題。如果原始消息在傳

送的過程中被篡改了，那么在消息接收者那里，對被篡改的消息提取的摘要肯定和原始

的不一樣。并且，由于篡改者沒有消息發(fā)送方的私鑰，即使他可以重新算出被篡改消息

的摘要，也不能偽造出數(shù)字簽名。

那么數(shù)字簽名呢？

綜上所述，數(shù)字簽名其實就是只有信息的發(fā)送者才能產(chǎn)生的別人無法偽造的一段數(shù)字

串，這段數(shù)字串同時也是對信息的發(fā)送者發(fā)送信息真實性的一個有效證明。

不知道大家有沒有注意，前面講的這種數(shù)字簽名方法，有一個前提，就是消息的接收者

必須要事先得到正確的公鑰。如果一開始公鑰就被別人篡改了，那壞人就會被你當(dāng)成好

人，而真正的消息發(fā)送者給你發(fā)的消息會被你視作無效的。而且，很多時候根本就不具

備事先溝通公鑰的信息通道。那么如何保證公鑰的安全可信呢？這就要靠數(shù)字證書來解

決了。

所謂數(shù)字證書，一般包含以下一些內(nèi)容：

證書的發(fā)布機構(gòu)（Issuer）

證書的有效期（Validity）

消息發(fā)送方的公鑰

證書所有者（Subject）

數(shù)字簽名所使用的算法

數(shù)字簽名

可以看出，數(shù)字證書其實也用到了數(shù)字簽名技術(shù)。只不過要簽名的內(nèi)容是消息發(fā)送方的

公鑰，以及一些其它信息。但與普通數(shù)字簽名不同的是，數(shù)字證書中簽名者不是隨隨便

便一個普通的機構(gòu)，而是要有一定公信力的機構(gòu)。這就好像你的大學(xué)畢業(yè)證書上簽名的

一般都是德高望重的校長一樣。一般來說，這些有公信力機構(gòu)的根證書已經(jīng)在設(shè)備出廠

前預(yù)先安裝到了你的設(shè)備上了。所以，數(shù)字證書可以保證數(shù)字證書里的公鑰確實是這個

證書的所有者的，或者證書可以用來確認(rèn)對方的身份。數(shù)字證書主要是用來解決公鑰的

安全發(fā)放問題。

綜上所述，總結(jié)一下，數(shù)字簽名和簽名驗證的大體流程如下圖所示：

引用鏈接：

新聞標(biāo)題：android簽名證書,提取安卓系統(tǒng)簽名證書
文章路徑：http://chinadenli.net/article17/dsippgj.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、網(wǎng)站策劃、網(wǎng)站建設(shè)、網(wǎng)站營銷、網(wǎng)站改版、網(wǎng)站設(shè)計公司

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)