爲了便於理解SSL/TLS的單向認證和雙向認證執行流程，這裏先介紹一些術語。
1. 散列函數(Hash function)：又稱散列算法、哈希函數，是一種從任何一種數據中創建小的數字”指紋”的方法。散列函數把消息或數據壓縮成摘要，使得數據量變小，將數據的格式固定下來。該函數將數據打亂混合，重新創建一個叫做散列值(hash values, hash codes, hash sums)的指紋。散列值通常用一個短的隨機字母和數字組成的字符串代表。好的散列函數在輸入域中很少出現散列衝突。
散列函數的工作原理如下圖所示：把輸入(消息、文件等)看成n比特塊的序列。對輸入用迭代方式每次處理一塊，生成n比特的散列函數。
所有散列函數都有如下一個基本特性：如果兩個散列值是不相同的(根據同一函數)，那麼這兩個散列值的原始輸入也是不相同的。這個特性是散列函數具有確定性的結果，具有這種性質的散列函數稱爲單向散列函數。但另一方面，散列函數的輸入和輸出不是唯一對應關係的，如果兩個散列值相同，兩個輸入值很可能是相同的，但也可能不同，這種情況稱爲”散列碰撞(collision)”，這通常是兩個不同長度的輸入值，刻意計算出相同的輸出值。輸入一些數據計算出散列值，然後部分改變輸入值，一個具有強混淆特性的散列函數會產生一個完全不同的散列值。典型的散列函數都有非常大的定義域，比如SHA-2最高接受(2^64-1)/8長度的字節字符串。同時散列函數一定有着有限的值域，比如固定長度的比特串。在某些情況下，散列函數可以設計成具有相同大小的定義域和值域間的單射。在密碼學中，散列函數必須具有不可逆性。
爲滿足在消息認證中的應用，散列函數H必須具有下列性質：
(1).H可適用於任意長度的數據塊。
(2).H能生成固定長度的輸出。
(3).對於任意給定的x，計算H(x)相對容易，並且可以用軟/硬件方式實現。
(4).對於任意給定值h，找到滿足H(x)=h的x在計算上不可行。滿足這一特性的散列函數稱爲具有單向性，或具有抗原像攻擊性。
(5).對於任意給定的數據塊x，找到滿足H(y)=H(x)的y!=x在計算上是不可行的。滿足這一特性的散列函數被稱爲具有抗第二原像攻擊性，有時也稱爲具有抗弱碰撞攻擊性。
(6).找到滿足H(x)=H(y)的任意一對(x,y)在計算上是不可行的。滿足這一特性的散列函數被稱爲抗碰撞性，有時也被稱爲抗強碰撞性。
前三個性質是使用散列函數進行消息認證的實際可行要求。第四個屬性，抗原像攻擊，是單向性：給定消息容易產生它的散列碼，但是給定散列碼幾乎不可能恢復出消息。抗第二原像攻擊性質保證了對於給定的消息，不可能找到具有相同散列值的可替換消息。滿足上面前5個性質的散列函數稱爲弱散列函數。如果還滿足第6個性質則稱其爲強散列函數。除提供認證之外，消息摘要還能驗證數據的完整性。
應用最爲廣泛的散列函數是安全散列算法(SHA)。SHA是基於散列函數MD4，按照消息摘要大小，可分爲SHA-1、SHA-224、SHA-256、SHA-384、SHA-512，後4種又被稱爲SHA-2，它們輸出摘要大小依次爲160bits、224bits、256bits、384bits、512bits。SHA-1不再認可。
2. HMAC(Hash-based Message Authentication Code)：基於Hash的消息認證碼，又稱散列消息認證碼，是一種通過特別計算方式之後產生的消息認證碼(MAC)，使用密碼散列函數，同時結合一個加密密鑰。它可以用來保證數據的完整性，同時可以用來作某個消息的身份驗證。HMAC運算利用哈希算法，以一個密鑰和一個消息作爲輸入，生成一個消息摘要作爲輸出。使用消息摘要算法MD2、MD4、MD5、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512所構造的HMAC，分別稱爲HMAC-MD2、HMAC-MD4、HMAC-MD5、HMAC-SHA1、HMAC-SHA-224、HMAC-SHA-384、HMAC-SHA-512。
3. 數字簽名(digital signature)：又稱公鑰數字簽名，是一種功能類似寫在紙上的普通簽名，但是使用了公鑰加密領域的技術，以用於鑑別數字信息的方法。一套數字簽名通常會定義兩種互補的運算，一個用於簽名，另一個用於驗證。數字簽名是非對稱密鑰加密技術與數字摘要技術的應用。數字簽名了的文件的完整性是很容易驗證的，而且數字簽名具有不可抵賴性(即不可否認性)，其過程如下圖所示：
每個人都有一對”鑰匙”(數字身份)，其中一個只有本人知道(私鑰)，另一個公開的(公鑰)。簽名的時候用私鑰，驗證簽名的時候用公鑰。又因爲任何人都可以落款申稱他就是使用者本人，因此公鑰必須向接受者信任的人(身份認證機構)來註冊。註冊後身份認證機構給使用者發一數字證書。對文件簽名後，使用者把此數字證書連同文件及簽名一起發給接受者，接受者向身份認證機構求證是否真地是用使用者的密鑰簽發的文件。
信息發佈者可以使用數字簽名，信息發佈的目的是讓人們知道信息，雖然沒必要對消息進行加密，但是必須排除有人僞裝信息發佈者發佈假消息的風險，這時信息發佈者就可以使用數字簽名。而對明文消息施加的簽名，稱爲明文簽名(clearsign)。軟件的作者可以加上數字簽名，以便用戶下載後對簽名進行驗證。認證機構(CA)也可以爲用戶的公鑰加上數字簽名生成證書，以便人們確認用戶公鑰的合法性。SSL/TLS使用服務器證書(加上了數字簽名的服務器公鑰)認證服務器身份是否合法。
通常我們使用公鑰加密，用私鑰解密。而在數字簽名中，我們使用私鑰加密(相當於生成簽名)，公鑰解密(相當於驗證簽名)。我們可以直接對消息進行簽名(即使用私鑰加密，此時加密的目的是爲了簽名，而不是保密)，驗證者用公鑰正確解密消息，如果和原消息一致，則驗證簽名成功。但通常我們會對消息的散列值簽名，因爲通常散列值的長度遠小於消息原文，使得簽名(非對稱加密)的效率大大提高。注意，計算消息的散列值不是數字簽名的必要步驟。在實際使用中，我們既想加密消息，又想簽名，所以要對加密和簽名組合使用，比如TLS就組合了加密和簽名。數字簽名應用了公鑰密碼領域使用的單向函數原理。單向函數指的是正向操作非常簡單，而逆向操作非常困難的函數，比如大整數乘法。一般簽名對象爲消息的散列值。
4. 公開密鑰認證(public key certificate，或公鑰證書)，又稱數字證書(digital certificate)或身份證書(identity certificate)：是用於公開密鑰基礎建設的電子文件，用來證明公開密鑰擁有者的身份。此文件包含了公鑰信息、擁有者身份信息(主體)、以及數字證書認證機構(發行者)對這份文件的數字簽名，以保證這個文件的整體內容正確無誤。擁有者憑着此文件，可向電腦系統或其他用戶表明身份，從而對方獲得信任並授權訪問或使用某些敏感的電腦服務。電腦系統或其他用戶可以透過一定的程序覈實證書上的內容，包括證書有否過期、數字簽名是否有效，如果你信任簽發的機構，就可以信任證書上的密鑰，憑公鑰加密與擁有者進行可靠的通信。簡而言之，認證機構用自己的私鑰對需要認證的人(或組織機構)的公鑰施加數字簽名並生成證書，即證書的本質就是對公鑰施加數字簽名。數字證書的其中一個最主要好處是在認證擁有者身份期間，擁有者的敏感個人數據(如出生日期、身份證號碼等)並不會傳輸至索取數據者的電腦系統上。透過這種數據交換模式，擁有者既可證實自己的身份，亦不用過度披露個人數據，對保障電腦服務訪問雙方皆有好處。人們透過信任數字證書認證機構的根證書、及其使用公開密鑰加密作數字簽名核發的公開密鑰認證，形成信任鏈架構，已在TLS實現並在萬維網的HTTPS、在電子郵件的SMTPS和STARTTLS廣泛應用。業界現行的標準是國際電信聯盟電信標準化部門制定的X.509，並由IETF發行的RFC 5280詳細述明。
證書種類：根證書(自簽證書)、中介證書和終端實體(TLS服務器/客戶端)證書的關係，如下圖所示：
(1).自簽證書：在用於小範圍測試等目的的時候，用戶也可以自己生成數字證書，但沒有任何可信賴的人簽名，這種自簽名證書通常不會被廣泛信任，使用時可能會遇到電腦軟件的安全警告。
(2).根證書：獲得廣泛認可，通常已預先安裝在各種軟件(包括操作系統、瀏覽器、電郵軟件等)，作爲信任鏈的起點，來自於公認可靠的政府機關、軟件公司、證書頒發機構公司等，與各大軟件商透過嚴謹的核認程序纔在不同的軟件廣泛部署。由於部署程序複雜費時，需要行政人員的授權及機構法人身份的核認，一張根證書有效期可能長達十年以上。在某些企業，也可能會在內部電腦自行安裝企業自籤的根證書，以支持內部網的企業級軟件；但是這些證書可能未被廣泛認可，只在企業內部適用。
(3).中介證書(或中間證書)：認證機構的一個重要任務就是爲客戶簽發證書，雖然廣泛認可的認證機構都已擁有根證書，相對應的私鑰可用以簽署其他證書，但因爲密鑰管理和行政考慮，一般會先行簽發中介證書，才爲客戶作數字簽署。中介證書的有效期會較根證書爲短，並可能對不同類別的客戶有不同的中介證書作分工。
(4).授權證書：又稱屬性證書，本身沒有公鑰，必須依附在一張有效的數字證書上纔有意義，其用處是賦予相關擁有人簽發終端實體證書的權力；某些情況下，如果只在短期內授予證書機構簽發權力，便可以不改變(縮短)該機構本身持有的證書的有效期。這種情況，類似於某人持有長達十年期的護照，而只透過簽發短期入境簽證，來個別賦予護照持有人額外權力。
(5).終端實體證書(或葉子證書)：其他不會用作簽發其他證書的，都可稱爲終端實體證書，在實際的軟件中部署，以便創建加密通道時應用。
(6).TLS服務器證書：服務器通常以域名形式在互聯網上提供服務，服務器證書上主體的通用名稱就會是相應的域名，相關機構名稱則寫在組織或單位一欄上。服務器證書(包括公鑰)和私鑰會安裝於服務器，等待客戶端連接時協議加密細節。客戶端的軟件(如瀏覽器)會運行認證路徑驗證算法以確保安全，如果未能肯定加密通道是否安全(例如證書上的主體名稱不對應網站域名、服務器使用了自簽證書、或加密算法不夠強)，可能會警告用戶。
(7).通配符證書：如果服務器證書上主體的通用名稱(或主體別名)一欄以通配符前綴，則該證書可以用於旗下的所有子域名，特別適合較具規模、或設有多個子網站的機構一次過申領，套用於多個服務器上；即使未來創建新的子域名，也可以套用。但通配符不可用於擴展認證證書上。
(8).TLS客戶端證書：有時候，某些TLS服務器可能會在創建加密通道時，要求客戶端提供客戶端證書，以驗證身份及控制訪問權限。客戶端證書包含電子郵件地址或個人姓名，而不是主機名。但客戶端證書比較不常見，因爲考慮到技術門檻及成本因素，通常都是由服務提供者驗證客戶身份，而不是依賴第三方認證機構。通常，需要使用到客戶端證書的服務都是內部網的企業級軟件，他們會設立自己的內部根證書，由企業的技術人員在企業內部的電腦安裝相關客戶端證書以便使用。在公開的互聯網，大多數網站都是使用登錄密碼和Cookie來驗證用戶，而不是客戶端證書。客戶端證書在RPC系統中更常見，用於驗證連接設備的許可授權。
證書申領：(1).鮑伯在自己的機器上使用密碼學安全僞隨機數生成器產生一對足夠強的密鑰，鮑伯的私鑰不會向任何人發送。(2).鮑伯把他的公鑰，連同主體消息、使用目的等組成證書籤署請求，發送給認證機構伊凡。(3).伊凡(用另外一些渠道)覈實鮑伯的身份。(4).如果伊凡信任這個請求，他便使用鮑伯的公鑰和主體消息，加上證書有效期、用途等限制條件，組成證書的基本數據。(5).伊凡用自己的私鑰對鮑勃的公鑰加上數字簽名並生成證書。(6).伊凡把生成的證書發送給鮑伯(伊凡也可以透過證書透明度公佈他簽發了新的證書)。
證書使用：(1).鮑伯可以隨便把證書向外發佈。(2).鮑伯與愛麗絲事先可能互不認識，但鮑伯與愛麗絲都信任伊凡，愛麗絲使用認證機構伊凡的公鑰驗證數字簽名，如果驗證成功，便可以信任鮑勃的公鑰是真正屬於鮑伯的。(3).愛麗絲可以使用證書上的鮑勃的公鑰加密明文，得到密文併發送給鮑伯。(4).鮑伯可以可以用自己的私鑰把密文解密，得到明文。
電子證書可以二進制或Base64形式存儲，常見的文件擴展名有.cer、.crt、.der和.pem。如果把證書和私鑰一起存儲，則可以使用PKCS#12(.p12)格式。
5. X.509：ITU-T推薦標準X.509是X.500推薦標準系列的一部分，X.500系列推薦標準定義了一套目錄服務。所謂目錄服務，實際上是指用於維護用戶信息數據庫的一個或一組分佈式服務器。這些信息包括從用戶名到網絡地址的映射關係，以及其他關於用戶的屬性和信息。X.509定義了一個使用X.500目錄向用戶提供認證服務的框架。該目錄可以作爲公鑰證書存儲庫。每個證書都包括用戶的公鑰，並由一個可信任的認證中心用私鑰簽名。除此之外，X.509定義了另一個基於使用公鑰證書的認證協議。
X.509是密碼學裏公鑰證書的格式標準。X.509證書已應用在包括TLS/SSL在內的衆多網絡協議裏。X.509證書裏含有公鑰、身份信息(比如網絡主機名，組織的名稱或個體名稱等)和簽名信息(可以是證書籤發機構CA的簽名，也可以是自簽名)。對於一份經由可信的證書籤發機構簽名或者可以通過其它方式驗證的證書，證書的擁有者就可以用證書及相應的私鑰來創建安全的通信，對文檔進行數字簽名。除了證書本身功能，X.509還附帶了證書吊銷列表和用於從最終對證書進行簽名的證書籤發機構直到最終可信點爲止的證書合法性驗證算法。X.509是ITU-T標準化部門基於他們之前的ASN.1定義的一套證書標準。
X.509基於公鑰加密體制和數字簽名的使用。這個標準並沒有強制使用某個特定的算法，但是推薦使用RSA。數字簽名方案假定需要使用散列函數。同樣，這個標準也沒有強制使用某種特定的散列算法。
X.509方案的核心是與每個用戶相關聯的公鑰證書。這些用戶證書是由可信任的認證中心(CA)創建的，並由CA或用戶放在目錄中。目錄服務器本身不負責公鑰的產生和認證功能，它只爲用戶獲取證書提供一個容易訪問的場所。
瀏覽器(如Firefox、Internet Explorer、Microsoft Edge、Safari以及Google Chrome)和操作系統都預裝有可信任的根證書列表，所以主流CA發佈的TLS證書都直接可以正常使用。
證書文件擴展名：X.509有多種常用的擴展名，不過其中的一些還用於其它用途，就是說具有這個擴展名的文件可能並不是證書，比如說可能只是保存了私鑰。
(1).pem：DER編碼的證書再進行Base64編碼的數據存放在"-----BEGIN CERTIFICATE-----"和"-----END CERTIFICATE-----"之中。
(2).cer, .crt, .der：通常是DER二進制格式的，但Base64編碼後也很常見。
(3).p7b, .p7c：PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)。
(4).p12：PKCS#12格式，包含證書的同時可能還有帶密碼保護的私鑰。
(5).pfx：PFX，PKCS#12之前的格式(通常用PKCS#12格式，比如那些由IIS產生的PFX文件)。
PKCS#7是簽名或加密數據的格式標準，官方稱之爲容器。由於證書是可驗真的簽名數據，所以可以用SignedData結構表述。.P7C文件是退化的SignedData結構，沒有包括簽名的數據。
PKCS#12由PFX進化而來的用於交換公共的和私有的對象的標準格式。
證書的一般結構包含以下要素，如下圖所示：一般遵從X.509格式規範的證書，會有以下的內容，它們以字段的方式表示。
(1).版本：區別連續版本中的證書格式，默認爲版本1；如果證書中有發放者唯一標識符或者主體唯一標識符，則說明此值一定爲2；如果存在一個或多個擴展，則此值一定爲3。現行通用版本是3。
(2).序號：一個整數值，此值在發放證書的CA中唯一，且明確與此證書相關聯。
(3).簽名算法標識符：用於進行簽名證書的算法和一切有關的參數。由於此信息在證書末尾的簽名域中被重複，此域基本沒有用處。
(4).發放者名稱：創建和簽發該證書的CA的X.500名稱。
(5).有效期：包括兩個日期：證書有效的最初日期和最晚日期。
(6).主體名稱：此證書指向用戶的名稱。也就是說，此證書覈實擁有相關私鑰的主體的公鑰。
(7).主體公鑰信息：主體的公鑰，加上一個表明此公鑰用於何種加密算法的標識和任何相關參數。
(8).發放者唯一標識符：一個可選的比特串域，在X.500名稱被重用於不同實體中的情況下，它用來唯一地確定發放證書的CA。
(9).主體唯一標識符：一個可選的比特串域，在X.500名稱被重用於不同實體中的情況下，它用來唯一地確定主體。
(10).擴展：一個和多個擴展域組成的集合。在版本3中加入擴展。
(11).簽名：包括此證書的一切其他的域。它包含用CA的私鑰加密過的其他域的散列碼。此域包含簽名算法標識符。
6. 認證中心(Certificate Authority , CA)：數字證書認證機構，也稱爲電子商務認證中心、電子商務認證授權機構，是負責發放和管理數字證書的權威機構，並作爲電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。
CA中心爲每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。CA機構的數字簽名使得攻擊者不能僞造和篡改證書。它負責產生、分配並管理所有參與網上交易的個體所需的數字證書，因此是安全電子交易的核心環節。在SET交易中，CA不僅對持卡人、商戶發放證書，還要對獲款的銀行、網關發放證書。CA是證書的簽發機構，它是PKI(Public Key Infrastructure)的核心。CA是負責簽發證書、認證證書、管理已頒發證書的機關。它要制定政策和具體步驟來驗證、識別用戶身份，並對用戶證書進行簽名，以確保證書持有者的身份和公鑰的擁有權。用戶若欲獲取證書，應先向CA提出申請，CA判明申請者的身份後，爲之分配一個公鑰，並將該公鑰與其身份信息綁定，爲該整體簽名，簽名後的整體即爲證書，發還給申請者。如果一個用戶想鑑別另一個證書的真僞，他就用CA的公鑰對那個證書上的簽字進行驗證，一旦驗證通過，該證書就被認爲是有效的。
7. SSL/TLS：Secure Sockets Layer/ Transport Layer Security(安全套接層/傳輸層安全性協議)，是一種安全協議，目的是爲互聯網通信提供安全及數據完整性保障。TLS的前身是SSL。網景公司(Netscape)在1994年推出HTTPS協議，以SSL進行加密，這是SSL的起源。IETF將SSL進行標準化，1999年公佈TLS 1.0標準文件(RFC 2246)。隨後又公佈TLS 1.1(RFC 4346, 2006年)、TLS 1.2(RFC 5246, 2008年)和TLS 1.3(RFC 8446, 2018年)。目前已成爲互聯網上保密通信的工業標準。
SSL包含記錄層(Record Layer)和傳輸層，記錄層協議確定傳輸層數據的封裝格式。傳輸層安全協議使用X.509認證，之後利用非對稱加密演算來對通信方做身份認證，之後交換對稱密鑰作爲會談密鑰(Session key)。這個會談密鑰是用來將通信兩方交換的數據做加密，保證兩個應用間通信的保密性和可靠性，使客戶與服務器應用之間的通信不被攻擊者竊聽。
TLS協議採用主從式架構模型，用於在兩個應用程序間透過網絡創建起安全的連線，防止在交換數據時受到竊聽及篡改。TLS協議的優勢是與高層的應用層協議(如HTTP、FTP、Telnet等)無耦合。應用層協議能透明地運行在TLS協議之上，由TLS協議進行創建加密信道需要的協商和認證。應用層協議傳送的數據在通過TLS協議時都會被加密，從而保證通信的私密性。
TLS協議是可選的，必須配置客戶端和服務器才能使用。主要有兩種方式實現這一目標：一個是使用統一的TLS協議端口(例如：用於HTTPS的端口443)；另一個是客戶端請求服務器連接到TLS時使用特定的協議機制(例如：電子郵件常用的STARTTLS)。一旦客戶端和服務器都同意使用TLS協議，他們通過使用一個握手過程協商出一個有狀態的連接以傳輸數據。通過握手，客戶端和服務器協商各種參數用於創建安全連接。
在客戶端和服務器開始交換TLS所保護的加密信息之前，他們必須安全地交換或協定加密密鑰和加密數據時要使用的密碼。用於密鑰交換的方法包括：使用RSA算法生成公鑰和私鑰(在TLS握手協議中被稱爲TLS_RSA)、Diffie-Hellman(在TLS握手協議中被稱爲TLS_DH)、臨時Diffie-Hellman(在TLS握手協議中被稱爲TLS_DHE)、橢圓曲線迪菲-赫爾曼(在TLS握手協議中被稱爲TLS_ECDH)、臨時橢圓曲線Diffie-Hellman(在TLS握手協議中被稱爲TLS_ECDHE)、匿名Diffie-Hellman(在TLS握手協議中被稱爲TLS_DH_anon)和預共享密鑰(在TLS握手協議中被稱爲TLS_PSK)。在交換過程中使用的公鑰/私鑰加密密鑰的長度和在交換協議過程中使用的公鑰證書也各不相同，因而提供強健性安全。
SSL使用TCP提供一種可靠的端對端的安全服務。SSL不是單個協議，它由兩層協議組成，如下圖所示：
SSL記錄協議對各種更高層協議提供基本的安全服務。尤其是，超文本傳輸協議(Hypertext Transfer Protocol, HTTP)是爲Web客戶端/服務器的交互提供傳輸服務的協議，它可以在SSL的頂層運行。SSL中定義的三個較高層協議分別是：握手協議、修改密碼規範協議和警報協議。這些SSL協議規範用來管理SSL的交換。
SSL協議中的兩個重要概念是SSL會話和SSL連接，按照規範文件，它們的定義如下：
(1).連接：是一種能夠提供合適服務類型(按照OSI分層模型定義)的傳輸。對SSL來說，這種連接是點對點的關係而且都是短暫的。每一條連接都與一個會話相關聯。
(2).會話：SSL會話是客戶與服務器之間的一種關聯。會話是通過握手協議來創建的。所有會話都定義了密碼安全參數集合，這些參數可以在多個安全連接之間共享。會話通常用來減少每次連接建立安全參數的昂貴協商費用。
會話狀態由下列參數定義：
(1).會話標識符：由服務器產生的用於標識活動或可恢復的會話狀態的一個任意字節序列。
(2).對等實體證書：對等實體的X.509v3證書。會話狀態的這一元素可以爲空。
(3).壓縮方法：加密前用於壓縮數據的算法。
(4).密碼規格：包括大塊數據加密算法(例如空算法、AES算法等)規格和用於計算MAC(消息認證碼)的散列算法(如MD5或SHA-1算法等)規格。它還定義了一些密碼屬性，例如散列值長度等。
(5).主密鑰：客戶端和服務器共享的48字節的會話密鑰。
(6).可恢復性：表明會話是否可被用於初始化新連接的標誌。
連接狀態由下列參數定義：
(1).服務器和客戶端隨機數：由服務器和客戶端爲每個連接選定的字節串。
(2).服務器寫MAC密鑰：服務器發送數據時用於計算MAC值的密鑰。
(3).客戶端寫MAC密鑰：客戶端發送數據時用於計算MAC值的密鑰。
(4).服務器寫密鑰：服務器用於加密數據、客戶端用於解密數據的加密密鑰。
(5).客戶端寫密鑰：客戶端用於加密數據、服務器用於解密數據的對稱加密密鑰。
(6).初始化向量：在CBC模式中，需要爲每個密鑰配置一個初始化向量(IV)。最初的IV值由SSL的握手協議初始化。之後，每個記錄的最後一個密碼塊被保存，以作爲後續記錄的IV。
(7).序列號：建立連接的各方爲每條連接發送和接收的消息維護單獨的序列號。當一方發送或接收改變密碼規格的消息時，相應的序列號應置零。序列號的值不能超過2^64-1。
SSL握手協議：這一協議允許客戶端和服務器相互認證，並協商加密和MAC算法，以及用於保護數據使用的密鑰通過SSL記錄傳送。握手協議在任何應用數據被傳輸之前使用。握手協議由客戶端和服務器之間的一系列消息交換組成。
下圖說明了爲建立客戶端和服務器之間的邏輯連接需要進行的初始交換。這些交換可分爲4個階段：
第一階段：客戶端發起建立連接請求：這一階段主要是發起邏輯連接並建立與之關聯的安全能力。交換首先由客戶端通過發送下列client_hello消息啓動：
(1).版本：客戶端的SSL最高版本。
(2).隨機數：由客戶端產生的隨機序列，由32比特時間戳以及安全隨機數生成器產生的28字節隨機數組成。這些數沒有任何意義，主要用於密鑰交換過程中防止重放攻擊。
(3).會話ID：可變長度的會話標識符。非零值表示客戶端希望更新現有連接的參數，或爲該會話創建一條新連接。零值表示客戶端希望在新會話上建立一條新連接。
(4).密碼套件：按優先級的降序排列的、客戶端支持的密碼算法列表。列表中的每一行(即每一個密碼套件)同時定義了密鑰交換算法和密碼規格。
(5).壓縮方法：客戶端支持的壓縮方法列表。
發送完client_hello消息後，客戶端將等待server_hello消息，該消息所包含的參數與client_hello消息包含的參數相同。同時server_hello消息遵循以下的慣例。版本域包含客戶端支持的較低版本和服務器支持的最高版本。服務器產生一個獨立於客戶端隨機域的新隨機數域。如果客戶端會話ID域的值非零，那麼服務器應採用相同的取值。否則，服務器的會話ID域將包括一個新會話值。密碼套件域將包括服務器從客戶端提供的可選方案中選定的唯一一組密碼套件。壓縮域包括服務器從客戶端建議中選定的壓縮方法。密碼套件參數的第一項內容是密鑰交換方法(如傳統加密密鑰和MAC交換方法)。
第二階段：服務器認證和密鑰交換：如果需要認證，則這一階段的開始以服務器發送其證書爲標誌。發送的消息包括一個X.509證書或一個X.509證書鏈。之後，如果有必要，將發送一個服務器密鑰交換(server_key_exchange)消息。接下來，服務器可以向客戶端請求證書。certificate_request(證書請求)消息包括兩個參數：certificate_type(證書類型)和certificate_authorities(證書機構)。證書類型指出了公鑰算法及其用法。第二階段中的最後一條消息(也是始終需要存在的消息之一)是server_done(服務器結束)消息。該消息由服務器發出並示意服務器的hello及相關消息已經結束。該消息沒有參數，發送完這個消息後，服務器要等待客戶的響應。
第三階段：客戶端認證和密鑰交換：接收到server_done(服務器結束)消息後，如果需要，客戶端應該驗證服務器提供的證書是否有效，同時還要檢查server_hello參數是否是可接受的。如果所有這些條件均滿足，那麼客戶端將返回一條或更多消息給服務器。如果服務器已請求證書，則以客戶端發送一條certificate消息爲這一階段的開始。如果沒有合適的證書可用，那麼客戶端發送一個no_ceritificate alert(無證書警報)。接下來是client_key_exchange(客戶端密鑰交換)消息。該消息必須在這一階段發送，消息內容由密鑰交換類型決定。最後，在這一階段，客戶端可以發送certificate_verify(證書驗證)消息，以便對客戶端證書進行顯示驗證。僅當客戶端證書具有簽名功能時纔會發送該消息。這個消息是對一個散列碼的簽名，該散列碼基於前面的消息。
第四階段：完成：這一階段完成安全連接的建立。客戶端發送一個change_cipher_spec(修改密碼規格)消息，並把掛起的密碼規格複製到當前密碼規格中。值得注意的是，該消息不是握手協議的一部分，而是使用修改密碼規格協議發送的。客戶端在新算法、新密鑰和新祕密值下立即發送finished(結束)消息。finished消息用於驗證密鑰交換和認證過程是否成功。作爲對客戶發送的這兩條消息的響應，服務器發送自己的change_cipher_spec_message(修改密碼規格消息)，把未定的密碼規格轉變爲當前的密碼規格併發送其finished消息。到此爲止握手過程已經完成，客戶端與服務器可以開始交換應用層數據。
瞭解了上面一些術語後，接下來介紹下SSL/TLS的單向認證和雙向認證過程，其實就是握手協議。單向認證如通過瀏覽器訪問某個網站，雙向認證如使用U盾登入網上銀行，需客戶端和服務器相互認證。除認證外，還要協商加密和MAC算法，以及用於保護數據使用的密鑰。由客戶端和服務器之間的一系列消息組成。
假設ca.crt爲CA的證書，server.crt爲服務器證書，client.crt爲客戶端證書，server.key爲服務器私鑰，client.key爲客戶端私鑰，server.pub爲服務器公鑰，client.pub爲客戶端公鑰。ca.crt應該已默認存在於客戶端。
1. SSL/TLS單向認證過程：
(1).客戶端發起連接請求：請求消息包括客戶端支持的最高SSL協議、客戶端支持的密碼套件列表、客戶端支持的壓縮算法列表、隨機數、會話ID等信息。
(2).服務器返回消息：該消息所包含的參數與(1)中相同，包括客戶端支持的SSL協議較低版本和服務器支持的最高版本；服務器從客戶端提供的可選方案中選定的唯一一組密碼套件(協議支持的密鑰交換方法包括RSA，固定Diffie-Hellman等，密碼規格包括密碼算法如RC4等，MAC算法如MD5、SHA-1等)；服務器從客戶端提供的可選方案中選定的壓縮算法；隨機數等信息；同時返回消息中還包括服務器證書server.crt，此證書裏有服務器公鑰和簽名，它是一個X.509證書或一個X.509證書鏈。
(3).客戶端通過本地的ca.crt驗證server.crt的合法性：證書是否過期、通過ca.crt獲取server.crt中的公鑰、驗證此公鑰是否能正確解開server.crt中的數字簽名、證書上的域名是否和服務器的實際域名相匹配。驗證通過後繼續通信，否則終止通信。
(4).客戶端向服務發送自己支持的對稱加密算法列表，供服務器進行選擇。
(5).服務器在客戶端提供的加密方案中選擇加密程度最高的加密算法，並將選定好的加密方案通過明文方式返回給客戶端。
(6).客戶端接收到服務器端返回的加密方案後，生成隨機碼，用作通信過程中對稱加密的密鑰，使用服務器端的公鑰進行加密，將加密後的隨機碼發送至服務器。
(7).服務器收到客戶端返回的加密信息後，使用自己的私鑰進行解密，獲取對稱加密密鑰。
在接下來的數據傳輸中，服務器和客戶端將會使用該密鑰進行對稱加密，保證通信過程中的信息安全。
2. SSL/TLS雙向認證過程：
(1).客戶端發起連接請求：請求消息包括客戶端支持的最高SSL協議、客戶端支持的密碼套件列表、客戶端支持的壓縮算法列表、隨機數、會話ID等信息。
(2).服務器返回消息：該消息所包含的參數與(1)中相同，包括客戶端支持的SSL協議較低版本和服務器支持的最高版本；服務器從客戶端提供的可選方案中選定的唯一一組密碼套件(協議支持的密鑰交換方法包括RSA，固定Diffie-Hellman等，密碼規格包括密碼算法如RC4等，MAC算法如MD5、SHA-1等)；服務器從客戶端提供的可選方案中選定的壓縮算法；隨機數等信息；同時返回消息中還包括服務器證書server.crt，此證書裏有服務器公鑰和簽名，它是一個X.509證書或一個X.509證書鏈。服務器請求客戶端證書。
(3).客戶端通過本地的ca.crt驗證server.crt的合法性：證書是否過期、通過ca.crt獲取server.crt中的公鑰、驗證此公鑰是否能正確解開server.crt中的數字簽名、證書上的域名是否和服務器的實際域名相匹配。驗證通過後繼續通信，否則終止通信。
(4).客戶端向服務器發送client.crt，還包括客戶端支持的對稱加密算法列表，供服務器進行選擇。
(5).服務器驗證client.crt，驗證通過後會獲取到客戶端公鑰，否則拒絕連接；服務器在客戶端提供的加密方案中選擇加密程度最高的加密算法，並將選定好的加密方案通過客戶端公鑰加密後返回給客戶端。
(6).客戶端接收到服務器返回的加密方案後，使用客戶端私鑰進行解密，生成隨機碼，用作通信過程中對稱加密的密鑰，使用服務器的公鑰進行加密，將加密後的隨機碼發送至服務器。
(7).服務器收到客戶端返回的加密信息後，使用自己的私鑰進行解密，獲取對稱加密密鑰。
在接下來的數據傳輸中，服務器和客戶端將會使用該密鑰進行對稱加密，保證通信過程中的信息安全。
注：以上內容來自網絡整理，主要參考：
1. 《網絡安全基礎應用與標準》