证书在手，认证无忧---证书浅析

在IPSec VPN篇章中，我们介绍了IPSec隧道两端设备使用证书进行身份认证的内容，在刚刚推出的SSL VPN开篇中，也介绍了证书认证的相关内容。作为网络世界的“身份证”，证书在身份认证的场景中已经得到了普遍应用。

大家可能已经习惯了用户名+密码的认证方式，而对证书这种认证方式还不太了解。为此，强叔带来了本篇内功心法，揭示证书的来龙去脉和使用方法，帮助大家提升内力。

根基 ---公钥密码学

在介绍证书之前，我们先来了解一些密码学的基本概念，包括对称密码学和非对称密码学，为理解证书的实现原理打好基础。

首先，一提到加密，我们自然会想到通信双方使用相同的算法和密钥去加密和解密数据。加密和解密过程中用到的密钥是双方都知道的，即双方的“共享密钥”。这种加密方式称为对称密码学，也叫做单钥密码学。

如下图所示，A向B发送数据，A使用双方事先协商好的算法和密钥来加密数据，B使用相同的算法和密钥来解密数据。反之同理，B向A发送数据时，B加密数据而A解密数据，双方使用的都是相同的算法和密钥。

注意：我们用“算法[密钥]”来表示使用该算法和密钥对数据进行加密或解密处理，下文中出现的类似表达方式含义相同。

 

对称密码学的优点是效率高，开销小，适合加密大量的数据。但对称密码学要求通信双方事先协商好密钥，这就要求在协商过程中必须做好保密，密钥只能让使用的人知道，不能泄露。另外，如果通信方数量庞大，比如A需要和数百个对象通信，为了安全起见，就需要在A上维护数百个不同的共享密钥，这就为密钥更新和管理带来诸多不便。

为了解决对称密码学面临的问题，公钥密码学横空出世，开创了密码学的新方向。公钥密码学使用了两个不同的密钥：一个可对外界公开，称为“公钥”；一个只有所有者知道，称为“私钥”。这一对密钥具有如下特点：

l  用公钥加密的信息只能用相应的私钥解密，反之用私钥加密的信息也只能用相应的公钥解密，即用其中任一个密钥加密的信息只能用另一个密钥进行解密。

l  要想由一个密钥推出另一个密钥，在计算上是不可能的。

由于公钥密码学使用了两个不同的密钥，所以属于非对称密码学，也称为双钥密码学。目前常用的公钥密码学算法有以下几种：

l  RSA（Rivest, Shamir and Adleman），这个由三位发明者名字命名的算法是当前最著名、应用最广泛的公钥密码学算法。RSA可实现数据加解密、真实性验证和完整性验证。

l  DSA（Digital Signature Algorithm），中文名称叫数字签名算法，可实现签名功能。本篇对DSA不做过多的介绍，大家可以自行查阅相关资料。

l  DH（Diffie-Hellman），也是由发明者名字命名的一种密钥交换算法，通信双方通过一系列的数据交换，最终计算出密钥，以便用于以后的报文加密。在IPSec中就用到了DH算法，使得建立IPSec隧道的两端网关设备可以计算出密钥，而不必担心密钥泄露，我们在IPSec篇中对此进行过介绍。

数据加解密

下面我们就以RSA算法为例，介绍通信双方如何实现数据加解密功能。如下图所示，A和B各自生成自己的公钥和私钥，并且相互交换了双方的公钥（至于双方是通过什么途径来交换公钥，我们先留个伏笔，后面会讲到）。A要向B发送数据，A使用B的公钥加密数据然后发送给B，B收到后使用自己的私钥解密数据。因为其他人没有B的私钥，即使截获报文也无法解密，这就保证了数据传输的安全性。B向A发送数据时，过程同理。

 

与对称密码学相比，公钥密码学加密数据的计算非常复杂，而且开销大、速度较慢，所以不适用于加密大量数据的场景。在实际使用中，通信双方通常会使用公钥密码学来交换密钥素材，双方最终计算出密钥，而用对称密码学来加密实际的数据，两者配合使用，保证了加密速度和安全性。

如下图所示，A向B发送数据，A使用B的公钥把加密算法和密钥素材加密后发给B，B收到后使用自己的私钥解密，这样就得到了算法和密钥素材（B也可以将自己要采用的算法和密钥素材发给A，即双方通过协商方式来确定算法和密钥素材），双方根据密钥素材计算出密钥。然后就可以通过对称密码学的机制，使用相同的算法和密钥对数据进行加密和解密。

 

 

真实性验证

除了加解密，RSA还能实现真实性验证，即身份认证功能，这也是利用了公钥密码学中由任一个密钥加密的信息只能用另一个密钥进行解密这一原理。

如下图所示，A要认证B的身份，首先A向B发送数据（例如一串字符串），B用自己的私钥将数据加密，然后发送给A。A用自己所持有的B的公钥解密，将解密后的数据和原始数据进行对比，如果一致，说明数据的确是由B发过来的。因为B的私钥只能由B持有，因此A可以通过判断对方是否持有私钥来判断对方是否就是B，进而实现了对B的身份认证，这就是使用公钥密码学来进行身份认证的理论基础。

 

加解密功能是数据发送方使用接收方的公钥加密，接收方使用自己的私钥解密。而身份认证功能是被认证方使用自己的私钥进行加密，认证方使用被认证方的公钥进行解密。

完整性验证

使用私钥加密公钥解密这种方式，还能实现完整性验证，即签名功能。所谓签名，就是在数据的后面再加上一段内容，可以证明数据没有被修改过，那怎么样生成签名呢？

发送方可以用自己的私钥加密数据，然后连同数据一起发给接收方。但是，由于公钥密码学计算复杂、速度慢的原因，通常发送方一般不直接使用私钥加密数据，而是先将原始数据经过某种计算得出一段较短的数据，然后发送方使用自己的私钥加密这段新的数据，这和直接加密原始数据的效果是一样的，而且还兼顾了安全和处理速度。这种计算方式是通过HASH密码学来实现的。

HASH密码学可以将任意长的字符串通过哈希计算出固定长度字符串，并且该计算是单向运算，无法逆推。最重要的是，原字符串任意字符的变化都会导致不同的计算结果。HASH计算后得出的信息通常称为原字符串的摘要信息，也可以称为指纹信息。通过对比摘要信息，就可以判断数据是否被修改，所以HASH密码学通常用于保证数据的完整性。常见的HASH算法有MD（Message Digest algorithm）系列、SHA（Secure Hash Algorithm）系列等，之前在IPSec篇中我们也都配置过这些算法。

如下图所示，A向B发送数据之前，先使用HASH算法将数据进行HASH计算，得出摘要信息。然后使用自己的私钥将摘要信息加密，形成签名，最后将数据和签名一并发给B。B收到后，使用相同的HASH算法也对数据进行HASH计算，得到摘要信息；然后B使用A的公钥对签名进行解密，得到另一个摘要信息。B将两个摘要信息进行对比，如果两者一致，就说明数据确实是从A发过来的，并且没有被修改过，这样既验证了A的身份又实现了数据完整性保护。

注意：为了便于讲解，图中A发给B的信息没有加密，实际情况下，A会使用通过计算得出的密钥将信息加密后再发给B，B使用相同的密钥解密后再进行处理。

 

我们花费了一些笔墨介绍公钥密码学的原理，相信大家对公钥密码学已经有了初步的了解。必须强调一点，公钥密码学能够保证安全的重要前提是私钥必须得到安全妥善的保存，不能被泄露。接下来我们便要解决前面留下的问题，即通信双方是通过什么途径来获取到对方的公钥。

通常情况下，通信双方在每次通信时都把自己的公钥发给对方，这是最直接的方法。但是这种方法存在安全问题，因为谁都可以生成公钥和私钥，仅凭一个公钥，我们无法判断收到的公钥到底是不是对方的。除非对方把公钥和身份信息同时发送过来，并且有绝对可信的第三方做**，证明这个公钥确实是发送方的。也就是说，通信双方就需要一个安全可信的载体来交换公钥，这个载体就是证书。

载体 ---证书

证书，也叫做数字证书，是网络世界中的“身份证”。证书将持有者的身份信息和公钥关联到一起，保证公钥确实是这个证书持有者的，通过证书就可以确认持有者的身份。证书由权威的、公正的、可信任的第三方机构颁发，我们把证书的颁发机构称为CA（Certificate Authority），相当于现实生活中的公安局。

证书属性

公钥是通过证书来向外界公开分发的，证书中必然会含有持有者的公钥信息。除此之外，证书中还包括哪些信息呢？下图展示了一个遵循X.509 v3版本规范的证书格式，我们简要介绍一下其中的关键信息。

 

l  签名算法：生成该证书的签名时所使用的HASH密码学算法和公钥密码学算法。

l  颁发者：谁颁发了这个证书，即CA的名称。

l  主题：该证书时颁发给谁的，即证书持有者的名称。

l  公钥信息：证书持有者的公钥信息。

l  签名：CA对该证书的签名，又叫做CA的指纹信息。

下图展示了证书中签名的形成过程，操作都是在证书颁发之前，也就是在CA上来进行的。首先，CA使用签名算法中的HASH密码学算法（如SHA1）生成证书的摘要信息，然后使用签名算法中的公钥密码学算法（如RSA），配合CA自己的私钥对摘要信息进行加密，最终形成签名。

 

证书颁发

通常情况下，为网络中的设备（PC、防火墙等）申请证书时，我们先要在设备上生成公私密钥对，然后将公钥以及设备信息提供给CA，CA根据这些信息来生成证书。当然，也可以由CA来帮助设备生成公私密钥对，并为设备生成证书。然后将CA生成的公私密钥对和证书导入到设备中，省去了设备自己生成公私密钥对的过程。

CA生成证书后，会把证书以文件的形式颁发给使用者。常见的证书存储格式如下表所示。

DER

二进制编码，后缀名.der/.cer/.crt

不包含私钥

PEM

BASE 64编码，后缀名.pem/.cer/.crt

不包含私钥

PKCS #12

PKCS编码，后缀名.p12

包含私钥

注意：公私密钥对必须成对出现才能保证公钥密钥学正常运转，所以如果CA同时为设备生成了公私密钥对和证书，就需要将公私密钥对（主要是其中的私钥）和证书同时颁发给设备，颁发时需要根据不同情况选择证书的存储格式。例如，颁发给PC时就要选择PKCS #12格式，将私钥和证书同时颁发；颁发给防火墙时，因为防火墙只支持DER/PEM格式，所以要选择DER/PEM，同时还必须将公私密钥对以单独文件的形式颁发给防火墙。

证书验证

证书颁发给使用者后，使用者就会拿着证书到处证明自己的身份。如果我们收到了一个这样的证书，怎么才能判断这个证书就是合法的，不是伪造的呢？还记得前面我们介绍过的HASH密码学吗，我们可以利用HASH密码学原理，通过证书中的签名来验证证书的真伪。

例如，A收到了B发过来的证书，想要验证这个证书的真伪，此时A首先需要获取到为B颁发证书的那个CA的公钥，用这个公钥解密证书中的签名，得到摘要信息；然后A使用证书中签名算法里面的HASH密码学算法对证书进行HASH计算，也得到一个摘要信息。A将两个摘要信息进行对比，如果两者一致，就说明证书确实是由这个CA颁发的（能用CA的公钥解密说明该CA确实持有私钥），并且没有被篡改过，该证书没有问题。当然，也会同时检查证书是否在有效期内。

到这里大家可能会有疑问，为A颁发证书的那个CA的公钥又该如何获取呢？答案还是证书，从CA的证书获取。也就是说，CA除了给别人颁发证书外，它本身也有自己的证书，证书中包含CA的公钥。A使用CA的证书验证B的证书的过程如下图所示。

  

 

再进一步，如何判断为B颁发证书的这个CA的证书真伪以及是否被篡改过？答案是用CA自己的公钥来验证自己的签名，即用CA证书中的公钥解密该证书中的签名，得到摘要信息；然后使用CA证书中签名算法里面的HASH密码学算法对该证书进行HASH计算，得到另一个摘要信息，两者一致，说明该CA证书是真实的，没有被篡改过。 此时有一个新的问题，假设黑客伪造了CA证书，证书中的签名是黑客用自己的私钥来签名，而公钥就是黑客自己的公钥，那么对该CA证书的验证也能通过。所以上述验证过程的前提是CA证书必须是在可信任的机构获取的，保证没有被伪造。

如果通信双方要互相验证对方的证书，那就要分别获取到为对方颁发证书的CA的证书。如下图所示，A如果要验证B的证书，则A必须先获取为B颁发证书的CA的证书，用CA的证书验证B的证书；B如果要验证A的证书，则B必须先获取为A颁发证书的CA的证书，用CA的证书验证A的证书。如果A和B是由同一个CA颁发的证书，那么两者获取到的CA的证书是相同的，如果A和B是由两个不同的CA颁发的证书，那么两者获取到的CA的证书是不同的。

 

对于证书的使用方法，下面我们再进行一下总结：

1、通信双方各自持有自己的证书，当一方需要向另一方证明身份时，就把自己的证书发送过去。双方不用事先保存对方的证书，只在验证时接收对方发送过来的证书即可。

2、一方验证另一方证书的真伪时，必须事先获取到为另一方颁发证书的CA的证书，用这个CA证书来验证对方的证书。

注意：因为不同的CA会颁发不同证书，所以在证书的世界中，每个人可能会持有多个证书。同理，每个人也会获取到多个不同的CA证书。在这种情况下，一方收到另一方发过来的证书时，会根据证书中颁发者的名称，在自己的系统中查找对应的CA证书，找到后就用这个CA证书来验证。如果没有找到，那就说明事先没有获取到CA证书，也就无法判断对方发送过来的证书的真伪。

上面我们介绍了证书的很多内容，但还是有一个前提条件没有解决，那就是如何从CA获取证书？我们可以通过PKI（Public Key Infrastructure）框架来实现证书的生成、管理和维护，但是搭建一个PKI环境比较复杂。其实我们可以向网上的专业证书颁发机构申请证书，例如Verisign、Geotrust、Globalsign等。

我们还可以利用平时常用的资源，搭建我们自己的CA环境。比如，常用的Windows Server操作系统就可以作为CA来颁发证书，具体的配置方法在网上都可以搜索到，此处不再赘述。这里强叔想为大家介绍一个开源的第三方证书管理软件XCA，通过这个软件来帮助设备生成公私密钥对，然后为设备生成并颁发证书。

下面我们就结合证书的具体应用，介绍XCA的使用方法。

应用 ---IPSec VPN和SSL VPN

证书在IPSec中的应用

在IPSec引入数字证书，身份认证简单便捷一篇中，我们已经介绍过了IPSec隧道两端网关设备使用证书进行身份认证的配置，在这里就不做过多介绍了。需要注意的是，当时两台网关设备是从同一个CA申请的证书，所以两台设备上安装的CA证书也是相同的；如果两台网关设备从不同的CA申请证书，那就需要在两台网关设备上分别安装为对方颁发证书的那个CA的证书。

证书在SSL VPN中的应用

在远程接入IPSec现短板，SSL VPN登上历史舞台一篇中，我们分析了客户端和服务器（即防火墙设备）建立SSL连接的过程，其中包括了两个阶段：首先是客户端对服务器进行身份认证，然后是服务器对客户端进行身份认证。

下图展示了在SSL VPN连接建立过程中，不同类型的证书的安装和使用方法。由于客户端和服务器都是由XCA颁发的证书，所以两者获取到的CA的证书是相同的。另外，由于我们使用了XCA生成的证书替换了服务器内置的证书，所以还需要将XCA为服务器生成的公私密钥对导入到服务器中。

 

第一阶段：客户端验证服务器的身份

我们先来看一下第一个阶段。在这个阶段中，服务器将自己的证书发送给客户端，客户端需要用为服务器颁发证书的CA的证书来验证这个证书。但是，客户端在自己的系统上没有找到CA的证书，无法验证服务器证书的真伪，所以浏览器会提示警告框。

我们可以先忽略这个警告，等出现登录页面后，在页面左侧下载CA证书并安装到客户端的系统中，就可以验证服务器证书的真伪，后续客户端登录时就不会再出现警告框了。

可见，服务器向CA申请好证书后，将自己的证书连同CA的证书一块内置到系统中。当服务器需要被客户端验证时，就会将自己的证书发给客户端；同时，在登录页面上提供CA证书，供客户端下载使用。

当然，我们也可以替换掉服务器内置的证书，使用我们自己认可的CA，如XCA为服务器颁发新的证书。下面介绍如何使用XCA软件来生成CA证书和服务器的证书。

操作步骤如下：

1、从http://sourceforge.net/projects/xca/下载并安装XCA软件，具体过程略。

2、在“File”菜单中创建一个新的数据库，输入数据库的名字，然后设置该数据库的密码，使用这个数据库来保存密钥对和证书的信息。

3、在“Private  Keys”页签，生成CA的公私密钥对。

 

参考上述步骤，生成服务器的公私密钥对，密钥对的Name为10.1.1.1，即用服务器的IP地址标识，其他参数不变。

4、在“Certificate”页签，生成CA的证书。

然后为该CA证书生成CRL，即设置该证书的有效期。

5、参考上述步骤，生成服务器的证书，与CA证书生成过程中有差异的参数取值如下表所示。

注意：服务器证书的CN字段取值必须与服务器IP地址一致的要求，否则在客户端上无法验证通过，所以我们这里将证书的名称设置为10.1.1.1。

Source页签

Signing

Use this Certificate for signing: CA

Template for the new certificate

[default] HTTPS_server

Subject页签

Internal name

10.1.1.1

commonName

10.1.1.1

Private key

10.1.1.1 (RSA)

6、以PEM格式导出CA证书CA.crt和服务器证书10.1.1.1.crt，保存文件备用。

 

 

7、导出服务器的公私密钥对10.1.1.1.pem，保存文件备用。为了保证密钥对的安全，导出时要设置密码。

 

8、将CA证书CA.crt发送至客户端，在客户端上双击CA.crt，按照提示将该证书存储到“受信任的根证书颁发机构”中。

9、将服务器的公私密钥对文件10.1.1.1.pem上传至服务器，然后执行如下命令导入公私密钥对，password处输入导出时设置的密码。

注意：在SSL握手过程的第3次通信中，客户端会使用服务器的公钥将随机数pre-master-key加密后发给服务器，要求服务器上必须存在私钥才能解密。

[Server] pki import rsa-key-pair 10.1.1.1 pem 10.1.1.1.pem password huawei

10、在服务器上安装自己的证书10.1.1.1.crt。

 

11、配置服务器使用10.1.1.1.crt来向客户端证明自己的身份。

 

完成上述操作后，当客户端访问服务器的登录页面时，就可以用XCA的CA证书来验证服务器发送过来的证书。由于服务器的证书也是由XCA颁发的，所以验证通过，浏览器不会提示警告框。

第二阶段：服务器验证客户端的身份

下面来看一下第二个阶段，即服务器使用证书方式对客户端进行身份认证的过程。在这个阶段中，客户端要向服务器发送自己的证书，服务器使用为客户端颁发证书的CA的证书来验证客户端的证书。下面我们就以服务器使用证书匿名认证方式认证客户端为例，介绍使用XCA软件为客户端生成证书的过程。

操作步骤如下（省略了与第一阶段相似的部分截图）：

1、在“Private  Keys”页签，生成客户端的公私密钥对，密钥对的Name为Client。

2、在“Certificate”页签，按照下表中的参数取值，生成客户端的证书。

Source页签

Signing

Use this Certificate for signing: CA

Template for the new certificate

[default] HTTPS_client

Subject页签

Internal name

Client

commonName

Client

Private key

Client (RSA)

3、以PEM格式导出CA证书CA.crt，以PKCS #12格式导出客户端的证书Client.p12（因为PKCS #12格式的证书中包含了私钥，所以导出时需要设置密码），保存文件备用。

注意：本步骤中导出的CA证书要安装到服务器（防火墙）上，格式必须为PEM或DER，而客户端证书要安装到客户端（PC）上，格式必须为PKCS #12。

4、将客户端证书发送至客户端，在客户端上双击Client.p12，按照提示安装即可，安装过程中需要输入导出该证书时设置的密码。

安装成功后，在Windows操作系统的MMC控制台中，可以看到客户端的证书，以及在第一阶段的步骤8中安装的CA证书。客户端证书中包含私钥，所以图标比CA证书的图标多了一个“钥匙”的标志，如下图所示。

 

5、在服务器上安装CA的证书CA.crt，该CA证书在第一阶段的步骤6中已经导出。

 

6、配置服务器使用CA.crt来验证客户端的身份。

 

完成上述操作后，客户端使用浏览器访问服务器的登录页面时，就可以在浏览器中选择自己的证书来进行身份认证，成功登录到服务器上。

至此，本篇的内容就全都介绍完毕，希望通过强叔的介绍，能够帮助大家明晰证书概念原理，掌握证书使用方法，更好地运用证书来进行身份认证。也请大家继续关注强叔侃墙，关注SSL VPN接下来的技术贴。