加密和解密技术基础、PKI及创建私有CA
一、數(shù)據(jù)加密和解密概述
數(shù)據(jù)加密和解密是一門歷史悠久的技術(shù)，從古代就已經(jīng)出現(xiàn)了，一直發(fā)展到當代。其中，數(shù)據(jù)加密的目的有很多，可以是為了保證本地數(shù)據(jù)存取的安全性，可以是為了保證數(shù)據(jù)流在網(wǎng)絡傳輸過程中的保密性，也可以是為了驗證數(shù)據(jù)的完整性，還可以通過數(shù)據(jù)加密來實現(xiàn)密鑰的交換等。
數(shù)據(jù)加密依賴于某種加密算法和加密密鑰，而數(shù)據(jù)解密則依賴于某種解密算法和解密密鑰。而在當代加密解密技術(shù)中，加密密鑰既可以與解密密鑰相同，也可以和解密密鑰不同，這取決于使用什么方法進行加解密。
二、安全的目標
就信息傳輸過程來說，安全目標有以下三個要點：
(1)保密性：確保通信雙方之間的通信數(shù)據(jù)不會被無關(guān)的第三方所竊取，這是最基本的要求。
(2)完整性：確保通信時數(shù)據(jù)不會丟失或被第三方篡改、破壞，一旦數(shù)據(jù)丟失或被篡改時，通信的一方能夠立即發(fā)現(xiàn)。
(3)可用性：確保授權(quán)用戶能夠按需合法訪問資源。
三、安全***類型
對應于以上的安全目標，分別有以下三種***類型：
(1)威脅保密性的***：竊聽/竊取、通信量分析；
(2)威脅完整性的***：篡改、偽裝、重放、否認；
(3)威脅可用性的***：拒絕服務(Dos)、分布式拒絕服務(DDos)；
四、安全防范的解決方案
為了防范安全***，可以分別從技術(shù)層面上和服務層面上防范：
(1)技術(shù)層面：提供加密和解密技術(shù)。這個層面解決了本地數(shù)據(jù)存儲加密和通信過程中數(shù)據(jù)加密的一系列問題，可分為傳統(tǒng)加密算法和現(xiàn)代加密算法：
????①傳統(tǒng)加密算法：替換加密算法、置換加密算法；
????②現(xiàn)代加密算法：現(xiàn)代塊加密方法
(2)服務層面：提供用于抵御***以及為了達到上述安全目標而特地設(shè)計的服務。在這一層面上主要有認證機制和訪問控制機制：
????①認證機制：確定訪問資源的用戶是誰、通信對方的身份是否為期望的另一方等；
????②訪問控制機制：確定某個用戶是否有權(quán)限訪問資源；如果有權(quán)限訪問資源，再進一步確定用戶所能夠訪問的資源以及對資源能夠執(zhí)行的操作（查看、使用、修改、創(chuàng)建等）；
在以上技術(shù)和服務這兩個層面中會用到的密鑰算法和協(xié)議有對稱加密、公鑰加密（非對稱加密）、單向加密以及認證協(xié)議。接下來介紹在實現(xiàn)安全通信過程中所用到的加密算法以及它們的實現(xiàn)。
五、加密算法和實現(xiàn)
1、對稱加密
(1)特點：加密和解密使用同一個密鑰；通信時，雙方要想實現(xiàn)基于對稱加密算法來實現(xiàn)通信需要預先共享密鑰。
(2)用途：用于實現(xiàn)數(shù)據(jù)保密性。
(3)常見算法：
①DES：Data Encryption Standard，即數(shù)據(jù)加密標準。DES算法是以64bits(8Bytes)為塊，在加密端把數(shù)據(jù)分成多塊，對每塊數(shù)據(jù)(64bits)進行加密，生成64bits密文；在解密端則把64bits密文轉(zhuǎn)換為64bits明文。各個塊之間建立一定的聯(lián)系，DES使用16個迭代塊來完成迭代。其中，加密和解密使用56bits密鑰。
②3DES：Triple DES，即三輪DES加密機制。3DES加密次數(shù)是DES的三個數(shù)量級(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模式，則服務器端與每一個客戶端之間的通信都必須使用不同的密鑰，造成服務器端密鑰過多的問題。
②密鑰分發(fā)困難：對稱加密可實現(xiàn)通信時數(shù)據(jù)加密功能，但問題是雙方通信之前必須交互密鑰，而密鑰在交換過程中也同樣保證保密性，這時會造成密鑰分發(fā)困難的問題，必須依賴于一種安全的方法來實現(xiàn)密鑰的交換。
2、非對稱加密
(1)特點：也稱為公鑰加密。加密和解密數(shù)據(jù)使用不同的密鑰，例如用公鑰加密的數(shù)據(jù)只能使用與之配對的私鑰進行解密，而用私鑰加密則只能使用與之配對的公鑰進行解密。相比于對稱加密，公鑰加密可把公鑰直接公開，即使公鑰在通信時被竊取，因為沒有與之配對的私鑰，所以仍然無法解密數(shù)據(jù)。
????①公鑰：public key，從私鑰中提取產(chǎn)生，可公開給所有人。
????②私鑰：secret key，通過工具創(chuàng)建生成，由使用者自己留存，必須保證其私密性。
(2)用途：
①數(shù)字簽名：主要用于讓接受方確認發(fā)送方的身份。
②密鑰交換：通過對方的公鑰加密一個對稱密鑰，并發(fā)送給對方，對方通過其私鑰解密之后就可以獲取對稱密鑰了。這解決了上述對稱加密算法中密鑰分發(fā)困難這一問題。
③數(shù)據(jù)加密：這種直接使用公鑰加密算法來實現(xiàn)通信時數(shù)據(jù)的保密性的方式并不常用，因為這種方式要比使用對稱加密慢上3個數(shù)量級，不推薦。
(3)常見算法：
①RSA：名稱由RSA三個提出者(Ron Rivest,?Adi Shamir,?Leonard Adleman)的姓氏首字母組合而成，這種算法的可靠性由對極大整數(shù)做因數(shù)分解的難度決定；RSA既能實現(xiàn)數(shù)字簽名，又能實現(xiàn)加解密。
②DSA：Digital Signature Algorithm，即數(shù)字簽名算法，又稱DSS(Digital Signature Standard, 數(shù)字簽名標準)；DSA僅能實現(xiàn)數(shù)字簽名，不能用于加解密。
③其他公鑰加密算法有ELGamal等。
(4)缺陷：通信效率低。
3、單向加密
(1)特點：提取數(shù)據(jù)特征碼，只能加密，不能解密，它是基于兩個特性。
????①定長輸出：提取出來的數(shù)據(jù)量是定長的，與進行加密的數(shù)據(jù)的量無關(guān)。
????②雪崩效應：初始條件的微小改變會引起加密結(jié)果的巨大變化。
(2)用途：用于實現(xiàn)數(shù)據(jù)完整性的驗證。
(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)
兩種實現(xiàn)方式：
①公鑰加密：常見的算法有RSA等。
②DH算法：Deffie-Hellman(迪菲-赫爾曼)算法。
③其他用于實現(xiàn)密鑰交換的算法有：ECDH(橢圓曲線DH)、ECDHE(臨時橢圓曲線DH)等。
?
以下為DH算法的工作原理圖：
以下為更一般的描述：
Alice生成隨機自然數(shù)a、隨機大質(zhì)數(shù)p和原根g；
Alice計算，計算結(jié)果為A，并把p,g,A發(fā)送給Bob；
Bob生成隨機自然數(shù)b，根據(jù)Alice發(fā)過來的p,g，計算，計算結(jié)果為B；
Bob把B發(fā)送給Alice，并計算，計算結(jié)果為K；而Alice計算，計算結(jié)果也為K；
Alice和Bob以K值作為密鑰進行通信。
注意：在整個密鑰協(xié)商過程中，p、g、和的值是可以公開給***者的，而a,b,K值是不公開的。但即使***者知道、p和g的值，也無法計算出a，同理，***者無法通過、g和g的值計算出b，更不用說計算出K值(最終Alice和Bob協(xié)商好的密鑰)了。這個問題就是著名的離散對數(shù)問題。
六、一次加密通信的過程
這里以發(fā)送方Alice和接收方Bob為例。
加密和發(fā)送過程：
1、當發(fā)送方Alice有數(shù)據(jù)要發(fā)送給Bob時，為了確保數(shù)據(jù)能夠完整地發(fā)送至Bob，首先需要使用單向加密算法去計算出這段要發(fā)送的數(shù)據(jù)的特征碼；
2、為了便于Bob收到數(shù)據(jù)之后可驗證身份，發(fā)送方Alice使用本地私鑰加密這段特征碼，并將加密后的特征碼附加在數(shù)據(jù)后面；
3、為了確保通信過程是保密的，發(fā)送方Alice生成一個臨時的對稱密鑰，并使用這個對稱密鑰加密整段數(shù)據(jù)；
4、發(fā)送方Alice獲取Bob的公鑰，再使用Bob的公鑰加密來加密剛才生成的臨時的對稱密鑰，并把加密后的對稱密鑰附加在整段加密數(shù)據(jù)后面，而后發(fā)送給Bob。
接收和解密過程：
接收和解密的過程和解密發(fā)送的過程剛好相反。
1、接收方Bob收到數(shù)據(jù)之后，先使用自己的私鑰去解密這段加密過的對稱密鑰(由Alice生成)；
2、接收方Bob用解密得到的對稱密鑰去解密整段（發(fā)送方用對稱密鑰）加密的內(nèi)容；此時接收方Bob得到Alice發(fā)送給自己的數(shù)據(jù)和加密后的特征碼；
3、接收方Bob用對方Alice的公鑰去解密這段特征碼，如果能解密出來，則發(fā)送方的身份得到驗證（沒錯，就是Alice發(fā)送的）；
4、接收方Bob再用同樣的單向加密算法去計算這段數(shù)據(jù)的特征碼，與解密得到的特征碼進行比較，如果相同，則數(shù)據(jù)完整性得到驗證，否則說明數(shù)據(jù)有可能被篡改或被破壞。
圖解加密通信過程：
問題總結(jié)：
(1)什么是數(shù)字簽名？
數(shù)字簽名就是對數(shù)據(jù)的特征碼進行加密。(2)如何保證公鑰不被篡改？
解決方法：將公鑰放在證書中。只要證書是可信的，那么公鑰就是可信的。(3)公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），雙方都生成一個臨時的“會話密鑰”（session?key），用來 加密信息。由于“會話密鑰”是對稱加密，因此運算速度快，比公鑰加密快3個數(shù)量級，而公鑰加密 本身只用于加密“會話密鑰”本身，這樣就減少了耗用的時間。七、數(shù)字證書認證機構(gòu)--CA
前面的加密通信過程中能夠保證通信過程的保密性、通信數(shù)據(jù)的完整性，但這是以雙方(Alice和Bob)能夠在此之前可靠地獲取對方的公鑰為前提的。如果不能保證能夠可靠獲取對方公鑰，那么就有可能出現(xiàn)中間人***（Man-in-the-middle attack，縮寫：MITM）。假設(shè)這個中間人是Eve，Eve就可以分別與Alice和Bob建立聯(lián)系，而這時Alice獲取的是“假的”Bob公鑰，而Bob獲取的是“假的”Alice公鑰；這時候Alice和Bob在毫不知情的情況下進行通信，但其實他們之間數(shù)據(jù)包的轉(zhuǎn)發(fā)是經(jīng)由Eve的，如圖：
上述的通信過程中缺失的一環(huán)在于通信雙方不能保證可靠地獲取對方的公鑰，因此，為了保證可靠地獲取通信對方的公鑰，于是就有了數(shù)字證書認證機構(gòu)(Certificate Authority，縮寫：CA)。CA就是為了能夠保證通信雙方能夠可靠獲取對方的公鑰，而特地設(shè)定的一個雙方公信的第三方可信機構(gòu)。威瑞信（VeriSign）就是其中一家非常有名的數(shù)字證書認證機構(gòu)。
為了避免出現(xiàn)上述一環(huán)的缺失，Alice和Bob可向公信的CA申請有效的證書，并由CA分別頒發(fā)給Alice和Bob，其中這個證書中的信息包括了證書擁有者的名稱、公鑰、證書的有效期等信息，而CA還會提取證書中信息的特征碼，并用CA自己的私鑰進行加密，再把加密后的特征碼附加在證書中最后面。此后，當雙方通信時，Alice和Bob雙方都把自己的證書發(fā)給對方，并都分別使用CA的公鑰去解密證書中的特征碼，如果能解密，則說明證書的確由他們所信任的CA機構(gòu)所頒發(fā)；接著使用同樣的單向加密算法去提取證書中信息的特征碼，與解密出來的特征碼進行比較，如果兩者相同，說明證書內(nèi)容完整，沒有被篡改或破壞，而對方的證書中就有對方的公鑰。
但這又引入了一個問題，Alice和Bob如何可靠地獲取CA的呢?顯然，不能基于網(wǎng)絡通信的方式獲取CA的公鑰（否則又會出現(xiàn)中間人***等問題），而應該當面交易。全球有多個CA機構(gòu)，這些CA的數(shù)量是有限、基本固定的；它們彼此之間存在互信鏈，也就是說CA的信任關(guān)系是可以傳遞的。為了管理方便，全球有一個根CA，它與其他CA是從屬關(guān)系。
為了解決通信主機能夠可靠獲取CA的公鑰，CA需要自簽一份證書，就是CA自簽名證書，在證書信息中包括了CA的名稱、CA的公鑰等，通信主機（這里是Alice和Bob）需要獲取CA證書，這樣才能獲取CA公鑰以及其他的CA信息，并能通過CA證書來驗證其他通信主機的證書是否可靠。CA證書的獲取需要通過當面交易來實現(xiàn)，而微軟公司直接在windows操作系統(tǒng)上集成了在全球具有公信力的CA證書，但在Linux中一般不內(nèi)置CA證書，需要自己通過可靠手段獲取。
雖然通過上述手段可以極大地保證通信過程的安全性，但仍然存在問題，例如在這整個通信過程中使用的某種算法出現(xiàn)漏洞依然不夠安全。
八、公鑰基礎(chǔ)設(shè)施--PKI
以上述為例子，如果Alice的私鑰丟失或者被竊取，則需要立即向CA機構(gòu)申請吊銷證書，聲明證書作廢，將損失將至最低；為了能夠第一時間讓其他人知道證書已經(jīng)吊銷，可以通過各種媒體來傳播，例如新聞、報紙等。由此可見，CA不單要頒發(fā)證書，還需要提供證書吊銷列表，公開聲明有哪些證書已經(jīng)吊銷及不能再信任。因此，為了可以更好地管理CA，發(fā)展出了一套以CA為核心的體系--公鑰基礎(chǔ)設(shè)施（Public Key Infrastructure，縮寫為：PKI）。
PKI架構(gòu)主要包括以下四部分：
①簽證機構(gòu)：Certificate Authority，縮寫為CA；負責簽署證書；
②注冊機構(gòu)：Registration Authority，縮寫為RA；負責接收簽署證書的申請；
③證書吊銷列表：Certificate Revocation List，縮寫為CRL；負責公開所有已經(jīng)吊銷的證書；
④證書存取庫：Certificate Repository，縮寫為CR；負責將公開所有已申請的證書的相關(guān)信息；
為了統(tǒng)一數(shù)字證書的格式，國際電信聯(lián)盟（ITU-T）制定了數(shù)字證書標準--X.509，即數(shù)字證書的格式遵循X.509標準。在X.509v3版本中，定了數(shù)字證書的結(jié)構(gòu)以及認證協(xié)議標準。而由X.509v3定義的數(shù)字證書應該包括以下幾個部分：
1. 版本號
2. 序列號（標識第幾個證書）
3. 簽名算法
4. 發(fā)行者名稱（CA名稱）
5. 有效期限
6. 主體名稱
7. 主體公鑰
8. 發(fā)行者的唯一標識
9. 主體的唯一標識
10. 擴展信息
11. 發(fā)行者的簽名（即CA對整個證書的簽名；CA把以上內(nèi)容進行單向加密，得到特征碼；再使用CA自己的私鑰對特征碼進行加密，并附在證書后面，用來生成發(fā)行者數(shù)字簽名）
九、總結(jié)：CA如何在A和B通信之間發(fā)揮作用？
基本過程：
1、首先，在A和B通信之前需要互相發(fā)送證書；
2、A和B之間協(xié)商通信過程中要使用的加密算法（對稱加密、公鑰加密、單向加密、密鑰交換）；
3、開始驗證證書：
1)用CA的公鑰去解密CA的簽名，如果能解密，則說明證書來源可靠；
2)用同樣的單向加密算法計算出證書中信息的特征碼，與解密得到的特征碼進行比較；如果兩者相同，則說明證書完整性可靠；
3)檢查證書的有效日期是否在當前時間的合理范圍內(nèi)；如果證書過期了則不會被認可；
4)檢查證書的主體名稱與期望通信的對方是否一致；如果不一致則不會被認可；
5)檢查證書是否被吊銷過；如果沒有吊銷則可使用該證書，否則證書不會被認可。
注意：在每次通信過程中，以上步驟一步也不能少；另外，A和B需要事先獲取CA自簽名證書，因為持有CA自簽名證書是用來驗證CA頒發(fā)給其他人或主機的證書的前提。
十、SSL/TLS概述
1、為什么需要SSL？
我們知道，服務程序一般都會存在bug，***只要找到服務程序的bug就可以基于網(wǎng)絡進行***。對于這種情況，我們的服務程序邏輯要盡可能做得足夠安全，但程序總會有bug，因此需要做好安全防范，解決思路是使用一個監(jiān)控程序?qū)λ械馁Y源訪問做監(jiān)控，如果***者想做一些未經(jīng)授權(quán)的資源訪問，則這個監(jiān)控程序自動報警。通俗地來講，就是“一旦它把手伸到不該伸的地方就報警”，這是一種輔助機制。但這種輔助機制只能確保本地服務程序不會被違規(guī)機制所訪問到，不能確保資源在網(wǎng)絡傳輸過程是安全的。
在早期計算機未普及時，使用計算機網(wǎng)絡進行通信的主機很少，網(wǎng)絡安全不是很受到重視。而在早期設(shè)計的一些協(xié)議本身就不具備加解密功能，例如http,ftp,smtp,pop3等協(xié)議。即便后來隨著互聯(lián)網(wǎng)的發(fā)展，網(wǎng)絡安全得到越來越多的關(guān)注，這些協(xié)議也很難在其中添加加解密功能，因為早期的很多協(xié)議已經(jīng)成為了網(wǎng)絡通信的公共功能和基礎(chǔ)設(shè)施，一旦在這些基礎(chǔ)協(xié)議（例如http）添加上加解密功能，則會牽一發(fā)而動全身，各個依賴于這些基礎(chǔ)服務程序開發(fā)出來的程序勢必會受到影響。
因此，網(wǎng)景公司為http協(xié)議研發(fā)設(shè)計了一種可被調(diào)用的功能模塊，這個功能模塊所處的位置在應用層和傳輸層之間的半層，作為公共功能庫，也稱為半層庫。任何程序在研發(fā)時可調(diào)用這個半層庫以實現(xiàn)加解密和密鑰分發(fā)的功能，不調(diào)用則不使用。這個半層庫就是SSL庫。
2、SSL是什么？
SSL（Secure Sockets Layer，安全套接字層）是一種安全的加解密協(xié)議，它的實現(xiàn)也是需要程序（算法）來實現(xiàn)。SSL是位于應用層和傳輸層之間的半層庫，基于任何其它協(xié)議（例如HTTP、FTP等）進行通信時，只要調(diào)用了SSL這半層庫就可以實現(xiàn)安全加密通信了。SSL的功能包括加密、數(shù)字證書認證、完整性保護。而對SSL協(xié)議的一種開源實現(xiàn)OpenSSL程序就可以完成這些功能。基于HTTP協(xié)議進行通信時，只要調(diào)用了SSL庫，就可以實現(xiàn)基于HTTPS進行更安全的通信了，因此HTTPS不是一個新的應用層協(xié)議。因為調(diào)用了SSL庫，因此基于HTTPS進行通信同樣可實現(xiàn)加密通信、數(shù)字證書認證、完整性保護等功能了。通常，HTTP直接和TCP通信，一旦使用SSL，則HTTP變成和SSL通信，再由SSL和TCP進行通信了。
SSL是一種公共功能，但SSL本身只是一種規(guī)范和協(xié)議，需要程序員開發(fā)出一種遵循SSL協(xié)議規(guī)范的程序來實現(xiàn)。對于其他協(xié)議和程序也一樣，例如httpd、nginx是HTTP協(xié)議的服務端程序?qū)崿F(xiàn)，而各種瀏覽器如IE、Chrome及Firefox等則是HTTP協(xié)議的客戶端程序?qū)崿F(xiàn)；在Windows界面上的遠程終端程序Xshell、在Linux上的SSH程序也是SSH協(xié)議的客戶端程序?qū)崿F(xiàn)。而SSL協(xié)議在Linux上的開源實現(xiàn)有OpenSSL和GPG，其中OpenSSL是SSL協(xié)議和SSL庫的實現(xiàn)，而GPG是PGP協(xié)議的實現(xiàn)，Openssl和GPG也是密鑰算法和協(xié)議的實現(xiàn)。
任何一個加密解密庫（例如ssl庫）要求必須滿足以下兩個功能：
①實現(xiàn)加解密的基本功能；
②能夠基于網(wǎng)絡通信方式實現(xiàn)密鑰分發(fā)。
3、加密通信協(xié)議歷史
1994年，NetScape公司設(shè)計了主要用于Web的SSL?1.0版，但因漏洞太多所以沒有發(fā)布。 1995年，NetScape公司發(fā)布了SSL?2.0版，但同樣有很多漏洞。 1996年，SSL?3.0版問世，由NetScape發(fā)布，并得到大規(guī)模應用。 1999年，IEIF將SSL標準化，發(fā)布了SSL的升級版TLS?1.0。 2006年和2008年，TLS進行了兩次升級，分別發(fā)布了TLS?1.1和TLS?1.2。 截止至2016年1月，TLS?1.3仍然處于草案階段。協(xié)議：
SSL：Secure?Sockets?Layer，安全套接字層協(xié)議。 TLS：Transport?Layer?Security，傳輸層安全協(xié)議。目前應用最廣泛的是TLS 1.2版，在主瀏覽器上都有支持。
TLS 1.0通常被標識為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。
4、SSL/TLS分層設(shè)計
雖然SSL/TLS主要是為了實現(xiàn)加解密以及密鑰分發(fā)的功能，但也采用了分層設(shè)計規(guī)范來對其進行實現(xiàn)，各分層設(shè)計如下：
1、最底層：基礎(chǔ)算法原語的實現(xiàn)，如aes,rsa,md5等。 2、再上一層：各種算法的實現(xiàn)。 3、再上一層：各種組合算法實現(xiàn)的半成品。 4、最上層：用各種組件拼裝而成的各種成品密碼學協(xié)議軟件。SSL/TLS采用分層設(shè)計的好處在于SSL/TLS可以提供諸多應用程序在不同級別進行調(diào)用，可以直接調(diào)用其軟件程序，也可以調(diào)用其半成品，甚至可以調(diào)用其算法。
5、SSL/TLS協(xié)議的基本過程
(1)客戶端向服務器端索要并驗證證書。 (2)雙方協(xié)商生成“會話密鑰”。 (3)雙方采用“會話密鑰”進行加密通信。上面過程的前兩步，又稱為“握手階段”(handshake)。
握手階段的詳細過程：
“握手階段”一共有四個步驟，我們一個個來看。需要注意的是，在“握手階段”過程中，客戶端和服務端之間的通信是明文的。
5.1 客戶端發(fā)出請求（ClientHello）
首先，由客戶端（通常是瀏覽器）向服務器端發(fā)送一個加密通信請求，這個就叫做ClientHello請求。
在這一步中，客戶端主要向服務器提供以下信息：
這里需要注意的是，客戶端向服務器發(fā)送的信息中不包括服務器的域名，這是因為從理論上一個服務器只能包含一個網(wǎng)站，否則會分不清客戶端請求的是哪個網(wǎng)站的證書，這也是為什么一臺服務器上只有一張數(shù)字證書的原因。
顯然，這對于虛擬主機來說非常不方便，因此TLS協(xié)議在2006年時添加了Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。
5.2 服務器回應（ServerHello）
服務器接收到客戶端的請求后，就會作出回應，這就叫做ServerHello。服務器的回應應該包括以下內(nèi)容：
處理上面這些信息，如果服務器需要確認客戶端的身份，就會在這一步中再添加一項請求，即要求客戶端提供“客戶端證書”。比如，金融機構(gòu)往往只允許客戶連接入自己的網(wǎng)絡，在這個網(wǎng)絡中創(chuàng)建了其私有CA；并且，金融機構(gòu)會向正式客戶提供一個USB密鑰，里面就包含有一張證書。
5.3 客戶端回應
客戶端收到服務器回應后，首先要驗證服務器證書。如果證書不是可信CA機構(gòu)頒布、或者證書中完整性驗證不通過、或者證書已經(jīng)過期、或者證書持有者與客戶端期望通信的主機不一致、或者證書已經(jīng)吊銷，就會向訪問者發(fā)出一個警告，由其選擇是否要繼續(xù)通信。
如果證書確認無誤，就會從證書中取出服務器的公鑰，并向服務器發(fā)送以下內(nèi)容：
(1)一個隨機數(shù)。該隨機數(shù)用服務器公鑰加密，防止被竊聽。 (2)編碼變更通知，表示隨后的信息將用雙方商定的加密方法和密鑰發(fā)送。 (3)客戶端握手結(jié)束通知，表示客戶端握手階段已經(jīng)結(jié)束。這一項同時也是前面發(fā)送的所有內(nèi)容的 hash值，用來供服務器校驗，在這一步中客戶端發(fā)送給服務器端的隨機數(shù)是整個握手階段中的第三個隨機數(shù)，又稱"pre-master key"。有了它之后，客戶端和服務器就同時有了三個隨機數(shù)，接著雙方就用事先商定的加密方法，各自由這三個隨機數(shù)生成同一把本次通信要用到的“會話密鑰”。
至于為什么為什么一定要用三個隨機數(shù)來生成“會話密鑰”：
(1)不管是客戶端還是服務器，都要使用隨機數(shù)，確保每次通信生成的臨時“會話密鑰”都不相同。 (2)由于SSL協(xié)議中的證書是靜態(tài)的，因此很有必要引入一種隨機的因素，來確保通信中使用的“會 話密鑰”足夠隨機，不具有可猜測性。 (3)SSL協(xié)議不信任通信雙方的主機能夠生成真正的隨機數(shù)，因為如果隨機數(shù)是軟件生成的，那么這 個由軟件生成的隨機數(shù)就有章可循，生成的只是偽隨機數(shù)，因此為了避免這一情況，就將客戶端、 服務端的隨機數(shù)和pre-master-secret（或者pre-master?key，由客戶端生成）這個隨機數(shù)“合并”、“攪和”起來，通過 密鑰生成器生成一個“會話密鑰”，使其足夠隨機，不具有可猜測性。此外，如果在前一步中，服務器需要向客戶端請求證書時，則在這一步中客戶端會向服務器發(fā)送“客戶端證書”。
5.4 服務器的最后回應
服務器收到客戶端的發(fā)來的第三個隨機數(shù)"pre-master-secret"之后，計算生成本次會話用到的“會話密鑰”。而后，向客戶端發(fā)送如下內(nèi)容：
至此，整個握手階段全部結(jié)束。接下來，客戶端與服務器進入加密通信。如果是基于HTTPS進行加密通信，握手階段之后的通信過程就完全使用普通的HTTP協(xié)議了，只不過使用“會話密鑰”加密內(nèi)容。
6、SSL/TLS的開源實現(xiàn)
前面提到，SSL/TLS的開源實現(xiàn)為OpenSSL和GPG，這里介紹OpenSSL。
OpenSSL的組件：
OpenSSL是對SSL/TLS協(xié)議、SSL/TLS庫的實現(xiàn)，其組件包括以下三部分：
①libcrypto庫：加密解密庫，專門用于實現(xiàn)加密解密功能。
②libssl庫：用于實現(xiàn)ssl安全通信機制的庫。
③openssl多用途命令行工具：可實現(xiàn)加解密功能，以及模擬ssl實現(xiàn)安全通信功能。
需要注意的是，如果只是使用加解密功能，而不需要實現(xiàn)網(wǎng)絡通信，則直接調(diào)用libcrypto庫即可；如果既要使用加解密功能，又要實現(xiàn)網(wǎng)絡安全通信，則可以調(diào)用libcrypo庫和libssl庫。而openssl這個工具則內(nèi)部封裝了libcrypto庫和libssl庫，可以實現(xiàn)上述加解密和安全通信的功能。libcrypto庫和libssl庫主要由開發(fā)者寫程序時調(diào)用。
接下來介紹這個openssl多用途命令行工具對上述密鑰算法和協(xié)議的實現(xiàn)。
openssl有眾多子命令，這些子命令可分為三類：
查看：
接下來介紹如何使用openssl命令實現(xiàn)對稱加密、單向加密、公鑰加密，以及如何生成用戶密碼和隨機數(shù)。
對稱加密：
(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算法結(jié)合密鑰才能加密。 Verifying?-?enter?des-ede3-cbc?encryption?password:????//再次確認密鑰。 [root@localhost?~]#? [root@localhost?~]#?cat?test.cipher????//重新查看加密后的文本。 U2FsdGVkX18R/MdkP4l4Z8Gxrgfdsf6zne+EBjC4zWWunysQw39QYw==????//已加密為密文。說明（enc子命令）：
-d：表示解密。 -e：表示加密。 -ciphername：表示加密算法的名稱。 -salt：表示在加密時添加雜質(zhì)。 -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 //根據(jù)自己需要選擇即可。單向加密操作：
[root@localhost?~]#?openssl?dgst?-md5?test MD5(test)=?00843d3c93ab6f87ed642a66960a6815使用其他工具也能得到相同的加密結(jié)果：
[root@localhost?~]#?md5sum?test 00843d3c93ab6f87ed642a66960a6815??test公鑰加密：
前面提到，公鑰加密的用途有三個：數(shù)字簽名、密鑰交換、數(shù)據(jù)加密解密，它們各自的實現(xiàn)方式如下：
(1)數(shù)字簽名：
①工具：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-----但是！這樣會出現(xiàn)一個問題，我們不妨查看以下這個生成的私鑰文件的屬性：
[root@localhost?~]#?ll?/tmp/private.key -rw-r--r--.?1?root?root?497?Mar??6?00:44?/tmp/private.key一般生成的本地私鑰僅自己可見，且一般不放在/tmp目錄下（這里僅作為演示）。
所以我們可以在輸出私鑰時直接設(shè)置好權(quán)限，如下：
[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'，將權(quán)限掩碼設(shè)置為'077'，這樣生成的私鑰文件的權(quán)限就是'600'了。這里還需要注意的是，在命令兩端用小括號括起來表示調(diào)用子shell執(zhí)行括號中的命令，執(zhí)行結(jié)束后即退出子shell，因為在子shell中設(shè)置的權(quán)限掩碼不會改變當前shell的權(quán)限掩碼。
因此，生成本地私鑰的格式為：
#?(umask?077;?openssl?genrsa?-out?/PATH/TO/PRIVATE_KEY_FILE?NUM_BITS)這里/PATH/TO/PRIVATE_KEY_FILE需要根據(jù)自己的需要替換為私鑰的輸出文件，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'根據(jù)自己的需要進行替換。
示例：
[root@localhost?~]#?openssl?passwd?-1?-salt?hello1234 Password:? $1$hello123$281DIFsN1M4.qkU0KTrJN.需要注意的是，這里的'-1'表示使用md5算法進行單向加密，目前openssl還不支持使用sha512進行單向加密，因此不能使用'-6'標識sha512算法并使用之進行加密。
生成隨機數(shù)：
隨機數(shù)生成工具有：openssl rand
語法格式：
#?openssl?rand?-hex?NUM????//采用16進制編碼輸出。 #?openssl?rand?-base64?NUM????//采用文本編碼輸出。這里的'NUM'表示生成的隨機數(shù)的字節(jié)數(shù)，可根據(jù)自己的需要進行替換。
生成8個16進制隨機數(shù)：
[root@localhost?~]#?openssl?rand?-hex?4 7a3df49f產(chǎn)生base64編碼的100位隨機數(shù)：
[root@localhost?~]#?openssl?rand?-base64?100 U5lwC1cgtgfNJ9s55jU6xR0rpTsErzJ4mZUsR+kVrASZsvNyTP/q/7/E1sG8bRqc 3ZYCKISsK60Au5tnX16WgKRLr533axQgur7z/JhxEezcnc4wqSHsaq6nqvVBT3H9 oQTEzA==以8個16進制隨機數(shù)作為salt設(shè)置密碼：
[root@localhost?~]#?openssl?passwd?-1?-salt?$(openssl?rand?-hex?4) Password:? $1$9a9222ab$gMoHzmXOgGRMdTE54w5Jz0借助'openssl rand'來生成密碼是常用的技巧。
這里介紹一下Linux系統(tǒng)上的隨機數(shù)生成器：
/dev/random：僅從熵池返回隨機數(shù)，一旦熵池中的隨機數(shù)用盡，則會阻塞，導致程序無法取隨機數(shù)。 /dev/urandom：從熵池中返回隨機數(shù)，一旦熵池中的隨機數(shù)用盡，則會利用軟件生層偽隨機數(shù)，不 會導致阻塞；偽隨機數(shù)不安全。這里的熵池就是運行中的內(nèi)核維護的一段內(nèi)存空間，在這片內(nèi)存空間中存放了大量隨機數(shù)，而在系統(tǒng)剛啟動時為空。熵池中隨機數(shù)的來源主要有：
(1)硬盤IO中斷時間間隔：當發(fā)生IO操作時，各個IO操作之間的時間差即作為隨機數(shù)，放在內(nèi)存中。 (2)鍵盤IO中斷時間間隔：鍵盤的兩次擊鍵之間的時間差作為隨機數(shù)，放在內(nèi)存中。因此由硬件產(chǎn)生的隨機數(shù)不具有可猜測性，相對于軟件產(chǎn)生的偽隨機數(shù)更安全。在安全性要求較高時不會使用/dev/urandom生成，因為有可能會生成偽隨機數(shù)，而偽隨機數(shù)不安全。
需要注意的是，一旦程序取了內(nèi)存中的某個隨機數(shù)，則相當于“剪切”了內(nèi)存中的這個隨機數(shù)（保證兩個程序取到的隨機數(shù)不同）。容易想到，如果程序取內(nèi)存中隨機數(shù)的速度比生成隨機數(shù)的速度塊時，則有可能耗盡內(nèi)存中的隨機數(shù)，在這種情況下就可能造成阻塞，程序需要等待熵池中的隨機數(shù)的生成。
如果阻塞了應該如何解決？方法之一自然是快速敲鍵盤以產(chǎn)生大量隨機數(shù)，而另一種方法是增加IO操作數(shù)，例如復制一個大文件至另外路徑下（會產(chǎn)生大量IO操作），第二種方法產(chǎn)生隨機數(shù)的速度要快得多。
通過openssl構(gòu)建和管理私有CA：
CA有兩種，一種是公共信任的CA，另一種是私有CA。私有CA可用于實現(xiàn)小范圍內(nèi)的證書驗證。
建立私有CA的工具有openssl和OpenCA，OpenCA是openssl的二次封裝，更為人性化。但熟練掌握openssl創(chuàng)建和管理私有CA能幫助我們更好地理解CA背后的工作機制，因此這里介紹openssl創(chuàng)建和管理私有CA。
當openssl命令基于CA工作時，配置文件為：/etc/pki/tls/openssl.cnf.
這里介紹以下配置文件中的一些配置項：
構(gòu)建私有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，這個文件名必須和配置文件中的定義保持一致，并保證生成出來的私鑰文件的權(quán)限符合要求。
[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：生成自簽格式證書，專用于創(chuàng)建私有CA時。 -key：生成請求證書用到的私鑰文件路徑。 -out：生成的請求文件路徑；如果是自簽操作，則直接生成簽署過的證書。 -days：證書的有效時長，單位是day。(3)為CA提供所需的目錄及文件。
創(chuàng)建所需的目錄及文件：
[root@CA?~]#?mkdir?-pv?/etc/pki/CA/{certs,crl,newcerts} [root@cA?~]#?touch?/etc/pki/CA/{serial,index.txt}需要注意的是，這里創(chuàng)建的文件有可能是系統(tǒng)上默認就存在的，如果不存在則創(chuàng)建。
serial這個文件需要給明第一個證書的號碼是多少：
[root@CA?~]#?echo?01?>?/etc/pki/CA/serial這里表示一旦要為其他服務器主機簽署證書時，這個要申請的證書的序列號為01，此后會自動遞增。
要用到證書進行安全通信的服務器，需要向CA請求簽署證書。步驟如下：
(1)用到證書的主機生成私鑰。
(2)生成證書簽署請求。
(3)將證書簽署請求通過可靠方式發(fā)送給CA主機。
(4)在CA主機上簽署證書，并通過可靠方式將簽署證書發(fā)送給申請證書簽署請求的主機。
這里以httpd服務器為例，若要基于https進行加密通信時，需要在Web服務器上做如下操作：
(1)Web服務器主機生成私鑰。
這里將生成的私鑰放置于/etc/httpd/ssl目錄下：
需要注意的是，這里在Web服務器主機上創(chuàng)建的私鑰文件放置目錄可根據(jù)自己需要存放，這一點和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?[]:????//挑戰(zhàn)式密碼。 An?optional?company?name?[]:這里最后要求輸入的挑戰(zhàn)式密碼的作用在于，如果此處的Web服務器主機向CA服務器基于網(wǎng)絡發(fā)送證書簽署請求時，一旦被竊取，則會要求竊取者輸入挑戰(zhàn)式密碼才可以查看證書請求中的信息。這兩個密碼可以不填寫。
這里需要注意的是，由于剛才創(chuàng)建的CA是私有CA，而私有CA是在小范圍內(nèi)進行通信的，因此Web服務器主機和CA服務器主機最好在同一地域、同一公司、同一單位內(nèi)，否則有可能會出錯。
(3)通過可靠方式將Web服務器的證書簽署請求發(fā)送給CA主機。
這一步需要注意的是，一般是CA機構(gòu)當面來到申請的服務器上拷貝證書簽署請求（例如U盤拷貝），而不使用網(wǎng)絡傳輸?shù)姆绞健５@里僅是作為實驗環(huán)境，因此直接用遠程復制工具scp將Web服務器主機上的證書請求發(fā)送至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主機上簽署證書，并通過可靠方式將簽署證書發(fā)送給Web服務器。
CA主機收到了證書簽署請求：
為Web服務器主機簽署證書：
接著將證書通過可靠方式發(fā)送給Web服務器主機，這里在實驗環(huán)境下同樣使用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 //因為已經(jīng)有了已簽署的證書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相關(guān)選項：
-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信息（在使用證書的主機上執(zhí)行）。
(2)CA主機先根據(jù)客戶端提交的serial和subject信息，對比其與本地數(shù)據(jù)庫index.txt中的存儲是否一致；如果一致，則吊銷證書。
(3)生成吊銷證書的吊銷編號（第一次吊銷證書時執(zhí)行）。
(4)更新證書吊銷列表。
這里繼續(xù)以上述例子進行示例。
(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信息發(fā)送到CA主機。 root@10.10.10.140's?password:? crl_info??????????????????????????100%??100?????0.1KB/s???00:00(2)CA主機根據(jù)客戶端（Web服務器）提交的serial和subject信息，將其與本地數(shù)據(jù)庫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????//對比結(jié)果一致。 [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? //可以發(fā)現(xiàn)，CA主機上的數(shù)據(jù)庫index.txt中對應項中的首個字母變?yōu)?#39;R'，表示已吊銷。(3)因為對于該私有CA來說是第一次吊銷其他主機的證書，因此需要生成吊銷證書的吊銷編號：
[root@CA?~]#?echo?01?>?/etc/pki/CA/crlnumber下次再吊銷其他證書時就不用執(zhí)行這個操作了。
(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
轉(zhuǎn)載于:https://blog.51cto.com/xuweitao/1909366
總結(jié)
以上是生活随笔為你收集整理的加密和解密技术基础、PKI及创建私有CA的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： python inport os 是什么
- 下一篇： ubuntn卸载显卡驱动后无法进入图形界