加密和解密技术基础、PKI及创建私有CA
一、數據加密和解密概述
數據加密和解密是一門歷史悠久的技術，從古代就已經出現了，一直發展到當代。其中，數據加密的目的有很多，可以是為了保證本地數據存取的安全性，可以是為了保證數據流在網絡傳輸過程中的保密性，也可以是為了驗證數據的完整性，還可以通過數據加密來實現密鑰的交換等。
數據加密依賴于某種加密算法和加密密鑰，而數據解密則依賴于某種解密算法和解密密鑰。而在當代加密解密技術中，加密密鑰既可以與解密密鑰相同，也可以和解密密鑰不同，這取決于使用什么方法進行加解密。
二、安全的目標
就信息傳輸過程來說，安全目標有以下三個要點：
(1)保密性：確保通信雙方之間的通信數據不會被無關的第三方所竊取，這是最基本的要求。
(2)完整性：確保通信時數據不會丟失或被第三方篡改、破壞，一旦數據丟失或被篡改時，通信的一方能夠立即發現。
(3)可用性：確保授權用戶能夠按需合法訪問資源。
三、安全***類型
對應于以上的安全目標，分別有以下三種***類型：
(1)威脅保密性的***：竊聽/竊取、通信量分析；
(2)威脅完整性的***：篡改、偽裝、重放、否認；
(3)威脅可用性的***：拒絕服務(Dos)、分布式拒絕服務(DDos)；
四、安全防范的解決方案
為了防范安全***，可以分別從技術層面上和服務層面上防范：
(1)技術層面：提供加密和解密技術。這個層面解決了本地數據存儲加密和通信過程中數據加密的一系列問題，可分為傳統加密算法和現代加密算法：
????①傳統加密算法：替換加密算法、置換加密算法；
????②現代加密算法：現代塊加密方法
(2)服務層面：提供用于抵御***以及為了達到上述安全目標而特地設計的服務。在這一層面上主要有認證機制和訪問控制機制：
????①認證機制：確定訪問資源的用戶是誰、通信對方的身份是否為期望的另一方等；
????②訪問控制機制：確定某個用戶是否有權限訪問資源；如果有權限訪問資源，再進一步確定用戶所能夠訪問的資源以及對資源能夠執行的操作（查看、使用、修改、創建等）；
在以上技術和服務這兩個層面中會用到的密鑰算法和協議有對稱加密、公鑰加密（非對稱加密）、單向加密以及認證協議。接下來介紹在實現安全通信過程中所用到的加密算法以及它們的實現。
五、加密算法和實現
1、對稱加密
(1)特點：加密和解密使用同一個密鑰；通信時，雙方要想實現基于對稱加密算法來實現通信需要預先共享密鑰。
(2)用途：用于實現數據保密性。
(3)常見算法：
①DES：Data Encryption Standard，即數據加密標準。DES算法是以64bits(8Bytes)為塊，在加密端把數據分成多塊，對每塊數據(64bits)進行加密，生成64bits密文；在解密端則把64bits密文轉換為64bits明文。各個塊之間建立一定的聯系，DES使用16個迭代塊來完成迭代。其中，加密和解密使用56bits密鑰。
②3DES：Triple DES，即三輪DES加密機制。3DES加密次數是DES的三個數量級(10^3)。
③AES：Advanced Encryption Standard，即高級加密標準。AES支持多種變長密鑰，如128bits, 192bits, 256bits, 384bits等。
④其它對稱加密算法有：Blowfish, Twofish, IDEA, RC6, CAST5等。
注意：DES算法存在缺陷，而且只使用56bits的密鑰太短；為了提供更高的安全性，可使用DES的派生算法3DES來進行加密，但3DES算法和DES算法一樣存在可被***的缺陷。后來DES被AES所替代。
(4)缺陷：
①密鑰過多：如果通信是基于C/S模式，則服務器端與每一個客戶端之間的通信都必須使用不同的密鑰，造成服務器端密鑰過多的問題。
②密鑰分發困難：對稱加密可實現通信時數據加密功能，但問題是雙方通信之前必須交互密鑰，而密鑰在交換過程中也同樣保證保密性，這時會造成密鑰分發困難的問題，必須依賴于一種安全的方法來實現密鑰的交換。
2、非對稱加密
(1)特點：也稱為公鑰加密。加密和解密數據使用不同的密鑰，例如用公鑰加密的數據只能使用與之配對的私鑰進行解密，而用私鑰加密則只能使用與之配對的公鑰進行解密。相比于對稱加密，公鑰加密可把公鑰直接公開，即使公鑰在通信時被竊取，因為沒有與之配對的私鑰，所以仍然無法解密數據。
????①公鑰：public key，從私鑰中提取產生，可公開給所有人。
????②私鑰：secret key，通過工具創建生成，由使用者自己留存，必須保證其私密性。
(2)用途：
①數字簽名：主要用于讓接受方確認發送方的身份。
②密鑰交換：通過對方的公鑰加密一個對稱密鑰，并發送給對方，對方通過其私鑰解密之后就可以獲取對稱密鑰了。這解決了上述對稱加密算法中密鑰分發困難這一問題。
③數據加密：這種直接使用公鑰加密算法來實現通信時數據的保密性的方式并不常用，因為這種方式要比使用對稱加密慢上3個數量級，不推薦。
(3)常見算法：
①RSA：名稱由RSA三個提出者(Ron Rivest,?Adi Shamir,?Leonard Adleman)的姓氏首字母組合而成，這種算法的可靠性由對極大整數做因數分解的難度決定；RSA既能實現數字簽名，又能實現加解密。
②DSA：Digital Signature Algorithm，即數字簽名算法，又稱DSS(Digital Signature Standard, 數字簽名標準)；DSA僅能實現數字簽名，不能用于加解密。
③其他公鑰加密算法有ELGamal等。
(4)缺陷：通信效率低。
3、單向加密
(1)特點：提取數據特征碼，只能加密，不能解密，它是基于兩個特性。
????①定長輸出：提取出來的數據量是定長的，與進行加密的數據的量無關。
????②雪崩效應：初始條件的微小改變會引起加密結果的巨大變化。
(2)用途：用于實現數據完整性的驗證。
(3)常見算法：
①md5：Message Digest 5，即信息摘要，'5'是版本號；取出的特征碼定長為128bits。
②sha1：Secure Hash Algorithm 1，即安全哈希算法，'1'是版本號；取出的特征碼定長為160bits。
③其他的單向加密算法還有：sha224、sha256、sha384、sha512 ...分別表示定長輸出224bits、256bits、384bits、512bits ...
注意：CentOS 5用戶密碼加密使用的是md5，CentOS 6/7用戶密碼加密使用的是sha512.
4、密鑰交換(IKE, Internet Key Exchange)
兩種實現方式：
①公鑰加密：常見的算法有RSA等。
②DH算法：Deffie-Hellman(迪菲-赫爾曼)算法。
③其他用于實現密鑰交換的算法有：ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)等。
?
以下為DH算法的工作原理圖：
以下為更一般的描述：
Alice生成隨機自然數a、隨機大質數p和原根g；
Alice計算，計算結果為A，并把p,g,A發送給Bob；
Bob生成隨機自然數b，根據Alice發過來的p,g，計算，計算結果為B；
Bob把B發送給Alice，并計算，計算結果為K；而Alice計算，計算結果也為K；
Alice和Bob以K值作為密鑰進行通信。
注意：在整個密鑰協商過程中，p、g、和的值是可以公開給***者的，而a,b,K值是不公開的。但即使***者知道、p和g的值，也無法計算出a，同理，***者無法通過、g和g的值計算出b，更不用說計算出K值(最終Alice和Bob協商好的密鑰)了。這個問題就是著名的離散對數問題。
六、一次加密通信的過程
這里以發送方Alice和接收方Bob為例。
加密和發送過程：
1、當發送方Alice有數據要發送給Bob時，為了確保數據能夠完整地發送至Bob，首先需要使用單向加密算法去計算出這段要發送的數據的特征碼；
2、為了便于Bob收到數據之后可驗證身份，發送方Alice使用本地私鑰加密這段特征碼，并將加密后的特征碼附加在數據后面；
3、為了確保通信過程是保密的，發送方Alice生成一個臨時的對稱密鑰，并使用這個對稱密鑰加密整段數據；
4、發送方Alice獲取Bob的公鑰，再使用Bob的公鑰加密來加密剛才生成的臨時的對稱密鑰，并把加密后的對稱密鑰附加在整段加密數據后面，而后發送給Bob。
接收和解密過程：
接收和解密的過程和解密發送的過程剛好相反。
1、接收方Bob收到數據之后，先使用自己的私鑰去解密這段加密過的對稱密鑰(由Alice生成)；
2、接收方Bob用解密得到的對稱密鑰去解密整段（發送方用對稱密鑰）加密的內容；此時接收方Bob得到Alice發送給自己的數據和加密后的特征碼；
3、接收方Bob用對方Alice的公鑰去解密這段特征碼，如果能解密出來，則發送方的身份得到驗證（沒錯，就是Alice發送的）；
4、接收方Bob再用同樣的單向加密算法去計算這段數據的特征碼，與解密得到的特征碼進行比較，如果相同，則數據完整性得到驗證，否則說明數據有可能被篡改或被破壞。
圖解加密通信過程：
問題總結：
(1)什么是數字簽名？
數字簽名就是對數據的特征碼進行加密。(2)如何保證公鑰不被篡改？
解決方法：將公鑰放在證書中。只要證書是可信的，那么公鑰就是可信的。(3)公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），雙方都生成一個臨時的“會話密鑰”（session?key），用來 加密信息。由于“會話密鑰”是對稱加密，因此運算速度快，比公鑰加密快3個數量級，而公鑰加密 本身只用于加密“會話密鑰”本身，這樣就減少了耗用的時間。七、數字證書認證機構--CA
前面的加密通信過程中能夠保證通信過程的保密性、通信數據的完整性，但這是以雙方(Alice和Bob)能夠在此之前可靠地獲取對方的公鑰為前提的。如果不能保證能夠可靠獲取對方公鑰，那么就有可能出現中間人***（Man-in-the-middle attack，縮寫：MITM）。假設這個中間人是Eve，Eve就可以分別與Alice和Bob建立聯系，而這時Alice獲取的是“假的”Bob公鑰，而Bob獲取的是“假的”Alice公鑰；這時候Alice和Bob在毫不知情的情況下進行通信，但其實他們之間數據包的轉發是經由Eve的，如圖：
上述的通信過程中缺失的一環在于通信雙方不能保證可靠地獲取對方的公鑰，因此，為了保證可靠地獲取通信對方的公鑰，于是就有了數字證書認證機構(Certificate Authority，縮寫：CA)。CA就是為了能夠保證通信雙方能夠可靠獲取對方的公鑰，而特地設定的一個雙方公信的第三方可信機構。威瑞信（VeriSign）就是其中一家非常有名的數字證書認證機構。
為了避免出現上述一環的缺失，Alice和Bob可向公信的CA申請有效的證書，并由CA分別頒發給Alice和Bob，其中這個證書中的信息包括了證書擁有者的名稱、公鑰、證書的有效期等信息，而CA還會提取證書中信息的特征碼，并用CA自己的私鑰進行加密，再把加密后的特征碼附加在證書中最后面。此后，當雙方通信時，Alice和Bob雙方都把自己的證書發給對方，并都分別使用CA的公鑰去解密證書中的特征碼，如果能解密，則說明證書的確由他們所信任的CA機構所頒發；接著使用同樣的單向加密算法去提取證書中信息的特征碼，與解密出來的特征碼進行比較，如果兩者相同，說明證書內容完整，沒有被篡改或破壞，而對方的證書中就有對方的公鑰。
但這又引入了一個問題，Alice和Bob如何可靠地獲取CA的呢?顯然，不能基于網絡通信的方式獲取CA的公鑰（否則又會出現中間人***等問題），而應該當面交易。全球有多個CA機構，這些CA的數量是有限、基本固定的；它們彼此之間存在互信鏈，也就是說CA的信任關系是可以傳遞的。為了管理方便，全球有一個根CA，它與其他CA是從屬關系。
為了解決通信主機能夠可靠獲取CA的公鑰，CA需要自簽一份證書，就是CA自簽名證書，在證書信息中包括了CA的名稱、CA的公鑰等，通信主機（這里是Alice和Bob）需要獲取CA證書，這樣才能獲取CA公鑰以及其他的CA信息，并能通過CA證書來驗證其他通信主機的證書是否可靠。CA證書的獲取需要通過當面交易來實現，而微軟公司直接在windows操作系統上集成了在全球具有公信力的CA證書，但在Linux中一般不內置CA證書，需要自己通過可靠手段獲取。
雖然通過上述手段可以極大地保證通信過程的安全性，但仍然存在問題，例如在這整個通信過程中使用的某種算法出現漏洞依然不夠安全。
八、公鑰基礎設施--PKI
以上述為例子，如果Alice的私鑰丟失或者被竊取，則需要立即向CA機構申請吊銷證書，聲明證書作廢，將損失將至最低；為了能夠第一時間讓其他人知道證書已經吊銷，可以通過各種媒體來傳播，例如新聞、報紙等。由此可見，CA不單要頒發證書，還需要提供證書吊銷列表，公開聲明有哪些證書已經吊銷及不能再信任。因此，為了可以更好地管理CA，發展出了一套以CA為核心的體系--公鑰基礎設施（Public Key Infrastructure，縮寫為：PKI）。
PKI架構主要包括以下四部分：
①簽證機構：Certificate Authority，縮寫為CA；負責簽署證書；
②注冊機構：Registration Authority，縮寫為RA；負責接收簽署證書的申請；
③證書吊銷列表：Certificate Revocation List，縮寫為CRL；負責公開所有已經吊銷的證書；
④證書存取庫：Certificate Repository，縮寫為CR；負責將公開所有已申請的證書的相關信息；
為了統一數字證書的格式，國際電信聯盟（ITU-T）制定了數字證書標準--X.509，即數字證書的格式遵循X.509標準。在X.509v3版本中，定了數字證書的結構以及認證協議標準。而由X.509v3定義的數字證書應該包括以下幾個部分：
1. 版本號
2. 序列號（標識第幾個證書）
3. 簽名算法
4. 發行者名稱（CA名稱）
5. 有效期限
6. 主體名稱
7. 主體公鑰
8. 發行者的唯一標識
9. 主體的唯一標識
10. 擴展信息
11. 發行者的簽名（即CA對整個證書的簽名；CA把以上內容進行單向加密，得到特征碼；再使用CA自己的私鑰對特征碼進行加密，并附在證書后面，用來生成發行者數字簽名）
九、總結：CA如何在A和B通信之間發揮作用？
基本過程：
1、首先，在A和B通信之前需要互相發送證書；
2、A和B之間協商通信過程中要使用的加密算法（對稱加密、公鑰加密、單向加密、密鑰交換）；
3、開始驗證證書：
1)用CA的公鑰去解密CA的簽名，如果能解密，則說明證書來源可靠；
2)用同樣的單向加密算法計算出證書中信息的特征碼，與解密得到的特征碼進行比較；如果兩者相同，則說明證書完整性可靠；
3)檢查證書的有效日期是否在當前時間的合理范圍內；如果證書過期了則不會被認可；
4)檢查證書的主體名稱與期望通信的對方是否一致；如果不一致則不會被認可；
5)檢查證書是否被吊銷過；如果沒有吊銷則可使用該證書，否則證書不會被認可。
注意：在每次通信過程中，以上步驟一步也不能少；另外，A和B需要事先獲取CA自簽名證書，因為持有CA自簽名證書是用來驗證CA頒發給其他人或主機的證書的前提。
十、SSL/TLS概述
1、為什么需要SSL？
我們知道，服務程序一般都會存在bug，***只要找到服務程序的bug就可以基于網絡進行***。對于這種情況，我們的服務程序邏輯要盡可能做得足夠安全，但程序總會有bug，因此需要做好安全防范，解決思路是使用一個監控程序對所有的資源訪問做監控，如果***者想做一些未經授權的資源訪問，則這個監控程序自動報警。通俗地來講，就是“一旦它把手伸到不該伸的地方就報警”，這是一種輔助機制。但這種輔助機制只能確保本地服務程序不會被違規機制所訪問到，不能確保資源在網絡傳輸過程是安全的。
在早期計算機未普及時，使用計算機網絡進行通信的主機很少，網絡安全不是很受到重視。而在早期設計的一些協議本身就不具備加解密功能，例如http,ftp,smtp,pop3等協議。即便后來隨著互聯網的發展，網絡安全得到越來越多的關注，這些協議也很難在其中添加加解密功能，因為早期的很多協議已經成為了網絡通信的公共功能和基礎設施，一旦在這些基礎協議（例如http）添加上加解密功能，則會牽一發而動全身，各個依賴于這些基礎服務程序開發出來的程序勢必會受到影響。
因此，網景公司為http協議研發設計了一種可被調用的功能模塊，這個功能模塊所處的位置在應用層和傳輸層之間的半層，作為公共功能庫，也稱為半層庫。任何程序在研發時可調用這個半層庫以實現加解密和密鑰分發的功能，不調用則不使用。這個半層庫就是SSL庫。
2、SSL是什么？
SSL（Secure Sockets Layer，安全套接字層）是一種安全的加解密協議，它的實現也是需要程序（算法）來實現。SSL是位于應用層和傳輸層之間的半層庫，基于任何其它協議（例如HTTP、FTP等）進行通信時，只要調用了SSL這半層庫就可以實現安全加密通信了。SSL的功能包括加密、數字證書認證、完整性保護。而對SSL協議的一種開源實現OpenSSL程序就可以完成這些功能。基于HTTP協議進行通信時，只要調用了SSL庫，就可以實現基于HTTPS進行更安全的通信了，因此HTTPS不是一個新的應用層協議。因為調用了SSL庫，因此基于HTTPS進行通信同樣可實現加密通信、數字證書認證、完整性保護等功能了。通常，HTTP直接和TCP通信，一旦使用SSL，則HTTP變成和SSL通信，再由SSL和TCP進行通信了。
SSL是一種公共功能，但SSL本身只是一種規范和協議，需要程序員開發出一種遵循SSL協議規范的程序來實現。對于其他協議和程序也一樣，例如httpd、nginx是HTTP協議的服務端程序實現，而各種瀏覽器如IE、Chrome及Firefox等則是HTTP協議的客戶端程序實現；在Windows界面上的遠程終端程序Xshell、在Linux上的SSH程序也是SSH協議的客戶端程序實現。而SSL協議在Linux上的開源實現有OpenSSL和GPG，其中OpenSSL是SSL協議和SSL庫的實現，而GPG是PGP協議的實現，Openssl和GPG也是密鑰算法和協議的實現。
任何一個加密解密庫（例如ssl庫）要求必須滿足以下兩個功能：
①實現加解密的基本功能；
②能夠基于網絡通信方式實現密鑰分發。
3、加密通信協議歷史
1994年，NetScape公司設計了主要用于Web的SSL?1.0版，但因漏洞太多所以沒有發布。 1995年，NetScape公司發布了SSL?2.0版，但同樣有很多漏洞。 1996年，SSL?3.0版問世，由NetScape發布，并得到大規模應用。 1999年，IEIF將SSL標準化，發布了SSL的升級版TLS?1.0。 2006年和2008年，TLS進行了兩次升級，分別發布了TLS?1.1和TLS?1.2。 截止至2016年1月，TLS?1.3仍然處于草案階段。協議：
SSL：Secure?Sockets?Layer，安全套接字層協議。 TLS：Transport?Layer?Security，傳輸層安全協議。目前應用最廣泛的是TLS 1.2版，在主瀏覽器上都有支持。
TLS 1.0通常被標識為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
4、SSL/TLS分層設計
雖然SSL/TLS主要是為了實現加解密以及密鑰分發的功能，但也采用了分層設計規范來對其進行實現，各分層設計如下：
1、最底層：基礎算法原語的實現，如aes,rsa,md5等。 2、再上一層：各種算法的實現。 3、再上一層：各種組合算法實現的半成品。 4、最上層：用各種組件拼裝而成的各種成品密碼學協議軟件。SSL/TLS采用分層設計的好處在于SSL/TLS可以提供諸多應用程序在不同級別進行調用，可以直接調用其軟件程序，也可以調用其半成品，甚至可以調用其算法。
5、SSL/TLS協議的基本過程
(1)客戶端向服務器端索要并驗證證書。 (2)雙方協商生成“會話密鑰”。 (3)雙方采用“會話密鑰”進行加密通信。上面過程的前兩步，又稱為“握手階段”(handshake)。
握手階段的詳細過程：
“握手階段”一共有四個步驟，我們一個個來看。需要注意的是，在“握手階段”過程中，客戶端和服務端之間的通信是明文的。
5.1 客戶端發出請求（ClientHello）
首先，由客戶端（通常是瀏覽器）向服務器端發送一個加密通信請求，這個就叫做ClientHello請求。
在這一步中，客戶端主要向服務器提供以下信息：
這里需要注意的是，客戶端向服務器發送的信息中不包括服務器的域名，這是因為從理論上一個服務器只能包含一個網站，否則會分不清客戶端請求的是哪個網站的證書，這也是為什么一臺服務器上只有一張數字證書的原因。
顯然，這對于虛擬主機來說非常不方便，因此TLS協議在2006年時添加了Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
5.2 服務器回應（ServerHello）
服務器接收到客戶端的請求后，就會作出回應，這就叫做ServerHello。服務器的回應應該包括以下內容：
處理上面這些信息，如果服務器需要確認客戶端的身份，就會在這一步中再添加一項請求，即要求客戶端提供“客戶端證書”。比如，金融機構往往只允許客戶連接入自己的網絡，在這個網絡中創建了其私有CA；并且，金融機構會向正式客戶提供一個USB密鑰，里面就包含有一張證書。
5.3 客戶端回應
客戶端收到服務器回應后，首先要驗證服務器證書。如果證書不是可信CA機構頒布、或者證書中完整性驗證不通過、或者證書已經過期、或者證書持有者與客戶端期望通信的主機不一致、或者證書已經吊銷，就會向訪問者發出一個警告，由其選擇是否要繼續通信。
如果證書確認無誤，就會從證書中取出服務器的公鑰，并向服務器發送以下內容：
(1)一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。 (2)編碼變更通知，表示隨后的信息將用雙方商定的加密方法和密鑰發送。 (3)客戶端握手結束通知，表示客戶端握手階段已經結束。這一項同時也是前面發送的所有內容的 hash值，用來供服務器校驗，在這一步中客戶端發送給服務器端的隨機數是整個握手階段中的第三個隨機數，又稱"pre-master key"。有了它之后，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自由這三個隨機數生成同一把本次通信要用到的“會話密鑰”。
至于為什么為什么一定要用三個隨機數來生成“會話密鑰”：
(1)不管是客戶端還是服務器，都要使用隨機數，確保每次通信生成的臨時“會話密鑰”都不相同。 (2)由于SSL協議中的證書是靜態的，因此很有必要引入一種隨機的因素，來確保通信中使用的“會 話密鑰”足夠隨機，不具有可猜測性。 (3)SSL協議不信任通信雙方的主機能夠生成真正的隨機數，因為如果隨機數是軟件生成的，那么這 個由軟件生成的隨機數就有章可循，生成的只是偽隨機數，因此為了避免這一情況，就將客戶端、 服務端的隨機數和pre-master-secret（或者pre-master?key，由客戶端生成）這個隨機數“合并”、“攪和”起來，通過 密鑰生成器生成一個“會話密鑰”，使其足夠隨機，不具有可猜測性。此外，如果在前一步中，服務器需要向客戶端請求證書時，則在這一步中客戶端會向服務器發送“客戶端證書”。
5.4 服務器的最后回應
服務器收到客戶端的發來的第三個隨機數"pre-master-secret"之后，計算生成本次會話用到的“會話密鑰”。而后，向客戶端發送如下內容：
至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信。如果是基于HTTPS進行加密通信，握手階段之后的通信過程就完全使用普通的HTTP協議了，只不過使用“會話密鑰”加密內容。
6、SSL/TLS的開源實現
前面提到，SSL/TLS的開源實現為OpenSSL和GPG，這里介紹OpenSSL。
OpenSSL的組件：
OpenSSL是對SSL/TLS協議、SSL/TLS庫的實現，其組件包括以下三部分：
①libcrypto庫：加密解密庫，專門用于實現加密解密功能。
②libssl庫：用于實現ssl安全通信機制的庫。
③openssl多用途命令行工具：可實現加解密功能，以及模擬ssl實現安全通信功能。
需要注意的是，如果只是使用加解密功能，而不需要實現網絡通信，則直接調用libcrypto庫即可；如果既要使用加解密功能，又要實現網絡安全通信，則可以調用libcrypo庫和libssl庫。而openssl這個工具則內部封裝了libcrypto庫和libssl庫，可以實現上述加解密和安全通信的功能。libcrypto庫和libssl庫主要由開發者寫程序時調用。
接下來介紹這個openssl多用途命令行工具對上述密鑰算法和協議的實現。
openssl有眾多子命令，這些子命令可分為三類：
查看：
接下來介紹如何使用openssl命令實現對稱加密、單向加密、公鑰加密，以及如何生成用戶密碼和隨機數。
對稱加密：
(1)對稱加密工具：openssl enc, gpg
(2)支持的對稱加密算法：des, 3des, aes, blowfish, twofish
使用對稱加密算法加解密時，需要使用openssl的子命令enc。這里可查看enc幫助手冊：
[root@localhost?~]#?whatis?enc enc??????????????????(1ssl)??-?symmetric?cipher?routines [root@localhost?~]#?man?enc這里以/root目錄下的test文本文件作為示例吧：
[root@localhost?~]#?cat?test? I?love?you,Bob!使用算法3des對test文本進行對稱加密：
[root@localhost?~]#?openssl?enc?-e?-a?-des3?-salt?-in?test?-out?test.cipher //加密后輸出為test.cipher文本文件。 enter?des-ede3-cbc?encryption?password:????//此處輸入密鑰，由3des算法結合密鑰才能加密。 Verifying?-?enter?des-ede3-cbc?encryption?password:????//再次確認密鑰。 [root@localhost?~]#? [root@localhost?~]#?cat?test.cipher????//重新查看加密后的文本。 U2FsdGVkX18R/MdkP4l4Z8Gxrgfdsf6zne+EBjC4zWWunysQw39QYw==????//已加密為密文。說明（enc子命令）：
-d：表示解密。 -e：表示加密。 -ciphername：表示加密算法的名稱。 -salt：表示在加密時添加雜質。 -in：讀入指定文件。 -out：輸出為指定文件。 -a/-base64：編碼為文本格式。沒加此選項時，輸出為二進制格式（顯示為亂碼）也可對剛剛加密的文本進行解密：
[root@localhost?~]#?openssl?enc?-d?-a?-des3?-salt?-in?test.cipher?-out?test.plain //解密后輸出為test.plain文本文件。 enter?des-ede3-cbc?decryption?password:????//輸入解密密鑰，對稱加密時為加密密鑰。 [root@localhost?~]#? [root@localhost?~]#?cat?test.plain????//查看解密后的文本文件。 I?love?you,Bob!????//已解密為明文。單向加密：
單向加密工具：openssl dgst, gpg, md5sum, sha1sum, ...
這里同樣只介紹openssl dgst。單向加密需要用到openssl的子命令dgst，可查看其幫助手冊：
[root@localhost?~]#?whatis?dgst dgst?????????????????(1ssl)??-?message?digests dgst?[md2]???????????(1ssl)??-?message?digests dgst?[md4]???????????(1ssl)??-?message?digests dgst?[md5]???????????(1ssl)??-?message?digests dgst?[mdc2]??????????(1ssl)??-?message?digests dgst?[ripemd160]?????(1ssl)??-?message?digests dgst?[sha1]??????????(1ssl)??-?message?digests dgst?[sha]???????????(1ssl)??-?message?digests //根據自己需要選擇即可。單向加密操作：
[root@localhost?~]#?openssl?dgst?-md5?test MD5(test)=?00843d3c93ab6f87ed642a66960a6815使用其他工具也能得到相同的加密結果：
[root@localhost?~]#?md5sum?test 00843d3c93ab6f87ed642a66960a6815??test公鑰加密：
前面提到，公鑰加密的用途有三個：數字簽名、密鑰交換、數據加密解密，它們各自的實現方式如下：
(1)數字簽名：
①工具：openssl rsautl, gpg
②算法：RSA, DSA, ELGamal
(2)密鑰交換：
①工具：openssl dh, gpg
②算法：RSA, DSA, ELGamal
(3)加密解密：
①工具：openssl rsautl, gpg
②算法：RSA, ELGamal
這里生成本地私鑰：
[root@localhost?~]#?openssl?genrsa?1024 //此處'1024'指明生成的私鑰長度為1024bits.并使用rsa算法生成私鑰。Generating?RSA?private?key,?1024?bit?long?modulus ......++++++ ..............................................................................................++++++ e?is?65537?(0x10001) -----BEGIN?RSA?PRIVATE?KEY----- MIICXQIBAAKBgQC9uvCH3FsCZ4+nZJYNYXY8obVWRHFqO4lzunc4KmNuTIh/vwNZ 3BDijEse6gZNRjSyi3S8NcL8X6nX5mbQVYeP/LN1qU61hQZSnISH+ITtzq/fmRZI ZdaUeHWnwoHh4TS0kbrHvTNrAU/xVmKdLs/bezlWp9JpkqcF3q4rIDADuQIDAQAB AoGBAJpnBdQq2c2tJdUeIJcnF6fkGcTo0juX1BZgSyFkLaLXmcYMVtfMJdmYPpIb 9aDxX3Vl1ExOnC3yVDAlispEsJpvsFbmqkmDO5xp4ejlHcjHjrkkOYdGX5jM0ziO ns1yZCa7VW2FgZ1BfGUlPvViuf/JwoCl+FF6MCTiA9qYnEMBAkEA6npEERTfZtRN /3RhoLeEnU+tGspuL302AMCwZiaxdz2+oERVrLxzoyh8q9NjDyVNrBJfrfqf8/Fd 8KnRb0vq0QJBAM8lNDXoaMv8eLn8aKAOsz/fvOZdiat2pJylqsEl/vCksabymMHH VTOKvBJmoEmBZZPGiqYM72cUgdsaCJbGdGkCQQDB/N2LdEVPgZ32FocevDXPIDgK zidSyrh+7uwB10lDaaXoWiC3hEH3XmumjICL60TTc3ANNChZXftmPFi1R43BAkBq q/kADcfxy/kLpdznF8rdCMXJR7/+iWFpvbJ6NqvblqRZmbJqj9Djcv046JqAX99E Q0jhC+Y5Cgl5ICXuJxKJAkB+oRerGIBLzhKA2PiR05HqBZ9Uylg7GtVaCBhlbMUK Nqvni0dpY7b7uv8F0Xpu9CvT3ybVjZJFqiL1MVcmj3Rq -----END?RSA?PRIVATE?KEY-----可以直接將生成的私鑰通過重定向的方式導入文件，但openssl支持通過-out選項直接將生成的私鑰導出為指定文件，效果和重定向一樣，這里直接使用-out選項作為示例：
[root@localhost?~]#?openssl?genrsa?-out?/tmp/private.key?512 Generating?RSA?private?key,?512?bit?long?modulus .......++++++++++++ ....++++++++++++ e?is?65537?(0x10001) [root@localhost?~]#? [root@localhost?~]#? [root@localhost?~]#?cat?/tmp/private.key????//查看生成的private.key文件。 -----BEGIN?RSA?PRIVATE?KEY----- MIIBPAIBAAJBAOM4bUGEPA24bcWsB4qShkfddp/ChBAQ1REkuLASvs/c7wpjmhti C9+NS7hP1PIUL4drrGbu2PjxMhkqAmaahScCAwEAAQJAWViUzZBbtOFyeKn+hSS8 nIGe5Y8tMswLnCQeY03brgvqVY//JG8QRG9sIxRpD0saupLv5n8KI7hbt5Btin/r kQIhAPXMzCUmODyrd5Nv/oyeVPUrWoPgisziUWnpMZy+qrNbAiEA7KZA2FBGteBs axwlNrobCb7k4zX+yxKQ7R91YEhMGyUCIQDJyn8SRIVIsZAyd3Anq1ieCiB+QdpR h79EztAPGaz0HwIhAJp+Wz0dA1y/e+hdQoo862PsZP9Ug9fNciHr9LP73vulAiEA vVT+5vLL/6h31qIltgNn8Qdpd4DhMEn3aNQfj/eAPFs= -----END?RSA?PRIVATE?KEY-----但是！這樣會出現一個問題，我們不妨查看以下這個生成的私鑰文件的屬性：
[root@localhost?~]#?ll?/tmp/private.key -rw-r--r--.?1?root?root?497?Mar??6?00:44?/tmp/private.key一般生成的本地私鑰僅自己可見，且一般不放在/tmp目錄下（這里僅作為演示）。
所以我們可以在輸出私鑰時直接設置好權限，如下：
[root@localhost?~]#?(umask?077;?openssl?genrsa?-out?/tmp/private2.key?512) Generating?RSA?private?key,?512?bit?long?modulus ..............++++++++++++ .........++++++++++++ e?is?65537?(0x10001) [root@localhost?~]#? [root@localhost?~]#?ll?/tmp/private2.key? -rw-------.?1?root?root?497?Mar??6?00:51?/tmp/private2.key????//僅用戶自己能訪問。注意：這里使用了'umask 077'，將權限掩碼設置為'077'，這樣生成的私鑰文件的權限就是'600'了。這里還需要注意的是，在命令兩端用小括號括起來表示調用子shell執行括號中的命令，執行結束后即退出子shell，因為在子shell中設置的權限掩碼不會改變當前shell的權限掩碼。
因此，生成本地私鑰的格式為：
#?(umask?077;?openssl?genrsa?-out?/PATH/TO/PRIVATE_KEY_FILE?NUM_BITS)這里/PATH/TO/PRIVATE_KEY_FILE需要根據自己的需要替換為私鑰的輸出文件，NUM_BITS替換為生成私鑰的位長。
我們前面提到，公鑰是從私鑰中提取得到，這里就直接提取剛才生成的私鑰為例：
[root@localhost?~]#?openssl?rsa?-in?/tmp/private2.key?-pubout //其中-pubout選項表示提取出公鑰。 writing?RSA?key -----BEGIN?PUBLIC?KEY----- MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMeCHQUzzvDOqXvwsywlTW6LagW5Wz9U 0x5liKDtX//NJ2wHAmR/6kufaW+yw2pzBd7kFgrJTHTRkt4AnfZtsgECAwEAAQ== -----END?PUBLIC?KEY-----生成用戶密碼：
用戶密碼的生成工具有：passwd, openssl passwd
這里可以查看openssl的子命令passwd的幫助手冊：
[root@localhost?~]#?whatis?passwd passwd???????????????(1)??-?update?user's?authentication?tokens passwd???????????????(5)??-?password?file passwd?[sslpasswd]???(1ssl)??-?compute?password?hashes //此處標識為'1ssl'的第三項即為openssl的子命令passwd的幫助手冊。 [root@localhost?~]#?man?sslpasswd使用openssl生成用戶密碼格式如下：
#?openssl?passwd?-1?-salt?SALT這里'SALT'根據自己的需要進行替換。
示例：
[root@localhost?~]#?openssl?passwd?-1?-salt?hello1234 Password:? $1$hello123$281DIFsN1M4.qkU0KTrJN.需要注意的是，這里的'-1'表示使用md5算法進行單向加密，目前openssl還不支持使用sha512進行單向加密，因此不能使用'-6'標識sha512算法并使用之進行加密。
生成隨機數：
隨機數生成工具有：openssl rand
語法格式：
#?openssl?rand?-hex?NUM????//采用16進制編碼輸出。 #?openssl?rand?-base64?NUM????//采用文本編碼輸出。這里的'NUM'表示生成的隨機數的字節數，可根據自己的需要進行替換。
生成8個16進制隨機數：
[root@localhost?~]#?openssl?rand?-hex?4 7a3df49f產生base64編碼的100位隨機數：
[root@localhost?~]#?openssl?rand?-base64?100 U5lwC1cgtgfNJ9s55jU6xR0rpTsErzJ4mZUsR+kVrASZsvNyTP/q/7/E1sG8bRqc 3ZYCKISsK60Au5tnX16WgKRLr533axQgur7z/JhxEezcnc4wqSHsaq6nqvVBT3H9 oQTEzA==以8個16進制隨機數作為salt設置密碼：
[root@localhost?~]#?openssl?passwd?-1?-salt?$(openssl?rand?-hex?4) Password:? $1$9a9222ab$gMoHzmXOgGRMdTE54w5Jz0借助'openssl rand'來生成密碼是常用的技巧。
這里介紹一下Linux系統上的隨機數生成器：
/dev/random：僅從熵池返回隨機數，一旦熵池中的隨機數用盡，則會阻塞，導致程序無法取隨機數。 /dev/urandom：從熵池中返回隨機數，一旦熵池中的隨機數用盡，則會利用軟件生層偽隨機數，不 會導致阻塞；偽隨機數不安全。這里的熵池就是運行中的內核維護的一段內存空間，在這片內存空間中存放了大量隨機數，而在系統剛啟動時為空。熵池中隨機數的來源主要有：
(1)硬盤IO中斷時間間隔：當發生IO操作時，各個IO操作之間的時間差即作為隨機數，放在內存中。 (2)鍵盤IO中斷時間間隔：鍵盤的兩次擊鍵之間的時間差作為隨機數，放在內存中。因此由硬件產生的隨機數不具有可猜測性，相對于軟件產生的偽隨機數更安全。在安全性要求較高時不會使用/dev/urandom生成，因為有可能會生成偽隨機數，而偽隨機數不安全。
需要注意的是，一旦程序取了內存中的某個隨機數，則相當于“剪切”了內存中的這個隨機數（保證兩個程序取到的隨機數不同）。容易想到，如果程序取內存中隨機數的速度比生成隨機數的速度塊時，則有可能耗盡內存中的隨機數，在這種情況下就可能造成阻塞，程序需要等待熵池中的隨機數的生成。
如果阻塞了應該如何解決？方法之一自然是快速敲鍵盤以產生大量隨機數，而另一種方法是增加IO操作數，例如復制一個大文件至另外路徑下（會產生大量IO操作），第二種方法產生隨機數的速度要快得多。
通過openssl構建和管理私有CA：
CA有兩種，一種是公共信任的CA，另一種是私有CA。私有CA可用于實現小范圍內的證書驗證。
建立私有CA的工具有openssl和OpenCA，OpenCA是openssl的二次封裝，更為人性化。但熟練掌握openssl創建和管理私有CA能幫助我們更好地理解CA背后的工作機制，因此這里介紹openssl創建和管理私有CA。
當openssl命令基于CA工作時，配置文件為：/etc/pki/tls/openssl.cnf.
這里介紹以下配置文件中的一些配置項：
構建私有CA時，在確定配置為CA的服務器上生成一個自簽證書，并為CA提供所需要的目錄及文件即可。步驟如下：
(1)生成私鑰。
(2)生成自簽證書。
(3)為CA提供所需的目錄及文件。
下面一步步進行演示和說明。
演示之前，需要準備一臺CA服務器主機和HTTP服務器主機（后面實驗用到），它們的IP地址分別為：
CA服務器主機：10.10.10.140/24 HTTP服務器主機：10.10.10.139/24(1)生成私鑰。
[root@CA?~]#?(umask?077;?openssl?genrsa?-out?/etc/pki/CA/private/cakey.pem?4096) Generating?RSA?private?key,?4096?bit?long?modulus ....................++ ....................................................++ e?is?65537?(0x10001)需要注意的是，這里生成的私鑰文件名為cakey.pem，這個文件名必須和配置文件中的定義保持一致，并保證生成出來的私鑰文件的權限符合要求。
[root@CA?~]#?ll?/etc/pki/CA/private/cakey.pem? -rw-------.?1?root?root?3243?Mar?22?09:15?/etc/pki/CA/private/cakey.pem(2)生成自簽證書。
這里需要注意的是，我們知道證書中存放的是公鑰，但這里-key選項接著的是私鑰文件路徑，這是怎么回事呢？其實，這個命令在生成自簽證書時會自動從私鑰中提取出公鑰，并放入證書中。
各選項的意義：
-new：生成新證書簽署請求。 -x509：生成自簽格式證書，專用于創建私有CA時。 -key：生成請求證書用到的私鑰文件路徑。 -out：生成的請求文件路徑；如果是自簽操作，則直接生成簽署過的證書。 -days：證書的有效時長，單位是day。(3)為CA提供所需的目錄及文件。
創建所需的目錄及文件：
[root@CA?~]#?mkdir?-pv?/etc/pki/CA/{certs,crl,newcerts} [root@cA?~]#?touch?/etc/pki/CA/{serial,index.txt}需要注意的是，這里創建的文件有可能是系統上默認就存在的，如果不存在則創建。
serial這個文件需要給明第一個證書的號碼是多少：
[root@CA?~]#?echo?01?>?/etc/pki/CA/serial這里表示一旦要為其他服務器主機簽署證書時，這個要申請的證書的序列號為01，此后會自動遞增。
要用到證書進行安全通信的服務器，需要向CA請求簽署證書。步驟如下：
(1)用到證書的主機生成私鑰。
(2)生成證書簽署請求。
(3)將證書簽署請求通過可靠方式發送給CA主機。
(4)在CA主機上簽署證書，并通過可靠方式將簽署證書發送給申請證書簽署請求的主機。
這里以httpd服務器為例，若要基于https進行加密通信時，需要在Web服務器上做如下操作：
(1)Web服務器主機生成私鑰。
這里將生成的私鑰放置于/etc/httpd/ssl目錄下：
需要注意的是，這里在Web服務器主機上創建的私鑰文件放置目錄可根據自己需要存放，這一點和CA主機上的私鑰必須存放在/etc/pki/CA/private目錄下不同。
(2)Web服務器生成證書簽署請求。
[root@www?~]#?openssl?req?-new?-key?/etc/httpd/ssl/httpd.key?-out?/etc/httpd/ssl/httpd. csr?-days?365 //這里申請簽署1年期限的證書；由于不是生成自簽證書，因此不需要加上'-x509'選項。 You?are?about?to?be?asked?to?enter?information?that?will?be?incorporated into?your?certificate?request. What?you?are?about?to?enter?is?what?is?called?a?Distinguished?Name?or?a?DN. There?are?quite?a?few?fields?but?you?can?leave?some?blank For?some?fields?there?will?be?a?default?value, If?you?enter?'.',?the?field?will?be?left?blank. ----- Country?Name?(2?letter?code)?[XX]:CN State?or?Province?Name?(full?name)?[]:Guangdong Locality?Name?(eg,?city)?[Default?City]:Guangzhou Organization?Name?(eg,?company)?[Default?Company?Ltd]:iTab Organizational?Unit?Name?(eg,?section)?[]:Ops Common?Name?(eg,?your?name?or?your?server's?hostname)?[]:www.iTab.com Email?Address?[]:webmaster@iTab.comPlease?enter?the?following?'extra'?attributes to?be?sent?with?your?certificate?request A?challenge?password?[]:????//挑戰式密碼。 An?optional?company?name?[]:這里最后要求輸入的挑戰式密碼的作用在于，如果此處的Web服務器主機向CA服務器基于網絡發送證書簽署請求時，一旦被竊取，則會要求竊取者輸入挑戰式密碼才可以查看證書請求中的信息。這兩個密碼可以不填寫。
這里需要注意的是，由于剛才創建的CA是私有CA，而私有CA是在小范圍內進行通信的，因此Web服務器主機和CA服務器主機最好在同一地域、同一公司、同一單位內，否則有可能會出錯。
(3)通過可靠方式將Web服務器的證書簽署請求發送給CA主機。
這一步需要注意的是，一般是CA機構當面來到申請的服務器上拷貝證書簽署請求（例如U盤拷貝），而不使用網絡傳輸的方式。但這里僅是作為實驗環境，因此直接用遠程復制工具scp將Web服務器主機上的證書請求發送至CA主機上：
[root@www?~]#?scp?/etc/httpd/ssl/httpd.csr?root@10.10.10.140:/tmp/ root@10.10.10.140's?password:? httpd.csr????????????????????????????100%?1054?????1.0KB/s???00:00???? [root@www?~]#(4)在CA主機上簽署證書，并通過可靠方式將簽署證書發送給Web服務器。
CA主機收到了證書簽署請求：
為Web服務器主機簽署證書：
接著將證書通過可靠方式發送給Web服務器主機，這里在實驗環境下同樣使用scp命令即可：
[root@CA?~]#?scp?/etc/pki/CA/certs/httpd.crt?root@10.10.10.139:/etc/httpd/ssl/ root@10.10.10.139's?password:? httpd.crt?????????????????????????100%?5865?????5.7KB/s???00:00???? [root@www?~]#在Web服務器主機上查看：
[root@www?~]#?cd?/etc/httpd/ssl/ [root@www?ssl]#?ls httpd.crt??httpd.csr??httpd.key [root@www?ssl]#? [root@www?ssl]#?rm?-f?httpd.csr //因為已經有了已簽署的證書httpd.crt了，所以這里把httpd.csr這個證書請求刪除了。此外，如果有需要還可以在Web服務器主機或CA服務器主機上查看證書中的信息，這里在Web服務器主機上查看證書信息：
[root@www?ssl]#?openssl?x509?-in?/etc/httpd/ssl/httpd.crt?-noout?-serial?-subject serial=01 subject=?/C=CN/ST=Guangdong/O=iTab/OU=Ops/CN=www.iTab.com/emailAddress=webmaster@iTab.com相關選項：
-noout：不輸出編碼格式的證書信息。 -serial：輸出證書的序列號。 -subject：輸出證書的主體標識信息。在CA主機上同樣可以查看證書的序列號和主體標識信息：
[root@CA?~]#?openssl?x509?-in?/etc/pki/CA/certs/httpd.crt?-noout?-serial?-subject serial=01 subject=?/C=CN/ST=Guangdong/O=iTab/OU=Ops/CN=www.iTab.com/emailAddress=webmaster@iTab.com [root@CA?~]#吊銷證書時，步驟如下：
(1)客戶端獲取要吊銷的證書的serial和subject信息（在使用證書的主機上執行）。
(2)CA主機先根據客戶端提交的serial和subject信息，對比其與本地數據庫index.txt中的存儲是否一致；如果一致，則吊銷證書。
(3)生成吊銷證書的吊銷編號（第一次吊銷證書時執行）。
(4)更新證書吊銷列表。
這里繼續以上述例子進行示例。
(1)如果Web服務器主機要吊銷證書，首先應該獲取要吊銷的證書的serial和subject信息：
[root@www?~]#?openssl?x509?-in?/etc/httpd/ssl/httpd.crt?-noout?-serial?-subject?>? crl_info [root@www?~]#? [root@www?~]#?cat?crl_info????//查看生成的文件。 serial=01 subject=?/C=CN/ST=Guangdong/O=iTab/OU=Ops/CN=www.iTab.com/emailAddress=webmaster@iTab.com [root@www?~]#? [root@www?~]#? [root@www?~]#?scp?crl_info?root@10.10.10.140:/tmp/ //將serial和subject信息發送到CA主機。 root@10.10.10.140's?password:? crl_info??????????????????????????100%??100?????0.1KB/s???00:00(2)CA主機根據客戶端（Web服務器）提交的serial和subject信息，將其與本地數據庫index.txt中存儲的信息進行比較，如果一致，則可以吊銷該證書：
[root@CA?~]#?cat?/tmp/crl_info serial=01 subject=?/C=CN/ST=Guangdong/O=iTab/OU=Ops/CN=www.iTab.com/emailAddress=webmaster@iTab.com [root@CA?~]#? [root@CA?~]#?cat?/etc/pki/CA/index.txt V????180322051301Z????01????unknown????/C=CN/ST=Guangdong/O=iTab/OU=Ops/CN=www.iTab.com /emailAddress=webmaster@iTab.com????//對比結果一致。 [root@CA?~]#吊銷證書的語法格式：
# openssl ca -revoke /etc/pki/CA/newcerts/SERIAL.pem
其中的SERIAL要換成證書真正的序列號。
開始吊銷證書：
[root@CA?~]#?openssl?ca?-revoke?/etc/pki/CA/newcerts/01.pem????//這里序列號為01. Using?configuration?from?/etc/pki/tls/openssl.cnf Revoking?Certificate?01. Data?Base?Updated [root@CA?~]#? [root@CA?~]#?cat?/etc/pki/CA/index.txt R????180322051301Z????170322114603Z????01????unknown????/C=CN/ST=Guangdong/O=iTab/OU=Op s/CN=www.iTab.com/emailAddress=webmaster@iTab.com? //可以發現，CA主機上的數據庫index.txt中對應項中的首個字母變為'R'，表示已吊銷。(3)因為對于該私有CA來說是第一次吊銷其他主機的證書，因此需要生成吊銷證書的吊銷編號：
[root@CA?~]#?echo?01?>?/etc/pki/CA/crlnumber下次再吊銷其他證書時就不用執行這個操作了。
(4)更新證書吊銷列表：
[root@CA?~]#?openssl?ca?-gencrl?-out?/etc/pki/CA/thisca.crl使用ls查看：
查看crl文件：
[root@CA?~]#?openssl?crl?-in?/etc/pki/CA/thisca.crl?-noout?-text Certificate?Revocation?List?(CRL):????//證書吊銷列表。Version?2?(0x1)Signature?Algorithm:?sha256WithRSAEncryptionIssuer:?/C=CN/ST=Guangdong/L=Guangzhou/O=iTab/OU=Ops/CN=ca.iTab.com/emailAddress=caadmin@iTab.comLast?Update:?Mar?22?12:11:34?2017?GMTNext?Update:?Apr?21?12:11:34?2017?GMTCRL?extensions:X509v3?CRL?Number:?2 Revoked?Certificates:Serial?Number:?01Revocation?Date:?Mar?22?11:46:03?2017?GMTSignature?Algorithm:?sha256WithRSAEncryption3e:12:b2:12:23:c7:e2:fe:25:ea:3d:cd:16:ad:ea:01:9b:8f:94:0a:d4:78:95:87:09:55:6b:9b:6e:c3:34:e9:d1:8c:ca:a1:a0:7b:b6:50:01:31:d7:7b:b7:3a:50:94:39:ea:fa:0b:cb:79:63:53:28:c0:cc:66:55:2e:fa:f2:15:50:b4:66:4d:16:99:22:35:09:70:cc:1e:e1:5a:d5:2c:8a:cb:9b:95:5e:94:dc:fa:13:cf:21:dd:a4:8d:84:a9:ae:52:2f:1d:40:00:ae:ca:7a:9a:a7:bd:97:15:2e:6b:d7:ca:f7:44:cd:a3:41:58:19:ff:5a:50:48:bf:9d:4a:b5:c9:8c:ae:e8:b2:0e:53:95:63:63:0d:d2:ff:e8:64:3f:23:59:78:74:fd:ab:f8:2c:9b:fd:5d:31:41:9f:8a:42:da:06:23:0c:34:13:bf:10:0a:9a:eb:57:a4:03:85:14:5b:9c:b3:b5:c4:2f:38:be:9f:71:9f:70:a1:3e:cf:1e:b3:05:b1:67:38:6f:87:e0:44:69:b8:a8:b1:09:6e:6d:32:29:7c:49:cf:ae:46:7e:c4:e8:a9:58:b1:2c:37:db:4f:d1:19:61:d4:0c:38:b2:8f:61:97:bb:ce:cf:61:4d:15:c4:05:02:1e:e3:73:7c:0c:4c:54:de:33:80:b4:26:3c:95:0a:da:d0:68:cb:e3:ac:54:42:a5:0b:25:cf:63:f0:f2:d0:2c:69:c6:21:c1:21:cf:dd:e2:a5:a7:03:59:0d:18:53:b2:36:b6:03:a8:4a:38:7c:c2:51:31:0e:4f:f7:e7:d9:dd:63:63:42:39:23:38:75:89:07:0f:53:73:1e:d0:01:07:48:dd:c5:71:39:59:fc:31:c1:fd:5d:9c:eb:dd:58:e5:09:7f:23:84:9e:f9:23:05:bd:6a:9e:ba:67:ef:8b:98:3f:f8:1d:53:ac:22:63:57:19:b5:bc:6f:81:cd:d7:71:31:e8:a9:fd:bb:ac:03:2d:82:8e:f6:9c:25:dd:80:bd:30:5d:13:00:c8:4a:b4:f2:a6:7a:bd:53:8c:0b:68:bf:8d:b2:86:7f:b8:ce:fa:11:88:24:2a:d7:ae:d7:17:85:7f:fa:0e:79:bc:03:d4:a8:88:22:d9:a4:2a:ac:12:01:8f:e9:1e:a8:57:31:19:a1:2d:aa:8d:30:3e:13:e6:33:cd:f9:95:4f:1f:99:7e:65:5b:23:3a:f2:41:0c:12:c9:5b:22:4e:a8:29:be:25:75:8b:fc:5e:3d:aa:1c:42:93:87:98:33:e9:82:4c:ea:d6:20:2c:a3:29:8a:fd:43:63:07:a9:3c:ee:09:dc:04:31:ec:ec [root@CA?~]#十一、參考鏈接
RFC 4366,?Transport Layer Security (TLS) Extensions
轉載于:https://blog.51cto.com/xuweitao/1909366
總結
以上是生活随笔為你收集整理的加密和解密技术基础、PKI及创建私有CA的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python inport os 是什么
- 下一篇： ubuntn卸载显卡驱动后无法进入图形界