CN106533689B - 一种在ssl/tls通信中加载数字证书的方法和装置 - Google Patents

Abstract

本申请实施例提供了一种在SSL/TLS通信中加载数字证书的方法和装置，该方法包括：接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。本申请实施例实现了在握手协商过程中动态加载合适的数字证书，以保证成功完成SSL/TLS的握手协商。

Description

一种在SSL/TLS通信中加载数字证书的方法和装置

技术领域

本申请涉及通信的技术领域，特别是涉及一种在SSL/TLS通信中加载数字证书的方法和一种在SSL/TLS通信中加载数字证书的装置。

背景技术

基于电子商务和网上银行等新兴应用，极大地方便了人们的日常生活，受到人们的青睐。由于这些应用都需要在网络上进行在线交易，它们对网络通信的安全性提出了更高的要求。因此，HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer，超文本传输安全协议)已经被越来越多的网站所使用。

HTTPS是以安全为目标的HTTP(Hypertext transfer protocol，超文本传送协议)通道，即HTTP下加入SSL(Secure Sockets Layer，安全套接层协议)或其后续版本TLS(Transport Layer Security，安全传输层协议)，SSL/TLS利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。。

SSL/TLS所应用的密码算法，如摘要的哈希算法、证书的签名算法、数据的加密算法等也随之不断的更新，而目前各种客户端(包括各种版本的浏览器，各种应用等)所能支持的加密方式也参差不齐。

在诸如电子商务平台这样访问量巨大的网站中，经常面临各种版本的客户端访问。

目前对于支持SSL/TLS的服务器基本是在启动时加载数字证书，对于指定的域名只能使用一个数字证书，数字证书一旦加载只能用证书里规定的摘要算法和签名算法来进行SSL/TLS握手协商。

如果某些旧版本的客户端无法支持证书里的较新的算法，则协商失败，从而导致客户端无法通过HTTPS访问网站，网站兼容性差，导致通信的安全性低。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种在SSL/TLS通信中加载数字证书的方法和相应的一种在SSL/TLS通信中加载数字证书的装置。

为了解决上述问题，本申请实施例公开了一种在SSL/TLS通信中加载数字证书的方法，包括：

接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；

根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；

判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；

根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。

可选地，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤包括：

从所述握手请求消息中查找密码套件；

从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式；

可选地，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤还包括：

从所述握手请求中查找传输层安全协议TLS的扩展头；

从所述扩展头中识别客户端支持的第一签名方式。

可选地，所验证的第一签名方式为客户端的加密强度最高的第一签名方式。

可选地，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。

可选地，所述判断所述密钥交换方式和所述签名方式是否与当前加载的数字证书匹配的步骤包括：

查找与所述密钥交换方式匹配的公钥；

识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；

判断所述第一签名方式是否与所述第二签名方式匹配；

若是，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；

若否，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。

可选地，所述加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书的步骤包括：

识别在所述公钥所属的分组中其他数字证书的第三签名方式；

判断所述第三签名方式是否与所述第一签名方式匹配；

若是，则加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。

本申请实施例还公开了一种在SSL/TLS通信中加载数字证书的装置，包括：

握手请求消息接收模块，用于接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；

客户端信息验证模块，用于根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；

数字证书匹配模块，用于判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则调用数字证书加载模块；

数字证书加载模块，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；

握手响应消息返回模块，用于根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。

可选地，所述客户端信息验证模块包括：

密码套件查找子模块，用于从所述握手请求消息中查找密码套件；

密码套件识别子模块，用于从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式；

可选地，所述客户端信息验证模块还包括：

扩展头查找子模块，用于从所述握手请求中查找传输层安全协议TLS的扩展头；

扩展头识别子模块，用于从所述扩展头中识别客户端支持的第一签名方式。

可选地，所验证的第一签名方式为客户端的加密强度最高的第一签名方式。

可选地，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。

可选地，所述数字证书匹配模块包括：

公钥查找子模块，用于查找与所述密钥交换方式匹配的公钥；

当前签名方式识别子模块，用于识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；

第一签名方式匹配子模块，用于判断所述第一签名方式是否与所述第二签名方式匹配；若是，则调用第一判定子模块，若否，则调用第二判定子模块；

第一判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；

第二判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。

可选地，所述数字证书加载模块包括：

其他签名方式识别子模块，用于识别在所述公钥所属的分组中其他数字证书的第三签名方式；

第二签名方式匹配子模块，用于判断所述第三签名方式是否与所述第一签名方式匹配；若是，则调用数字证书替换子模块；

数字证书替换子模块，用于加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。

本申请实施例包括以下优点：

本申请实施例数字证书与客户端支持的密钥交换方式和第一签名方式的匹配，实现了在握手协商过程中动态加载合适的数字证书，以保证成功完成SSL/TLS的握手协商，提高了网站的兼容性差，保证了客户端通过HTTPS等安全协议访问网站，提高了通信的安全性。

本申请实施例针对同一域名可以配置多种不同类型的数字证书，提高了数字证书的动态加载效率。

附图说明

图1是本申请的一种在SSL/TLS通信中加载数字证书的方法实施例的步骤流程图；

图2是本申请实施例的一种网络模型架构图；

图3是本申请实施例的一种SSL的握手的信令图；

图4是本申请的一种在SSL/TLS通信中加载数字证书的装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

SSL/TLS是安全网络传输协议，主要是为了保护在互联网中传递的机密信息，该协议包括两个过程:握手阶段,数据传输阶段。

数据传输阶段就是对传输的数据分别使用协商好的对称秘钥进行加解密和摘要秘钥进行摘要运算以保证数据的私密性和完整性。

而握手阶段的主要目的就是为了确认对方身份的真实有效性并产生数据传输阶段所需要的秘钥。

SSL握手过程如下：

a.客户端项服务器端发送Client hello消息，消息主要包括SSL版本号，随机数、会回话ID、密码套件、压缩方法等信息。

其中，密码套件表明了客户端所能支持的算法列表，其中包括密钥交换方式、签名方式和对此加密方式。

b.服务器返回给客户端Server hello消息，包括SSL版本号，服务器和客户端共同支持的密钥交换方式、签名方式和对此加密方式，以及用于后续生成秘钥的随机数。

这里服务器需要的通过预先加载的数字证书以及签名方式来和Client hello里的密码套件进行匹配，只有匹配成功才会返回Server hello消息，并在Client_hello里标识双方协商好的所使用的密码算法。

c.服务器发送指定的证书(证书链)给客户端，用于身份验证。

d.客户端成功验证服务器证书后，发送client key exchange消息给服务器，用于将预主秘钥通过服务器的公钥加密后发送给服务器。

e.双方根据预主秘钥以及随机数生成用于传输阶段的主秘钥，从而完成SSL握手协商的过程。

在步骤e中，客户端在验证服务器证书的时候根据证书里的签名方式以及签名所使用的哈希摘要算法对证书里的数字签名进行验证，如果客户端不支持响应的签名算法和摘要算法，则数字证书的验证就会失败，SSL握手就无法完成。

因此，提出了本申请实施例的构思之一，当客户端无法支持数字证书的签名算法和摘要算法时，动态加载客户端支持的数字证书进行握手，保证SSL/TLS的握手成功。

参照图1，示出了本申请的一种在SSL/TLS通信中加载数字证书的方法实施例的步骤流程图，具体可以包括如下步骤：

步骤101，接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；

如图2所示，SSL/TLS在应用层与TCP(Transmission Control Protocol传输控制协议)、IP(Internet Protocol，网络之间互连的协议)层之间。

应用层的数据不再直接传递给传输层，而是传递给SSL/TLS层，SSL/TLS层对从应用层收到的数据进行加密。

SSL协议本身分为两层：

上层为SSL握手协议(SSL handshake protocol)、SSL密码变化协议(SSL changecipher spec protocol)和SSL警告协议(SSL alert protocol)；

底层为SSL记录协议(SSL record protocol)。

SSL握手协议：用来协商通信过程中使用的密码套件(加密算法、密钥交换算法和MAC算法等)、在服务器和客户端之间安全地交换密钥、实现服务器和客户端的身份验证。

SSL密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的密码套件和密钥进行保护和传输。

SSL警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。

SSL记录协议：主要负责对上层的数据(SSL握手协议、SSL密码变化协议、SSL警告协议和应用层协议报文)进行分块、计算并添加MAC值、加密，并把处理后的记录块传输给对端。

TLS协议包括两个协议组：TLS记录协议和TLS握手协议。

TLS记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用MAC、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。

TLS握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

由于TLS是建立在SSL的基础上的，是SSL的后续版本，两者之间存在着差别，主要是它们所支持的加密算法不同，而整体的流程是基本相同的，因此，在本申请实施例中，主要以SSL进行说明。

SSL握手的第一阶段启动逻辑连接，建立这个连接的安全能力。

如图3所示，客户端(client)向服务器(server)发出Client hello消息(即握手请求消息)并等待服务器(server)的响应。

步骤102，根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；

Client hello消息通常包括Version(版本)，Random(客户端随机数)，Session id(会话ID)，Cipher suite(客户端支持的密码套件)，Compression method(客户端支持的压缩方法)等信息。

具体而言，由于不同版本的客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在SSL通信过程中使用同一套加解密算法才能保证数据能够正常的加解密。

因此，在SSL握手阶段，客户端告知服务端其所支持的签名方式，即客户端将本地支持的密码套件(Cipher Suite)的列表传送给服务器。

则服务器可以从握手请求消息中查找密码套件，从密码套件中识别客户端支持的密钥交换方式和第一签名方式。

基于SSL的密码套件通常以“SSL”开头，基于TLS的密码套件通常以或“TLS”开头，紧跟着的是密钥交换阶段所使用密钥交换方式、传输数据所使用的对称加密方式、数据完整性验证所使用的MAC里所采用的签名方式(如哈希算法)，用“With”这个词把密钥交换方式、对称加密方式、签名方式分开。

密码套件的示例下：

SSL_DHE_RSA_WITH_DES_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

其中，DHE_RSA、ECDHE_ECDSA为密钥交换方式，DES_CBC、AES_128_GCM为对称加密方式，SHA、SHA256为签名方式(即不同版本的哈希算法)。

为了进一步保证通信的安全性，所验证的第一签名方式可以为客户端的加密强度最高的第一签名方式。

因此，服务器在解析Client hello的时候，可以遍历密码套件的列表，从而记录加密强度最高的第一签名方式。

此外，如果是基于TLS进行通信并且含有TLS签名方式的扩展头，则可以从握手请求中查找传输层安全协议TLS的扩展头，这个扩展头里指明了客户端所能支持的签名方式的列表，从扩展头中可以读取客户端支持的签名方式，更新客户端支持的第一签名方式。

需要说明的是，某些使用了TLS的客户端，如IE浏览器，也可能没有按照TLS的规范增加扩展头，此种情况下，仍可以遍历密码套件列表来获取客户端所能支持的第一签名方式。

步骤103，判断所述密钥交换方式和所述第一签名方式、是否与当前加载的数字证书匹配；若否，则执行步骤104；

数字证书的格式普遍采用的是X.509V3国际标准，一个标准的X.509数字证书包含以下一些内容：

版本信息，序列号，所使用的签名方式，发行机构名，有效期，所有人名称，协商使用的公开秘钥，数字签名。

通常情况下，数字证书是需要申请，并由专门的数字证书认证机构(CA)通过审核之后颁发的电子证书。

颁发数字证书的同时，会产生一个私钥和公钥。私钥由服务器保存，不可泄漏。公钥则是附带在数字证书的信息中，可以公开的。

数字证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被串改。

在本申请实施例中，数字证书可以按照公钥的类型划分分组，目前OpenSSL(OpenSecure Sockets Layer，开放式安全套接层协议)可以支持同时加载三种类型的数字证书，以便在协商的时候可以更好地支持不同类型的客户端，减少数字证书匹配的时间。

例如，服务器配置了如下数字证书：

sha256WithRSAEncryption(公钥使用RSA)

sha1WithRSAEncryption(公钥使用RSA)

ecdsa-with-SHA256(公钥使用ECC)

ecdsa-with-SHA1(公钥使用ECC)

则可以将sha256WithRSAEncryption，sha1WithRSAEncryption划分为一个分组，即此组中所有数字证书的公钥使用RSA，将ecdsa-with-SHA256，ecdsa-with-SHA1划分为另一个分组，即此组中所有数字证书的公钥使用ECC。

在每个分组中可以加载其中一个数字证书。

在一种情况中，服务器在启动的时候，可以将配置好的数字证书读入内存，并将指定的数字证书加载到SSL或TLS的上下文。

在另一种情况中，若在SSL或TLS的通信时加载了其他数字证书，在结束该SSL或TLS的通信时，可以重新将指定的数字证书加载到SSL或TLS的上下文。

由于数字证书加载操作较为简单，属于轻加载，即使频繁替换数字证书也不会对SSL或TLS的握手协商产生影响。

在实际应用中，可以对服务器(如Tengine)修改配置文件，可以允许配置多个数字证书，以及修改相应的存储结构。

本申请实施例针对同一域名可以配置多种不同类型的数字证书，提高了数字证书的动态加载效率。

为了进一步保证通信的安全性，当前加载的数字证书可以为所属分组中加密强度最高的数字证书。

例如，SHA256的加密强度比SHA1高，则对于上述示例的分组，在可以加载sha256WithRSAEncryption、ecdsa-with-SHA256。

在本申请实施例中，服务器(如Tengine)在初始化SSL/TLS的时候，可以向SSL/TLS服务程序注册一个回调函数，用于在后续握手阶段根据签名方式动态选择数字证书。

在握手阶段(即接收到Client hello消息进行解析的时候)，调用这个回调函数，向回调函数传递的一个参数，即客户端所能支持的签名方式，如加密强度最高的哈希算法。

回调函数执行对此哈希算法和当前同类型分组的的证书所使用的签名算法进行匹配，找到算法强度最高并且匹配客户端哈希算法强度的证书重新加载。

具体而言，在匹配当前的数字证书时，可以查找与密钥交换方式匹配的公钥，识别在该公钥所属的分组中当前加载的数字证书的第二签名方式；

从而，判断第一签名方式是否与第二签名方式匹配，所谓匹配，则第二签名方式的加密强度等于或低于第一签名方式的加密强度。

例如，假设第一签名方式为SHA256，若第二签名方式为SHA224，则两者匹配，若第二签名方式为SHA512，则两者不匹配。

当第一签名方式与第二签名方式匹配时，则可以判定密钥交换方式和签名方式、是与当前加载的数字证书匹配；

当第一签名方式与第二签名方式不匹配时，则可以判定密钥交换方式和签名方式、与当前加载的数字证书不匹配。

例如，若客户端的密码套件为SSL_DHE_RSA_WITH_DES_CBC_SHA，则其第一签名方式为SHA，若在RSA所属的分组中，当前加载的数字证书为sha256WithRSAEncryption，则其第二签名方式为sha256，与SHA不匹配，需要重新加载其他匹配的数字证书。

步骤104，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；

在具体实现中，可以识别在公钥所属的分组中其他数字证书的第三签名方式，判断第三签名方式是否与第一签名方式匹配，若是，则加载第三签名方式所属的数字证书至SSL或TLS的上下文，以替换在在公钥所属的分组中当前加载的数字证书，后续的SSL或TLS的握手操作，将使用此新的数字证书发送给客户端以保证握手操作的正常进行。

为了进一步保证通信的安全性，若识别到多个匹配的数字证书，则可以加载其中签名方式的加密强度最高的数字证书。

步骤105，根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。

需要说明的是，在步骤103中，若判断所述密钥交换方式和所述第一签名方式、与当前加载的数字证书匹配，则可以直接执行步骤105，返回握手响应消息。

在步骤103中，若判断所述密钥交换方式和所述第一签名方式、与当前加载的数字证书不匹配，则执行步骤104，加载匹配的数字证书，再执行执行步骤105，返回握手响应消息。

如图3所示，服务器(server)向客户端(client)返回Server hello消息(即握手响应消消息)，对Client hello消息中的信息进行确认。

Server hello通常消息包括Version(版本，取客户端支持的最高版本号和服务端支持的最高版本号中的较低者)，Random(服务器随机数)，Session id(会话ID)，Ciphersuite(服务器选择的密码套件)，Compression method(服务器选择的压缩方法)等信息。

本申请实施例数字证书与客户端支持的密钥交换方式和第一签名方式的匹配，实现了在握手协商过程中动态加载合适的数字证书，以保证成功完成SSL/TLS的握手协商，提高了网站的兼容性差，保证了客户端通过HTTPS等安全协议访问网站，提高了通信的安全性。

这个阶段之后，客户端、服务器可以知道下列内容：

(1)SSL版本；

(2)密钥交换方式、签名方式和对称加密方式；

(3)压缩方法；

(4)有关密钥生成的两个随机数。

步骤这个阶段之后，服务器和客户端可以按照SSL或TLS的规范进行握手操作和加解密的操作。

以下以SSL的规范进行讲解：

服务器将携带自己公钥的数字证书通过Certificate消息发送给SSL客户端。

服务器发送Server Hello Done消息，通知客户端版本和密码套件协商结束，开始进行密钥交换。

客户端验证服务器的数字证书合法后，利用数字证书中的公钥加密客户端随机生成的premaster secret(预备主密钥)，并通过Client Key Exchange消息发送给服务器。

客户端发送Change Cipher Spec消息，通知服务器后续报文将采用协商好的密钥和密码套件进行加密和MAC计算。

客户端计算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值，利用协商好的密钥和密码套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给SSL服务器。

服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和密码套件协商成功。

服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和密码套件进行加密和MAC计算。

服务器计算已交互的握手消息的Hash值，利用协商好的密钥和密码套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished消息发送给客户端。

客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和密码套件协商成功。

客户端接收到服务器发送的Finished消息后，如果解密成功，则可以判断服务器是数字证书的拥有者，即服务器身份验证成功，因为只有拥有私钥的服务器才能从ClientKey Exchange消息中解密得到premaster secret，从而间接地实现了客户端对服务器的身份验证。

握手完成后，服务器和客户端分别用预备主密钥各自生成了加密所需要的对称主密钥，完整性验证所用的认证秘钥和初始化向量。

在数据传输阶段，对于每一个数据分组，发送端(服务器或客户端)都会先用对称秘钥进行加密，用认证秘钥对数据分组按照握手时协商的签名方式(如基于MD5或SHA的MAC算法)进行签名，产生摘要。

接收端(客户端或服务器)用对称秘钥进行解密，并且对解密数据用认证密钥按照握手时协商的签名方式(如基于MD5或SHA的MAC算法)进行签名，产生摘要并与接收得到的摘要作对比，校验数据的完整性。

如果二者相同，则报文没有改变；否则，报文在传输过程中被修改，，接收端(客户端或服务器)将丢弃该报文。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图4，示出了本申请的一种在SSL/TLS通信中加载数字证书的装置实施例的结构框图，具体可以包括如下模块：

握手请求消息接收模块401，用于接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；

客户端信息验证模块402，用于根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；

数字证书匹配模块403，用于判断所述密钥交换方式和所述第一签名方式、是否与当前加载的数字证书匹配；若否，则调用数字证书加载模块404；

数字证书加载模块404，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；

握手响应消息返回模块405，用于根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。

在本申请的一个实施例中，所述客户端信息验证模块402可以包括如下子模块：

密码套件查找子模块，用于从所述握手请求消息中查找密码套件；

密码套件识别子模块，用于从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式；

在本申请的一个实施例中，所述客户端信息验证模块402还可以包括如下子模块：

扩展头查找子模块，用于从所述握手请求中查找传输层安全协议TLS的扩展头；

扩展头识别子模块，用于从所述扩展头中识别客户端支持的第一签名方式。

在具体实现中，所验证的第一签名方式可以为客户端的加密强度最高的第一签名方式。

在实际应用中，所述数字证书可以按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书可以为所属分组中加密强度最高的数字证书。

在本申请的一个实施例中，所述数字证书匹配模块404可以包括如下子模块：

公钥查找子模块，用于查找与所述密钥交换方式匹配的公钥；

当前签名方式识别子模块，用于识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；

第一签名方式匹配子模块，用于判断所述第一签名方式是否与所述第二签名方式匹配；若是，则调用第一判定子模块，若否，则调用第二判定子模块；

第一判定子模块，用于判定所述密钥交换方式和所述签名方式、与当前加载的数字证书匹配；

第二判定子模块，用于判定所述密钥交换方式和所述签名方式、与当前加载的数字证书不匹配。

在本申请的一个实施例中，所述数字证书加载模块405可以包括如下子模块：

其他签名方式识别子模块，用于识别在所述公钥所属的分组中其他数字证书的第三签名方式；

第二签名方式匹配子模块，用于判断所述第三签名方式是否与所述第一签名方式匹配；若是，则调用数字证书替换子模块；

数字证书替换子模块，用于加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

本申请实施例是参照根据本申请实施例的方法、终端设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种在SSL/TLS通信中加载数字证书的方法和一种在SSL/TLS通信中加载数字证书的装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (13)

1.一种在SSL/TLS通信中加载数字证书的方法，其特征在于，包括：

接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；

根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；

判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；

根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。

2.根据权利要求1所述的方法，其特征在于，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤包括：

从所述握手请求消息中查找密码套件；

从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式。

3.根据权利要求2所述的方法，其特征在于，所述根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式的步骤还包括：

从所述握手请求中查找传输层安全协议TLS的扩展头；

从所述扩展头中识别客户端支持的第一签名方式。

4.根据权利要求1或2或3所述的方法，其特征在于，所验证的第一签名方式为客户端的加密强度最高的第一签名方式。

5.根据权利要求1或2或3所述的方法，其特征在于，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。

6.根据权利要求5所述的方法，其特征在于，所述判断所述密钥交换方式和所述签名方式是否与当前加载的数字证书匹配的步骤包括：

查找与所述密钥交换方式匹配的公钥；

识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；

判断所述第一签名方式是否与所述第二签名方式匹配；

若是，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；

若否，则判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。

7.根据权利要求6所述的方法，其特征在于，所述加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书的步骤包括：

识别在所述公钥所属的分组中其他数字证书的第三签名方式；

判断所述第三签名方式是否与所述第一签名方式匹配；

若是，则加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。

8.一种在SSL/TLS通信中加载数字证书的装置，其特征在于，包括：

握手请求消息接收模块，用于接收客户端基于安全套接层协议SSL或传输层安全协议TLS发送的握手请求消息；

客户端信息验证模块，用于根据所述握手请求消息验证客户端支持的密钥交换方式和第一签名方式；

数字证书匹配模块，用于判断所述密钥交换方式和所述第一签名方式是否与当前加载的数字证书匹配；若否，则调用数字证书加载模块；

数字证书加载模块，加载其他与所述密钥交换方式和所述第一签名方式匹配的数字证书；

握手响应消息返回模块，用于根据匹配数字证书成功的所述密钥交换方式和所述第一签名方式，向客户端返回握手响应消息。

9.根据权利要求8所述的装置，其特征在于，所述客户端信息验证模块包括：

密码套件查找子模块，用于从所述握手请求消息中查找密码套件；

密码套件识别子模块，用于从所述密码套件中识别客户端支持的密钥交换方式和第一签名方式。

10.根据权利要求9所述的装置，其特征在于，所述客户端信息验证模块还包括：

扩展头查找子模块，用于从所述握手请求中查找传输层安全协议TLS的扩展头；

扩展头识别子模块，用于从所述扩展头中识别客户端支持的第一签名方式。

11.根据权利要求8或9或10所述的装置，其特征在于，所述数字证书按照公钥的类型划分分组，在每个分组中加载其中一个数字证书，当前加载的数字证书为所属分组中加密强度最高的数字证书。

12.根据权利要求11所述的装置，其特征在于，所述数字证书匹配模块包括：

公钥查找子模块，用于查找与所述密钥交换方式匹配的公钥；

当前签名方式识别子模块，用于识别在所述公钥所属的分组中当前加载的数字证书的第二签名方式；

第一签名方式匹配子模块，用于判断所述第一签名方式是否与所述第二签名方式匹配；若是，则调用第一判定子模块，若否，则调用第二判定子模块；

第一判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书匹配；

第二判定子模块，用于判定所述密钥交换方式和所述签名方式与当前加载的数字证书不匹配。

13.根据权利要求12所述的装置，其特征在于，所述数字证书加载模块包括：

其他签名方式识别子模块，用于识别在所述公钥所属的分组中其他数字证书的第三签名方式；

第二签名方式匹配子模块，用于判断所述第三签名方式是否与所述第一签名方式匹配；若是，则调用数字证书替换子模块；

数字证书替换子模块，用于加载所述第三签名方式所属的数字证书，以替换在所述公钥所属的分组中当前加载的数字证书。