安全HTTPS-全面详解对称加密，非对称加密，数字签名，数字证书和HTTPS

一，对称加密

所谓对称加密，就是它们在编码时使用的密钥e和解码时一样d(e=d)，我们就将其统称为密钥k。

 

对称加解密的过程如下：

发送端和接收端首先要共享相同的密钥k(即通信前双方都需要知道对应的密钥)才能进行通信。发送端用共享密钥k对明文p进行加密，得到密文c，并将得到的密文发送给接收端，接收端收到密文后，并用其相同的共享密钥k对密文进行解密，得出明文p。

 

一般加密和解密的算法是公开的，需要保持隐秘的是密钥k，流行的对称加密算法有：DES，Triple-DES，RC2和RC4

 

对称加密的不足主要有两点：

1，  发送方和接收方首先需要共享相同的密钥，即存在密钥k的分发问题，如何安全的把共享密钥在双方进行分享，这本身也是一个如何安全通信的问题，一种方法是提前双方约定好，不通过具体的通信进行协商，避免被监听和截获。另外一种方式，将是下面我们介绍的通过非对称加密信道进行对称密码的分发和共享，即混合加密系统。

2，  密钥管理的复杂度问题。由于对称加密的密钥是一对一的使用方式，若一方要跟n方通信，则需要维护n对密钥。

 

对称加密的好处是：

加密和解密的速度要比非对称加密快很多，因此常用非对称加密建立的安全信道进行共享密钥的分享，完成后，具体的加解密则使用对称加密。即混合加密系统。

 

另外一个点需要重点说明的是，密钥k的长度对解密破解的难度有很重大的影响，k的长度越长，对应的密码空间就越大，遭到暴力破解或者词典破解的难度就更大，就更加安全。

 

二，非对称加密

所谓非对称加密技术是指加密的密钥e和解密的密钥d是不同的（e!=d），并且加密的密钥e是公开的，叫做公钥，而解密的密钥d是保密的，叫私钥。

 

非对称加解密的过程如下：

加密一方找到接收方的公钥e (如何找到呢？大部分的公钥查找工作实际上都是通过数字证书来实现的)，然后用公钥e对明文p进行加密后得到密文c，并将得到的密文发送给接收方，接收方收到密文后，用自己保留的私钥d进行解密，得到明文p，需要注意的是：用公钥加密的密文，只有拥有私钥的一方才能解密，这样就可以解决加密的各方可以统一使用一个公钥即可。

 

常用的非对称加密算法有：RSA

 

非对称加密的优点是：

1，  不存在密钥分发的问题，解码方可以自己生成密钥对，一个做私钥存起来，另外一个作为公钥进行发布。

2，  解决了密钥管理的复杂度问题，多个加密方都可以使用一个已知的公钥进行加密，但只有拥有私钥的一方才能解密。

  非对称加密不足的地方是加解密的速度没有对称加密快。

 

综上，分析了对称加密和非对称加密各自的优缺点后，有没有一种办法是可以利用两者的优点但避开对应的缺点呢？答应是有的，实际上用得最多的是混合加密系统，比如在两个节点间通过便捷的公开密码加密技术建立起安全通信，然后再用安全的通信产生并发送临时的随机对称密钥，通过更快的对称加密技术对剩余的数据进行加密。

 

三，数字签名

上面讨论了非对称加密技术在编码中的使用，解决的是传送数据的私密性，一般是用公钥作为加密key，而私钥作为解密key，那假如是用私钥作为加密key，而公钥作为解密key呢？

由于私钥只有对应一方才知道，因此若通过对应的公钥可以验证对方是用对应的私钥进行加密的，则可以说明对方的身份，这就是数字签名。

 

数字签名需要解决的两个任务是：

1，  谁编写的报文；

2，  报文的内容是否被篡改过；

 

数字签名的过程一般如下：

1，  发送方A首先对变长的报文提取成一个定长的摘要，一般是md5等

2，  A对摘要应用了一个签名函数，并且用A自己的私钥作为参数，因为只有A才知道私钥，所以正确的签名会说明签名者就是其所有者。

3，  一旦计算出签名，节点A就将其附加到报文的末尾，并将报文和签名一起都发送给B

4，  在接收端B，首先会按照同样的算法计算出报文的摘要，然后对签名用A的公钥进行解码，得出解码后的摘要，两个摘要进行比较，则可以判断是否是A发送的且内容没被篡改过。

 

四，数字证书

实际上，好多的公钥都是通过数字证书进行发布的，数字证书类似一个人的身份证一样，由对应的官方的颁发结构颁发的，类似一个人的身份证有姓名，身份证ID，有效期，颁发机构-一般是某某派出所等，数字证书也有类似的形式。

 

基本的数字证书包括了一些常见的信息：

1， 对象的名称（人，服务器，组织等）

2， 过期时间

3， 对象的公钥

4， 证书发布者（由谁为证书担保）

5， 来自证书发布者的数字签名。

…

需要注意的是，任何人都可以创建一个证书，但不是所有人都能够获得受人尊敬的签发权从而为证书信息提供担保，并用其私人密钥签发证书。

不幸的是，数字证书没有单一的全球标准，但现在使用的大多数证书是以一种标准格式– X.509 v3，来存储它们的信息。

 

x.509证书格式：

字段	描述
版本号	这个证书的X.509证书版本号，现在通常是版本3
序列号	证书颁发机构CA生成的唯一整数，CA生成的每个证书都要有一个唯一的系列号，类似身份证号码
签名算法ID	签名使用是算法，如用RSA加密的MD2摘要
证书颁发者	以X.500格式说明的CA的组织名称
有效期	证书的有效期，由一个起始日期和一个结束日期来表示
对象名称	证书中描述的实体，比如一个人或者一个组织，对象名称以x.500格式表示
对象的公开密钥信息	证书对象的公钥，公钥使用的算法，以及所有附加的参数
发布者唯一的ID(可选)	可选的证书发布者唯一ID，这样可以重用相同的发布者名称了
对象唯一的ID（可选）	可选的证书对象唯一ID，这样就可以重用相同的对象名称了
扩展	一些扩展信息
证书的颁发机构签名	CA用指定的签名算法对上述所有字段的数字签名

 

x.509证书有很多种，如服务器端证书，个人证书等。

浏览器中的证书：

 

 

 

注意：每个证书均有对应于证书公钥的私钥，私钥不能被导出，访问一般需要密码等。

 

浏览器会默认存储一些受信任的根证书颁发机构的证书，从图中可以看，这些证书都是颁发者颁发给自己的。

 

 

五，用服务器证书对服务进行认证

在支付网站中，用户需要确认他们输入支付密码的站点是真正的经过认证的站点，而不是被钓鱼的网站，因此用户有必要认证对应的服务器，而这种方式是通过服务器证书来进行的。过程大概如下：

1， 通过https建立一个安全web事务之后，浏览器会自动获取所连服务器的数字证书；

其中服务器证书包括了：

        Web站点名称和主机名

        Web站点的公钥；

        颁发机构的名称；

        颁发机构给证书的签名；

2，  若服务器没有证书，则安全连接失败。

3，  浏览器首先检查服务器证书是否还在有效期内，若过期，则提示失效；

4，  浏览器查看服务器证书对应的CA，若该CA是很权威的机构，则浏览器可能已经知道了对应的公钥了（浏览器会预先安装很多签名颁发机构的证书并认为是受信任的），这时，浏览器用CA的数字证书里面的公钥来验证该CA颁发的服务器证书的有效性。类似去公安局验证某人的身份证是否是真的。

5，则浏览器对签名颁发机构CA一无所知，浏览器无法确定是否该信任这个签名颁发机构，它通常会向用户提示一个对话框，看看他是否相信这个签名发布者。

5，  一旦完成了对服务器证书的验证，接下来就可以使用服务器证书里面的公钥进行服务器身份的验证；

6，  客户端生成一个随机数给到服务器，要求对应的服务用对应服务器证书是私钥进行签名。

7，  服务器对随机数进行签名，并回传给到客户端。

8，  客户端用服务器证书的公钥对随机数的签名进行验证，若验证通过，则说明对应的服务器确实拥有对应服务器证书的私钥，因此判断服务器的身份正常。否则，则任务服务器身份被伪造。

 

六，用客户端证书对客户端进行认证

客户端证书和服务器证书类似，只是服务器证书增加一些对服务器站点名称和主机名等内容的签注，客户端证书一般是某个机构针对个人颁发的，用于标识个人的身份。如财付通提示用户安装对应的数字证书，就是一个客户端证书，在安装客户端证书的时候，实际上会把用户对应该证书的私钥要保存起来。客户端用私钥进行签名，然后第三方用客户端证书的公钥进行验签实现对客户端身份的认证。

 

七，HTTPS的双向认证，则需要客户端和服务器交换证书。

在发送已加密的HTTP报文前，客户端和服务器要进行一次SSL握手，在这个握手的过程中，它们要完成以下工作：

1，  交换协议版本号；

2，  选择一个两端都了解的密码；

3，  对两端的身份进行验证；

4，  生成临时的会话密钥，后续便用该密钥进行加密信道。

1.  HTTPS

1.1. 什么是HTTPS

HTTPS（HypertextTransfer Protocol Secure）即安全的HTTP。HTTPS的安全基础是安全套接层（Secure Sockets Layer，SSL）。HTTP工作在应用层（OSI模型的最高层），SSL协议工作在一个较低的子层，位于TCP/IP协议和HTTP协议之间。在HTTP报文传输前对其加密，并在到达时对其解密。严格地讲，HTTPS并不是一个单独的协议，而是工作在SSL协议上的HTTP协议。

TLS对SSL进行了扩充，是SSL的继任者，但两者区别不大，以下讨论中不对TLS和SSL做严格区分。

HTTPS主要作用有两种：（1）确认通讯双方的身份，（2）建立安全通道，保证数据传输安全。1.2. HTTPS的主要作用

1.2.1. 确认通讯双方的身份

HTTPS通讯中，通过签名技术通讯双方可以确认对方身份。身份认证分为单向认证和双向认证。单向认证中只有服务器端有证书，双向认证中服务器和客户端都有证书。一般的HTTPS站点只有服务器有证书，而客户端无证书。

单向认证是双向认证的简化版，本文讨论过程中如无特殊说明都认为是双向认证。

1.2.2. 建立安全通道，保证数据传输安全

基于SSL协议通讯双方可以协商一个用于对称加密的密钥，该密钥是一个难以破解的随机数，而且依赖通讯双方的证书、私钥等来协商。密钥协商好后，通讯双方用该密钥对数据进行加解密，从而保证数据安全。

1.3. HTTPS与HTTP协议的差异

(1).   HTTP 的URL是以“http://”开始，HTTPS的URL是以“https://”开始；

(2).   HTTP默认端口为80，HTTPS的默认端口为443；

(3).   采用HTTPS的Web Server需要到CA申请证书；

(4).   HTTPS由HTTP+SSL来实现，可进行加密传输、身份认证等，要比HTTP安全

(5).   HTTP的信息是明文传输，而HTTPS的信息是加密传输

  

2.  公开密钥加密

2.1. 什么是公开密钥加密？

公开密钥加密也称非对称密钥加密，该加密算法使用两个不同的密钥：加密密钥和解密密钥。前者公开，又称公开密钥，简称公钥；后者保密，又称私有密钥，简称私钥。这两个密钥是数学相关的，用某用户加密密钥加密后所得的信息只能用该用户的解密密钥才能解密。RSA算法（由发明者Rivest，Shmir和Adleman姓氏首字母缩写而来）是著名的公开密钥加密算法。

公钥加密的另一用途是身份验证：用私钥加密的信息，可以用公钥对其解密，接收者由此可知这条信息确实来自于拥有私钥的某人。私钥加密的过程即数字签名。

用公钥加密的数据只有私钥才能解密；相反的，用私钥加密的数据只有公钥才能解密，正是这种不对称性才使得公用密钥密码系统被广泛应用。

2.2. 优点

与对称密钥加密相比，优点在于无需共享的通用密钥，解密的私钥不发往任何用户。即使公钥在网上被截获，如果没有与其匹配的私钥，也无法解密，所截获的公钥是没有任何用处的。　　

2.3. 过程

假设两个用户A，B进行通信，公钥为c,私钥为d，明文为x.

Step 1. A用公钥对明文进行加密形成密文c(x)，然后传输密文；

Step 2. B收到密文，用私钥对密文进行解密d(c(x)),得到要通信的明文

2.4. 对称密钥加密

对称密钥加密又叫专用密钥加密，即发送和接收数据的双方必须使用相同的密钥对明文进行加密和解密运算。

3.    数字证书和CA

3.1. 确认主机的真实性

采用https 的server（服务器）必须从CA （CertificateAuthority）申请一个用于证明服务器用途类型的数字证书（或者叫CA证书）. 该证书只有用于对应的server 时，客户端才信任此主机.

CA（Certificate Authority）即"认证机构"，是负责签发证书、认证证书、管理已颁发证书的机构，是PKI（Public Key Infrastructure，公钥基础设施）的核心。它要制定政策和具体步骤来验证、识别用户身份，并对用户证书进行签名，以确保证书持有者的身份和公钥的拥有权。

CA 也拥有一个证书（内含公钥）和私钥。网上的公众用户通过验证 CA 的签字从而信任CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。

 

3.2. 什么是数字证书

数字证书（CA证书是经过认证的数字证书）是一个用于互联网通讯中认证身份的工具，由权威机构——CA机构（Certificate Authority）发行。其作用类似于司机的驾驶执照和公民身份证。CA作为公正的第三方来确保证书的有效性[6]。全国存在多个CA机构（只要你有公信力你也可以成立一家CA机构）。

数字证书包含一个公钥以及该密钥所有者的信息。证书还标明有有效期，并通过另一密钥（CA私钥）进行签名，该密钥能保证这些属性的真实性，最重要的是，保证公钥本身的真实性[14]。最简单的证书包含一个公钥、名称以及证书授权中心的数字签名（公开密钥只是证书的一部分内容）。目前，证书的格式和验证方法普遍遵循X.509 国际标准。

CA机构自身也拥有一个证书（内含公钥）和一个私钥。

用户如果想得到一个数字证书，他应先向 CA申请，CA审查申请者的身份后，给他分配一个公钥，并将公钥与申请者的身份信息绑在一起，同时用自己的私钥签字，最终生成一个证书，发给申请者；同时还将一个与公钥关联的私钥也发给申请者。证书的内容主要有：CA信息、CA签字、证书拥有者信息、证书公钥和证书有效期等。

某人需要验证一个证书时，用签发该证书的CA的公钥来解密其签名信息，以验证证书是否可信。CA证书也需要验证，验证CA证书是一个递归上溯的过程，验证过程终止于根证书。根证书是一份特殊的证书，它的签发者是它本身，下载根证书就表明用户对该根证书，以及其所签发的证书都信任。

 

3.3. 数字证书基本原理

数字证书采用公开密钥加密体制，利用一个强关联的密钥对进行加、解密。证书拥有者保存好自己的私钥，用它进行解密和签名；并把公钥公开，供一组用户所共享，用于加密和验证签名。

1、加密：发送数据时，发送方使用接收方的公钥对数据加密，接收方用私钥解密，还原消息。算法保证公钥加密的数据只有对应的私钥才能解密。

2、数字签名：证书拥有者用私钥对信息进行加密，由于私钥仅为本人所有，这样就生成了别人无法伪造的数据，该数据即数字签名。采用数字签名，能够确认以下两点：

（1）保证信息是由签名者所发送，签名者不能否认或者难以否认；

（2）保证信息自签发后到收到为止，未曾做过任何修改，签发的文件是真实的文件。

算法保证只有公钥才能解开私钥加密的信息。

3.4. 如何生成数字证书

略

 

4.  SSL

4.1. 什么是SSL

SSL 是一个安全协议，它提供使用TCP/IP 的通信应用程序间的隐私与完整性。传输层安全（Transport Layer Security，TLS）对SSL进行了升级改造，将成为SSL的继任者。

4.2. 加密过程

SSL 协议既用到了公钥加密技术(非对称加密)，又用到了对称加密技术。

Step 1：用公开密钥加密技术（通常为RSA）验证彼此身份（有时服务器不需要验证客户端身份），并协商Step2中通讯时所用的对称加密密钥；

Step 2：用对称密钥加密技术（如DES，或者RC4）加密服务器端和客户端通讯时的数据。

这样做的好处是：公开密钥加密相对复杂，速度慢，可用来完成安全性要求较高的身份认证、密钥协商等事务；对称密钥加密技术相对简单，速度快，可用来加密数据量大的传输内容。

4.3. 构成

SSL协议的优势在于它与应用层协议是独立无关的。高层的应用层协议 (例如：Http、FTP、Telnet等等 ) 能透明的建立于SSL协议之上。SSL协议在应用层协议通信之前就已完成数据加密、通信密钥的协商和服务器的认证等工作。在此之后应用层协议所传送的数据都会被加密，从而保证通信的私密性。

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：记录协议（SSL Record Protocol）和握手协议（SSL Handshake Protocol）。记录协议建立在可靠的传输协议（如TCP）之上，为高层协议，如握手协议，提供数据封装、压缩、加解密等支持。握手协议建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。握手协议协商好加密算法、压缩算法和对称加密密钥等后，开始应用层数据传输（如HTTP协议的数据传输）。应用层的数据传输也是工作在记录协议之上，由记录层用协商好的密钥对其数据进行加解密，确保数据安全。

4.4. RSA算法

1977年美国麻省理工学院的Ron Rivest、Adi Shamirh和LenAdleman共同发明了RSA加密算法。。该算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但要对其乘积进行因式分解却极其困难。

4.5. SSL协议的身份认证和对称加密密钥的协商

4.5.1. TSL协议交互过程

TSL的身份认证和密钥协商大致过程如下（下面只考虑新建会话的情况，而不考虑重启存在会话的情况）：

Step1：客户端往服务器端发ClientHello消息

消息特点：该消息是客户端连接服务器端时发送的第一个消息。

消息构成：

(1).   使用的TLS协议版本。

(2).    随机数；用于计算对称加密时的“主密码”。

(3).   会话ID；重连时有用，可为空。

(4).   加密算法列表；客户端支持的加密算法列表，并按照客户端的偏好从前往后排。

(5).   压缩算法列表；客户端支持的压缩算法列表，并按照客户端的偏好从前往后排。

(6).   扩展信息。

消息作用：用于发起会话、交换随机数、协商加密算法、压缩算法等。

 

Step2：服务器端验证ClientHello消息，主要验证：

(1)   消息格式是否合法；

(2)   能否至少支持客户端所列举的一个加密算法和一个压缩算法等。

验证不通过则发送消息断开会话，验证通过则执行下一步。

 

Step3：服务器往客户端发送ServerHello消息。

消息特点：该消息是服务器收到ClientHello后返回给客户端的第一个消息。

消息构成：

(1).   使用的TLS协议版本。

(2).    随机数；用于计算对称加密时的“主密码”(这个随机数是服务器发送给客户端的,跟第一步骤的随机数不同,第一个是客户端发送给服务的)

(3).   一个加密算法；服务器从客户端的加密算法列表中选中的一个加密算法。

(4).   一个压缩算法；服务器从客户端的压缩算法列表中选中的一个压缩算法。

(5).    会话ID；新建的唯一的会话ID。

(6).   扩展信息。

消息作用：用于交换随机数、确定加密算法、压缩算法等。

 

Step4：服务器往客户端发送Certificate消息。

消息特点：该消息必须在ServerHello发送完后立即发送。如果是匿名协商，则无须发该消息。

消息构成：

(1).   证书列表；服务器的证书必须为证书列表的第一个，其后为签发服务器证书的证书，依次类推，最后一个证书为根证书签署的证书。根证书不在证书列表中，它是通过其他途径给到客户端的。(好多时候是浏览器预装好的)

消息作用：发送服务器证书，或者证书链。

 

Step5：服务器往客户端发送ServerKeyExchange消息。

消息特点：

(1).   该消息必须在Certificate发送完后立即发送（如果是匿名协商，则该消息紧跟在ServerHello后）。

(2).    该消息只有当Certificate消息无法提供足够信息让客户端完成“预主密码”交换时才需要。

 

消息构成：

(1).   密钥交换算法

消息作用：该消息用于发送密钥交换算法给客户端。客户端可利用这些算法和服务器端完成“预主密码”的交换。

 

Step6：服务器往客户端发送CertificateRequest消息。

消息特点：

(1).    非匿名的服务器可通过该消息来要求客户端发送证书验证其身份。

(2).   如果发送该消息则该消息在ServerKeyExchange发送完后立即发送(如果该次交互不发送ServerKeyExchange，则该消息紧跟Certificate消息)

消息构成：

(1).   证书类型列表；客户端的证书类型必须是证书类型列表中一种。

(2).   签名和哈希算法列表；列举服务器所支持的签名算法和哈希算法。

(3).   CA名字列表；服务器只接受的列表中所列出的CA所发行的证书，其他证书无法验证。

消息作用：请求客户端发送证书验证其身份。(只有双向认证才需要,即服务器也需要认证客户端)

 

Step7：服务器往客户端发送ServerHelloDone消息。

消息特点：

消息构成：

(1).   无消息内容。

消息作用：该消息用来告诉客户端ServerHello以及附属消息都已发送完毕。发完该消息后服务器等待客户端消息。

 

Step8：客户端往服务器端发送ClientCertificate消息。

消息特点：

(1).    该消息仅当收到服务器CertificateRequest时才发送，即服务器要求验证客户端。

(2).   如果发送该消息，则该消息必须是客户端收到ServerHelloDone消息后发往服务器的第一个消息。

消息构成：

(1).   证书列表。

消息作用：发送客户端证书让服务器认证。(只有双向认证才需要,即服务器也需要认证客户端)

 

 

Step9：客户端往服务器端发送ClientKeyExchange消息。

消息特点：

(1).   如果有ClientCertificate消息，则该消息必须紧跟其后发送；如果无ClientCertificate消息，则该消息是收到ServerHelloDone消息后发往服务器的第一个消息。

(2).   消息用RSA算法或者 Diffie-Hellman参数来协商预主密码。

(3).    采用RAS加密的协商预主密码时，先生成一个长的随机数，由该随机数和客户端的TSL版本号构成一个结构体，用服务器证书的公钥（从服务器证书获得）对结构体进行加密，并把加密后的数据发给服务器。

(4).   Diffie-Hellman参数协商比较复杂，暂不讨论。

消息构成：因加密算法而异。

消息作用：协商预主密码

 

Step10：客户端往服务器端发送CertificateVerify消息。

消息特点：

(1).   该消息只有当客户端证书有签名能力时(Tenfy:即有客户端证书，且证书是公钥和私钥都有的)发送，其它情况不发送（不含固定Diffie-Hellman参数的证书都有签名能力）。

(2).   该消息必须在ClientKeyExchange发送完后立即发送。

(3).   该消息采用客户端证书中的私钥信息进行加密。

消息构成：

(1).   把该消息之前的所有消息作为参数，用私钥对其进行签名得出一份数据，该数据即为消息体。

消息作用：通过签名方式，验证客户端身份。

 

Step 11：服务器用服务器私钥解密ClientKeyExchange消息得 “预主密码”。服务器和客户端用相同的算法计算“主密码”。主密码计算是根据预主密码、ClientHello中的随机数、ServerHello中的随机数得到的。计算好主密码后双方各向对方发送一个ChangeCipherSpec消息：

消息特点：

(1).   该消息必须在所有握手消息发送完之后，在Finished消息发送之前发送。

(2).   该消息必须在接收完所有握手消息之后，在接收Finished消息之前收到。

消息构成：

(1).   确认消息。

消息作用：确认采用刚才协商好的压缩算法、加密算法、主密码等来传输后继数据。

 

Step12：任意一方收到ChangeCipherSpec消息后告诉自己的Record Layer由读等待状态转为读状态，并采用新方式来传递数据。并往另外一端往发送Finished消息。

消息特点：

(1).   该消息是收到ChangeCipherSpec后立即发送的。

(2).    该消息是首次采用刚才协商好的压缩算法、加密算法、主密码等来传输的数据。

消息构成：

(1).   把前面大部分的握手消息作为参数，用相同的算法计算得到的一个值。

消息作用：完成压缩算法、加密算法等的协商，开始转入应用层数据传输。   

 

Step13：双方验证收到的消息，验证通过则开始应用层数据传输，否则断开。

 

TSL通讯时分为单向认证和双向认证。单向认证时只需要服务器端拥有证书（公钥是证书的一部分）和私钥，其中证书公开，私钥自己保管；双向加密时需要服务器和客户端都提供证书和私钥，证书都公开，私钥都自己保管。这两个对证书、私钥对无必然联系，实际编程时把它们作为两对独立的证书、私钥对来处理。

单向认证时，服务器端不会验证客户证书。故服务器无须发送CertificateRequest消息请求客户端证书，客户端无须发与证书相关的ClientCertificate和CertificateVerify消息。

 

4.5.2. TSL协议中的消息验证

通讯过程中必须严格按上述说明来发送和接收消息。接收方接收消息后一旦发现：(1)消息遗漏，(2) 消息次序不对，(3) 消息格式（如加密格式）有误，(4) 消息内容有误，(5) 自身致命错误等，接收方立即通过Alert Protocol往发送方发送ErrorAlert消息，告诉对方终止此次会话。如果是能容忍的错误，则不发任何消息，以免对方主动断开会话。

若干重要验证说明：

1.        客户端验证服务器的Certificate消息。主要验证内容为：

(1).    服务器证书使用日期是否有效。

(2).    发行服务器证书的CA是否可靠。

(3).    发行者的公钥能否解开服务器证书上的“发行者数字签名”。

(4).    服务器证书上的名称（如域名）是否和服务器实际名称匹配等（PHP中可以选择是否验证该选项）。

(Tenfy: 这里可以看出,客户端验证服务的时候,只需要验证对应服务器证书的有效性即可,无需验证对应服务器是否拥有跟该证书一致的私钥)

 

 

2.        服务器验证客户端的CertificateVerify消息。主要验证内容为：

(1).    用客户端公钥能否解开客户端私钥加密的消息。

(Tenfy:服务器验证客户端时候，还需要验证是否拥有跟证书对应的私钥)

 

3.        服务器验证客户端的ClientCertificate消息。主要验证内容为：

(1).    客户的证书使用日期是否有效。

(2).    为客户提供证书的CA 是否可靠。

(3).    发行CA 的公钥能否正确解开客户证书的发行CA的数字签名。

(4).    检查客户的证书是否在证书废止列表（CRL）中。

附：常见的证书格式

1.1. PEM 

Openssl使用PEM(RFC 1421－1424)文档格式。PEM全称是PrivacyEnhanced Mail，该标准定义了加密一个准备要发送邮件的标准。它的基本流程是这样的：

1、信息转换为ASCII码或其它编码方式；

2、使用对称算法加密转换了的邮件信息；

3、使用BASE64对加密后的邮件信息进行编码；

4、使用一些头定义对信息进行封装，这些头信息格式如下（不一定都需要，可选的）：

Proc-Type,4:ENCRYPTED

DEK-Info:cipher-name, ivec

其中，第一个头信息标注了该文件是否进行了加密，该头信息可能的值包括ENCRYPTED(信息已经加密和签名)、MIC-ONLY(信息经过数字签名但没有加密)、MIC-CLEAR(信息经过数字签名但是没有加密、也没有进行编码，可使用非PEM格式阅读)以及CLEAR(信息没有签名和加密并且没有进行编码，该项好象是openssl自身的扩展，但是并没有真正实现)；；第二个头信息标注了加密的算法以及使用的ivec参量，ivec其实在这儿提供的应该是一个随机产生的数据序列，与块加密算法中要使用到的初始化变量（IV）不一样。

5、在这些信息的前面加上如下形式头标注信息：

-----BEGINPRIVACY-ENHANCED MESSAGE-----

在这些信息的后面加上如下形式尾标注信息：

-----ENDPRIVACY-ENHANCED MESSAGE-----

上面是openssl的PEM文件的基本结构，需要注意的是，Openssl并没有实现PEM的全部标准，它只是对openssl中需要使用的一些选项做了实现，详细的PEM格式，请参考RFC1421－1424。

The Public-KeyCryptography Standards (PKCS)是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

1.2. PFX 

PFX（Personal Information Exchange）证书文件是采用PKCS(The Public-KeyCryptography Standards)标准生成的证书。PKCS是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。

PFX文件通常包含一个证书和与之对应的私钥，现阶段证书采用PKCS #12 标准[14]。这类文件是高度敏感的，在导出密钥对时，Windows 提供用密码加密 .pfx 文件；而在导入密钥对时，您必须再次提供此密码方可导入。

1.3. CER 

扩展名为 .cer 的文件采用 X.509v3 格式ASN.1 ，并由CA签名。这些文件中包含着一个公钥和额外的信息。这些文件一般用来提供给业务合作伙伴，以便他们能够使用公钥加密数据。

1.4. Java Key Store

Java Key Store（JKS）是Java语言中给出的一种密码保护的文件，可存储密钥和证书。JKS文件好比一个仓库，为防范别人随便乱拿，仓库可以设置一把锁，即JKS文件的密码（storepass）。仓库里可存放多种密钥，如公钥、私钥和密钥对（由配对公钥和私钥组成）。每个密钥都有一个名字，称为别名（alias）。仓库里的公钥只要你能进入仓库你就可以随便查看拿走，私钥则是有密码的（keypass），只允许有权限的人查看拿走。所以从JKS文件中读取公钥只需要知道JKS文件（仓库）的密码即可，但读取私钥时则还必须有私钥的密码[1]。