CN107786515A

CN107786515A - 一种证书认证的方法和设备

Info

Publication number: CN107786515A
Application number: CN201610752074.XA
Authority: CN
Inventors: 阎军智
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Communications Co Ltd
Priority date: 2016-08-29
Filing date: 2016-08-29
Publication date: 2018-03-09
Anticipated expiration: 2036-08-29
Also published as: CN107786515B

Abstract

本发明实施例提供一种证书认证的方法及设备，所述方法包括：第一设备向第二设备发送第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；所述第一设备接收所述第二设备发送的第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息；所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。解决在握手过程中客户端无需访问CRL或OCSP服务器即可进行服务器证书的有效性验证的问题。

Description

一种证书认证的方法和设备

技术领域

本发明涉及数字证书认证技术领域，尤其涉及一种在握手过程中证书认证的方法和设备。

背景技术

SSL(安全套接层)/TLS(安全传输层协议)是为网络通信提供安全及数据完整性的一种安全协议，在传输层对网络连接进行加密，可防止通信双方的通信内容被窃听、篡改、冒充。目前互联网中普遍采用的HTTPs(超文本传输安全协议)协议即是在SSL/TLS协议之上的HTTP(超文本传输协议)协议。

在网络接入场景中，用户设备在认证成功之前不能接入互联网，因此在认证成功之前用户设备不能访问CRL(证书撤消列表)服务器或OCSP(在线证书状态协议)服务器，导致用户设备在SSL/TLS握手过程中不能验证服务器证书的有效性，进而导致接入认证失败。若用户取消检查服务器证书的吊销状态信息，即，认为服务器证书不会被吊销，这样虽然可以进行后续的接入流程，但有可能接入虚假或恶意网络，造成信息泄露。

以中国移动WLAN网络为例，用户设备在接入互联网之前需要登录WLAN Portal进行认证，认证过程中采用了SSL/TLS协议。在用户设备接入认证之前浏览器会验证服务器证书，由于浏览器尚未接入互联网，此时就会弹出安全警告信息，告知用户设备“该站点安全证书吊销信息不可用”，如图1所示。

目前解决上述问题有两种方式，但这两种方式都具有显著缺点：

方式1、用户设备不进行证书有效性检查，即忽略上述安全警告。若采用该方式则表明用户设备认为服务器证书始终不会被吊销，一旦服务器证书因私钥泄露而被吊销，那么攻击者就可以使用被吊销的证书仿冒合法服务器，此时由于用户设备不验证证书有效性，有可能接入虚假或恶意网络，比如钓鱼网站，导致用户设备认证数据泄露。

方式2、在网络侧进行白名单设置，将CRL和OCSP服务器的IP地址加入白名单，使用户设备在未接入认证之前也可访问这些IP地址。该方法需要人工参与配置，若网络规模较小则不失为一种可行的方法。若网络规模较大，则白名单配置和维护需要耗费大量人工，极为不便。原因有二：其一，CRL和OCSP服务器地址通常以域名方式提供，为避免网络拥塞，通常这些域名对应许多IP地址，因此需要在所有接入设备中配置与CRL和OCSP域名对应的所有IP地址。以中国移动WLAN为例，需要在全国所有WLAN AC(接入控制器)设备上配置这些IP地址，配置和维护工作将耗费大量人工，极为不便。其二，这些IP地址很可能会变化，一般来讲，服务器证书有效期只有一至两年，到期后有可能更换其他CA(授权认证)机构的证书，不同CA机构提供CRL和OCSP服务的服务器地址不同，需要重新配置，另外使用同一个CA机构提供的证书，也有可能使用不同的CRL和OCSP服务器地址。

然而，目前尚未提出在握手过程中用户设备无需访问CRL或OCSP服务器即可进行服务器证书的有效性验证的解决方案。

发明内容

鉴于上述技术问题，本发明实施例提供一种证书认证的方法和设备，解决在握手过程中客户端无需访问CRL或OCSP服务器即可进行服务器证书的有效性验证的问题。

第一方面，提供了一种证书认证的方法，适用于握手过程中，所述方法包括：

第一设备向第二设备发送第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

所述第一设备接收所述第二设备发送的第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息；

所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证，包括：

所述第一设备根据所述第二设备证书的OCSP状态信息判断所述第二设备证书是否被吊销；

若被吊销，则确定所述第二设备的身份验证结果为验证失败；

若未被吊销，则继续对所述第二设备证书的正确性和/或有效性进行验证。

可选地，在所述第一设备接收所述第二设备发送的第一OCSP响应消息时，所述方法还包括：

所述第一设备接收所述第二设备发送的第二OCSP请求消息，所述第二OCSP请求消息用于请求所述第一设备的第一设备证书的OCSP状态信息；

所述第一设备向所述第二设备发送第二OCSP响应消息，所述第二OCSP响应消息中包括第一设备证书的OCSP状态信息，以使所述第二设备根据所述第一设备证书的OCSP状态信息对所述第一设备进行身份验证。

可选地，所述第一OCSP请求消息中指定一个或多个第一设备接受的OCSP提供方；或者所述第一OCSP请求消息中不指定第一设备接受的OCSP提供方，若不指定第一设备接受的OCSP提供方，则表示所述第一设备可接受所有合法的OCSP响应。

第二方面，还提供了一种证书认证的方法，适用于握手过程中，所述方法包括：

第二设备接收第一设备发送的第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

所述第二设备根据所述第一OCSP请求消息，确定所述第二设备证书的OCSP状态信息；

所述第二设备向所述第一设备发送第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息，以使所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，在所述第二设备向所述第一设备发送第一OCSP响应消息时，所述方法还包括：

所述第二设备向所述第一设备发送第二OCSP请求消息，所述第二OCSP请求消息用于请求所述第一设备的第一设备证书的OCSP状态信息；

所述第二设备接收所述第一设备发送的第二OCSP响应消息，所述第二OCSP响应消息中包括第一设备证书的OCSP状态信息；

所述第二设备根据所述第一设备证书的OCSP状态信息对所述第一设备进行身份验证。

可选地，所述第二设备根据所述第一OCSP请求消息，确定所述第二设备证书的OCSP状态信息，包括：

所述第二设备根据所述第一OCSP请求消息判断是否存储有所述第一设备接受的OCSP提供方提供的所述第二设备证书的OCSP状态信息；

若存储有，则所述第二设备本地获取所述第二设备证书的OCSP状态信息；

若没有存储，则所述第二设备向所述第一设备接受的OCSP提供方发起OCSP查询请求，然后接收由所述第一设备接受的OCSP提供方返回的OCSP查询结果，从所述OCSP查询结果中获取所述第二设备证书的OCSP状态信息。

第三方面，还提供了一种第一设备，所述第一设备包括：

第一发送模块，用于在握手过程中，向第二设备发送第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

第一接收模块，用于接收所述第二设备发送的第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息；

第一验证模块，用于根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，所述第一验证模块进一步用于：根据所述第二设备证书的OCSP状态信息判断所述第二设备证书是否被吊销；若被吊销，则确定所述第二设备的身份验证结果为验证失败；若未被吊销，则继续对所述第二设备证书的正确性和/或有效性进行验证。

可选地，所述第一设备还包括：

第二接收模块，用于接收所述第二设备发送的第二OCSP请求消息，所述第二OCSP请求消息用于请求所述第一设备的第一设备证书的OCSP状态信息；

第二发送模块，用于向所述第二设备发送第二OCSP响应消息，所述第二OCSP响应消息中包括第一设备证书的OCSP状态信息，以使所述第二设备根据所述第一设备证书的OCSP状态信息对所述第一设备进行身份验证。

第四方面，还提供了一种第二设备，所述第二设备包括：

第三接收模块，用于在握手过程中，接收第一设备发送的第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

确定模块，用于根据所述第一OCSP请求消息，确定所述第二设备证书的OCSP状态信息；

第三发送模块，用于向所述第一设备发送第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息，以使所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，所述第二设备还包括：

第四发送模块，用于向所述第一设备发送第二OCSP请求消息，所述第二OCSP请求消息用于请求所述第一设备的第一设备证书的OCSP状态信息；

第四接收模块，用于接收所述第一设备发送的第二OCSP响应消息，所述第二OCSP响应消息中包括第一设备证书的OCSP状态信息；

第二验证模块，用于根据所述第一设备证书的OCSP状态信息对所述第一设备进行身份验证。

可选地，所述确定模块进一步用于：根据所述第一OCSP请求消息判断是否存储有所述第一设备接受的OCSP提供方提供的所述第二设备证书的OCSP状态信息；若存储有，则从本地获取所述第二设备证书的OCSP状态信息；若没有存储，则向所述第一设备接受的OCSP提供方发起OCSP查询请求，然后接收由所述第一设备接受的OCSP提供方返回的OCSP查询结果，从所述OCSP查询结果中获取所述第二设备证书的OCSP状态信息。

上述技术方案中的一个技术方案具有如下优点或有益效果：通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现在第一设备和第二设备握手过程中可以有效检验第一设备和/或第二设备证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在第一设备和第二设备之间增加少量的消息字段即可实现(例如增加一个OCSP消息字段)，即无需网络设备配置，实现方便。进一步地，若第一设备和/或第二设备预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

附图说明

图1为现有技术中安全警告信息的示意图；

图2为本发明的第一实施例中证书认证的方法的流程示意图；

图3为本发明的第二实施例中证书认证的方法的流程示意图；

图4为本发明的第三实施例中证书认证的方法的流程示意图；

图5为本发明的第四实施例中证书认证的方法的流程示意图；

图6为本发明的第五实施例中客户端验证服务器证书的流程示意图；

图7为本发明的第六实施例中服务器验证客户端证书的流程示意图；

图8为本发明的第七实施例中服务器验证客户端证书以及客户端验证服务器证书的流程示意图；

图9为本发明的第八实施例中第一设备的结构框图；

图10为本发明的第九实施例中第二设备的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本领域技术人员知道，本发明的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本发明的实施例可以具体实现为以下形式：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区分类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便在这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如一系列步骤或单元的，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其他步骤或单元。

需要说明的是，在不冲突的情况下，本发明的实施例以及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明的技术方案。

第一实施例

参见图2，图中示出了一种证书认证的方法，适用于握手过程中，场景为第一设备能够在SSL/TLS握手过程中向第二设备发送请求查询第二设备证书的证书状态，第二设备接收到查询请求后，将第二设备证书状态作为响应返回给第一设备，具体步骤如下：

步骤201、第一设备向第二设备发送第一在线证书状态协议OCSP请求消息，第一OCSP请求消息用于请求第二设备的第二设备证书的OCSP状态信息，然后进入步骤202；

可选地，第一设备向第二设备发送第一设备握手报文和第一在线证书状态协议OCSP请求消息，第一OCSP请求消息用于请求第二设备的第二设备证书的OCSP状态信息；

在本实施例中，第一设备可以采用现有的方式向第二设备发送第一设备握手报文(ClientHello)，其中，第一设备握手报文与现有技术相同，包含第一设备SSL/TLS版本号、加密算法设置、随机数等内容。

可选地，在本实施例中，在第一OCSP请求消息中可以指定一个或多个第一设备接受的OCSP提供方，此时，第一OCSP请求消息用于请求第一设备接受的OCSP提供方提供的第二设备的第二设备证书的OCSP状态信息；如果在第一OCSP请求消息中不指定第一设备接受的OCSP提供方，则表示该第一设备可接受所有合法的OCSP响应。

当然可以理解的是，上述第一设备可以是客户机，第二设备为服务器，或者第一设备为服务器，第二设备为客户机。

步骤202、第一设备接收第二设备发送的第一OCSP响应消息，第一OCSP响应消息中包括第二设备证书的OCSP状态信息，然后进入步骤203；

可选地，第一设备接收第二设备发送的第二设备握手报文、第二设备证书和第一OCSP响应消息，第一OCSP响应消息中包括第二设备证书的OCSP状态信息；

上述第二设备握手报文(ServerHello)和第二设备证书与现有技术相同，在此不再敷述。

上述第一OCSP响应消息的产生过程如下：第二设备接收到第一设备的第一OCSP请求消息后，查询第二设备是否存储有第二设备证书的OCSP状态信息，且存储的OCSP状态是否是由第一设备能够接受的OCSP提供方提供的；若存储有第一设备能够接受的OCSP提供方提供的OCSP状态信息，则将OCSP状态信息作为第一OCSP响应消息发送给第一设备；否则，第二设备向第一设备能够接受的OCSP提供方发起OCSP查询请求，将接收到的OCSP查询响应作为OCSP响应发送给第一设备。需要说明的是，第二设备发送OCSP查询请求可使用现有技术，在此不再敷述。

步骤203、第一设备根据第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，第一设备根据第二设备证书的OCSP状态信息判断第二设备证书是否被吊销；若被吊销，则确定第二设备的身份验证结果为验证失败；若未被吊销，则继续对第二设备证书的正确性和/或有效性进行验证。需要说明的是，可以采用现有的验证技术继续验证第二设备证书的正确性和/或有效性，在此不再敷述。

在步骤203之后，第一设备和第二设备可以使用交互信息产生主秘钥和会话秘钥，双方建立安全通道。需要说明的是，可以采用现有的方式建立安全通道，在此不再敷述。

在本实施例中，通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现用户设备在接入网络之前(握手过程中)可以有效检验第二设备证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在第一设备和第二设备之间增加少量的消息字段即可实现，无需网络设备配置，实现方便。若第一设备和/或第二设备预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

第二实施例

参见图3，图中示出了一种证书认证的方法，适用于握手过程中，在本实施例中，第一设备和第二设备在握手过程中可同时携带OCSP状态信息，此种方式可减少第一设备和第二设备在握手过程中向CA机构进行CRL和OCSP主动查询的次数，提升握手效率，具体步骤如下：

步骤301、第一设备向第二设备发送第一在线证书状态协议OCSP请求消息，第一OCSP请求消息用于请求第二设备的第二设备证书的OCSP状态信息，然后进入步骤302；

可选地，第一设备向第二设备发送第一设备握手报文和第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

步骤302、第一设备接收第二设备发送的第一OCSP响应消息和第二OCSP请求消息，其中，第一OCSP响应消息中包括第二设备证书的OCSP状态信息，第二OCSP请求消息用于请求第一设备的第一设备证书的OCSP状态信息，然后进入步骤303；

可选地，第一设备接收所述第二设备发送的第二设备握手报文、第二设备证书、第一OCSP响应消息、证书请求Certificate Request和第二OCSP请求消息，其中，第一OCSP响应消息中包括第二设备证书的OCSP状态信息，第二OCSP请求消息用于请求第一设备的第一设备证书的OCSP状态信息。

需要说明的是，上述第二设备握手报文(ServerHello)、第二设备证书和证书请求Certificate Request与现有技术相同，在此不再敷述。

第二设备在收到第一OCSP请求消息后，将自身第二设备证书的OCSP状态信息作为第一OCSP响应消息与第二OCSP请求消息一起发送给第一设备，其中第二OCSP请求消息包含零个或多个第二设备接受的OCSP提供方。

步骤303、第一设备向第二设备发送第二OCSP响应消息，第二OCSP响应消息中包括第一设备证书的OCSP状态信息，以使第二设备根据第一设备证书的OCSP状态信息对第一设备进行身份验证；

可选地，第二设备根据第一设备证书的OCSP状态信息判断第一设备证书是否被吊销；若被吊销，则确定第一设备的身份验证结果为验证失败；若未被吊销，则继续对第一设备证书的正确性和/或有效性进行验证。需要说明的是，可以采用现有的验证技术继续验证第一设备证书的正确性和/或有效性，在此不再敷述。

步骤304、第一设备根据第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

在步骤304之后，第一设备和第二设备可以使用交互信息产生主秘钥和会话秘钥，双方建立安全通道。需要说明的是，可以采用现有的方式建立安全通道，在此不再敷述。

通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现用户设备在接入网络之前(握手过程中)可以有效检验第二设备证书和第一设备证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在第一设备和第二设备之间增加少量的消息字段即可实现，无需网络设备配置，实现方便。若第一设备和/或第二设备预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

第三实施例

参见图4，图中示出了一种证书认证的方法，适用于握手过程中，具体步骤如下：

步骤401、第二设备接收第一设备发送的第一在线证书状态协议OCSP请求消息，第一OCSP请求消息用于请求第二设备的第二设备证书的OCSP状态信息，然后进入步骤402；

可选地，第二设备接收第一设备发送的第一设备握手报文和第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息。

步骤402、第二设备根据第一OCSP请求消息，确定第二设备证书的OCSP状态信息，然后进入步骤403；

可选地，第二设备根据第一OCSP请求消息判断是否存储有第一设备接受的OCSP提供方提供的第二设备证书的OCSP状态信息；若存储有，则所述第二设备本地获取所述第二设备证书的OCSP状态信息；若没有存储，则所述第二设备向所述第一设备接受的OCSP提供方发起OCSP查询请求，然后接收由所述第一设备接受的OCSP提供方返回的OCSP查询结果，从所述OCSP查询结果中获取所述第二设备证书的OCSP状态信息。

步骤403、第二设备向第一设备发送第一OCSP响应消息，第一OCSP响应消息中包括第二设备证书的OCSP状态信息，以使第一设备根据第二设备证书的OCSP状态信息对第二设备进行身份验证。

可选地，第二设备向第一设备发送ServerHello、第二设备证书和第一OCSP响应消息，其中，ServerHello、第二设备证书与现有技术相同；第一OCSP响应消息中包含第一设备能够接受的OCSP状态。

在步骤403之后，第一设备和第二设备可以使用交互信息产生主秘钥和会话秘钥，双方建立安全通道。需要说明的是，可以采用现有的方式建立安全通道，在此不再敷述。

第四实施例

参见图5，图中示出了一种证书认证的方法，适用于握手过程中，具体步骤如下：

步骤501、第二设备接收第一设备发送的第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息，然后进入步骤502；

步骤502、第二设备根据第一OCSP请求消息，确定第二设备证书的OCSP状态信息，然后进入步骤503；

步骤503、第二设备向第一设备发送第一OCSP响应消息和第二OCSP请求消息，第一OCSP响应消息中包括第二设备证书的OCSP状态信息，以使所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证，第二OCSP请求消息用于请求第一设备的第一设备证书的OCSP状态信息，然后进入步骤504。

可选地，第二设备向第一设备发送ServerHello、第二设备证书、第一OCSP响应消息和第二OCSP请求消息，其中，ServerHello、第二设备证书与现有技术相同；第一OCSP响应消息中包含第一设备能够接受的OCSP状态，第二OCSP请求消息用于请求第一设备的第一设备证书的OCSP状态信息。

步骤504、第二设备根据第一设备证书的OCSP状态信息对第一设备进行身份验证。

第五实施例

参见图6，图中示出了一种客户端验证服务器证书的方法流程，其中，客户端能够在SSL/TLS握手过程中向服务器发送请求查询服务器证书的证书状态，服务器接收到查询请求后，将服务器证书状态作为响应返回给客户端，具体步骤如下：

步骤601、客户端向服务器发送ClientHello和OCSPRequest(OCSP请求)消息。

其中，ClientHello与现有技术相同，包含客户端SSL/TLS版本号、加密算法设置、随机数等内容；OCSPRequest用于请求对方证书的OCSP状态信息，其中包含零个或多个客户端接受的OCSP提供方，若未包含OCSP提供方则认为可接受所有合法的OCSP响应，若包含OCSP提供方则仅接受这些提供方提供的OCSP响应。

步骤602、服务器向客户端发送ServerHello、服务器证书和OCSPResponse(OCSP响应)。

其中，ServerHello和服务器证书与现有技术相同；OCSPResponse中包含客户端能够接受的OCSP状态。OCSPResponse产生过程如下：

服务器接收到客户端的OCSPRequest消息后，查询服务器是否存储有服务器证书的OCSP状态信息，且存储的OCSP状态是否是由客户端能够接受的提供方提供的。

若存储有客户端能够接受的提供方提供的OCSP状态信息，则将OCSP状态作为OCSPResponse发送给客户端。

否则，服务器向客户端能够接受的OCSP提供方发起OCSP查询请求，将接收到的OCSP查询响应作为OCSPResponse发送给客户端。服务器发起OCSP查询请求可使用现有技术。

步骤603、客户端使用接收到的信息验证服务器身份。

ClientKeyExchange是用服务器证书rsa公钥加密传输预主密钥。

Change cipher spec是客户端要求服务器在后续的通信中使用加密模式。

客户端使用OCSPResponse判断服务器证书是否被吊销，如果被吊销，则验证失败；如果未被吊销则进行后续验证流程。

客户端继续验证服务器证书的正确性和有效性，方法同现有技术。

步骤604、客户端和服务器使用交互的信息产生主密钥和会话密钥，双方建立安全通道，方法与现有技术相同。

在本实施例中，通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现用户设备在接入网络之前(握手过程中)可以有效检验服务器证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在客户端和服务器之间增加少量的消息字段即可实现，无需网络设备配置，实现方便。若客户端和/或服务器预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

第六实施例

参见图7，图中示出了服务器验证客户端证书的流程，具体步骤如下：

步骤701、客户端向服务器发送ClientHello。

上述ClientHello与现有技术相同，包含客户端SSL/TLS版本号、加密算法设置、随机数等内容。

步骤702、服务器向客户端发送ServerHello、服务器证书、CertificateRequest和OCSPRequest。

其中，ServerHello、服务器证书、CertificateRequest与现有技术相同。OCSPRequest用于请求对方证书的OCSP状态信息，其中包含零个或多个服务器接受的OCSP提供方，若未包含OCSP提供方则认为可接受所有合法的OCSP响应，若包含OCSP提供方则仅接受这些提供方提供的OCSP响应。

步骤703、客户端向服务器发送Certificate、OCSPResponse、ClientKeyExchange等信息。

ClientKeyExchange是用服务器证书rsa公钥加密传输预主密钥。

其中，除OCSPResponse之外的信息与现有技术相同。客户端将自身客户端证书的OCSP状态作为OCSPResponse发送给服务器。

步骤704、服务器使用接收到的信息验证客户端身份。

服务器使用OCSPResponse判断客户端证书是否被吊销，如果被吊销，则验证失败；如果未被吊销则进行后续验证流程。

服务器继续验证客户端证书的正确性和有效性，方法同现有技术。

步骤705、客户端和服务器使用交互的信息产生主密钥和会话密钥，双方建立安全通道，方法与现有技术相同。

在本实施例中，通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现用户设备在接入网络之前(握手过程中)可以有效检验客户端证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在客户端和服务器之间增加少量的消息字段即可实现，无需网络设备配置，实现方便。若客户端和/或服务器预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

第七实施例

参见图8，图中示出了服务器验证客户端证书以及客户端验证服务器证书的流程，具体步骤如下：

步骤801、客户端向服务器发送ClientHello和OCSPRequest消息。

其中，ClientHello与现有技术相同，包含客户端SSL/TLS版本号、加密算法设置、随机数等内容。OCSPRequest包含零个或多个客户端接受的OCSP提供方，若未包含OCSP提供方则认为可接受所有合法的OCSP响应，若包含OCSP提供方则仅接受这些提供方提供的OCSP响应。

步骤802、服务器向客户端发送ServerHello、服务器证书、OCSPResponse、CertificateRequest和OCSPRequest。

其中，ServerHello、服务器证书、CertificateRequest与现有技术相同。服务器将自身服务器证书的OCSP状态作为OCSPResponse发送给客户端。OCSPRequest包含零个或多个服务器接受的OCSP提供方。

步骤803、客户端使用接收到的信息验证服务器身份。

步骤804、客户端向服务器发送Certificate、OCSPResponse、ClientKeyExchange等信息。

步骤805、服务器使用接收到的信息验证客户端身份。

步骤806、客户端和服务器使用交互的信息产生主密钥和会话密钥，双方建立安全通道，方法与现有技术相同。

在本实施例中，通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现用户设备在接入网络之前(握手过程中)可以有效检验客户端证书和服务器证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在客户端和服务器之间增加少量的消息字段即可实现，无需网络设备配置，实现方便。若客户端和/或服务器预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

第八实施例

参见图9，图中示出了一种第一设备，所述第一设备900包括：

第一发送模块901，用于在握手过程中，向第二设备发送第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

第一接收模块902，用于接收所述第二设备发送的第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息；

第一验证模块903，用于根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，所述第一设备还包括：

在本实施例中，通过在SSL/TLS握手过程中携带OCSP状态请求和OCSP状态响应的方式，实现在第一设备和第二设备握手过程中可以有效检验第一设备和/或第二设备证书的状态信息，确保接入合法的网络。而且本实施例充分利用现有技术，仅需在第一设备和第二设备之间增加少量的消息字段即可实现，无需网络设备配置，实现方便。若第一设备和/或第二设备预先存储OCSP状态信息，则在握手过程无需向CA机构进行证书状态查询(CRL和OCSP查询)，提高效率。

第九实施例

参见图10，图中示出了一种第二设备，第二设备1000包括：

第三接收模块1001，用于在握手过程中，接收第一设备发送的第一在线证书状态协议OCSP请求消息，所述第一OCSP请求消息用于请求所述第二设备的第二设备证书的OCSP状态信息；

确定模块1002，用于根据所述第一OCSP请求消息，确定所述第二设备证书的OCSP状态信息；

第三发送模块1003，用于向所述第一设备发送第一OCSP响应消息，所述第一OCSP响应消息中包括第二设备证书的OCSP状态信息，以使所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证。

可选地，所述第二设备还包括：

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一项或多项实施例中。

在本发明的各种实施例中，应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定

另外，本文中术语“系统”和“网络”在本文中常可互换使用。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

在本申请所提供的实施例中，应理解，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

在本申请所提供的几个实施例中，应该理解到，所揭露方法和设备，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理包括，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述收发方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述的是本发明的优选实施方式，应当指出对于本技术领域的普通人员来说，在不脱离本发明所述的原理前提下还可以做出若干改进和润饰，这些改进和润饰也在本发明的保护范围内。

Claims

1.一种证书认证的方法，其特征在于，所述方法包括：

2.根据权利要求1所述的方法，其特征在于，所述第一设备根据所述第二设备证书的OCSP状态信息对所述第二设备进行身份验证，包括：

3.根据权利要求1所述的方法，其特征在于，在所述第一设备接收所述第二设备发送的第一OCSP响应消息时，所述方法还包括：

4.根据权利要求1所述的方法，其特征在于，所述第一OCSP请求消息中指定一个或多个第一设备接受的OCSP提供方；或者所述第一OCSP请求消息中不指定第一设备接受的OCSP提供方，若不指定第一设备接受的OCSP提供方，则表示所述第一设备可接受所有合法的OCSP响应。

5.一种证书认证的方法，其特征在于，所述方法包括：

6.根据权利要求5所述的方法，其特征在于，在所述第二设备向所述第一设备发送第一OCSP响应消息时，所述方法还包括：

7.根据权利要求5所述的方法，其特征在于，所述第二设备根据所述第一OCSP请求消息，确定所述第二设备证书的OCSP状态信息，包括：

8.一种第一设备，其特征在于，所述第一设备包括：

9.根据权利要求8所述的第一设备，其特征在于，所述第一验证模块进一步用于：根据所述第二设备证书的OCSP状态信息判断所述第二设备证书是否被吊销；若被吊销，则确定所述第二设备的身份验证结果为验证失败；若未被吊销，则继续对所述第二设备证书的正确性和/或有效性进行验证。

10.根据权利要求8所述的第一设备，其特征在于，所述第一设备还包括：

11.根据权利要求8所述的第一设备，其特征在于，所述第一OCSP请求消息中指定一个或多个第一设备接受的OCSP提供方；或者所述第一OCSP请求消息中不指定第一设备接受的OCSP提供方，若不指定第一设备接受的OCSP提供方，则表示所述第一设备可接受所有合法的OCSP响应。

12.一种第二设备，其特征在于，所述第二设备包括：

13.根据权利要求12所述的第二设备，其特征在于，所述第二设备还包括：

14.根据权利要求12所述的第二设备，其特征在于，所述确定模块进一步用于：根据所述第一OCSP请求消息判断是否存储有所述第一设备接受的OCSP提供方提供的所述第二设备证书的OCSP状态信息；若存储有，则从本地获取所述第二设备证书的OCSP状态信息；若没有存储，则向所述第一设备接受的OCSP提供方发起OCSP查询请求，然后接收由所述第一设备接受的OCSP提供方返回的OCSP查询结果，从所述OCSP查询结果中获取所述第二设备证书的OCSP状态信息。