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

SSL 雙向認(rèn)證握手過程

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

struct {

ProtocolV ersion client_version; // SSL協(xié)議版本號(hào)

Random random; // 客戶端產(chǎn)生的隨機(jī)數(shù)

SessionID session_id; // 會(huì)話標(biāo)志符

CipherSuite cipher_suites<0..216-1>; // 客戶端支持的加密算法套件

CompressionMethod compression_methods<0..28 -1>; // 客戶端支持的數(shù)據(jù)壓縮算法 } ClientHello;

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

struct {

ProtocolV ersion server_version; // SSL協(xié)議版本號(hào)

Random random; // 服務(wù)器端產(chǎn)生的隨機(jī)數(shù)

SessionID session_id; // 會(huì)話標(biāo)志符

CipherSuite cipher_suite; // 服務(wù)器端所支持的加密算法套件

CompressionMethod compression_method; // 服務(wù)器端所支持的數(shù)據(jù)壓縮算法

} ServerHello;

opaque ASN.1Cert<1..2 24 -1>;

struct {

ASN.1Cert certificate_list<1..224-1>; // X509.3 證書鏈，在此，只有服務(wù)器端的證書。 } Certificate;

客戶利用服務(wù)器傳過來的信息驗(yàn)證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，

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

發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名” ----- 用于驗(yàn)證證書中提供的公鑰的可用性。（簽名算法 公鑰 密文）

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

enum { rsa, diffie_hellman, fortezza_dms } KeyExchangeAlgorithm;

struct {

opaque rsa_modulus<1..216-1>;

opaque rsa_exponent<1..216-1>;

} ServerRSAParams;

其中：

rsa_modulus 服務(wù)器的臨時(shí)的RSA 密鑰的模數(shù)。

rsa_exponent 服務(wù)器的臨時(shí)的RSA 密鑰的公開指數(shù)。

struct {

opaque dh_p<1..216-1>;

opaque dh_g<1..216-1>;

opaque dh_Y s <1..216-1>;

} ServerDHParams; /* 短期的DH 參數(shù) */

其中：

dh_p Diffie-Hellman 操作中用到的質(zhì)模數(shù)。

dh_g Diffie-Hellman 操作中用到的發(fā)生器。

dh_Y 服務(wù)器的Diffie-Hellman 公開值(gX mod p)。

struct {

opaque r_s [128];

} ServerFortezzaParams;

其中：

r_s 服務(wù)器為密鑰交換算法而生成的隨機(jī)數(shù)。

digitally-signed struct {

select(SignatureAlgorithm) {

case anonymous: struct { };

case rsa: opaque md5_hash[16];

opaque sha_hash[20];

case dsa: opaque sha_hash[20];

};

} Signature;

struct {

select (KeyExchangeAlgorithm) {

case diffie_hellman: ServerDHParams params;

Signature signed_params;

case rsa: ServerRSAParams params;

Signature signed_params;

case fortezza_dms: ServerFortezzaParams params;

};

} ServerKeyExchange;

其中：

params 服務(wù)器的密鑰交換參數(shù)。

signed_params 相應(yīng)的參數(shù)值的哈希值，及對(duì)此哈希值的簽名。

md5_hash MD5(ClientHello.random Serverhello.random ServerParams); sha_hash SHA(ClientHello.random ServerHello.random ServerParams);

enum { anonymous, rsa, dsa } SignatureAlgorithm;

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

服務(wù)器端請(qǐng)求證書

enum { rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),

rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_dms(20), (255)

} ClientCertificateType;

opaque DistinguishedName<3..216-1>;

struct {

ClientCertificateType certificate_types<1..28-1>; // 請(qǐng)求證書類型列表

DistinguishedName certificate_authorities<3..216-1>; // CA列表

} CertificateRequest;

如果服務(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é)束。

struct { } ClientHelloDone;

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

struct { } ServerHelloDone;

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

本文來自CSDN 博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：

SSL 協(xié)議與數(shù)字證書

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)的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強(qiáng)調(diào)要求使用 128 位加密通訊的原因。

證 書 各 部 分 的 含 義

V ersion 證書版本號(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）。

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

用戶名稱（Subject ） 含義：用來指定證書用戶的 X.500 唯一名稱（DN ，Distinguished Name）。 用戶公鑰信息（Subject Public Key Information ） 算法（algorithm ） 算法標(biāo)識(shí)（Algorithm Identifier ） 用戶公鑰（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 Issuer ） 簽發(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)行解密。 證書中的公鑰用途（Key Usage ） 含義：用來指定公鑰用途。

用戶的私鑰有效期（Private Key Usage Period ） 起始日期（Note Before ） 終止日期（Note After ） 含義：用來指定用戶簽名私鑰的起始日期和終止日期。 CA 承認(rèn)的證書政策列表（Certificate Policies ） 含義：用來指定用戶證書所適用的政策，證書政策可由對(duì)象標(biāo)識(shí)符表示。 用戶的代用名（Substitutional 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 Required ） 含義：顯示支付網(wǎng)關(guān)是否支持與沒有證書的持卡人進(jìn)行交易。 SET 擴(kuò)展（SETExtensions ） 含義：列出支付網(wǎng)關(guān)支持的支付命令的 SET 信息擴(kuò)展。 CRL 數(shù)據(jù)定

義版本（V ersion ） 含義：顯示 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 ）

本文來自CSDN 博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：

SSL 單向、雙向認(rèn)證

單向認(rèn)證：客戶端向服務(wù)器發(fā)送消息，服務(wù)器接到消息后，用服務(wù)器端的密鑰庫中的私鑰對(duì)數(shù)據(jù)進(jìn)行加密，然后把加密后的數(shù)據(jù)和服務(wù)器端的公鑰一起發(fā)送到客戶端，客戶端用服務(wù)器發(fā)送來的公鑰對(duì)數(shù)據(jù)解密，然后在用傳到客戶端的服務(wù)器公鑰對(duì)數(shù)據(jù)加密傳給服務(wù)器端，服務(wù)器用私鑰對(duì)數(shù)據(jù)進(jìn)行解密，這就完成了客戶端和服務(wù)器之間通信的安全問題，但是單向認(rèn)證沒有驗(yàn)證客戶端的合法性。

雙向認(rèn)證：

（1）客戶端向服務(wù)器發(fā)送消息，首先把消息用客戶端證書加密然后連同時(shí)把客戶端證書一起發(fā)送到服務(wù)器端

（2）服務(wù)器接到消息后用首先用客戶端證書把消息解密，然后用服務(wù)器私鑰把消息加密，把服務(wù)器證書和消息一起發(fā)送到客戶端

（3）客戶端用發(fā)來的服務(wù)器證書對(duì)消息進(jìn)行解密，然后用服務(wù)器的證書對(duì)消息加密，然后在用客戶端的證書對(duì)消息在進(jìn)行一次加密，連同加密消息和客戶端證書一起發(fā)送到服務(wù)器端，

（4）到服務(wù)器端首先用客戶端傳來的證書對(duì)消息進(jìn)行解密，確保消息是這個(gè)客戶發(fā)來的，然后用服務(wù)器端的私鑰對(duì)消息在進(jìn)行解密這個(gè)便得到了明文數(shù)據(jù)。

設(shè)置包括兩個(gè)方面：客戶端（IE 瀏覽器）和服務(wù)器（Web Server），我一個(gè)一個(gè)介紹吧。

客戶端配置非常簡單：只要在IE 的Internet 選項(xiàng)中的高級(jí)選項(xiàng)欄中選中“使用SSL 2.0”和“使用SSL 3.0”即可，如果使用的IE 瀏覽器是5.0以上，加密強(qiáng)度是128位的高強(qiáng)度，如果是5.0以下的瀏覽器需要下載安全補(bǔ)丁，否則只有40位加密強(qiáng)度。

服務(wù)器（Web Server ）端配置比較負(fù)責(zé)，我舉例說明IIS 配置的過程（其他Web Server 如何配置我就不知道了）：首先使用IIS 本身帶有的一個(gè)工具生成私有密鑰（密鑰導(dǎo)出有固定的格式），然后使用這個(gè)私有密鑰到CA 中心或者一個(gè)能生產(chǎn)證書的工具，生成一個(gè)證書，這個(gè)證書稱為站點(diǎn)證書，最后將這個(gè)證書導(dǎo)入IIS ，IIS 站點(diǎn)的身份就可以通過這個(gè)證書認(rèn)證了。

實(shí)際上如果要求雙向認(rèn)證的話，客戶端也要求有證書，就是給每個(gè)客戶端發(fā)放一個(gè)證書，但是這比較復(fù)雜，一般要求有一個(gè)CA 中心的存在，否則只能做到單項(xiàng)認(rèn)證，也就是只能驗(yàn)證服務(wù)器端的身份，不過你可以通過用戶名和口令來驗(yàn)證用戶的身份，這是最簡單的方法。

配置完成之后，只要訪問Web Server的方式改為https://就可以了。這時(shí)如果是第一次訪問，一般情況需要下載站點(diǎn)證書和簽發(fā)站點(diǎn)證書的根證書，就是我們經(jīng)?？吹降腎E 瀏覽器彈出的是否繼續(xù)加載的對(duì)話框，如果選擇繼續(xù)加載，證書就下載到本地并安裝到了瀏覽器中，以后訪問就不會(huì)出現(xiàn)這個(gè)對(duì)話框了。

1. client 向server 端發(fā)送ssl 版本號(hào)，cipher 設(shè)置，隨機(jī)數(shù)(randomly generated data) 和其他

sever 端所要求的信息。

2.server 端向client 端發(fā)送ssl 版本號(hào)，cipher 設(shè)置, 隨機(jī)數(shù)(randomly generated data)和其他client 端所要求的信息。server 發(fā)送其證書信息，如果是雙向認(rèn)證(client請(qǐng)求server 端資源時(shí)，server 需要對(duì)client 端進(jìn)行認(rèn)證) ，則請(qǐng)求client 發(fā)送證書。

3.client 端根據(jù)server 發(fā)送過來的信息來認(rèn)證server ，如果認(rèn)證失敗，提示client user 不能夠建立encrypted and authenticated connection.如果認(rèn)證成功，執(zhí)行4。

4.client 利用handshake 過程所產(chǎn)生的數(shù)據(jù)為會(huì)話建立premaster secret，用server 的public key(在第2步的server 證書中得到) 對(duì)其加密。

5. 如果server 端需要雙向認(rèn)證，client 端對(duì)another piece of data進(jìn)行簽名，這個(gè)數(shù)據(jù)對(duì)于handshake 是唯一的，client 和server 都知道該數(shù)據(jù)。client 發(fā)送這個(gè)signed data ，client 的證書和premaster secret.

6. 如果server 端需要雙向認(rèn)證，server 對(duì)client 端進(jìn)行認(rèn)證，如果認(rèn)證失敗，則結(jié)束會(huì)話，否則server 利用private key將premaster secret解密，將解密的premaster secret經(jīng)過一系