CN115150162B - 一种根证书更新方法、装置 - Google Patents

Abstract

本发明实施例公开了一种根证书更新方法、装置。该方法包括：在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；接收服务端响应于第一握手请求的第一回复消息，其中，第一回复消息中携带有该服务端当前部署的第二根证书的信息；在根据第一回复消息握手成功并建立连接后，根据第二根证书的信息判断该第一根证书与该第二根证书是否一致；在第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。通过本发明，解决了相关技术中根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题，达到了提高安全性、减轻服务端计算压力以及节约带宽的技术效果。

Description

一种根证书更新方法、装置

技术领域

本发明涉及安全技术领域，尤其涉及一种根证书更新方法、装置。

背景技术

安全传输层协议(Transport Layer Security，简称为TLS)认证机制中,客户端需要一个根证书,才能和服务器实现TLS握手，然而,TLS根证书一般都有一个有效期,过了这个时间点客户端如果不更新根证书都无法实现TLS连云。对于浏览器而言,一般不存在这个问题,因为浏览器使用的是电脑的根证书,而电脑的根证书一般都会由操作系统实现更新(以Windows系统为例,系统内部的Cryptographic Services会与Windows Update同步,自动更新根证书)。而对于多数物联网设备,由于无法像windows电脑一样实现根证书的更新,会导致证书过期后设备都无法联网。以某物联网平台所用根证书为例,有效期是2028.1.28.在这个时间点后,预置了旧的TLS根证书的设备,都无法实现TLS连云。通过空中下载技术(Over-the-Air Technology，简称为OTA)升级固件是一个解决方案,但是具备OTA能力的物联网设备数量非常有限。因此,需要另外一种机制,确保物联网设备中的根证书能够像windows一样实现定时更新,确保TLS连接功能都正常,不至于某一天多数设备都无法连云，可能导致重大事件,如某市某一天所有的公交自行车都无法租车/还车等等。

针对上述问题，相关技术提出了一种根证书更新方法，在该方法中客户端(设备)每次建联都要上传完整的根证书,服务端比较客户端上传的根证书和新部署的根证书是否相同,如果不同则下发新的根证书，该方法存在以下技术问题：1、客户端的根证书在公网上暴露,招来不必要的攻击；2、服务端判断根证书是否过期，加重了服务端的计算压力；3、客户端上传完整的根证书浪费了带宽。

针对相关技术中，根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题，目前尚未得到有效的解决。

发明内容

为解决上述技术问题，本发明实施例期望提供一种根证书更新方法、装置、电子设备和计算机可读存储介质，能够解决相关技术中客户端的根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题。

本发明实施例提供一种根证书更新方法，包括：在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；接收所述服务端响应于所述第一握手请求的第一回复消息，其中，所述第一回复消息中携带有所述服务端当前部署的第二根证书的信息；在根据所述第一回复消息握手成功并建立连接后，根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致；在所述第一根证书与所述第二根证书不一致的情况下，将当前存储的所述第一根证书更新为所述第二根证书。

本发明实施例还提供了一种根证书更新方法，包括：接收客户端发送的第一握手请求，其中，所述第一握手请求中携带有第一指示信息，所述第一指示信息用于指示所述客户端当前存储的第一根证书未过期；向所述客户端发送响应于所述第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，所述第一回复消息中携带有当前部署的第二根证书的信息；所述第二根证书的信息用于所述客户端判断所述第一根证书与所述第二根证书是否一致，以及供所述客户端在所述第一根证书与所述第二根证书不一致的情况下更新所述第一根证书。

本发明实施例还提供了一种根证书更新装置，包括：第一发送模块，用于在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；第一接收模块，用于接收所述服务端响应于所述第一握手请求的第一回复消息，其中，所述第一回复消息中携带有所述服务端当前部署的第二根证书的信息；判断模块，用于在根据所述第一回复消息握手成功并建立连接后，根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致；更新模块，用于在所述第一根证书与所述第二根证书不一致的情况下，将当前存储的所述第一根证书更新为所述第二根证书。

本发明实施例还提供了一种根证书更新装置，包括：第二接收模块，用于接收客户端发送的第一握手请求，其中，所述第一握手请求中携带有第一指示信息，所述第一指示信息用于指示所述客户端当前存储的第一根证书未过期；第二发送模块，用于向所述客户端发送响应于所述第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，所述第一回复消息中携带有当前部署的第二根证书的信息；所述第二根证书的信息用于所述客户端判断所述第一根证书与所述第二根证书是否一致，以及供所述客户端在所述第一根证书与所述第二根证书不一致的情况下更新所述第一根证书。

本发明实施例提供一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行上述任一项方法的步骤。

本发明实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有指令，指令被处理器执行时实现上述任一项方法的步骤。

本发明实施例提供了一种根证书更新方法、装置、电子设备和计算机可读存储介质，其中，该方法包括：在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；接收该服务端响应于该第一握手请求的第一回复消息，其中，该第一回复消息中携带有该服务端当前部署的第二根证书的信息；在根据该第一回复消息握手成功并建立连接后，根据该第二根证书的信息判断该第一根证书与该第二根证书是否一致；在该第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。也就是说，本发明实施例改进了当前的客户端和服务端的握手方式，在握手中携带新的证书的信息(例如，摘要)，不需要客户端上传完整的根证书，提高了安全性，同时也节约了带宽，另外，在本申请实施例中由客户端根据新的证书的信息判断是否需要更新当前根证书，减轻了服务端的计算压力，进而解决了相关技术中根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本申请实施例的一种根证书更新方法的计算机终端的硬件结构框图；

图2为本发明实施例提供的一种根证书更新方法的流程示意图；

图3是本发明实施例的一种根证书更新方法的服务器的硬件结构框图

图4为本发明实施例提供的另一种根证书更新方法的流程示意图；

图5为本发明实施例提供的一种根证书更新装置的流程示意图；

图6为本发明实施例提供的另一种根证书更新装置的流程示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

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

实施例一

根据本申请实施例，提供了一种根证书更新的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例，图1是本申请实施例的一种根证书更新方法的计算机终端的硬件结构框图。如图1所示，计算机终端10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中的客户端的根证书更新方法对应的程序指令/模块，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的根证书更新方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在上述运行环境下，本申请提供了如图2所示的根证书更新方法。图2是根据本申请实施例一的根证书更新方法的流程图。

如图2所示，本申请实施例提供的根证书更新方法，该方法可以应用于客户端，该客户端包括但并不限于：物联网平台的客户端、设备管理平台、APP等，当然本申请实施例的应用场景也可以包括服务器1和服务器2之间的根证书更新，其中服务器1相当于客户端，服务器2相当于服务端，只要是两端进行根证书更新的方法均适用，并不作具体场景的限定。另外，在存在以下至少2种影响根证书的安全性的情况时，也可以使用本申请实施例提供的根证书更新方法：第一种情况,是CA机构错误签发了证书或签发了欺诈性数字证书；第二种情况，是服务端私钥泄露的情况。在上述2种情况下,根证书需要更新才能避免被恶意攻击。反之,在上述2种情况下,如果设备在网上传输的报文中宣告自己持有了已经变得不安全的根证书,可能会招致来更多的攻击。

另外，本申请实施例的客户端相比于具备空中下载技术(Over-the-AirTechnology，简称为OTA)功能的客户端而言，可以不具备该OTA功能。

上述根证书更新方法包括以下步骤：

S202，在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；

可选地，在本实施例中，上述第一握手请求可以是TLS握手请求，在此，并不作任何限定。

S204，接收该服务端响应于该第一握手请求的第一回复消息，其中，该第一回复消息中携带有该服务端当前部署的第二根证书的信息；

可选地，在本实施例中，上述第二根证书的信息包括但并不限于：第二根证书的摘要、第二根证书的标签等，在此，并不作任何限定。

需要说明的是，上述S204相较于相关技术，服务端只是下发最新根证书的信息(例如，摘要、标签等),带宽更低，客户端自己看情况进行本地根证书的更新,将服务端的计算压力分摊到每个客户端,减少了服务端的压力。

S206，在根据该第一回复消息握手成功并建立连接后，根据该第二根证书的信息判断该第一根证书与该第二根证书是否一致；

也就是说，客户端向服务端发送握手请求报文，在服务端收到该握手请求报文后，向客户端发送回复报文，客户端处理握手结果，如果握手成功，则表示服务端可信，客户端和服务端建立连接。

可选地，在上述第二根证书的信息包括第二根证书的摘要时，根据该第二根证书的信息判断该第一根证书与该第二根证书是否一致包括：

S11，根据与该服务端预先确定的根证书请求信息确定该第一根证书的摘要；

S12，根据该第一根证书的摘要和该第二根证书的摘要，判断该第一根证书与该第二根证书是否一致。

通过上述S11～S12，根据第一根证书的摘要和第二根证书的摘要来判断第一根证书与第二根证书是否一致，进一步节省了算力。

S208，在该第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。

可选地，在上述第二根证书的信息包括第二根证书的摘要时，将当前存储的该第一根证书更新为该第二根证书包括：

S21，根据该第二根证书的摘要，请求该服务端下发该第二根证书；

需要说明的是，在本申请实施例的优选方案中，上述第二根证书是服务端通过当前连接以明文方式下发的。当然也可以采用密文方式，在此，并不作限定。

S22，接收该服务端通过当前连接下发的该第二根证书，并将当前存储的该第一根证书替换为该第二根证书。

通过上述S21～S22，在客户端和服务端建立连接后，说明服务端可信，通过当前连接接收服务端下发的第二根证书，相比于相关技术中采用对称密钥加密的方式，进一步节约了算力。

可选地，在本实施例中，在请求该服务端下发该第二根证书之前，该方法还包括：

S31，判断当前时间是否满足更新根证书的条件，直至当前时间满足更新根证书的条件后，执行请求该服务端下发该第二根证书的步骤。

例如，假设上述更新根证书的条件为客户端当前任务处理量小于某一阈值，那么在当前任务处理量非常大，直接去请求该服务端下发该第二根证书，必然会对当前任务产生不好的影响，因此，在本申请实施例中，客户端需要根据自己当前任务处理量，择机(比如任务低谷期)请求该服务端下发该第二根证书。因此，本申请实施例允许客户端先建连再择机更新根证书,不强制客户端先更新根证书再建连,更适合物联网场景，可以避免服务端证书更新对客户端任务的影响。因为部分物联网设备对建连的时间长短相当敏感,比如共享充电宝等任务,如果强制要求根证书完成更新后再连云,无疑会大大影响用户体验。

又例如，假设上述更新根证书的条件为客户端当前时间不在更新限制条件内(例如，1年内不检查升级)那么如果客户端的当前时间刚好在该更新限制条件内，是不需要请求该服务端下发该第二根证书，而是在该更新限制条件之外的时间点，才会考虑更新根证书，从而节约算力。

可选地，在本实施例中，前文描述了客户端根证书未过期的情况，下面将对客户端根证书已过期的情况展开描述。

可选地，上述根证书更新方法还包括：

S41，在当前存储的第一根证书已过期的情况下，向服务端发送第二握手请求，其中，该第二握手请求中携带有该第一根证书的信息和根证书请求信息；

可选地，在本实施例中，上述根证书请求信息包括但并不限于：productKey、deviceName、随机数、signmethod等信息。上述第一根证书的信息包括但并不限于：第一根证书的摘要、第一根证书的标签等信息。

S42，接收该服务端响应于该第二握手请求的第二回复消息，其中，该第二回复消息中携带有该服务端当前部署的第二根证书和该第二根证书的摘要；

S43，根据该根证书请求信息确定该第二根证书的摘要，并验证所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要是否一致；

S44，在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要一致的情况下，根据该第二回复消息握手成功并建立连接，以及将当前存储的该第一根证书更新为该第二根证书。

可选地，在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要不一致的情况下，还包括：

S51，确定握手失败，以及拒绝该第二根证书。

通过上述S41～44以及S51，在客户端根证书过期情况下,不基于对称秘钥也能实现根证书的安全更新。

可选地，在本实施例中，由于当前存储的第一根证书已过期，无法再用证书校验服务端的能力,但是可以使用基于哈希的消息身份验证代码(HmacSHA256)等数字签名工具对服务器的身份进行校验。例如，客户端生成一个字符串(包含随机数,设备的身份id)；客户端用自己保存的密码,对上述字符串计算出一个哈希的摘要,得出code1；客户端向服务端传输这个字符串；服务端解析字符串,获取到客户端的身份id,从后台数据库中查询出客户端的密码(与存储在客户端中的密码一致)，再用这个密码对字符串计算哈希摘要,得出code2，客户端比较code1/code2,如果一致,则认为服务端可信。

在一个可选地实施方式中，在握手成功并建立连接之后，上述方法还包括：

S51，接收该服务端通过当前连接下发的第三根证书，其中，该第三根证书为在保持当前连接过程中该服务端重新部署的根证书；

需要说明的是，上述第三根证书是服务端通过当前连接以明文方式下发的。由于上述客户端和服务端之间保持长连接，因此服务端是可信的，服务端在下发第三根证书时采用明文的方式，而不是相关技术中服务端下推的公钥证书采用对称秘钥加密,增加了服务端/客户端算力开销，进一步节约了算力。

另外，需要说明的是，上述下发方式也可以是密文方式，在此，并不作限定。

S52，将当前存储的该第一根证书更新为该第三根证书。

也就是说，服务端部署新的根证书(即上述第三根证书)，现有连接不受影响，服务端向客户端下发新的根证书，客户端因为与服务端维持连接，相信内容可靠，接受新的根证书，进一步节省了算力。

可选地，在本实施例中，上述握手方式可以是TLS握手，下面以TLS握手为例，对本申请实施例进行举例描述，其中，分为三种情况，情形一、客户端根证书未过期、情形二、客户端根证书还未过期，但客户端和服务端一直连接未断开，情形三、客户端根证书已过期。下面分别针对该三种情况进行展开举例说明。其主要包括以下步骤：

关于情形一，本示例提供的根证书更新方法包括：

S61，客户端向服务端发送client_params，client_random，TLS版本和供筛选的加密套件列表；

S62，服务端返回：server_random、server_params、TLS版本、确定的加密套件方法以及本申请实施例的该服务端当前部署的第二根证书的信息(摘要)；

S63，客户端接收，根据该第二根证书的信息(摘要)判断该第一根证书与该第二根证书是否一致，在该第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。

关于情形二，本示例提供的根证书更新方法包括：

S71，客户端与服务端发送client_params，client_random，TLS版本和供筛选的加密套件列表；

S72，服务端返回：server_random、server_params、TLS版本、确定的加密套件方法；

S73，客户端和服务端建立连接，择机接收服务端发送的第二根证书，根据该第二根证书，将当前存储的该第一根证书更新为该第二根证书。

关于情形三，本示例提供的根证书更新方法包括：

S81，客户端与服务端发送client_params，client_random，TLS版本和供筛选的加密套件列表、第一根证书的信息(例如，摘要)和根证书请求信息；

S82，服务端返回：server_random、server_params、TLS版本、确定的加密套件方法、本申请实施例的该服务端当前部署的第二根证书以及该第二根证书的摘要；

S83，客户端接收，根据该根证书请求信息确定该第二根证书的摘要，并验证所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要是否一致；在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要一致的情况下，根据该第二回复消息握手成功并建立连接，以及将当前存储的该第一根证书更新为该第二根证书。

综上，本申请实施例，在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；接收该服务端响应于该第一握手请求的第一回复消息，其中，该第一回复消息中携带有该服务端当前部署的第二根证书的信息；在根据该第一回复消息握手成功并建立连接后，根据该第二根证书的信息判断该第一根证书与该第二根证书是否一致；在该第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。也就是说，本发明实施例改进了当前的客户端和服务端的握手方式，在握手中携带新的证书的信息(例如，摘要)，不需要客户端上传完整的根证书，提高了安全性，同时也节约了带宽，另外，在本申请实施例中由客户端根据新的证书的信息判断是否需要更新当前根证书，减轻了服务端的计算压力，进而解决了相关技术中根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题。

实施例二

根据本发明实施例，还提供了一种根证书更新方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组服务器可执行指令的服务器架构中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例二所提供的方法实施例可以在服务器、与服务器集群连接的网关设备或者类似的运算装置中执行。以运行在服务器上为例，图3是本发明实施例的根证书更新方法的服务器的硬件结构框图。如图3所示，服务器30可以包括一个或多个(图中仅示出一个)处理器302(处理器302可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器304、以及用于通信功能的传输模块306。本领域普通技术人员可以理解，图3所示的结构仅为示意，其并不对上述电子装置的结构造成限定。

例如，服务器30还可包括比图3中所示更多或者更少的组件，或者具有与图3所示不同的配置。

存储器304可用于存储应用软件的软件程序以及模块，如本发明实施例中的根证书更新方法对应的程序指令/模块，处理器302通过运行存储在存储器304内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的根证书更新方法。存储器304可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器304可进一步包括相对于处理器302远程设置的存储器，这些远程存储器可以通过网络连接至服务器30。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置306用于经由一个网络接收或者发送数据。上述的网络具体实例可包括服务器30的通信供应商提供的无线网络。在一个实例中，传输装置306包括一个网络适配器(Network Interface Controller，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置306可以为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

在上述运行环境下，本申请提供了如图4所示的根证书更新方法。在服务端，图4是根据本发明实施例二的根证书更新方法的流程图。

如图4所示，本申请实施例提供的根证书更新方法，包括以下步骤：

S402，接收客户端发送的第一握手请求，其中，该第一握手请求中携带有第一指示信息，该第一指示信息用于指示该客户端当前存储的第一根证书未过期；

可选地，上述客户端包括但并不限于：物联网平台、设备管理平台、APP等。该客户端相比于具备空中下载技术(Over-the-Air Technology，简称为OTA)功能的客户端而言，可以不具备该OTA功能。上述第一握手请求可以是TLS握手请求，在此，并不作任何限定。

S404，向所述客户端发送响应于该第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，该第一回复消息中携带有当前部署的第二根证书的信息；该第二根证书的信息用于该客户端判断该第一根证书与该第二根证书是否一致，以及供该客户端在该第一根证书与该第二根证书不一致的情况下更新该第一根证书。

可选地，在本实施例中，上述第二根证书的信息包括但并不限于：第二根证书的摘要、第二根证书的标签等，在此，并不作任何限定。

通过上述S402～S404，改进了当前的客户端和服务端的握手方式，在握手中携带新的证书的信息(例如，摘要)，不需要客户端上传完整的根证书，提高了安全性，同时也节约了带宽，另外，在本申请实施例中由客户端根据新的证书的信息判断是否需要更新当前根证书，减轻了服务端的计算压力，进而解决了相关技术中根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题。

在一个可选地实施方式中，上述方法还包括：

S91，接收该客户端发送的第二握手请求，其中，该第二握手请求中携带有第二指示信息，该第二指示信息用于指示该客户端当前存储的第一根证书已过期和根证书请求信息；

S92，向所述客户端发送响应于该第二握手请求的第二回复消息，其中，该第二回复消息中携带有该服务端当前部署的第二根证书和该第二根证书的摘要，以供该客户端根据该根证书请求信息确定该第二根证书的摘要，并验证所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要是否一致，在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要一致的情况下，根据该第二回复消息握手成功并建立连接，以及将当前存储的该第一根证书更新为该第二根证书。

可选地，在本实施例中，上述根证书请求信息包括但并不限于：productKey、deviceName、随机数、signmethod等信息。上述第一根证书的信息包括但并不限于：第一根证书的摘要、第一根证书的标签等信息。

通过上述S91～S92，在客户端根证书过期情况下,不基于对称秘钥也能实现根证书的安全更新。

可选地，在本实施例中，在握手成功并建立连接之后，上述方法还包括：

S101，通过当前连接向所述客户端下发第三根证书，其中，该第三根证书为在保持当前连接过程中该服务端重新部署的根证书，以供该客户端将当前存储的该第一根证书更新为该第三根证书。

需要说明的是，上述第三根证书是服务端通过当前连接以明文方式下发的。由于上述客户端和服务端之间保持长连接，因此服务端是可信的，服务端在下发第三根证书时采用明文的方式，而不是相关技术中服务端下推的公钥证书采用对称秘钥加密,增加了服务端/客户端算力开销，进一步节约了算力。

另外，需要说明的是，上述下发方式也可以是密文方式，在此，并不作限定。

可选地，在本实施例中，服务端还可以及时感知根证书(对应上述第二根证书)是否安全,可以动态更新该根证书(对应上述第二根证书)。具体地，可以通过新闻或者电子邮件等方式及时感知到服务端所部署的根证书是否过期,从而及时更新根证书。

实施例三

根据本发明实施例，还提供了一种用于实施上述方法实施例的根证书更新装置实施例，本申请上述实施例所提供的装置可以在客户端上运行。该装置可以应用于客户端，该客户端包括但并不限于：物联网平台的客户端、设备管理平台、APP等，当然本申请实施例的应用场景也可以包括服务器1和服务器2之间的根证书更新，其中服务器1相当于客户端，服务器2相当于服务端，只要是两端进行根证书更新的方法均适用，并不作具体场景的限定。另外，在存在以下至少2种影响根证书的安全性的情况时，也可以使用本申请实施例提供的根证书更新方法：第一种情况,是CA机构错误签发了证书或签发了欺诈性数字证书；第二种情况，是服务端私钥泄露的情况。在上述2种情况下,根证书需要更新才能避免被恶意攻击。反之,在上述2种情况下,如果设备在网上传输的报文中宣告自己持有了已经变得不安全的根证书,可能会招致来更多的攻击。

另外，本申请实施例的客户端相比于具备空中下载技术(Over-the-AirTechnology，简称为OTA)功能的客户端而言，可以不具备该OTA功能。

图5是根据本发明实施例三的根证书更新装置的结构示意图。如图5所示，该根证书更新装置包括：

第一发送模块52，用于在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；

可选地，在本实施例中，上述第一握手请求可以是TLS握手请求，在此，并不作任何限定。

第一接收模块54，用于接收该服务端响应于该第一握手请求的第一回复消息，其中，该第一回复消息中携带有该服务端当前部署的第二根证书的信息；

可选地，在本实施例中，上述第二根证书的信息包括但并不限于：第二根证书的摘要、第二根证书的标签等，在此，并不作任何限定。

需要说明的是，上述第一接收模块54相较于相关技术，服务端只是下发最新根证书的信息(例如，摘要、标签等),带宽更低，客户端自己看情况进行本地根证书的更新,将服务端的计算压力分摊到每个客户端,减少了服务端的压力。

判断模块56，用于在根据该第一回复消息握手成功并建立连接后，根据该第二根证书的信息判断该第一根证书与该第二根证书是否一致；

也就是说，客户端向服务端发送握手请求报文，在服务端收到该握手请求报文后，向客户端发送回复报文，客户端处理握手结果，如果握手成功，则表示服务端可信，客户端和服务端建立连接。

可选地，在上述第二根证书的信息包括第二根证书的摘要时，上述判断模块56还用于根据与该服务端预先确定的根证书请求信息确定该第一根证书的摘要；根据该第一根证书的摘要和该第二根证书的摘要，判断该第一根证书与该第二根证书是否一致。通过上述判断模块56根据第一根证书的摘要和第二根证书的摘要来判断第一根证书与第二根证书是否一致，进一步节省了算力。

更新模块58，用于在该第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。

可选地，在上述第二根证书的信息包括第二根证书的摘要时，上述更新模块58还用于根据该第二根证书的摘要，请求该服务端下发该第二根证书；接收该服务端通过当前连接下发的该第二根证书，并将当前存储的该第一根证书替换为该第二根证书。

需要说明的是，上述第二根证书是服务端通过当前连接以明文方式下发的。

通过上述更新模块58，在客户端和服务端建立连接后，说明服务端可信，通过当前连接接收服务端下发的第二根证书，相比于相关技术中采用对称密钥加密的方式，进一步节约了算力。

另外，需要说明的是，上述下发方式也可以是密文方式，在此，并不作限定。

可选地，在本实施例中，在请求该服务端下发该第二根证书之前，上述装置还包括：，判断当前时间是否满足更新根证书的条件，直至当前时间满足更新根证书的条件后，执行请求该服务端下发该第二根证书的步骤的模块。

例如，假设上述更新根证书的条件为客户端当前任务处理量小于某一阈值，那么在当前任务处理量非常大，直接去请求该服务端下发该第二根证书，必然会对当前任务产生不好的影响，因此，在本申请实施例中，客户端需要根据自己当前任务处理量，择机(比如任务低谷期)请求该服务端下发该第二根证书。因此，本申请实施例允许客户端先建连再择机更新根证书,不强制客户端先更新根证书再建连,更适合物联网场景，可以避免服务端证书更新对客户端任务的影响。因为部分物联网设备对建连的时间长短相当敏感,比如共享充电宝等任务,如果强制要求根证书完成更新后再连云,无疑会大大影响用户体验。

又例如，假设上述更新根证书的条件为客户端当前时间不在更新限制条件内(例如，1年内不检查升级)那么如果客户端的当前时间刚好在该更新限制条件内，是不需要请求该服务端下发该第二根证书，而是在该更新限制条件之外的时间点，才会考虑更新根证书，从而节约算力。

可选地，在本实施例中，前文描述了客户端根证书未过期的情况，下面将对客户端根证书已过期的情况展开描述。

可选地，上述根证书更新装置还包括：在当前存储的第一根证书已过期的情况下，向服务端发送第二握手请求，其中，该第二握手请求中携带有该第一根证书的信息和根证书请求信息；接收该服务端响应于该第二握手请求的第二回复消息，其中，该第二回复消息中携带有该服务端当前部署的第二根证书和该第二根证书的摘要；根据该根证书请求信息确定该第二根证书的摘要，并验证所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要是否一致；在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要一致的情况下，根据该第二回复消息握手成功并建立连接，以及将当前存储的该第一根证书更新为该第二根证书的模块。

可选地，在本实施例中，上述根证书请求信息包括但并不限于：productKey、deviceName、随机数、signmethod等信息。上述第一根证书的信息包括但并不限于：第一根证书的摘要、第一根证书的标签等信息。

可选地，在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要不一致的情况下，上述装置还包括确定握手失败，以及拒绝该第二根证书的模块。通过该模块，在客户端根证书过期情况下,不基于对称秘钥也能实现根证书的安全更新。

可选地，在本实施例中，由于当前存储的第一根证书已过期，无法再用证书校验服务端的能力,但是可以使用基于哈希的消息身份验证代码(HmacSHA256)等数字签名工具对服务端的身份进行校验。例如，客户端生成一个字符串(包含随机数,设备的身份id)；客户端用自己保存的密码,对上述字符串计算出一个哈希的摘要,得出code1；客户端向服务端传输这个字符串；服务端解析字符串,获取到客户端的身份id,从后台数据库中查询出客户端的密码(与存储在客户端中的密码一致)，再用这个密码对字符串计算哈希摘要,得出code2，客户端比较code1/code2,如果一致,则认为服务端可信。

在一个可选地实施方式中，在握手成功并建立连接之后，上述装置还包括接收该服务端通过当前连接下发的第三根证书；将当前存储的该第一根证书更新为该第三根证书的模块，其中，该第三根证书为在保持当前连接过程中该服务端重新部署的根证书。

需要说明的是，上述第三根证书是服务端通过当前连接以明文方式下发的。由于上述客户端和服务端之间保持长连接，因此服务端是可信的，服务端在下发第三根证书时采用明文的方式，而不是相关技术中服务端下推的公钥证书采用对称秘钥加密,增加了服务端/客户端算力开销，进一步节约了算力。

也就是说，服务端部署新的根证书(即上述第三根证书)，现有连接不受影响，服务端向客户端下发新的根证书，客户端因为与服务端维持连接，相信内容可靠，接受新的根证书，进一步节省了算力。

另外，需要说明的是，上述下发方式也可以是密文方式，在此，并不作限定。

综上，本申请实施例，在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；接收该服务端响应于该第一握手请求的第一回复消息，其中，该第一回复消息中携带有该服务端当前部署的第二根证书的信息；在根据该第一回复消息握手成功并建立连接后，根据该第二根证书的信息判断该第一根证书与该第二根证书是否一致；在该第一根证书与该第二根证书不一致的情况下，将当前存储的该第一根证书更新为该第二根证书。也就是说，本发明实施例改进了当前的客户端和服务端的握手方式，在握手中携带新的证书的信息(例如，摘要)，不需要客户端上传完整的根证书，提高了安全性，同时也节约了带宽，另外，在本申请实施例中由客户端根据新的证书的信息判断是否需要更新当前根证书，减轻了服务端的计算压力，进而解决了相关技术中根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题。

实施例四

根据本发明实施例，还提供了一种用于实施上述方法实施例的根证书更新装置实施例，本申请上述实施例所提供的装置可以在服务器上运行。

图6是根据本发明实施例四的根证书更新装置的结构示意图。如图6所示，该根证书更新装置包括：

第二接收模块62，用于接收客户端发送的第一握手请求，其中，该第一握手请求中携带有第一指示信息，该第一指示信息用于指示该客户端当前存储的第一根证书未过期；

可选地，上述客户端包括但并不限于：物联网平台、设备管理平台、APP等。该客户端相比于具备空中下载技术(Over-the-Air Technology，简称为OTA)功能的客户端而言，可以不具备该OTA功能。上述第一握手请求可以是TLS握手请求，在此，并不作任何限定。

第二发送模块64，用于向客户端发送响应于该第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，该第一回复消息中携带有当前部署的第二根证书的信息；该第二根证书的信息用于该客户端判断该第一根证书与该第二根证书是否一致，以及供该客户端在该第一根证书与该第二根证书不一致的情况下更新该第一根证书。

可选地，在本实施例中，上述第二根证书的信息包括但并不限于：第二根证书的摘要、第二根证书的标签等，在此，并不作任何限定。

通过上述模块，改进了当前的客户端和服务端的握手方式，在握手中携带新的证书的信息(例如，摘要)，不需要客户端上传完整的根证书，提高了安全性，同时也节约了带宽，另外，在本申请实施例中由客户端根据新的证书的信息判断是否需要更新当前根证书，减轻了服务端的计算压力，进而解决了相关技术中根证书更新方法存在不安全、服务端计算压力较重以及带宽浪费的技术问题。

在一个可选地实施方式中，上述装置还包括：接收该客户端发送的第二握手请求，其中，该第二握手请求中携带有第二指示信息，该第二指示信息用于指示该客户端当前存储的第一根证书已过期和根证书请求信息；向客户端发送响应于该第二握手请求的第二回复消息，其中，该第二回复消息中携带有该服务端当前部署的第二根证书和该第二根证书的摘要，以供该客户端根据该根证书请求信息确定该第二根证书的摘要，并验证所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要是否一致，在所确定的该第二根证书的摘要与该第二回复消息中携带的该第二根证书的摘要一致的情况下，根据该第二回复消息握手成功并建立连接，以及将当前存储的该第一根证书更新为该第二根证书的模块。通过该模块，在客户端根证书过期情况下,不基于对称秘钥也能实现根证书的安全更新。

可选地，在本实施例中，上述根证书请求信息包括但并不限于：productKey、deviceName、随机数、signmethod等信息。上述第一根证书的信息包括但并不限于：第一根证书的摘要、第一根证书的标签等信息。

可选地，在本实施例中，在握手成功并建立连接之后，上述装置还包括：通过当前连接向该客户端下发第三根证书的模块，其中，该第三根证书为在保持当前连接过程中该服务端重新部署的根证书，以供该客户端将当前存储的该第一根证书更新为该第三根证书。

需要说明的是，上述第三根证书是服务端通过当前连接以明文方式下发的。由于上述客户端和服务端之间保持长连接，因此服务端是可信的，服务端在下发第三根证书时采用明文的方式，而不是相关技术中服务端下推的公钥证书采用对称秘钥加密,增加了服务端/客户端算力开销，进一步节约了算力。

另外，需要说明的是，上述下发方式也可以是密文方式，在此，并不作限定。

可选地，在本实施例中，服务端还可以及时感知根证书(对应上述第二根证书)是否安全,可以动态更新该根证书(对应上述第二根证书)。具体地，可以通过新闻或者电子邮件等方式及时感知到服务端所部署的根证书是否过期,从而及时更新根证书。

实施例五

本发明实施例还提供了一种电子设备，包括：处理器；用于存储处理器可执行指令的存储器；其中，处理器被配置为执行上述任一项方法的步骤。

实施例六

本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有指令，指令被处理器执行时实现上述任一项方法的步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (12)

1.一种根证书更新方法，其特征在于，包括：

在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；

接收所述服务端响应于所述第一握手请求的第一回复消息，其中，所述第一回复消息中携带有所述服务端当前部署的第二根证书的信息；

在根据所述第一回复消息握手成功并建立连接后，根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致；

在所述第一根证书与所述第二根证书不一致的情况下，将当前存储的所述第一根证书更新为所述第二根证书。

2.根据权利要求1所述的方法，其特征在于，所述第二根证书的信息包括所述第二根证书的摘要；

根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致包括：根据与所述服务端预先确定的根证书请求信息确定所述第一根证书的摘要；根据所述第一根证书的摘要和所述第二根证书的摘要，判断所述第一根证书与所述第二根证书是否一致；

将当前存储的所述第一根证书更新为所述第二根证书包括：根据所述第二根证书的摘要，请求所述服务端下发所述第二根证书；接收所述服务端通过当前连接下发的所述第二根证书，并将当前存储的所述第一根证书替换为所述第二根证书。

3.根据权利要求2所述的方法，其特征在于，在请求所述服务端下发所述第二根证书之前，所述方法还包括：

判断当前时间是否满足更新根证书的条件，直至当前时间满足更新根证书的条件后，执行请求所述服务端下发所述第二根证书的步骤。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在当前存储的第一根证书已过期的情况下，向服务端发送第二握手请求，其中，所述第二握手请求中携带有所述第一根证书的信息和根证书请求信息；

接收所述服务端响应于所述第二握手请求的第二回复消息，其中，所述第二回复消息中携带有所述服务端当前部署的第二根证书和所述第二根证书的摘要；

根据所述根证书请求信息确定所述第二根证书的摘要，并验证所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要是否一致；

在所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要一致的情况下，根据所述第二回复消息握手成功并建立连接，以及将当前存储的所述第一根证书更新为所述第二根证书。

5.根据权利要求4所述的方法，其特征在于，在所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要不一致的情况下，确定握手失败，以及拒绝所述第二根证书。

6.根据权利要求1所述的方法，其特征在于，所述第二根证书是所述服务端通过当前连接以明文方式下发的。

7.一种根证书更新方法，其特征在于，包括：

接收客户端发送的第一握手请求，其中，所述第一握手请求中携带有第一指示信息，所述第一指示信息用于指示所述客户端当前存储的第一根证书未过期；

向所述客户端发送响应于所述第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，所述第一回复消息中携带有当前部署的第二根证书的信息；所述第二根证书的信息用于所述客户端判断所述第一根证书与所述第二根证书是否一致，以及供所述客户端在所述第一根证书与所述第二根证书不一致的情况下更新所述第一根证书。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

接收所述客户端发送的第二握手请求，其中，所述第二握手请求中携带有第二指示信息，所述第二指示信息用于指示所述客户端当前存储的第一根证书已过期和根证书请求信息；

向所述客户端发送响应于所述第二握手请求的第二回复消息，其中，所述第二回复消息中携带有服务端当前部署的第二根证书和所述第二根证书的摘要，以供所述客户端根据所述根证书请求信息确定所述第二根证书的摘要，并验证所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要是否一致，在所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要一致的情况下，根据所述第二回复消息握手成功并建立连接，以及将当前存储的所述第一根证书更新为所述第二根证书。

9.一种根证书更新装置，其特征在于，包括：

第一发送模块，用于在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；

第一接收模块，用于接收所述服务端响应于所述第一握手请求的第一回复消息，其中，所述第一回复消息中携带有所述服务端当前部署的第二根证书的信息；

判断模块，用于在根据所述第一回复消息握手成功并建立连接后，根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致；

更新模块，用于在所述第一根证书与所述第二根证书不一致的情况下，将当前存储的所述第一根证书更新为所述第二根证书。

10.一种根证书更新装置，其特征在于，包括：

第二接收模块，用于接收客户端发送的第一握手请求，其中，所述第一握手请求中携带有第一指示信息，所述第一指示信息用于指示所述客户端当前存储的第一根证书未过期；

第二发送模块，用于向所述客户端发送响应于所述第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，所述第一回复消息中携带有当前部署的第二根证书的信息；所述第二根证书的信息用于所述客户端判断所述第一根证书与所述第二根证书是否一致，以及供所述客户端在所述第一根证书与所述第二根证书不一致的情况下更新所述第一根证书。

11.一种电子设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行权利要求1-6、7-8所述的任一项方法的步骤。

12.一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令被处理器执行时实现权利要求1-6、7-8所述的任一项方法的步骤。