强叔侃墙 VPN篇 IPSec引入数字证书，身份认证简单便捷

在前面两篇贴子中，天地会总舵和分舵的网关进行身份认证时都是使用预共享密钥方式。单从配置过程来说，该方式配置简单，只需在总舵和分舵的网关上配置相同的密钥即可。但随着分舵数量越来越多，总舵和每个分舵之间形成的对等体都要配置预共享密钥。如果所有对等体都使用同一个密钥，存在安全风险；而每个对等体都使用不同的密钥，又不便于管理和维护。

分舵数量日益增长，天地会亟需一个新的身份信息认证方案来代替预共享密钥方式，降低管理成本。既然天地会的总舵和分舵都是以合法生意（如当铺和票号）作为掩护，不如直接向官府的刑部申请为当铺和票号发放身份凭证，标明当铺和票号的身份信息。因为刑部是公正的、可信赖的官府部门，所以盖着刑部大印的身份凭证也就是可信任的，总舵和分舵就可以直接通过身份凭证来验证双方的身份。

这个身份凭证就叫做数字证书，简称证书，是由第三方机构颁发的代表设备身份信息的“身份证”。通过引入证书机制，总舵和分舵可以简单便捷地进行身份认证。在详细介绍证书的实现原理和获取方法之前，我们先来了解一下公钥密码学和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 [e-mail]   //Email地址

pki entity fwb

 common-name fwb   //通用名称

fqdn fwb.tdh.com   //FQDN名称

ip-address 3.3.3.3   //IP地址

email [e-mail]   //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:[e-mail]         

    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

email

本端ID：[e-mail]

对端ID：[e-mail]

本端ID：[e-mail]

对端ID：[e-mail]

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的相关内容，敬请期待。