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

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

Info

Publication number
WO2024002143A1
WO2024002143A1 PCT/CN2023/103110 CN2023103110W WO2024002143A1 WO 2024002143 A1 WO2024002143 A1 WO 2024002143A1 CN 2023103110 W CN2023103110 W CN 2023103110W WO 2024002143 A1 WO2024002143 A1 WO 2024002143A1
Authority
WO
WIPO (PCT)
Prior art keywords
root certificate
server
client
certificate
root
Prior art date
Application number
PCT/CN2023/103110
Other languages
English (en)
French (fr)
Inventor
陈熙彩
张金峰
Original Assignee
阿里云计算有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里云计算有限公司 filed Critical 阿里云计算有限公司
Publication of WO2024002143A1 publication Critical patent/WO2024002143A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the present invention relates to the field of security technology, and in particular to a root certificate updating method, device, electronic equipment and computer-readable storage medium.
  • the client needs a root certificate to achieve the TLS handshake with the server.
  • the TLS root certificate generally has a validity period. After this time point, if the client TLS connection to the cloud cannot be achieved without updating the root certificate.
  • this problem generally does not exist, because the browser uses the root certificate of the computer, and the root certificate of the computer is generally updated by the operating system (taking the Windows system as an example, the Cryptographic Services within the system will be updated with the Windows Update synchronization, automatically update the root certificate).
  • the root certificate cannot be updated like a Windows computer, the device will not be able to connect to the Internet after the certificate expires.
  • the validity period is January 28, 2028.
  • devices with the old TLS root certificate preset will not be able to connect to the cloud via TLS.
  • Upgrading firmware through Over-the-Air Technology (OTA) is a solution, but the number of IoT devices with OTA capabilities is very limited. Therefore, another mechanism is needed to ensure that the root certificates in IoT devices can be updated regularly like windows, and to ensure that TLS connection functions are normal, so that most devices will not be unable to connect to the cloud one day, which may lead to major incidents, such as in a city On a certain day, all bus bicycles cannot be rented/returned, etc.
  • a root certificate update method In this method, the client (device) uploads a complete root certificate every time it establishes a connection, and the server compares the root certificate uploaded by the client with the newly deployed root certificate. Whether the certificates are the same, if they are different, a new root certificate will be issued.
  • This method has the following technical problems: 1. The client's root certificate is exposed on the public network, attracting unnecessary attacks; 2. The server determines whether the root certificate has expired, which aggravates the problem. Computing pressure on the server; 3. The client wastes bandwidth by uploading the complete root certificate.
  • the root certificate update method has technical problems such as insecurity, heavy computing pressure on the server, and waste of bandwidth, which have not yet been effectively solved.
  • embodiments of the present invention are expected to provide a root certificate update method, device, electronic device and computer-readable storage medium, which can solve the problems in the related art that the client's root certificate update method is insecure and the server has high computing pressure. technical issues of heavy traffic and wasted bandwidth.
  • An embodiment of the present invention provides a method for updating a root certificate, which includes: sending a first handshake request to the server when the currently stored first root certificate has not expired; and receiving a response from the server to the first handshake request.
  • the first reply message wherein the first reply message carries information about the second root certificate currently deployed by the server; after the handshake is successful and the connection is established according to the first reply message, according to the third
  • the information of the two root certificates determines whether the first root certificate and the second root certificate are consistent; if the first root certificate and the second root certificate are inconsistent, the currently stored first root certificate is The certificate is updated to the second root certificate.
  • An embodiment of the present invention also provides a root certificate updating method, including: receiving a first handshake request sent by a client, wherein the first handshake request carries first indication information, and the first indication information is used to Indicate that the first root certificate currently stored by the client has not expired; send a first reply message in response to the first handshake request to the client, and determine that the handshake is successful and establish a connection, wherein the first reply The message carries information about the currently deployed second root certificate; the information about the second root certificate is used by the client to determine whether the first root certificate and the second root certificate are consistent, and for the client to The terminal updates the first root certificate when the first root certificate and the second root certificate are inconsistent.
  • An embodiment of the present invention also provides a root certificate updating device, including: a first sending module, configured to send a first handshake request to the server when the currently stored first root certificate has not expired; a first receiving module , used to receive the first reply message from the server in response to the first handshake request, wherein the first reply message carries information about the second root certificate currently deployed by the server; the judgment module, After the handshake is successful and the connection is established according to the first reply message, it is used to determine whether the first root certificate and the second root certificate are consistent according to the information of the second root certificate; an update module is used to If the first root certificate is inconsistent with the second root certificate, the currently stored first root certificate is updated to the second root certificate.
  • a root certificate updating device including: a first sending module, configured to send a first handshake request to the server when the currently stored first root certificate has not expired; a first receiving module , used to receive the first reply message from the server in response to the first handshake request, wherein the first reply message carries information about the second root certificate currently
  • An embodiment of the present invention also provides a root certificate updating device, including: a second receiving module, configured to receive a first handshake request sent by the client, where the first handshake request carries first indication information, so The first indication information is used to indicate that the first root certificate currently stored by the client has not expired; the second sending module is used to send a first reply message in response to the first handshake request to the client, and It is determined that the handshake is successful and the connection is established, where the first reply message carries information about the currently deployed second root certificate; the information about the second root certificate is used by the client to determine whether the first root certificate is the same as the one currently deployed. Whether the second root certificate is consistent, and for the client to update the first root certificate if the first root certificate is inconsistent with the second root certificate.
  • Embodiments of the present invention provide an electronic device, including: a processor; a memory used to store instructions executable by the processor; wherein the processor is configured to execute the steps of any of the above methods.
  • Embodiments of the present invention provide a computer-readable storage medium. Instructions are stored on the computer-readable storage medium. When the instructions are executed by a processor, the steps of any of the above methods are implemented.
  • Embodiments of the present invention provide a root certificate updating method, device, electronic device and computer-readable storage medium, wherein the method includes: when the currently stored first root certificate has not expired, sending the first first root certificate to the server. Handshake request; receiving the first reply message from the server in response to the first handshake request, where the first reply message carries information about the second root certificate currently deployed by the server; in accordance with the first reply message After the handshake is successful and the connection is established, it is judged based on the information of the second root certificate whether the first root certificate and the second root certificate are consistent; if the first root certificate and the second root certificate are inconsistent, the currently stored The first root certificate is updated to the second root certificate.
  • the embodiment of the present invention improves the current handshake method between the client and the server.
  • the handshake carries new certificate information (for example, summary), and does not require the client to upload the complete root certificate, which improves security.
  • bandwidth is saved.
  • the client determines whether the current root certificate needs to be updated based on the information of the new certificate, which reduces the computing pressure on the server, thereby solving the insecurity of the root certificate update method in related technologies. , technical issues such as heavy computing pressure on the server and waste of bandwidth.
  • Figure 1 is a hardware structure block diagram of a computer terminal according to a root certificate update method according to an embodiment of the present application
  • Figure 2 is a schematic flow chart of a root certificate updating method provided by an embodiment of the present invention.
  • Figure 3 is a hardware structure block diagram of a server of a root certificate update method according to an embodiment of the present invention
  • Figure 4 is a schematic flow chart of another root certificate update method provided by an embodiment of the present invention.
  • Figure 5 is a schematic flow chart of a root certificate updating device provided by an embodiment of the present invention.
  • Figure 6 is a schematic flowchart of another root certificate updating apparatus provided by an embodiment of the present invention.
  • FIG. 1 is a hardware structure block diagram of a computer terminal of a root certificate updating method according to an embodiment of the present application.
  • the computer terminal 10 may include one or more (only one is shown in the figure) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) , a memory 104 for storing data, and a transmission device 106 for communication functions.
  • a processing device such as a microprocessor MCU or a programmable logic device FPGA
  • the computer terminal 10 may also include more or fewer components than shown in FIG. 1 , or have a different configuration than shown in FIG. 1 .
  • the memory 104 can be used to store software programs and modules of application software, such as the program instructions/modules corresponding to the client's root certificate update method in the embodiment of the present application.
  • the processor 102 runs the software programs and modules stored in the memory 104, thereby Execute various functional applications and data processing, that is, implement the above root certificate update method.
  • Memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
  • the memory 104 may further include memory located remotely relative to the processor 102, and these remote memories may be connected to the computer terminal 10 through a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.
  • the transmission device 106 is used to receive or send data via a network.
  • Specific examples of the above-mentioned network may include a wireless network provided by a communication provider of the computer terminal 10 .
  • the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station to communicate with the Internet.
  • the transmission device 106 may be a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet wirelessly.
  • RF Radio Frequency
  • the root certificate update method provided by the embodiment of this application can be applied to clients.
  • the clients include but are not limited to: clients of the Internet of Things platform, device management platforms, APPs, etc.
  • the application scenarios of the application embodiment may also include the root certificate update between server 1 and server 2, where server 1 is equivalent to the client and server 2 is equivalent to the server.
  • server 1 is equivalent to the client
  • server 2 is equivalent to the server.
  • the root certificate update method is applied to both ends, it is applicable, and There are no restrictions on specific scenarios.
  • the root certificate update method provided by the embodiment of this application can also be used: The first situation is that the CA authority issued a certificate by mistake or issued a fraudulent number.
  • the second case is when the private key of the server is leaked.
  • the root certificate needs to be updated to avoid malicious attacks.
  • the device declares in the packets transmitted on the Internet that it holds a root certificate that has become insecure, it may lead to more attacks.
  • the client in the embodiment of the present application does not need to have the OTA function.
  • OTA Over-the-Air Technology
  • the above root certificate update method includes the following steps:
  • the first handshake request may be a TLS handshake request, which is not subject to any limitation.
  • S204 Receive a first reply message from the server in response to the first handshake request, where the first reply message carries information about the second root certificate currently deployed by the server;
  • the information of the second root certificate includes but is not limited to: the digest of the second root certificate, the label of the second root certificate, etc., and is not limited in any way here.
  • the above-mentioned S204 only issues the latest root certificate information (for example, digest, label, etc.), and the bandwidth is lower.
  • the client updates the local root certificate based on the situation, and the service
  • the computing pressure on the client is distributed to each client, reducing the pressure on the server.
  • determining whether the first root certificate and the second root certificate are consistent based on the information of the second root certificate includes:
  • S11 Determine the digest of the first root certificate based on the root certificate request information predetermined with the server;
  • S12 Based on the digest of the first root certificate and the digest of the second root certificate, determine whether the first root certificate and the second root certificate are consistent.
  • updating the currently stored first root certificate to the second root certificate includes:
  • the above-mentioned second root certificate is issued by the server in clear text through the current connection.
  • the ciphertext method can also be used, but there is no limitation here.
  • S22 Receive the second root certificate issued by the server through the current connection, and replace the currently stored first root certificate with the second root certificate.
  • the method before requesting the server to issue the second root certificate, the method further includes:
  • the above describes the case where the client root certificate has not expired, and the following will describe the case where the client root certificate has expired.
  • the above root certificate update method also includes:
  • the above root certificate request information includes but is not limited to: productKey, deviceName, random number, signmethod and other information.
  • the above-mentioned information of the first root certificate includes but is not limited to: the summary of the first root certificate, the label of the first root certificate and other information.
  • S43 Determine the digest of the second root certificate based on the root certificate request information, and verify whether the determined digest of the second root certificate is consistent with the digest of the second root certificate carried in the second reply message;
  • the method further includes:
  • the certificate can no longer be used to verify the server's capabilities, but digital signature tools such as hash-based message authentication code (HmacSHA256) can be used to authenticate the server. The identity of the server is verified.
  • HmacSHA256 hash-based message authentication code
  • the client For example, the client generates a string (including a random number and the device's identity id); the client uses its own saved password to calculate a hash digest of the above string and obtains code1; the client transmits this to the server String; the server parses the string, obtains the client's identity id, queries the client's password from the backend database (consistent with the password stored in the client), and then uses this password to calculate the hash digest of the string, and obtains When code2 comes out, the client compares code1/code2. If they are consistent, the server is considered credible.
  • a string including a random number and the device's identity id
  • the client uses its own saved password to calculate a hash digest of the above string and obtains code1
  • the client transmits this to the server String
  • the server parses the string, obtains the client's identity id, queries the client's password from the backend database (consistent with the password stored in the client), and then uses this password to calculate the hash
  • S51 Receive the third root certificate issued by the server through the current connection, where the third root certificate is the root certificate redeployed by the server while maintaining the current connection;
  • the above third root certificate is issued by the server in clear text through the current connection. Since the above-mentioned client and server maintain a long connection, the server is trustworthy.
  • the server uses plain text when issuing the third root certificate, instead of using symmetric public key certificates pushed down by the server in related technologies. Key encryption increases the computing power overhead of the server/client, further saving computing power.
  • the above delivery method may also be a ciphertext method, which is not limited here.
  • the above-mentioned handshake method may be a TLS handshake.
  • the following uses the TLS handshake as an example to describe the embodiment of this application.
  • Scenario 3 The client root certificate has expired. Below are examples for each of these three situations. It mainly includes the following steps:
  • the root certificate update methods provided in this example include:
  • the client sends client_params, client_random, TLS version and cipher suite list for filtering to the server;
  • the server returns: server_random, server_params, TLS version, determined cipher suite method, and information (summary) of the second root certificate currently deployed by the server in the embodiment of this application;
  • S63 The client receives and determines whether the first root certificate and the second root certificate are consistent based on the information (digest) of the second root certificate. If the first root certificate and the second root certificate are inconsistent, the The currently stored first root certificate is updated to the second root certificate.
  • the root certificate update methods provided in this example include:
  • the client and server send client_params, client_random, TLS version and cipher suite list for filtering;
  • the server returns: server_random, server_params, TLS version, and determined cipher suite method;
  • the client establishes a connection with the server, selects an opportunity to receive the second root certificate sent by the server, and updates the currently stored first root certificate to the second root certificate based on the second root certificate.
  • the root certificate update methods provided in this example include:
  • the client and the server send client_params, client_random, TLS version and cipher suite list for filtering, first root certificate information (for example, digest) and root certificate request information;
  • first root certificate information for example, digest
  • the server returns: server_random, server_params, TLS version, determined cipher suite method, the second root certificate currently deployed by the server in the embodiment of this application, and the summary of the second root certificate;
  • the client receives, determines the digest of the second root certificate based on the root certificate request information, and verifies whether the determined digest of the second root certificate is the same as the digest of the second root certificate carried in the second reply message. Consistent; if the determined digest of the second root certificate is consistent with the digest of the second root certificate carried in the second reply message, the handshake is successful and the connection is established according to the second reply message, and the currently stored The first root certificate of is updated to the second root certificate.
  • a first handshake request is sent to the server; and a first reply message from the server in response to the first handshake request is received, where, The first reply message carries information about the second root certificate currently deployed by the server; after the handshake is successful and the connection is established according to the first reply message, it is determined based on the information about the second root certificate that the first root certificate is Whether the second root certificate is consistent; if the first root certificate is inconsistent with the second root certificate, update the currently stored first root certificate to the second root certificate. That is to say, the embodiment of the present invention improves the current handshake method between the client and the server.
  • the handshake carries new certificate information (for example, summary), and does not require the client to upload the complete root certificate, which improves security. At the same time, bandwidth is saved.
  • the client determines whether the current root certificate needs to be updated based on the information of the new certificate, which reduces the computing pressure on the server, thereby solving the insecurity in the root certificate update method in related technologies. , technical issues such as heavy computing pressure on the server and waste of bandwidth.
  • an embodiment of a root certificate update method is also provided. It should be noted that the steps shown in the flow chart of the accompanying drawings can be executed in a server architecture such as a set of server executable instructions, and, Although a logical sequence is shown in the flowcharts, in some cases the steps shown or described may be performed in a sequence different from that herein.
  • FIG. 3 is a hardware structure block diagram of the server of the root certificate update method according to the embodiment of the present invention.
  • the server 30 may include one or more (only one is shown in the figure) processors 302 (the processor 302 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), A memory 304 for storing data, and a transmission module 306 for communication functions.
  • processors 302 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA
  • a memory 304 for storing data
  • a transmission module 306 for communication functions.
  • the memory 304 can be used to store software programs and modules of application software, such as the program instructions/modules corresponding to the root certificate update method in the embodiment of the present invention.
  • the processor 302 executes various operations by running the software programs and modules stored in the memory 304.
  • Memory 304 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.
  • memory 304 may further include memory located remotely relative to processor 302, and these remote memories may be connected to server 30 via a network. Examples of the above-mentioned networks include but are not limited to the Internet, intranets, local area networks, mobile communication networks and combinations thereof.
  • the transmission device 306 is used to receive or send data via a network.
  • the above-mentioned specific example of the network may include a wireless network provided by the communication provider of the server 30 .
  • the transmission device 306 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station to communicate with the Internet.
  • the transmission device 306 may be a radio frequency (Radio Frequency, RF) module, which is used to communicate with the Internet wirelessly.
  • RF Radio Frequency
  • S402. Receive the first handshake request sent by the client, where the first handshake request carries first indication information, and the first indication information is used to indicate that the first root certificate currently stored by the client has not expired;
  • the above-mentioned clients include but are not limited to: Internet of Things platform, device management platform, APP, etc. Compared with clients with Over-the-Air Technology (OTA) function, this client does not need to have the OTA function.
  • the above-mentioned first handshake request may be a TLS handshake request, and there is no limitation here.
  • S404 Send a first reply message in response to the first handshake request to the client, and determine that the handshake is successful and the connection is established, where the first reply message carries information about the currently deployed second root certificate;
  • the information of the second root certificate is used by the client to determine whether the first root certificate is consistent with the second root certificate, and for the client to update the third root certificate if the first root certificate is inconsistent with the second root certificate.
  • S91 Receive the second handshake request sent by the client, where the second handshake request carries the second indication.
  • Information the second indication information is used to indicate that the first root certificate currently stored by the client has expired and the root certificate request information;
  • S92 Send a second reply message in response to the second handshake request to the client, where the second reply message carries the second root certificate currently deployed by the server and the digest of the second root certificate, For the client to determine the digest of the second root certificate based on the root certificate request information, and to verify whether the determined digest of the second root certificate is consistent with the digest of the second root certificate carried in the second reply message. , when the determined digest of the second root certificate is consistent with the digest of the second root certificate carried in the second reply message, the handshake is successful and the connection is established according to the second reply message, and the currently stored The first root certificate is updated to the second root certificate.
  • the above root certificate request information includes but is not limited to: productKey, deviceName, random number, signmethod and other information.
  • the above-mentioned information of the first root certificate includes but is not limited to: the summary of the first root certificate, the label of the first root certificate and other information.
  • the above method further includes:
  • an embodiment of a root certificate updating device for implementing the above method embodiment.
  • the device provided by the above embodiment of this application can be run on the client.
  • the device can be applied to a client, which includes but is not limited to: a client of an Internet of Things platform, a device management platform, an APP, etc.
  • the application scenarios of the embodiments of this application can also include the communication between server 1 and server 2.
  • Root certificate update, where server 1 is equivalent to the client and server 2 is equivalent to the server. As long as the root certificate update method is used at both ends, it is applicable and is not limited to specific scenarios.
  • the first handshake request may be a TLS handshake request, which is not subject to any limitation.
  • the first receiving module 54 is configured to receive a first reply message from the server in response to the first handshake request, where the first reply message carries information about the second root certificate currently deployed by the server;
  • the client sends a handshake request message to the server.
  • the server receives the handshake request message, it sends a reply message to the client.
  • the client processes the handshake result. If the handshake is successful, it means that the server can letter, the client and server establish a connection.
  • the judgment module 56 is also configured to determine the digest of the first root certificate based on the root certificate request information predetermined with the server; according to The digest of the first root certificate and the digest of the second root certificate are used to determine whether the first root certificate and the second root certificate are consistent.
  • the above determination module 56 determines whether the first root certificate and the second root certificate are consistent based on the digest of the first root certificate and the digest of the second root certificate, thereby further saving computing power.
  • the update module 58 is configured to update the currently stored first root certificate to the second root certificate when the first root certificate is inconsistent with the second root certificate.
  • the update module 58 is also configured to request the server to issue the second root certificate based on the digest of the second root certificate; receive The server issues the second root certificate through the current connection and replaces the currently stored first root certificate with the second root certificate.
  • the above delivery method may also be a ciphertext method, which is not limited here.
  • the above device before requesting the server to issue the second root certificate, the above device further includes: determining whether the current time meets the conditions for updating the root certificate, until the current time meets the conditions for updating the root certificate. Then, execute the module that requests the server to issue the second root certificate.
  • the client needs to choose an opportunity (such as a low task period) to request the server to issue the second root certificate based on its current task processing volume. Therefore, the embodiment of this application allows the client to establish a connection first and then choose an opportunity to update the root certificate. It does not force the client to update the root certificate first and then establish a connection. It is more suitable for the Internet of Things scenario and can avoid the impact of the server certificate update on the client's tasks. Because some IoT devices are very sensitive to the length of time it takes to establish a connection, such as sharing power bank and other tasks, if it is mandatory to complete the update of the root certificate before connecting to the cloud, it will undoubtedly greatly affect the user experience.
  • the above condition for updating the root certificate is that the client's current time is not within the update restrictions (for example, no upgrade will be checked within 1 year). Then if the client's current time happens to be within the update restrictions, there is no need to request the server. The second root certificate is issued, and the root certificate will be updated at a time point outside the update restrictions, thereby saving computing power.
  • the above describes the case where the client root certificate has not expired, and the following will describe the case where the client root certificate has expired.
  • the above-mentioned root certificate updating device further includes: when the currently stored first root certificate has expired, sending a second handshake request to the server, wherein the second handshake request carries the first root certificate. information and root certificate request information; receiving a second reply message from the server in response to the second handshake request, wherein the second reply message carries the second root certificate currently deployed by the server and the second root certificate.
  • the above device further includes determining that the handshake failed, and rejecting the second root certificate. Certificate module. Through this module, when the client root certificate expires, the root certificate can be safely updated without being based on the symmetric key.
  • the certificate can no longer be used to verify the server's capabilities, but digital signature tools such as hash-based message authentication code (HmacSHA256) can be used to authenticate the server.
  • digital signature tools such as hash-based message authentication code (HmacSHA256) can be used to authenticate the server.
  • the identity of the server is verified.
  • the client generates a string (including a random number and the device's identity id); the client uses its own saved password to calculate a hash digest of the above string and obtains code1; the client transmits this to the server String; the server parses the string, obtains the client's identity id, and checks it from the background database Query the client's password (which is consistent with the password stored in the client), then use this password to calculate the hash digest of the string, and get code2. The client compares code1/code2. If they are consistent, the server is considered trustworthy.
  • HmacSHA256 hash-based message authentication code
  • the above device further includes receiving a third root certificate issued by the server through the current connection; and updating the currently stored first root certificate to the third root certificate.
  • the above third root certificate is issued by the server in clear text through the current connection. Since the above-mentioned client and server maintain a long connection, the server is trustworthy.
  • the server uses plain text when issuing the third root certificate, instead of using symmetric public key certificates pushed down by the server in related technologies. Key encryption increases the computing power overhead of the server/client, further saving computing power.
  • the server deploys a new root certificate (the third root certificate mentioned above), and the existing connection is not affected.
  • the server issues a new root certificate to the client.
  • the client maintains a connection with the server and believes the content. Reliable, accepting new root certificates, further saving computing power.
  • the above delivery method may also be a ciphertext method, which is not limited here.
  • a first handshake request is sent to the server; and a first reply message from the server in response to the first handshake request is received, where, The first reply message carries information about the second root certificate currently deployed by the server; after the handshake is successful and the connection is established according to the first reply message, it is determined based on the information about the second root certificate that the first root certificate is Whether the second root certificate is consistent; if the first root certificate is inconsistent with the second root certificate, update the currently stored first root certificate to the second root certificate. That is to say, the embodiment of the present invention improves the current handshake method between the client and the server.
  • the handshake carries new certificate information (for example, summary), and does not require the client to upload the complete root certificate, which improves security. At the same time, bandwidth is saved.
  • the client determines whether the current root certificate needs to be updated based on the information of the new certificate, which reduces the computing pressure on the server, thereby solving the insecurity in the root certificate update method in related technologies. , technical issues such as heavy computing pressure on the server and waste of bandwidth.
  • an embodiment of a root certificate updating device for implementing the above method embodiment is also provided.
  • the device provided by the above embodiment of the present application can be run on a server.
  • FIG 6 is a schematic structural diagram of a root certificate updating device according to Embodiment 4 of the present invention. As shown in Figure 6, the root certificate updating device includes:
  • the second receiving module 62 is configured to receive the first handshake request sent by the client, where the first handshake request carries first indication information, and the first indication information is used to indicate the first root currently stored by the client.
  • the certificate has not expired;
  • the above-mentioned clients include but are not limited to: Internet of Things platform, device management platform, APP, etc. Compared with clients with Over-the-Air Technology (OTA) function, this client does not need to have the OTA function.
  • the above-mentioned first handshake request may be a TLS handshake request, and there is no limitation here.
  • the second sending module 64 is configured to send a first reply message in response to the first handshake request to the client, and determine that the handshake is successful and establish a connection, where the first reply message carries the currently deployed second root certificate.
  • Information The information of the second root certificate is used by the client to determine whether the first root certificate and the second root certificate are consistent, and for the client to update the first root certificate if the first root certificate is inconsistent with the second root certificate. The first certificate.
  • the information of the second root certificate includes but is not limited to: the digest of the second root certificate, the label of the second root certificate, etc., and is not limited in any way here.
  • the current handshake method between the client and the server is improved.
  • the new certificate information (for example, digest) is carried in the handshake.
  • the client does not need to upload the complete root certificate, which improves security and saves money at the same time.
  • Bandwidth in addition, in the embodiment of this application, the client determines whether the current root certificate needs to be updated based on the information of the new certificate, which reduces the computing pressure on the server, thereby solving the problem of insecurity and server-side computing problems in the root certificate update method in related technologies. Technological issues with high pressure and wasted bandwidth.
  • the above device further includes: receiving a second handshake request sent by the client, wherein the second handshake request carries second indication information, and the second indication information is used to instruct the client The first root certificate currently stored by the client has expired and the root certificate request information; and a second reply message in response to the second handshake request is sent to the client, where the second reply message carries the third root certificate currently deployed by the server.
  • Two root certificates and a digest of the second root certificate for the client to determine the digest of the second root certificate based on the root certificate request information, and to verify the determined digest of the second root certificate and the second reply message Whether the digest of the second root certificate carried in the second reply message is consistent, and if the determined digest of the second root certificate is consistent with the digest of the second root certificate carried in the second reply message, according to the second reply message
  • the message handshake is successful and the connection is established, and the module that updates the currently stored first root certificate to the second root certificate. Through this module, when the client root certificate expires, the root certificate can be safely updated without being based on the symmetric key.
  • the above root certificate request information includes but is not limited to: productKey, deviceName, random number, signmethod and other information.
  • the above-mentioned information of the first root certificate includes but is not limited to: the summary of the first root certificate, the label of the first root certificate and other information.
  • the above device further includes: a module that issues a third root certificate to the client through the current connection, where the third root certificate is maintained while the current The root certificate redeployed by the server during the connection process allows the client to update the currently stored first root certificate to the third root certificate.
  • the above third root certificate is issued by the server in clear text through the current connection. Since the above-mentioned client and server maintain a long connection, the server is trustworthy.
  • the server uses plain text when issuing the third root certificate, instead of using symmetric public key certificates pushed down by the server in related technologies. Key encryption increases the computing power overhead of the server/client, further saving computing power.
  • the server can also sense in time whether the root certificate (corresponding to the above-mentioned second root certificate) is safe, and can dynamically update the root certificate (corresponding to the above-mentioned second root certificate). Specifically, whether the root certificate deployed on the server has expired can be detected in a timely manner through news or email, so that the root certificate can be updated in a timely manner.
  • An embodiment of the present invention also provides an electronic device, including: a processor; and a program for storing instructions executable by the processor. Memory; wherein the processor is configured to perform the steps of any one of the above methods.
  • Embodiments of the present invention also provide a computer-readable storage medium.
  • the computer-readable storage medium stores instructions. When the instructions are executed by a processor, the steps of any of the above methods are implemented.
  • the disclosed technical content can be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the units is only a logical function division.
  • multiple units or components may be combined or may be Integrated into another system, or some features can be ignored, or not implemented.
  • the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the units or modules may be in electrical or other forms.
  • the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
  • each functional unit in various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit.
  • the above integrated units can be implemented in the form of hardware or software functional units.
  • the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it may be stored in a computer-readable storage medium.
  • the technical solution of the present invention is essentially or contributes to the existing technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium , including several instructions to cause a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present invention.
  • the aforementioned storage media include: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, magnetic disk or optical disk and other media that can store program code. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

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

Description

一种根证书更新方法、装置
本申请要求于2022年07月01日提交中国专利局、申请号为202210765538.6、申请名称为“一种根证书更新方法、装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及安全技术领域，尤其涉及一种根证书更新方法、装置、电子设备和计算机可读存储介质。
背景技术
安全传输层协议(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-Air Technology，简称为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-Air Technology，简称为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 (14)

  1. 一种根证书更新方法，其特征在于，包括：
    在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；
    接收所述服务端响应于所述第一握手请求的第一回复消息，其中，所述第一回复消息中携带有所述服务端当前部署的第二根证书的信息；
    在根据所述第一回复消息握手成功并建立连接后，根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致；
    在所述第一根证书与所述第二根证书不一致的情况下，将当前存储的所述第一根证书更新为所述第二根证书。
  2. 根据权利要求1所述的方法，其特征在于，所述第二根证书的信息包括所述第二根证书的摘要；
    根据所述第二根证书的信息判断所述第一根证书与所述第二根证书是否一致包括：根据与所述服务端预先确定的根证书请求信息确定所述第一根证书的摘要；根据所述第一根证书的摘要和所述第二根证书的摘要，判断所述第一根证书与所述第二根证书是否一致；
    将当前存储的所述第一根证书更新为所述第二根证书包括：根据所述第二根证书的摘要，请求所述服务端下发所述第二根证书；接收所述服务端通过当前连接下发的所述第二根证书，并将当前存储的所述第一根证书替换为所述第二根证书。
  3. 根据权利要求2所述的方法，其特征在于，在请求所述服务端下发所述第二根证书之前，所述方法还包括：
    判断当前时间是否满足更新根证书的条件，直至当前时间满足更新根证书的条件后，执行请求所述服务端下发所述第二根证书的步骤。
  4. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    在当前存储的第一根证书已过期的情况下，向服务端发送第二握手请求，其中，所述第二握手请求中携带有所述第一根证书的信息和根证书请求信息；
    接收所述服务端响应于所述第二握手请求的第二回复消息，其中，所述第二回复消息中携带有所述服务端当前部署的第二根证书和所述第二根证书的摘要；
    根据所述根证书请求信息确定所述第二根证书的摘要，并验证所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要是否一致；
    在所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要一致的情况下，根据所述第二回复消息握手成功并建立连接，以及将当前存储的所述第一根证书更新为所述第二根证书。
  5. 根据权利要求4所述的方法，其特征在于，在所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要不一致的情况下，确定握手失败，以及拒绝所述第二根证书。
  6. 根据权利要求1至5中任一项所述的方法，其特征在于，在握手成功并建立连接 之后，所述方法还包括：
    接收所述服务端通过当前连接下发的第三根证书，其中，所述第三根证书为在保持当前连接过程中所述服务端重新部署的根证书；
    将当前存储的所述第一根证书更新为所述第三根证书。
  7. 根据权利要求2或6所述的方法，其特征在于，所述第二根证书或所述第三根证书是所述服务端通过当前连接以明文方式下发的。
  8. 一种根证书更新方法，其特征在于，包括：
    接收客户端发送的第一握手请求，其中，所述第一握手请求中携带有第一指示信息，所述第一指示信息用于指示所述客户端当前存储的第一根证书未过期；
    向所述客户端发送响应于所述第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，所述第一回复消息中携带有当前部署的第二根证书的信息；所述第二根证书的信息用于所述客户端判断所述第一根证书与所述第二根证书是否一致，以及供所述客户端在所述第一根证书与所述第二根证书不一致的情况下更新所述第一根证书。
  9. 根据权利要求8所述的方法，其特征在于，所述方法还包括：
    接收所述客户端发送的第二握手请求，其中，所述第二握手请求中携带有第二指示信息，所述第二指示信息用于指示所述客户端当前存储的第一根证书已过期和根证书请求信息；
    向所述客户端发送响应于所述第二握手请求的第二回复消息，其中，所述第二回复消息中携带有所述服务端当前部署的第二根证书和所述第二根证书的摘要，以供所述客户端根据所述根证书请求信息确定所述第二根证书的摘要，并验证所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要是否一致，在所确定的所述第二根证书的摘要与所述第二回复消息中携带的所述第二根证书的摘要一致的情况下，根据所述第二回复消息握手成功并建立连接，以及将当前存储的所述第一根证书更新为所述第二根证书。
  10. 根据权利要求8或9所述的方法，其特征在于，在握手成功并建立连接之后，所述方法还包括：
    通过当前连接向所述客户端下发第三根证书，其中，所述第三根证书为在保持当前连接过程中所述服务端重新部署的根证书，以供所述客户端将当前存储的所述第一根证书更新为所述第三根证书。
  11. 一种根证书更新装置，其特征在于，包括：
    第一发送模块，用于在当前存储的第一根证书未过期的情况下，向服务端发送第一握手请求；
    第一接收模块，用于接收所述服务端响应于所述第一握手请求的第一回复消息，其中，所述第一回复消息中携带有所述服务端当前部署的第二根证书的信息；
    判断模块，用于在根据所述第一回复消息握手成功并建立连接后，根据所述第二根证 书的信息判断所述第一根证书与所述第二根证书是否一致；
    更新模块，用于在所述第一根证书与所述第二根证书不一致的情况下，将当前存储的所述第一根证书更新为所述第二根证书。
  12. 一种根证书更新装置，其特征在于，包括：
    第二接收模块，用于接收客户端发送的第一握手请求，其中，所述第一握手请求中携带有第一指示信息，所述第一指示信息用于指示所述客户端当前存储的第一根证书未过期；
    第二发送模块，用于向所述客户端发送响应于所述第一握手请求的第一回复消息，以及确定握手成功并建立连接，其中，所述第一回复消息中携带有当前部署的第二根证书的信息；所述第二根证书的信息用于所述客户端判断所述第一根证书与所述第二根证书是否一致，以及供所述客户端在所述第一根证书与所述第二根证书不一致的情况下更新所述第一根证书。
  13. 一种电子设备，其特征在于，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器被配置为执行权利要求1-7、8-10所述的任一项方法的步骤。
  14. 一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，其特征在于，所述指令被处理器执行时实现权利要求1-7、8-10所述的任一项方法的步骤。
PCT/CN2023/103110 2022-07-01 2023-06-28 一种根证书更新方法、装置 WO2024002143A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210765538.6A CN115150162B (zh) 2022-07-01 2022-07-01 一种根证书更新方法、装置
CN202210765538.6 2022-07-01

Publications (1)

Publication Number Publication Date
WO2024002143A1 true WO2024002143A1 (zh) 2024-01-04

Family

ID=83410947

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/103110 WO2024002143A1 (zh) 2022-07-01 2023-06-28 一种根证书更新方法、装置

Country Status (2)

Country Link
CN (1) CN115150162B (zh)
WO (1) WO2024002143A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115150162B (zh) * 2022-07-01 2024-06-04 阿里云计算有限公司 一种根证书更新方法、装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040168055A1 (en) * 2003-02-20 2004-08-26 Lord Robert B. Secure instant messaging system
CN103001965A (zh) * 2012-12-10 2013-03-27 北京星网锐捷网络技术有限公司 服务器证书更新方法及服务器
CN108989039A (zh) * 2017-05-31 2018-12-11 中兴通讯股份有限公司 证书获取方法及装置
CN110071911A (zh) * 2019-03-20 2019-07-30 北京龙鼎源科技股份有限公司 信息传输方法及装置、证书更新的方法及装置
CN115150162A (zh) * 2022-07-01 2022-10-04 阿里云计算有限公司 一种根证书更新方法、装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6816900B1 (en) * 2000-01-04 2004-11-09 Microsoft Corporation Updating trusted root certificates on a client computer
US11316846B2 (en) * 2017-08-30 2022-04-26 Ncr Corporation Security update processing
US10834071B2 (en) * 2018-02-14 2020-11-10 Zixcorp Systems, Inc. Harvesting and distributing a certificate based on a DNS name
US11283629B2 (en) * 2019-10-10 2022-03-22 Red Hat, Inc. Automated replacement of renewable server certificates
CN113326503A (zh) * 2021-06-04 2021-08-31 深圳前海微众银行股份有限公司 一种证书管理方法及计算设备
CN113472790B (zh) * 2021-06-30 2023-10-27 中国工商银行股份有限公司 基于https协议的信息传输方法、客户端及服务器

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040168055A1 (en) * 2003-02-20 2004-08-26 Lord Robert B. Secure instant messaging system
CN103001965A (zh) * 2012-12-10 2013-03-27 北京星网锐捷网络技术有限公司 服务器证书更新方法及服务器
CN108989039A (zh) * 2017-05-31 2018-12-11 中兴通讯股份有限公司 证书获取方法及装置
CN110071911A (zh) * 2019-03-20 2019-07-30 北京龙鼎源科技股份有限公司 信息传输方法及装置、证书更新的方法及装置
CN115150162A (zh) * 2022-07-01 2022-10-04 阿里云计算有限公司 一种根证书更新方法、装置

Also Published As

Publication number Publication date
CN115150162B (zh) 2024-06-04
CN115150162A (zh) 2022-10-04

Similar Documents

Publication Publication Date Title
CN109039436B (zh) 一种卫星安全接入认证的方法及系统
US11082403B2 (en) Intermediate network entity
CN106233637B (zh) 用于短距离无线数据传输的系统和方法
US10326730B2 (en) Verification of server name in a proxy device for connection requests made using domain names
US9237021B2 (en) Certificate grant list at network device
US20130111572A1 (en) Ip push platform and connection protocol in a push notification framework
JP5982389B2 (ja) クロスアクセスログインコントローラ
US20080072043A1 (en) Device management system and method of controlling the same
CN102111326A (zh) 在二层隧道协议虚拟专用网实现移动的方法、系统和装置
WO2024002143A1 (zh) 一种根证书更新方法、装置
US10873497B2 (en) Systems and methods for maintaining communication links
CN105791235A (zh) 一种配置信息下载方法和设备
CN111327650A (zh) 数据传输方法、装置、设备及存储介质
CN109936515B (zh) 接入配置方法、信息提供方法及装置
EP2693691B1 (en) Method and apparatus for initializing gateway in device management system
CN113056759A (zh) 供网络设备用来获得分布式账本技术网络的状态的可信状态表示的方法和系统
US20160057232A1 (en) Portal device management method, portal device and portal system
WO2023009929A1 (en) Certificate revocation at datacenters as a service
CN107888383B (zh) 登录认证方法及装置
US20200053578A1 (en) Verification of wireless network connection
TWI795148B (zh) 處理存取控制的裝置、方法及系統
CN114844674B (zh) 动态授权方法、系统、电子设备及存储介质
CN114553602B (zh) 一种软硬生命老化控制方法及装置
KR20140095050A (ko) 이동 통신 시스템에서 단일 사용자 승인을 지원하는 관리 방법 및 장치
CN118250090A (zh) 物联网平台信息处理方法及装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23830318

Country of ref document: EP

Kind code of ref document: A1