在前面兩篇貼子中，天地會總舵和分舵的網關進行身份認證時都是使用預共享密鑰方式。單從配置過程來說，該方式配置簡單，只需在總舵和分舵的網關上配置相同的密鑰即可。但隨着分舵數量越來越多，總舵和每個分舵之間形成的對等體都要配置預共享密鑰。如果所有對等體都使用同一個密鑰，存在安全風險；而每個對等體都使用不同的密鑰，又不便於管理和維護。
分舵數量日益增長，天地會亟需一個新的身份信息認證方案來代替預共享密鑰方式，降低管理成本。既然天地會的總舵和分舵都是以合法生意（如當鋪和票號）作爲掩護，不如直接向官府的刑部申請爲當鋪和票號發放身份憑證，標明當鋪和票號的身份信息。因爲刑部是公正的、可信賴的官府部門，所以蓋着刑部大印的身份憑證也就是可信任的，總舵和分舵就可以直接通過身份憑證來驗證雙方的身份。
這個身份憑證就叫做數字證書，簡稱證書，是由第三方機構頒發的代表設備身份信息的“身份證”。通過引入證書機制，總舵和分舵可以簡單便捷地進行身份認證。在詳細介紹證書的實現原理和獲取方法之前，我們先來了解一下公鑰密碼學和PKI框架的知識。
公鑰密碼學公私分明，PKI框架深不可測
在Internet危機四伏，IPSec閃亮登場一篇中，我們提到過對稱密碼學，即總舵和分舵使用相同的密鑰來加密和解密。與之對應的是非對稱密碼學，即加密和解密數據使用不同的密鑰，也叫做公鑰密碼學。目前較常用的公鑰密碼學算法有RSA（Ron Rivest、Adi Shamirh、LenAdleman）和DSA（Digital Signature Algorithm）。
公鑰密碼學中使用了兩個不同的密鑰：一個可對外界公開的密鑰稱爲“公鑰”；只有所有者知道的密鑰稱爲“私鑰”。這一對密鑰的特點是，使用公鑰加密的信息只能用相應的私鑰解密，反之使用私鑰加密的信息也只能用相應的公鑰解密。
利用公鑰和私鑰的這個特點，就可以實現通信雙方的身份認證。例如，某個分舵網關使用自己的私鑰對信息進行加密（數字簽名），而總舵網關使用分舵網關對外公開的公鑰進行解密。因爲其他人沒有該分舵網關的私鑰，所以只要總舵使用對應的公鑰可以解密信息就確定信息是由該分舵發出來的，從而實現身份認證功能。
瞭解公鑰密碼學的基本概念後，如何在實際環境中應用公鑰密碼學理論呢？PKI（Public Key Infrastructure）正是一個基於公鑰密碼學理論來實現信息安全服務的基礎框架，數字證書是其核心組成部分，而IKE借用了PKI中的證書機制來進行對等體的身份認證。
PKI框架中包括以下兩個重要角色：
- 終端實體（EE，End Entity）：證書的最終使用者，例如總舵和分舵的網關。
- 證書頒發機構（CA，Certificate Authority）：是一個權威的、可信任的第三方機構（類似刑部），負責證書頒發、查詢以及更新等工作。
通常情況下，終端實體生成公私密鑰對，並將公鑰、實體信息發送給CA進行證書申請。CA審覈實體身份，根據實體的公鑰和實體信息製作證書，然後爲實體頒發證書。通過這一過程，總舵和分舵網關就可以從CA獲取到代表自己身份的證書。
CA生成的證書中包含了大量的信息，我們來看一個常見的證書結構：
圖中各個字段的簡要解釋如下：
- 版本：即使用X.509的版本，目前普遍使用的是v3版本（0x2）。
- 序列號：該序列號在CA服務範圍內唯一。
- 簽名算法：CA簽名使用的算法。
- 頒發者：CA的名稱。
- 有效期：包含有效的起、止日期，不在有效期範圍的證書爲無效證書。
- 主題：證書所有者的名稱。
- 公鑰信息：對外公開的公鑰。
- 擴展信息：通常包含了使用者備用名稱、使用者密鑰標識符等可選字段。
- 簽名：CA的簽名信息，又叫CA的指紋信息。
本篇中所提到的證書分爲兩種類型：網關自身的證書稱爲本地證書，代表網關的身份；而CA“自簽名”的證書稱爲CA證書，又叫根證書，代表了CA的身份。
上面簡單介紹了證書涉及的幾個重要概念，大家先有一個初步瞭解，關於公鑰密碼學和PKI框架的詳細介紹後續會給出。下面我們來看一下如何爲總舵和分舵的網關獲取到證書。
證書重要取之有道，在線離線靈活選擇
PKI框架中的CA用來處理證書的申請、頒發業務，總舵和分舵的網關可以通過下面兩種方式從CA獲取證書：
- 在線方式（帶內方式）
網關和CA通過證書申請協議交互報文，在線申請證書，申請到的證書直接保存到網關的存儲設備中（Flash或CF卡），常用的證書申請協議有SCEP（Simple Certification Enrollment Protocol）和CMP（Certificate Management Protocol）。該方式適用於網關支持SCEP或CMP的情況，同時依賴於網關與CA之間網絡的連通狀態。
- 離線方式（帶外方式）
首先，網關生成證書請求文件，我們將該文件通過磁盤、電子郵件等方式將該文件發送給CA。然後，CA根據證書請求文件爲網關製作證書，同樣通過磁盤、電子郵件等方式將證書返回。最後，我們將證書上傳到網關的存儲設備中。該方式適用於網關不支持SCEP或CMP的情況，或者網關與CA之間無法通過網絡互訪的情況。
上述兩種方式可根據網關的實際情況靈活選擇。下面以離線方式爲例，介紹天地會總舵和分舵的網關獲取證書的過程。
離線方式申請證書的流程如下圖所示：
1、創建公私密鑰對
首先，在網關FWA和FWB上創建各自的公私密鑰對，在申請證書時會用到公鑰信息。創建過程中，系統會提示輸入公鑰的位數，位數的長度範圍從512到2048。公鑰的長度越大，其安全性就越高，但計算速度相對來說比較慢。這裏我們要求最高的安全性，所以輸入2048。
在網關FWA上創建公私密鑰對：
[FWA] rsa local-key-pair create
The key name will be: FWA_Host
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 512]:2048
Generating keys...
.................................................+++
...............................................+++
..............++++++++
.++++++++
在網關FWB上創建公私密鑰對：
[FWA] rsa local-key-pair create
The key name will be: FWB_Host
The range of public key size is (512 ~ 2048).
NOTES: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus[default = 512]:2048
Generating keys...
.................................................+++
...............................................+++
..............++++++++
.++++++++
2、配置實體信息
申請證書時，網關FWA和FWB必須向CA提供能夠證明自己身份的信息，實體信息代表的就是網關的身份信息，包括：通用名稱（Common Name）、FQDN（Fully Qualified Domain Name）名稱、IP地址、電子郵箱地址等。其中，通用名稱是必須配置的，而其他幾項是可選配置的。
上述信息都將會包含在證書中，在IKE對等體中配置ID類型時，就可以根據證書中包含的實體信息來決定使用哪種ID類型來進行認證。
實體信息配置完成後，還需要在PKI域中引用實體信息。下面給出網關FWA和FWB上實體信息和PKI域的配置情況：
|
關鍵配置 |
FWA |
FWB |
|
實體信息 |
pki entity fwa common-name fwa //通用名稱 fqdn fwa.tdh.com //FQDN名稱 ip-address 1.1.1.1 //IP地址 email [email protected] //Email地址 |
pki entity fwb common-name fwb //通用名稱 fqdn fwb.tdh.com //FQDN名稱 ip-address 3.3.3.3 //IP地址 email [email protected] //Email地址 |
|
PKI域 |
pki domain fwa certificate request entity fwa //PKI域中引用實體信息 |
pki domain fwb certificate request entity fwb //PKI域中引用實體信息 |
3、生成證書請求文件
接下來就可以在網關FWA和FWB上生成證書請求文件，生成的證書請求文件以“PKI域名.req”的名字保存在網關FWA和FWB的存儲設備中，FWA生成的證書請求文件名字是fwa.req，FWA生成的證書請求文件名字是fwb.req。
[FWA] pki request-certificate domain fwa pkcs10
Creating certificate request file...
Info: Create certificate request file successfully.
[FWB] pki request-certificate domain fwb pkcs10
Creating certificate request file...
Info: Create certificate request file successfully.
在FWA上查看生成的證書請求文件，可以看到裏面包含了上面配置的通用名稱、FQDN名稱、IP地址和電子郵箱地址，以及FWA的公鑰信息。
[FWA] display pki cert-req filename fwa.req
Certificate Request:
Data:
Version: 0 (0x0)
Subject: CN=fwa
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:ae:68:50:18:e7:55:32:7a:0e:61:b6:6e:47:45:
ec:fb:29:d9:1b:4a:9d:6b:b0:00:b0:65:c8:fc:5b:
b4:68:d7:90:7d:96:f7:1d:e4:62:43:06:bc:d0:a3:
5b:b4:fa:30:a3:19:7e:6f:7c:05:6b:47:0c:a2:42:
1b:c4:82:f7:5b:0a:73:a1:0a:8b:00:dd:37:aa:5e:
21:02:56:b2:e6:55:31:08:8f:71:03:13:92:b9:c1:
51:7e:51:04:e2:ca:85:2e:45:97:bb:9a:0e:ed:61:
03:97:d2:1e:44:b2:9f:ff:b9:b1:1d:5d:65:7e:fc:
e6:13:c3:1e:71:81:d0:fe:a0:60:71:a4:8a:40:93:
92:e3:b3:b6:cf:56:f1:30:b2:fc:53:31:bd:9d:6f:
3c:33:1e:4a:a5:6f:83:c7:45:26:8d:c6:9c:84:85:
b5:8f:b9:e3:86:86:59:ad:9b:58:63:a1:3d:7b:81:
d7:43:14:3d:98:4a:a2:cb:82:2c:fa:ca:91:32:b1:
e0:09:de:fa:a8:d6:fc:ea:8e:7e:36:8f:fb:86:31:
1e:bc:5e:01:71:6b:b4:23:86:7b:05:c1:63:7a:f5:
bc:a7:9b:a1:da:ff:4f:26:2d:33:44:06:72:f1:7b:
84:d5:a8:49:1d:be:b4:0e:9c:94:85:34:7b:e5:bb:
8a:49
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Subject Alternative Name:
IP Address:1.1.1.1, DNS:fwa.tdh.com, email:[email protected]
Signature Algorithm: md5WithRSAEncryption
4b:a6:fc:91:2a:77:e3:30:02:bb:e4:0f:1a:bf:d2:a1:ad:81:
3e:44:51:81:b1:26:2d:2e:83:7c:0c:29:70:3c:6a:8a:7a:1a:
27:c8:a4:8d:3b:8f:dc:a7:d7:df:10:be:4c:96:1f:f5:db:96:
4d:e9:28:82:b9:2d:9b:e6:6d:22:52:ca:50:07:c2:7a:2b:17:
c7:49:7a:a6:a5:7c:cc:82:02:15:14:ca:9c:69:39:eb:fb:44:
3a:c9:75:d9:f5:b6:bf:b1:45:e4:e7:f4:db:df:eb:3d:6b:74:
ac:14:e9:51:af:b1:c8:d6:c1:19:48:bc:27:c1:37:59:41:38:
9c:1f:9a:7e:c7:fe:20:c9:e8:1d:94:55:ff:85:3e:8c:5a:f5:
f3:ff:9b:18:36:b1:25:2b:4d:60:2e:13:7b:be:91:c0:a1:1f:
6c:5c:1a:f6:3a:5b:e7:87:2b:43:7f:d8:f6:2b:c8:b1:df:7d:
c8:40:df:07:f9:52:4c:8b:ba:b0:10:f3:34:00:00:74:0b:ae:
c1:7a:9c:dd:de:26:26:28:30:de:e8:6c:dc:0a:c6:8f:27:27:
c6:0d:5e:8e:68:a8:8d:cc:eb:91:9c:59:3d:1e:f3:f3:58:72:
16:bf:cc:f5:df:71:bc:51:fb:98:83:c5:2b:17:73:d7:0a:6c:
f7:93:76:f4
4、CA根據證書請求文件製作證書
證書請求文件生成後，可以將該文件通過磁盤、電子郵件等方式將該文件發送給CA，由CA爲網關FWA和FWB製作證書。除了網關FWA和FWB的證書之外，CA還會提供自身的證書，即CA證書。CA將製作好的FWA和FWB的證書同自身的證書一道通過磁盤、電子郵件等方式返回。
CA製作證書的過程在此不詳細介紹，常用的Windows Server操作系統就可以作爲CA來申請和頒發證書。
5、導入證書
經過CA的處理，最終我們獲取到了網關FWA的證書fwa.cer，網關FWB的證書fwb.cer，以及CA本身的證書ca.cer。下圖展示了網關FWA的證書fwa.cer的內容：
將fwa.cer和ca.cer上傳到FWA的存儲設備中，將fwb.cer和ca.cer上傳到FWB的存儲設備中，然後還需要將證書分別導入到FWA和FWB上。
在FWA上導入CA證書和本地證書：
[FWA] pki import-certificate ca filename ca.cer
Info: Import file successfully.
[FWA] pki import-certificate local filename fwa.cer
Info: Import file successfully.
在FWB上導入CA證書和本地證書：
[FWB] pki import-certificate ca filename ca.cer
Info: Import file successfully.
[FWB] pki import-certificate local filename fwb.cer
Info: Import file successfully.
證書入主對等體，身份認證更便利
導入證書後，網關FWA和FWB都是有“身份”的設備了，在IKE對等體中引入證書，FWA和FWB就可以通過證書來認證對方的身份。
前面提到過，使用證書進行身份認證時，可以根據證書中包含的實體信息來決定使用哪種ID類型。目前可以在IKE對等體中使用DN（Distinguished Name）、FQDN、User-FQDN和IP四種ID類型。這四種ID類型對應的證書中字段以及FWA和FWB上的取值如下表所示。
|
ID類型 |
對應證書中的字段 |
FWA的取值 |
FWB的取值 |
|
DN |
Subject |
本端ID：/CN=fwa 對端ID：/CN=fwb |
本端ID：/CN=fwb 對端ID：/CN=fwa |
|
FQDN |
DNS |
本端ID：fwa.tdh.com 對端ID：fwb.tdh.com |
本端ID：fwb.tdh.com 對端ID：fwa.tdh.com |
|
User-FQDN |
|
本端ID：[email protected] 對端ID：[email protected] |
本端ID：[email protected] 對端ID：[email protected] |
|
IP |
IP Address |
本端ID：1.1.1.1 對端ID：3.3.3.3 |
本端ID：3.3.3.3 對端ID：1.1.1.1 |
下面以ID類型是DN爲例，介紹網關FWA和FWB的關鍵配置：
|
關鍵配置 |
FWA |
FWB |
|
IKE安全提議 |
ike proposal 10 authentication-method rsa-sig //採用證書認證方式 |
ike proposal 10 authentication-method rsa-sig //採用證書認證方式 |
|
IKE對等體 |
ike peer fwb certificate local-filename fwa.cer //FWA的證書 ike-proposal 10 local-id-type dn //ID類型爲DN remote-id /CN=fwb //FWB的DN remote-address 3.3.3.3 //FWB的IP地址 |
ike peer fwa certificate local-filename fwb.cer //FWB的證書 ike-proposal 10 local-id-type dn //ID類型爲DN remote-id /CN=fwb //FWA的DN remote-address 1.1.1.1 //FWA的IP地址 |
|
證書屬性訪問控制策略 |
pki certificate access-control-policy default permit |
pki certificate access-control-policy default permit |
採用證書方式的IKE協商過程與採用預共享密鑰方式的IKE協商過程大致相同，不同之處在於採用證書方式時，兩端交互身份信息的ISAKMP消息（主模式是第5、6條ISAKMP消息；野蠻模式是第1、2條ISAKMP消息）中多了證書載荷和簽名載荷，具體協商過程不再贅述。
至此，天地會找到了可以代替預共享密鑰方式的身份信息認證方案。當新的分舵與總舵建立IPSec連接時，只需要在同一個CA爲該分舵申請證書，然後分舵和總舵就可以通過證書來進行身份認證，從而無需再爲每個分舵和總舵之間的對等體都維護一個預共享密鑰，減少了天地會的管理成本。
說明：數字證書除了在IPSec中使用之外，還可以應用於SSL VPN中客戶端和服務器的身份認證，詳細內容將會在SSL VPN篇中介紹。
除了新發展的分舵，天地會還有一些老的分舵，已經通過GRE或L2TP方式接入總舵。如何在不改變原有接入方式的基礎上使這些分舵和總舵之間可以安全通信呢？下一篇貼子中將介紹GRE、L2TP以及移動接入場景中IPSec的相關內容，敬請期待。