證書下載流程怎麼做的簽名和加密

A. 手機軟體簽名證書怎麼做

證書要來簽名軟體的。每一個手機串號，可以製作一個證書。 簽名(sign)：就是在應用程序的特定欄位寫入特定的標記信息，表示該軟體已經通過了簽署者的審核。 簽署者對該軟體的安全性負責。其中簽名又大致分三種： 1. Symbian 簽名。 即 Symbian(塞班)手機操作系統官方簽名。通過了 Symbian 安全認證的軟體才會獲得 Symbian 的簽名。該類軟體有最高的安全級別。在手機上能正常安裝/運行/且能實現軟體提供的所有功能. 獲得 Symbian簽名需要軟體作者直接和 Symbian 官方打交道，基於多方面的原因，並不是所有軟體的作者都有能力獲得這個認證的。 2. 作者簽名。 軟體作者在發布軟體的時候就對軟體進行了簽名。這類軟體可以在手機上安裝運行(可能會遇到安全性警告，可跳過)。但不能實現那些「被特別限制」了的功能。如果某軟體根本不涉及這類功能，那麼軟體作者也完全可能自己簽名就行了。 還有一種可能就是軟體雖然有某部分功能屬於「被特別限制」的范圍，但並不是主要功能。軟體作者也可能發布一個「作者簽名版」，這樣的版本可以正常使用大部分功能，但會喪失一些特定功能。如「來電通」軟體就有這樣的版，幾乎全部功能都可以使用，只是不能開機自啟動。 3. 用戶簽名。 嚴格來說這個應該是屬於「開發者簽名」。因為 Symbian 為軟體開發者提供一種「開發證書」，原意本來是讓軟體開發者作軟體測試用的。這個「開發證書」是與作為測試用的機器的 IMEI 碼掛鉤的。使用這種證書簽名的軟體只能在該 IMEI 碼對應的機器上使用，不能用於別的機器。 所謂的「自簽名」其實就是利用了這個方式，說白了就是你說你是開發軟體的，你提供你測試機器的 IMEI 碼，Symbian 頒發給你一個「開發證書」，你用這個證書簽名你的「測試軟體」。你自己對你自己的「開發行為」負責！如此而已。 另外,開發證書自頒發日起有效期為半年.但在證書有效期內簽署好了的程序的使用時限是沒有限制的.

B. 關於數字簽名的認證流程

從你的描述看，你對相關概念有一定了解，只不過還需要實際的感性認識。

數字簽名的操作有兩個：簽名（此處為動詞，指生成簽名）、驗證簽名。
你說的數字簽名的認證流程實際上是指驗證簽名的流程，你的叫法不夠准確。
數字簽名 是基於公私鑰的，簽名和驗證簽名的操作都主要是公私鑰的加解密運算。
簽名的流程是用私鑰對原文做加密形成數字簽名。
驗證簽名的流程是用公鑰對數字簽名做解密，然後將解密出的數據與原文做比較，如果一樣，則簽名驗證成功，否則驗證失敗。

無論是Win7，還是Mac系統，都是這個原理和流程。Win7和Mac系統中都含有對數字證書和數字簽名的支持，比如密鑰庫、加解密演算法、證書庫、介面等。

現在說說數字證書，數字證書中包含公鑰，在做驗證簽名操作時，會使用到。而私鑰是不在數字證書中的，私鑰的位置根據證書類型的不同而不同（軟體證書的私鑰存放在電腦中，而其它證書的私鑰是存放於智能卡中，比如usbkey），在生成簽名時，會使用此私鑰。

再來說說CA，CA負責對數字證書的管理，比如生成、廢除、更新、補發等，所有數字證書都是由CA生成的。

最後說下「下載程序的數字簽名認證」，也就是指對下載程序的數字簽名進行驗證，看看程序是否已經被篡改或破壞。
程序在上傳到網路之前，先生成數字簽名，並將簽名數據和數字證書附在程序後面，一起上傳到網路上。
程序下載後，取出附在程序後面的數字簽名數據和數字證書中的公鑰，然後進行驗證簽名的操作（也就是用公鑰對簽名數據做解密運算，然後比對解出來的數據與原程序是否一致）。

還有疑問否？

C. 如何進行數字簽名

數字簽名是實現電子簽名的國際通用的手段，而在實踐中，我們往往把數字簽名與電子簽章電子簽名之間畫上等號。因而，要問如何進行數學簽名，其實也就是在問如何進行電子簽章電子簽名

我以微簽為例子吧，簡單的幾步就可以用上電子簽章。

1登錄微簽電子簽章平台官網，用手機號免費注冊登錄：

是不是非常方便快捷呢？電腦端和手機端都可以使用，說再多也不如您親自上微簽官網注冊一個賬號來的實在，親自體驗一下數字簽名怎麼做。

D. 如何製作和應用數字簽名證書

需要准備的工具：makecert.exe、cert2spc.exe、pvk2pfx.exe、signtool.exe。
在MS的SDK6.0中有個證書生成工具makecert.exe， 你可以使用這個工具來生成測試用的證書。
第一步，生成一個自簽名的根證書（issuer，簽發者）。
>makecert -n "CN=Root" -r -sv RootIssuer.pvk RootIssuer.cer
這個時候，會彈出提示框，首先給RootIssuer.pvk文件設置私鑰保護口令；

然後，再次輸入這個口令用私鑰(在RootIssuer.pvk文件中）來給公鑰（在RootIssuer.cer文件中）加密。

第二步，使用這個證書簽發一個子證書（使用者，subject）。
>makecert -n "CN=Child" -iv RootIssuer.pvk -ic RootIssuer.cer -sv ChildSubject.pvk ChildSubject.cer
此時，會彈出提示框先給這個子證書的私鑰文件ChildSubject.pvk設置保護口令；

然後，輸入這個子證書的私鑰(在ChildSubject.pvk中)口令來保護子證書的公鑰(在ChildSubject.cer中)。

接下來會提示輸入根證書私鑰(在RootIssuer.pvk中)口令來簽發整個子證書(公鑰和用戶信息)。

如果你還要簽發更多的子證書，類似的，使用這個證書來簽發再下層的證書，前提是ChildSubject證書也可以用於簽發(作為Issuer)用途。
備註：
(1)如果你需要一個交互證書，用於安全通信，那麼，加入選項 -sky exchange；
(2)如果你需要一個簽名證書來簽發證書或者二進制文件，那麼，加入選項 -sky signature.
(3)如果你需要一個客戶端證書來標志你的身份，或者個人信息保護（電子郵件），那麼，選項-n 中的E欄位是不可缺少的。
舉例：-n "CN=公司名稱, E=E-MAIL地址, O=組織名稱, OU=組織單位, C=國家, S=省份(州), P=縣城"
其他輔助工具:
1) 公鑰證書格式轉換成SPC。 cert2spc.exe
>cert2spc TestRoot.cer TestRoot.spc
.spc 意思是 軟體發布者證書（Software Pulisher Cerificate）.
2) 將公鑰證書和私鑰合並成一個PFX格式的證書文件。pvk2pfx.exe
>pvk2pfx -pvk TestRoot.pvk -spc TestRoot.spc -pfx TestRoot.pfx
輸入TestRoot.pvk的保護口令來合並.pvk和.spc文件，如果你不設置即將合並出來的TestRoot.pfx的保護口令的話，這個保護口令和輸入文件TestRoot.pvk的保護口令一樣。(備註：直接從cer文件也可以，不一定要得到SPC文件).
3) 簽名工具。signtool.exe
二進制文件數字簽名.為了保證二進制文件的完整性，數字簽名是一個好的方法。
以下命令啟動一個有圖形界面的文件簽名工具向導:
>signtool wizard
以下是命令行方式的簽名:
>signtool sign /f "pfx文件的全路徑" /p "pfx文件的保護口令" /t "http://timestamp.verisign.com/scripts/timstamp.dll" /d "本次簽名的描述" "被簽名的程序的全路徑"

E. 怎麼做簽名證書和簽名密鑰

*^o^*專業手機證書製作，高速高效高品質！＾_＾
採納回答後我幫你製作，完成之後立馬發到您的郵箱！並且提供簽名教程已經手機破解教程和玩機教程～

F. 如何給文檔進行Pdf 證書簽名呢 專家能告訴我怎麼做嗎

1、PDF 文檔簽名證書的出現有效防止了上述安全問題的發生，使用 PDF 文檔簽名證書可以進行身份簽名或確認簽名，簽名後的文檔可以向用戶證實 PDF 文檔簽署人的真實身份，簽署人的真實身份是通過權威的第三方進行審核並確認，這樣便保護了 PDF 文檔在傳輸的過程中沒有被非法篡
改，從而使得簽名後的 PDF 文檔可以安全可靠的用於企業之間電子文檔交換和電子合同簽署等。

2、作為一家聲譽卓著，備受信賴的CA中心和數字證書提供商，Entrust 目前主要提供以下 PDF 證書：個人簽名 USB 證書、部門簽名 USB 證書和部門簽名 HSM 證書。通過Entrust 的 PDF 文檔簽名證書服務，將有效保護您的各式 PDF 文檔，使其不會遭受非法篡改，並提高工作效率。 Entrust數字證書認證中心–提供全球可信的SSL、SSL證書、SSL數字證書、 增強型EVSSL證書、防範釣魚網站、防黑客攻擊、代碼簽名證書、伺服器證書、微軟代碼簽名認證、Symbian代碼簽名證書、數字簽名證書、中文數字證書、PDF簽名證書等服務。

3、網路 「億創恆安」 提供免費的專業技術咨詢。

G. 下載好證書應該如何簽名和安裝游戲

塞班不是有教程嗎？
直接把那兩個文件導入到簽名工具里，然後打開要簽名的軟體 ，設置好輸出位置 就行了

H. 如何：使用獨立的 X.509 證書進行簽名和加密

有銀行專用電子簽名版，私人也可以用手寫電子板！

I. 一文弄懂關於證書，簽名，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協議基於證書來實現。

J. 描述數據加密.數字簽名及證書的簡單原理和實現過程

我是客戶端，你是伺服器端，然後你我通信。
我們都無法確認對方確實就是我們想要進行通信的人，
因此我們各需要有一本由你我都信任的CA機構頒發的並且由CA機構已經蓋了章（即簽名）了的證書，該證書用來確認我們各自的身份，就好象我們的身份證。我們各自的證書都有公鑰以及簽名者（CA機構）等信息

通信時：我向你請求安全連接，然後你把你的證書發過來給我，接著我就進行驗證，驗證證書是否就是你的，即驗證證書上是否有你用你自己私鑰簽的名，若有，則用你證書上的公鑰加密我要發給你的信息，然後發過去給你，然後你就用你的私鑰進行解密以獲得我發給你的信息，若沒有，斷開連接

大概如此