SSL 單雙向驗(yàn)證原理為了便于更好的認(rèn)識(shí)和理解 SSL 協(xié)議，這里著重介紹 SSL 協(xié)議的握手協(xié)議。SSL 協(xié)議既用到了公鑰加密技術(shù)又用到了對(duì)稱加密技術(shù)，對(duì)稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公

SSL 單雙向驗(yàn)證原理

為了便于更好的認(rèn)識(shí)和理解 SSL 協(xié)議，這里著重介紹 SSL 協(xié)議的握手協(xié)議。SSL 協(xié)議既用到了公鑰加密技術(shù)又用到了對(duì)稱加密技術(shù)，對(duì)稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)。SSL 的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認(rèn)證，其主要過程如下：

①客戶端的瀏覽器向服務(wù)器傳送客戶端 SSL 協(xié)議的版本號(hào)，加密算法的種類，產(chǎn)生的隨機(jī)數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。 ②服務(wù)器向客戶端傳送 SSL 協(xié)議的版本號(hào)，加密算法的種類，隨機(jī)數(shù)以及其他相關(guān)信息，同時(shí)服務(wù)器還將向客戶端傳送自己的證書。

③客戶利用服務(wù)器傳過來的信息驗(yàn)證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒有通過，通訊將斷開；如果合法性驗(yàn)證通過，將繼續(xù)進(jìn)行第四步。(身份認(rèn)證)

④用戶端隨機(jī)產(chǎn)生一個(gè)用于后面通訊的“對(duì)稱密碼”，然后用服務(wù)器的公鑰（服務(wù)器的公鑰從步驟②中的服務(wù)器的證書中獲得）對(duì)其加密，然后將加密后的“預(yù)主密碼”傳給服務(wù)器。

⑤如果服務(wù)器要求客戶的身份認(rèn)證（在握手過程中為可選），用戶可以建立一個(gè)隨機(jī)數(shù)然后對(duì)其進(jìn)行數(shù)據(jù)簽名，將這個(gè)含有簽名的隨機(jī)數(shù)和客戶自己的證書以及加密過的“預(yù)主密碼”一起傳給服務(wù)器。

⑥如果服務(wù)器要求客戶的身份認(rèn)證，服務(wù)器必須檢驗(yàn)客戶證書和簽名隨機(jī)數(shù)的合法性，具體的合法性驗(yàn)證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發(fā)行 CA 的公鑰能否正確解開客戶證書的發(fā)行 CA 的數(shù)字簽名，檢查客戶的證書是否在證書廢止列表（CRL ）中。檢驗(yàn)如果沒有通過，通訊立刻中斷；如果驗(yàn)證通過，服務(wù)器將用自己的私鑰解開加密的“預(yù)主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生主通訊密碼（客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼）。

⑦服務(wù)器和客戶端用相同的主密碼即“通話密碼”，一個(gè)對(duì)稱密鑰用于 SSL 協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時(shí)在 SSL 通訊過程中還要完成數(shù)據(jù)通訊的完整性，防止數(shù)據(jù)通訊中的任何變化。

⑧客戶端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對(duì)稱密鑰，同時(shí)通知服務(wù)器客戶端的握手過程結(jié)束。

⑨服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對(duì)稱密鑰，同時(shí)通知客戶端服務(wù)器端的握手過程結(jié)束。

⑩ SSL 的握手部分結(jié)束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶和服務(wù)器開始使用相同的對(duì)稱密鑰進(jìn)行數(shù)據(jù)通訊，同時(shí)進(jìn)行通訊完整性的檢驗(yàn)。

雙向認(rèn)證 SSL 協(xié)議的具體過程

①瀏覽器發(fā)送一個(gè)連接請(qǐng)求給安全服務(wù)器。

②服務(wù)器將自己的證書，以及同證書相關(guān)的信息發(fā)送給客戶瀏覽器。

③客戶瀏覽器檢查服務(wù)器送過來的證書是否是由自己信賴的 CA 中心所簽發(fā)的。如果是，就繼續(xù)執(zhí)行協(xié)議；如果不是，客戶瀏覽器就給客戶一個(gè)警告消息：警告客戶這個(gè)證書不是可以信賴的，詢問客戶是否需要繼續(xù)。

④接著客戶瀏覽器比較證書里的消息，例如域名和公鑰，與服務(wù)器剛剛發(fā)送的相關(guān)消息是否一致，如果是一致的，客戶瀏覽器認(rèn)可這個(gè)服務(wù)器的合法身份。 ⑤服務(wù)器要求客戶發(fā)送客戶自己的證書。收到后，服務(wù)器驗(yàn)證客戶的證書，如果沒有通過驗(yàn)證，拒絕連接；如果通過驗(yàn)證，服務(wù)器獲得用戶的公鑰。

⑥客戶瀏覽器告訴服務(wù)器自己所能夠支持的通訊對(duì)稱密碼方案。

⑦服務(wù)器從客戶發(fā)送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密后通知瀏覽器。

⑧瀏覽器針對(duì)這個(gè)密碼方案，選擇一個(gè)通話密鑰，接著用服務(wù)器的公鑰加過密后發(fā)送給服務(wù)器。

⑨服務(wù)器接收到瀏覽器送過來的消息，用自己的私鑰解密，獲得通話密鑰。 ⑩服務(wù)器、瀏覽器接下來的通訊都是用對(duì)稱密碼方案，對(duì)稱密鑰是加過密的。 上面所述的是雙向認(rèn)證 SSL 協(xié)議的具體通訊過程，這種情況要求服務(wù)器和用戶雙方都有證書。單向認(rèn)證 SSL 協(xié)議不需要客戶擁有 CA 證書，具體的過程相對(duì)于上面的步驟，只需將服務(wù)器端驗(yàn)證客戶證書的過程去掉，以及在協(xié)商對(duì)稱密碼方案，對(duì)稱通話密鑰時(shí)，服務(wù)器發(fā)送給客戶的是沒有加過密的（這并不影響 SSL 過程的安全性）密碼方案。這樣，雙方具體的通訊內(nèi)容，就是加過密的數(shù)據(jù)，如果有第三方攻擊，獲得的只是加密的數(shù)據(jù)，第三方要獲得有用的信息，就需要對(duì)加密的數(shù)據(jù)進(jìn)行解密，這時(shí)候的安全就依賴于密碼方案的安全。而幸運(yùn)的是，目前所用的密碼方案，只要通訊密鑰長(zhǎng)度足夠的長(zhǎng)，就足夠的安全。這也是我們強(qiáng)調(diào)要求使用 128位加密通訊的原因。

1 SSL通訊示意圖

SSL 通訊示意圖如圖1所示：

2 SSL通訊說明

在該部分，將對(duì)圖1所示的示意圖進(jìn)行說明。為了說明的方便，在本文中稱客戶端為B ，服務(wù)器端為S 。

STEP 1: B——〉S （發(fā)起對(duì)話，協(xié)商傳送加密算法）

你好,S ！我想和你進(jìn)行安全對(duì)話，我的對(duì)稱加密算法有DES,RC5，我的密鑰交換算法有RSA 和DH ，摘要算法有MD5和SHA 。

STEP2: S——〉B （發(fā)送服務(wù)器數(shù)字證書）

你好,B ！那我們就使用DES －RSA －SHA 這對(duì)組合進(jìn)行通訊，為了證明我確實(shí)是S ，現(xiàn)在發(fā)送我的數(shù)字證書給你，你可以驗(yàn)證我的身份。

STEP 3: B——〉S （傳送本次對(duì)話的密鑰）

（檢查S 的數(shù)字證書是否正確，通過CA 機(jī)構(gòu)頒發(fā)的證書驗(yàn)證了S 證書的真實(shí)有效性后。生成了利用S 的公鑰加密的本次對(duì)話的密鑰發(fā)送給S ）

S, 我已經(jīng)確認(rèn)了你的身份，現(xiàn)在將我們本次通訊中使用的對(duì)稱加密算法的密鑰發(fā)送給你。

STEP4: S——〉B （獲取密鑰）

（S 用自己的私鑰解密獲取本次通訊的密鑰）。

B, 我已經(jīng)獲取了密鑰。我們可以開始通信了。

STEP5: S<——>B（進(jìn)行通訊）

說明：一般情況下，當(dāng)B 是保密信息的傳遞者時(shí)，B 不需要數(shù)字證書驗(yàn)證自己身份的真實(shí)性，如電子銀行的應(yīng)用，客戶需要將自己的賬號(hào)和密碼發(fā)送給銀行，因此銀行的服務(wù)器需要安裝數(shù)字證書來表明自己身份的有效性。在某些B2B 應(yīng)用，服務(wù)器端也需要對(duì)客戶端的身份進(jìn)行驗(yàn)證，這時(shí)客戶端也需要安裝數(shù)字證書以保證通訊時(shí)服務(wù)器可以辨別出客戶端的身份，驗(yàn)證過程類似于服務(wù)器身份的驗(yàn)證過程。

此外需要說明的是，在一些電子商務(wù)的應(yīng)用中，可能還會(huì)使用到電子簽名，或者為了信息交換的更加安全，會(huì)增加電子簽名和消息校驗(yàn)碼（MAC ）。

3 相關(guān)知識(shí)介紹

隨著電子商務(wù)的不斷發(fā)展，SSL 協(xié)議得到了越來越廣泛的使用。SSL 協(xié)議是介于HTTP 協(xié)議與TCP 之間的一個(gè)可選層，可以將其表示如下

下面我們通過一個(gè)例子來講解一下如何通過SSL 協(xié)議來訪問安全網(wǎng)頁(yè)，假如我們?cè)诰W(wǎng)上購(gòu)買游戲卡，在游戲網(wǎng)頁(yè)上我們點(diǎn)擊了付款，將進(jìn)入如下界面：

這時(shí)我們注意到在瀏覽器的地址欄的開頭是HTTPS 而不是HTTP ，在瀏覽器的右下角有一把鎖，說明已經(jīng)建立起SSL 加密通道。在如上過程中HTTP 層首先將請(qǐng)求轉(zhuǎn)換成HTTP 請(qǐng)求，然后SSL 層通過TCP 和IP 層實(shí)現(xiàn)了瀏覽器和服務(wù)器的握手（HANDSHAKE ），服務(wù)器層獲得密鑰，最后TCP 層與服務(wù)器之間建立了加密通道，實(shí)現(xiàn)了雙方安全交換信息的目的。

為了便于了解SSL ，下面在簡(jiǎn)要介紹一下信息加密相關(guān)知識(shí)。使用密鑰類型加密信息的加密算法可以分為以下幾類：HASH 編碼、對(duì)稱加密和非對(duì)稱加密三類。

HASH 編碼是使用HASH 算法從任意長(zhǎng)度的消息中計(jì)算HASH 值的一個(gè)過程，HASH 值可以說是消息的指紋，因?yàn)閷?duì)于任何不同的消息，幾乎總有不同的HASH 值。因此在SSL 通訊過程中，可以對(duì)消息的HASH 值進(jìn)行加密，確保傳遞的消息在傳輸過程中沒有被修改。

非對(duì)稱加密或稱之為公鑰加密使用數(shù)學(xué)上相關(guān)的兩個(gè)數(shù)值來對(duì)信息進(jìn)行編碼（加密），其中一個(gè)數(shù)字稱為公鑰，另一個(gè)稱為私鑰。公鑰加密的信息可以用私鑰解密，私鑰加密的信息可以用公鑰解密。由于公鑰可以大面積發(fā)放，因此公鑰加密在SSL 加密通信中應(yīng)用于對(duì)密鑰的加密或者進(jìn)行數(shù)字簽名。

對(duì)稱加密和非對(duì)稱加密相比的區(qū)別在于對(duì)稱加密中，加密信息和解密信息使用同樣的密鑰，因此該密鑰無法公開。但是其具有加密、解密快速的特點(diǎn)。

在SSL 通訊中，首先采用非對(duì)稱加密交換信息，使得服務(wù)器獲得瀏覽器端提供的對(duì)稱加密的密鑰，然后利用該密鑰進(jìn)行通訊過程中信息的加密和解密。為了保證消息在傳遞過程中沒有被篡改，可以加密HASH 編碼來確保信息的完整性。

服務(wù)器數(shù)字證書主要頒發(fā)給Web 站點(diǎn)或其他需要安全鑒別的服務(wù)器，證明服務(wù)器的身份信息，同樣客戶端數(shù)字證書用于證明客戶端的身份。在廣東省電子商務(wù)認(rèn)證中心網(wǎng)站上，可以看到對(duì)該機(jī)構(gòu)頒發(fā)的各種數(shù)字證書詳細(xì)的功能描述。

SSL 協(xié)議的握手和通訊

為了便于更好的認(rèn)識(shí)和理解 SSL 協(xié)議，這里著重介紹 SSL 協(xié)議的握手協(xié)議。SSL 協(xié)議既用到了公鑰加密技術(shù)又用到了對(duì)稱加密技術(shù)，對(duì)稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快，可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)。SSL 的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認(rèn)證，其主要過程如下：

① 客戶端的瀏覽器向服務(wù)器傳送客戶端 SSL 協(xié)議的版本號(hào)，加密算法的種類，產(chǎn)生的隨機(jī)數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。

② 服務(wù)器向客戶端傳送 SSL 協(xié)議的版本號(hào)，加密算法的種類，隨機(jī)數(shù)以及其他相關(guān)信息，同時(shí)服務(wù)器還將向客戶端傳送自己的證書。

③ 客戶利用服務(wù)器傳過來的信息驗(yàn)證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實(shí)際域名相匹配。如果合法性驗(yàn)證沒有通過，通訊將斷開；如果合法性驗(yàn)證通過，將繼續(xù)進(jìn)行第四步。

④ 用戶端隨機(jī)產(chǎn)生一個(gè)用于后面通訊的“對(duì)稱密碼”，然后用服務(wù)器的公鑰（服務(wù)器的公鑰從步驟②中的服務(wù)器的證書中獲得）對(duì)其加密，然后將加密后的“預(yù)主密碼”傳給服務(wù)器。

⑤ 如果服務(wù)器要求客戶的身份認(rèn)證（在握手過程中為可選），用戶可以建立一個(gè)隨機(jī)數(shù)然后對(duì)其進(jìn)行數(shù)據(jù)簽名，將這個(gè)含有簽名的隨機(jī)數(shù)和客戶自己的證書以及加密過的“預(yù)主密碼”一起傳給服務(wù)器。 ⑥ 如果服務(wù)器要求客戶的身份認(rèn)證，服務(wù)器必須檢驗(yàn)客戶證書和簽名隨機(jī)數(shù)的合法性，具體的合法性驗(yàn)證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的 CA 是否可靠，發(fā)行 CA 的公鑰能否正確解開客戶證書的發(fā)行 CA 的數(shù)字簽名，檢查客戶的證書是否在證書廢止列表（CRL ）中。檢驗(yàn)如果沒有通過，通訊立刻中斷；如果驗(yàn)證通過，服務(wù)器將用自己的私鑰解開加密的“預(yù)主密碼”，然后執(zhí)行一系列步驟來產(chǎn)生主通訊密碼（客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼）。

⑦ 服務(wù)器和客戶端用相同的主密碼即“通話密碼”，一個(gè)對(duì)稱密鑰用于 SSL 協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時(shí)在 SSL 通訊過程中還要完成數(shù)據(jù)通訊的完整性，防止數(shù)據(jù)通訊中的任何變化。

⑧ 客戶端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對(duì)稱密鑰，同時(shí)通知服務(wù)器客戶端的握手過程結(jié)束。

⑨ 服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對(duì)稱密鑰，同時(shí)通知客戶端服務(wù)器端的握手過程結(jié)束。

⑩ SSL 的握手部分結(jié)束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶和服務(wù)器開始使用相同的對(duì)稱密鑰進(jìn)行數(shù)據(jù)通訊，同時(shí)進(jìn)行通訊完整性的檢驗(yàn)。

雙向認(rèn)證 SSL 協(xié)議的具體過程

① 瀏覽器發(fā)送一個(gè)連接請(qǐng)求給安全服務(wù)器。

② 服務(wù)器將自己的證書，以及同證書相關(guān)的信息發(fā)送給客戶瀏覽器。

③ 客戶瀏覽器檢查服務(wù)器送過來的證書是否是由自己信賴的 CA 中心所簽發(fā)的。如果是，就繼續(xù)執(zhí)行協(xié)議；如果不是，客戶瀏覽器就給客戶一個(gè)警告消息：警告客戶這個(gè)證書不是可以信賴的，詢問客戶是否需要繼續(xù)。

④ 接著客戶瀏覽器比較證書里的消息，例如域名和公鑰，與服務(wù)器剛剛發(fā)送的相關(guān)消息是否一致，如果是一致的，客戶瀏覽器認(rèn)可這個(gè)服務(wù)器的合法身份。

⑤ 服務(wù)器要求客戶發(fā)送客戶自己的證書。收到后，服務(wù)器驗(yàn)證客戶的證書，如果沒有通過驗(yàn)證，拒絕連接；如果通過驗(yàn)證，服務(wù)器獲得用戶的公鑰。

⑥ 客戶瀏覽器告訴服務(wù)器自己所能夠支持的通訊對(duì)稱密碼方案。

⑦ 服務(wù)器從客戶發(fā)送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密后通知瀏覽器。

⑧ 瀏覽器針對(duì)這個(gè)密碼方案，選擇一個(gè)通話密鑰，接著用服務(wù)器的公鑰加過密后發(fā)送給服務(wù)器。 ⑨ 服務(wù)器接收到瀏覽器送過來的消息，用自己的私鑰解密，獲得通話密鑰。

⑩ 服務(wù)器、瀏覽器接下來的通訊都是用對(duì)稱密碼方案，對(duì)稱密鑰是加過密的。

上面所述的是雙向認(rèn)證 SSL 協(xié)議的具體通訊過程，這種情況要求服務(wù)器和用戶雙方都有證書。單向認(rèn)證 SSL 協(xié)議不需要客戶擁有 CA 證書，具體的過程相對(duì)于上面的步驟，只需將服務(wù)器端驗(yàn)證客戶證書的過程去掉，以及在協(xié)商對(duì)稱密碼方案，對(duì)稱通話密鑰時(shí)，服務(wù)器發(fā)送給客戶的是沒有加過密的（這并不影響 SSL 過程的安全性）密碼方案。 這樣，雙方具體的通訊內(nèi)容，就是加過密的數(shù)據(jù)，如果有第三方攻擊，獲得的只是加密的數(shù)據(jù)，第三方要獲得有用的信息，就需要對(duì)加密的數(shù)據(jù)進(jìn)行解密，這時(shí)候的安全就依賴于密碼方案的安全。而幸運(yùn)的是，目前所用的密碼方案，只要通訊密鑰長(zhǎng)度足夠的長(zhǎng)，就足夠的安全。這也是我們強(qiáng)調(diào)要求使用 128 位加密通訊的原因。

證 書 各 部 分 的 含 義

Version 證書版本號(hào)，不同版本的證書格式不同

Serial Number 序列號(hào)，同一身份驗(yàn)證機(jī)構(gòu)簽發(fā)的證書序列號(hào)唯一

Algorithm Identifier 簽名算法，包括必要的參數(shù) Issuer 身份驗(yàn)證機(jī)構(gòu)的標(biāo)識(shí)信息

Period of Validity 有效期

Subject 證書持有人的標(biāo)識(shí)信息

Subject ’s Public Key 證書持有人的公鑰

Signature 身份驗(yàn)證機(jī)構(gòu)對(duì)證書的簽名

證書的格式 認(rèn)證中心所發(fā)放的證書均遵循 X.509 V3 標(biāo)準(zhǔn)，其基本格式如下：

證書版本號(hào)（Certificate Format Version） 含義：用來指定證書格式采用的 X.509 版本號(hào)。

證書序列號(hào)（Certificate Serial Number） 含義：用來指定證書的唯一序列號(hào)，以標(biāo)識(shí) CA 發(fā)出的所有公鑰證書。

簽名（Signature ） 算法標(biāo)識(shí)（Algorithm Identifier） 含義：用來指定 CA 簽發(fā)證書所用的簽名算法。

簽發(fā)此證書的 CA 名稱（Issuer ） 含義：用來指定簽發(fā)證書的 CA 的 X.500 唯一名稱（DN ， Distinguished Name）。

證書有效期（Validity Period） 起始日期（notBefore ） 終止日期（notAfter ） 含義：用來指定證書起

始日期和終止日期。

用戶名稱（Subject ） 含義：用來指定證書用戶的 X.500 唯一名稱（DN ，Distinguished Name）。

用戶公鑰信息（Subject Public Key Information） 算法（algorithm ） 算法標(biāo)識(shí)（Algorithm Identi fier ） 用戶公鑰（subject Public Key ） 含義：用來標(biāo)識(shí)公鑰使用的算法，并包含公鑰本身。 證書擴(kuò)充部分（擴(kuò)展域）（Extensions ） 含義：用來指定額外信息。

X.509 V3 證書的擴(kuò)充部分（擴(kuò)展域）及實(shí)現(xiàn)方法如下： CA 的公鑰標(biāo)識(shí)（Authority Key Identifier ） 公鑰標(biāo)識(shí)（SET 未使用）（Key Identifier ） 簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificate Issu er ） 簽發(fā)證書者證書的序列號(hào)（Certificate Serial Number）

X.509 V3 證書的擴(kuò)充部分（擴(kuò)展域）及實(shí)現(xiàn)CA 的公鑰標(biāo)識(shí)（Authority Key Identifier ） 公鑰標(biāo)識(shí)（SET 未使用）（Key Identifier ） 簽發(fā)證書者證書的簽發(fā)者的甄別名（Certificat 簽發(fā)證書者證書的序列號(hào)（Certificate Serial N含義：CA 簽名證書所用的密鑰對(duì)的唯一標(biāo)識(shí)用戶的公鑰標(biāo)識(shí)（Subject Key Identifier ） 含義：用來標(biāo)識(shí)與證書中公鑰相關(guān)的特定密鑰進(jìn)行解密。 證書中的公鑰用途（Ke y Usage ） 含義：用來指定公鑰用途。

用戶的私鑰有效期（Private Key Usage Period ） 起始日期（Note Before ） 終止日期（Note Aft er ） 含義：用來指定用戶簽名私鑰的起始日期和終止日期。 CA 承認(rèn)的證書政策列表（Certificate Policies ） 含義：用來指定用戶證書所適用的政策，證書政策可由對(duì)象標(biāo)識(shí)符表示。 用戶的代用名（Subst itutional Name ） 含義：用來指定用戶的代用名。 CA 的代用名（Issuer Alt Name ） 含義：用來指定 CA 的代用名。 基本制約（Basic Constraints ） 含義：用來表明證書用戶是最終用戶還是 CA。 在 SET 系統(tǒng)中有一些私有擴(kuò)充部分（擴(kuò)展域）Hashed Root Key 含義：只在根證書中使用，用于證書更新時(shí)進(jìn)行回溯。 證書類型（Certificate Type ） 含義：用來區(qū)別不同的實(shí)體。該項(xiàng)是必選的。 商戶數(shù)據(jù)（Merchant Data ） 含義：包含支付網(wǎng)關(guān)需要的所有商戶信息。 持卡人證書需求（Card Cert Requir ed ） 含義：顯示支付網(wǎng)關(guān)是否支持與沒有證書的持卡人進(jìn)行交易。 SET 擴(kuò)展（SETExtensions ） 含義：列出支付網(wǎng)關(guān)支持的支付命令的 SET 信息擴(kuò)展。 CRL 數(shù)據(jù)定義版本（Version ） 含義：顯示 CRL 的版本號(hào)。

CRL 的簽發(fā)者（Issuer ） 含義：指明簽發(fā) CRL 的 CA 的甄別名。 CRL 發(fā)布時(shí)間（this Update ） 預(yù)計(jì)下一個(gè) CRL 更新時(shí)間（Next Update ） 撤銷證書信息目錄（Revoked Certificates ） CRL 擴(kuò)展（CRL Extension ） CA 的公鑰標(biāo)識(shí)（Authority Key Identifier ） CRL 號(hào)（CRL Number ）

一、SSL 會(huì)話中DH 算法與RSA 算法之間的區(qū)別：

區(qū)別有二：

1、 在DH 算法中，雙方中的一方會(huì)給一方傳送G ，另一方給對(duì)方傳送B ，這樣雙方用G 、

B 、雙方各自傳送的隨機(jī)數(shù)產(chǎn)生一個(gè)PRE －MASTER －KEY ，這個(gè)PRE －MASTER －KEY 會(huì)再與各自的隨機(jī)數(shù)在一起進(jìn)行運(yùn)算得出MASTER －KEY 。

而RSA 算法中，雙方不會(huì)互傳G 與B ，而是由CLIENT 產(chǎn)生一個(gè)數(shù)值，并且用對(duì)方的公鑰進(jìn)行加密，傳送給服務(wù)器方，由服務(wù)器方使用自己的私鑰進(jìn)行解密，之后雙方使用這個(gè)數(shù)與各自的隨機(jī)數(shù)進(jìn)行運(yùn)算產(chǎn)生PRE －MASTER －KEY ，之后的過程就完全一樣。

2、 在雙向認(rèn)證過程中，客戶需要向服務(wù)器端提交證書，并進(jìn)行數(shù)字簽名以證明對(duì)證書的合

法擁有權(quán)。

二、MASTER －KEY 是否是會(huì)話加密用的對(duì)稱密鑰：

不是，MASTER －KEY 根據(jù)雙方協(xié)商好的加密算法按長(zhǎng)度對(duì)MASTER －KEY 進(jìn)行劃分，

比如對(duì)稱算法使用3DES ，則長(zhǎng)度為168位，而HASH 算法如果是MD5－40，則劃分40位的長(zhǎng)度出來。這個(gè)MASTER －KEY 的長(zhǎng)度是按事先協(xié)商好的加密算法對(duì)應(yīng)的長(zhǎng)度計(jì)算的。

三、選用RSA 還是DH 算法？

是通過服務(wù)器HELLO 包中雙方商定的，雙方商定的辦法包括握手期間的非對(duì)稱算法、傳送數(shù)據(jù)時(shí)的對(duì)稱算法、及HASH 算法等。

四、在實(shí)際傳送數(shù)據(jù)時(shí)，數(shù)據(jù)用對(duì)稱算法加密，并用HASH 算法作防止篡改。

五、SSL 復(fù)用的概念：

1、在HTTPS 應(yīng)用中，一個(gè)TCP －CONN 中使用一個(gè)SSL －CONN ，在一個(gè)TCP －CONN

中傳遞的所有的HTTP －REQUEST 與HTTP －RESPONSE 都使用同一個(gè)SSL －CONN ；

2、而如果新的HTTP 包發(fā)現(xiàn)沒有可用的TCP －CONN 存在時(shí)，會(huì)新建一條TCP －CONN ，這時(shí)如果CLIENT 與SERVER 雙方同意進(jìn)行SSL 復(fù)用時(shí)就首先進(jìn)行SSL 復(fù)用（雙方同意使用SSL 復(fù)用的意向是通過在復(fù)用的CLIENT －HELLO 與SERVER －HELLO 包里面存在的，里面有想復(fù)用的SSL 會(huì)話ID ）復(fù)用的結(jié)果就是使用原來SSL －SESS 中的所有已協(xié)商的結(jié)果，包含對(duì)方的證書信息，使用的加密算法、產(chǎn)生的PRE －MASTER －KEY 等；這樣就省略了SSL 握手期間非對(duì)稱加密的很耗費(fèi)系統(tǒng)資源的過程。

3、注意：每條TCP －CONN 對(duì)應(yīng)一條SSL －CONN ，而一條SSL －SESSION 可能會(huì)包含了多條SSL －CONN ，即被其所復(fù)用，每條復(fù)用的SSL －CONN 中的PRE －MASTER －KEY 是一樣的，但由于在復(fù)用期間雙方再次交換HELLO 包時(shí)包含了新的隨機(jī)數(shù)，所以每條SSL －CONN 產(chǎn)生的MASTER －KEY 都是不同的，這點(diǎn)要注意。

4、如果復(fù)用成功，則一個(gè)客戶機(jī)與一個(gè)服務(wù)器間可以有多條TCP －CONN 、同樣數(shù)量的SSL －CONN ，但只有一條SSL －SESSION 。