第三方ca證書簽名加密

A. 如何使用ca證書 實現 電子簽名

《電子簽名法》第13、14條規定：電子簽名同時符合下列條件的，視為可靠的電子簽名：

從技術上來講，可以通過三種方式確保簽署時數字證書由電子簽名人控制：

其一是通過電子簽名人設置簽名密碼;

其二是系統下發驗證碼到電子簽名人提供的手機或郵箱，或提供驗證碼生成器給電子簽名人，通過電子簽名人回填驗證碼的方式確保數字證書由電子簽名人控制;

其三是通過EID調用數字證書。EID是派生於居民身份證、在網上遠程證實身份的證件，即「電子身份證」。在技術上。EID也是採用PKI(Public Key
Infrastructure，公鑰基礎設施)的密鑰對技術，由智能晶元生成私鑰，再由公安部門統一簽發證書、並經現場身份審核後，再發放給公民。EID
採用了PKI、硬證書加PIN碼的技術，通過這些技術可以有效防止在網路上身份信息被截取、篡改和偽造。而且由於EID具有PIN碼，別人撿到或盜取後也
無法使用。EID本身採用先進密碼技術，重要信息在key中物理上就無法被讀取，因此無法被破解，從而有效避免被他人冒用。

如果採用了「數字簽名」技術，一般可認定為可靠的電子簽名。

數字簽名並非是書面簽名的數字圖像化，而是通過密碼技術對電子文檔進行電子形式的簽名。實際上人們可以否認曾對一個文件簽過名，且筆跡鑒定的准確率並非
100%，但卻難以否認一個數字簽名。因為數字簽名的生成需要使用私有密鑰，其對應的公開密鑰則用以驗證簽名，再加上目前已有一些方案，如數字證書，就是把一個實體(法律主體)的身份同一個私有密鑰和公開密鑰對綁定在一起，使得這個主體很難否認數字簽名。

就其實質而言，數字簽名是接收方能夠向第三方證明接收到的消息及發送源的真實性而採取的一種安全措施，其使用可以保證發送方不能否認和偽造信息。

數字簽名的主要方式是：報文的發送方從報文文本中生成一個散列值(或報文摘要)。發送方用自己的私有密鑰對這個散列值進行加密來形成發送方的數字簽名。然後，這個數字簽名將作為報文的附件和報文一起發送給報文的接收方。報文的接收方首先從接收到的原始報文中計算出散列值(或報文摘要)，接著再用發送方的公開密鑰來對報文附加的數字簽名進行解密和驗證。如果兩個散列值(也稱哈希值)相同，那麼接收方就能確認該數字簽名是發送方的。哈希值有固定的長度，運算不可逆，不同明文的哈希值不同，而同樣明文的哈希值是相同並唯一的，原文的任何改動其哈希值就會發生變化，通過此原理可以識別文件是否被篡改。

事實上，被篡改的經過數字簽名的數據電文很容易被發覺，甚至該文件在外觀上即可識別、無需鑒定，除非被告能夠提交不同內容且未發現篡改的經過數字簽名的數據電文。

B. ca數字證書有什麼用

CA(Certificate Authority) ：全稱證書管理機構，即數字證書的申請、簽發及管理機關。其主要功能為： 產生密鑰對、生成數字證書、分發密鑰、密鑰管理等。

數字證書：是由CA機構頒發的證明（也就是問題中提及的CA證書），它包含了公鑰、公鑰擁有者名稱、CA 的數字簽名、有效期、授權中心名稱、證書序列號等信息。我們可以通俗的理解為數字證書是個人或企業在網路上的身份證。

申請手續簡化：

一是簡化商標數字證書申請手續，2月1日起，已提交數字證書申請的代理機構不需提交紙質材料，在網上申請系統提交用戶注冊申請後，審核通過後即發商標數字證書；

二是縮短商標數字證書製作周期，3月1日起，按周製作、發放新申請的商標數字證書，製作周期為1至2個月。

C. CA證書是什麼有什麼作用

CA 證書，顧名思義，就是CA機構頒發的數字證書。人人都可以找工具製作證書。所謂認證機構(CA，Certificate Authority)，是採用公開密鑰基礎技術，專門提供網路身份認證服務，負責簽發和管理數字證書，且具有權威性和公正性的第三方信任機構。CA的作用類似於我們現實生活中頒發證件的機構，如身份證辦理機構等。

數字證書是目前國際上最成熟並廣泛應用的信息安全技術。數字證書以密碼學為基礎，採用數字簽名、數字信封、時間戳服務等技術，在Internet上建立起有效的信任機制。它主要包含證書所有者的信息、證書所有者的公開密鑰和證書頒發機構的簽名等內容。通俗而言，數字證書就是個人或單位在網路上的身份證。

CA證書的作用：

• 作用一，驗證你打開的HTTPS網站是不是可信

• 作用二，驗證你所安裝的文件是不是遭到篡改

目前大多數知名的公司或組織機構發布的可執行文件(比如軟體安裝包、驅動程序、安全補丁)，都帶有數字簽名。建議大家在安裝軟體之前，都先看看是否有數字簽名，如果有，就按照上述步驟驗證;如果數字簽名無效，建議你還是別裝了，會有安全隱患。

D. ca證書的加密

我們將文字轉換成不能直接閱讀的形式（即密文）的過程稱為加密。即把我們平時看到的「http」加密成「https」來傳輸，這樣保證了信息在傳輸的過程中不被竊聽。目前國內可以完成這個工作的CA是Wosign

E. 加密、簽名、證書的作用及運用場景

本文主要是簡單介紹了常見的加密類型、各自的運用場景、為什麼需要數字簽名和數字證書、HTTPS涉及到的加密流程等。這里主要從使用者的角度出發，對演算法本身不做過多介紹。

對稱/非對稱加密均屬於 可逆加密，可以通過密鑰將密文還原為明文 。

有時候，我們希望明文一旦加密後，任何人（包括自己）都無法通過密文逆推回明文，不可逆加密就是為了滿足這種需求。
不可逆加密主要通過 hash演算法實現：即對目標數據生成一段特定長度hash值 ；無論你的數據是1KB、1MB、1GB，都是生成特定長度的一個Hash值（比如128bit）。這里大家應該能感受到一點 不可逆 的味道，加密後128bit的hash值顯然無法還原出1個G甚至更大的不規則數據的， hash可以看做是原來內容的一個摘要 。

常見演算法：

小明給小紅寫信：

經過九轉十八彎後，信的內容有可能：1. 被窺視 2. 被篡改（冒充小明發送假消息） ：

小紅先 生成對稱加密的密鑰key1 ，然後通過一個安全的渠道交予小明。
傳輸數據時，小明 使用key1加密 ，而小紅收到後再 使用key1解密 。
這時候 中間者既看不到原來的內容，也沒辦法篡改 （因為沒有密鑰）：

【對稱加密】實現簡單，性能優秀 ，演算法本身安全級別高。然而對 密鑰的管理 卻是個很頭疼的問題：一旦密鑰交到對方手裡，對方對密鑰的保管能力 我方是沒辦法控制 的，一旦對方泄露的話，加密就形同虛設了。
相對而言，【非對稱加密】的公鑰就沒有這個憂慮，因為 公鑰 的設計就是為了 可以公開的 ，盡管對方泄露，我方也不會有任何損失。

小紅生成一對公私鑰，自己持有私鑰（pri_key1），將公鑰（pub_key1）交予小明。
傳輸數據時，小明使用 公鑰加密 ，小紅使用 私鑰解密 。
因為 中間者沒有私鑰，公鑰加密的內容是無法獲取的 。此時達到了 防窺視 的效果：

然而因為 公鑰是可以公開的 ，如果 中間者知曉公鑰 的話，盡管沒有辦法看到原來的內容，卻 可以冒充小明發送假消息 ：

這時小紅在想，如果小明發送消息時，能帶上 只有他自己才能生成 的數據（字元串），我就能 驗證是不是小明發的真實消息 了。
通常這個 能證實身份的數據（字元串） 被稱之為 數字簽名（Signature）

小明再生成一對公私鑰 ，自己持有私鑰（pri_key2），將公鑰交予小紅（pub_key2）。

當小明傳輸數據時（可能很大），除了公鑰加密明文之外，還要帶上簽名：(1) 對明文做一個hash摘要 (2)對摘要進行私鑰加密，加密結果即簽名（傳輸內容=內容密文+簽名）

小紅收到後：(1) 解密簽名獲取hash (2)解密內容密文，對解密後的明文進行hash；如果兩個hash一致，說明驗簽通過。

盡管中間者修改了傳輸內容，但因為簽名無法冒認（沒有私鑰），小紅驗簽失敗，自然不會認可這份數據：

通常 非對稱加密要做到防窺視和防篡改，需要有兩對公私鑰 ：對方的公鑰用於內容加密，自己的私鑰用於簽名（讓對方驗證身份）。

因為HTTP協議明文通信的安全問題，引入了HTTPS：通過建立一個安全通道（連接），來保證數據傳輸的安全。

伺服器是 沒辦法直接將密鑰傳輸到瀏覽器的 ，因為在 安全連接建立之前，所有通信內容都是明文的 ，中間者可窺視到密鑰信息。
或許這時你想到了非對稱加密，因為公鑰是不怕公開的：

然而在第2步， 中間者可以截取伺服器公鑰，並替換成了自己的公鑰 ，此時加密就沒意義了：

為了 防止公鑰被假冒，數字證書（digital certificate ）便誕生了 。

當伺服器需要告訴瀏覽器公鑰時，並不是簡單地返回公鑰，而是響應 包含公鑰信息在內的數字證書 。

證書主要包含以下內容：

瀏覽器通過 【頒發機構的公鑰】進行解密驗簽 ，驗簽通過即說明證書的真實性，可以放心取 證書擁有者的公鑰 了。（ 常用CA機構的公鑰都已經植入到瀏覽器裡面 ）

數字證書只做一件事： 保證 伺服器響應的 公鑰是真實的 。

以上保證了 [瀏覽器⇒伺服器] 是加密的，然而 [伺服器⇒瀏覽器] 卻沒有（上圖第4步）；另外一個是 性能問題 ，如果所有數據都使用非對稱加密的話，會消耗較多的伺服器資源，通信速度也會受到較大影響。
HTTPS巧妙地結合了非對稱加密和對稱加密，在保證雙方通信安全的前提下，盡量提升性能。

HTTPS（SSL/TLS）期望 建立安全連接後，通信均使用【對稱加密】 。
建立安全連接的任務就是讓 瀏覽器-伺服器協商出本次連接使用的【對稱加密的演算法和密鑰】 ；協商過程中會使用到【非對稱加密】和數字證書。

特別注意的是：協商的密鑰必須是不容易猜到（足夠隨機的）：

其中比較核心的是隨機數r3（pre-master secret），因為之前的r1、r2都是明文傳輸的， 只有r3是加密傳輸 的。至於為什麼需要三個隨機數，可以參考：

以上是一個比較簡單的HTTPS流程，詳細的可以參考文末的引用。

參考資料：
[1] 數字證書應用綜合揭秘
[2] SSL/TLS協議運行機制的概述
[3] 圖解SSL/TLS協議
[4] 《圖解HTTP》