Digital certificate verification methods, devices, equipment, systems, and readable storage media

Abstract

This application discloses a method, apparatus, device, system, and readable storage medium for verifying digital certificates, belonging to the field of information and communication technology. The method includes: a second device sending a first certificate set to a first device, wherein the first certificate set is at least one of the certificate sets corresponding to each of at least two root certificates stored by the second device. The dormancy period of the target root certificate whose validity period is not the latest is covered by the working period of a backup secondary CA certificate signed by the target root certificate and the working periods of other secondary CA certificates. The first device verifies the legitimacy of at least one digital certificate of the second device based on the root certificates stored and trusted by the first device and the received first certificate set. In this application, the first device can verify the legitimacy of the digital certificate of the second device using the root certificates trusted by the first device. The first device does not need to upload other certificates, increase the number of certificate verification levels, or support new cryptographic algorithms, thus having a wide range of applications.

Description

Technical Field

[0001] This application relates to the field of information and communications technology (ICT), and in particular to methods, apparatus, devices, systems and readable storage media for verifying digital certificates. Background Technology

[0002] In the ICT field, devices hold digital certificates. Before two devices can communicate, they need to verify the validity of the digital certificates held by the other device. This verification process relies on root certificates, which have a limited validity period. To ensure the continuity of communication between the two devices, another root certificate with a later expiration date needs to be introduced before the first one expires. Therefore, there can be situations where at least two root certificates coexist.

[0003] Therefore, there is an urgent need to provide a digital certificate verification method so that devices can verify the legitimacy of their digital certificates when at least two root certificates coexist. Summary of the Invention

[0004] This application provides a method, apparatus, device, system, and readable storage medium for verifying digital certificates, enabling the device to verify the legitimacy of digital certificates when at least two root certificates coexist. The technical solution provided in this application is as follows.

[0005] Firstly, a method for verifying digital certificates is provided, applied to a first device storing root certificates trusted by the first device. The method includes: the first device first receiving a first certificate set sent by a second device, and then verifying the legitimacy of at least one digital certificate of the second device based on the root certificates trusted by the first device and the first certificate set. The second device stores at least two valid root certificates and certificate sets corresponding to each root certificate. The first certificate set is at least one of the certificate sets corresponding to each root certificate. A certificate set corresponding to a root certificate includes a secondary certification authority (CA) certificate signed by the root certificate, and a digital certificate of the second device generated based on the secondary CA certificate. The root certificates trusted by the first device are at least one of at least two root certificates. The certificate group corresponding to the target root certificate, which is not the one with the latest expiration date among at least two root certificates, includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate.

[0006] This application, when at least two root certificates coexist, uses the target root certificate to sign a backup secondary CA certificate and other secondary CA certificates, with the working periods of the backup secondary CA certificate and other secondary CA certificates covering the dormant period of the target root certificate. Therefore, even if a second device is deployed after the target root certificate enters its dormant period, the backup secondary CA certificate can still be used to sign the digital certificate of the second device, making it possible to verify the legitimacy of the second device's digital certificate through the target root certificate. For a first device that stores and trusts at least one of the at least two root certificates, even if the first device trusts the target root certificate, it only needs to use the root certificate trusted by the first device and the first certificate set received from the second device to verify the legitimacy of the second device's digital certificate. Therefore, the first device does not need to upload any additional certificates, increase the number of certificate verification levels, or support new cryptographic algorithms; that is, the first device does not need any modifications to verify the legitimacy of the second device's digital certificate when at least two root certificates coexist. This method not only has a wide range of applications but also reduces the cost of root certificate updates.

[0007] In one possible implementation, there are at least two backup secondary CA certificates, and the working periods of these at least two backup secondary CA certificates are consecutive or overlap. In this application, the relationship between the working periods of different backup secondary CA certificates can be flexibly configured.

[0008] In one possible implementation, the start time of the working period of the first backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate. The start time of the working period of the first backup secondary CA certificate can be flexibly set based on the end time of the working period of the last other secondary CA certificate.

[0009] In one possible implementation, the first device receives a first certificate set sent by the second device, including: the first device receiving a certificate set corresponding to the root certificate with the earliest expiration date among at least two root certificates sent by the second device. This implementation is suitable for situations where the first device trusts the root certificate with the earlier expiration date by default. In this implementation, the second device does not need to confirm the root certificate trusted by the first device to determine the first certificate set. In other words, the first device does not need to announce the root certificate trusted by the first device to the second device, making the verification process of the second device's digital certificate transparent and imperceptible to the first device. This implementation is suitable for scenarios where the first device and the second device cannot announce the root certificates they trust to each other.

[0010] In one possible implementation, before the first device receives the first certificate group sent by the second device, the method further includes: the first device sending at least one root certificate identifier to the second device, wherein the root certificate identifier indicates a root certificate trusted by the first device. Accordingly, the first device receiving the first certificate group sent by the second device includes: the first device receiving the certificate group corresponding to the root certificate trusted by the first device sent by the second device. This implementation is suitable for situations where the first device can announce the root certificates trusted by the first device to the second device. Then, the second device can select the certificate group corresponding to the root certificate trusted by the first device as the first certificate group from among the certificate groups corresponding to various root certificates, which helps to reduce the number of certificate groups sent to the first device, thereby reducing the resources required to send the first certificate group.

[0011] In one possible implementation, the method further includes: a first device sending a second certificate set to a second device. The second certificate set includes a secondary CA certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA certificate. The second certificate set is used by the second device to verify the legitimacy of at least one digital certificate of the first device. Besides the first device verifying the legitimacy of the second device's digital certificate, the second device can also verify the legitimacy of the first device's digital certificate; that is, the first and second devices mutually verify the legitimacy of the peer device's digital certificate. During this verification process, the first and second devices may not need to know which root certificate the peer device trusts and can directly send a default certificate set.

[0012] Secondly, a method for verifying digital certificates is provided. This method is applied to a second device, wherein the second device stores at least two valid root certificates and certificate sets corresponding to each root certificate. Each certificate set corresponding to a root certificate includes a secondary CA certificate signed by the root certificate and a digital certificate of the second device generated based on the secondary CA certificate. The method includes: the second device sending a first certificate set to a first device. The first certificate set is used by the first device to verify the legitimacy of at least one digital certificate of the second device. The first certificate set is at least one of the certificate sets corresponding to each root certificate. The secondary CA certificate included in the certificate set corresponding to the target root certificate (which has a non-latest expiration date among the at least two root certificates) is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate.

[0013] In one possible implementation, there are at least two backup secondary CA certificates, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

[0014] In one possible implementation, the start time of the working period of the first backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate.

[0015] In one possible implementation, before the second device sends the first certificate group to the first device, the method further includes: the second device uploading at least two root certificates and the certificate groups corresponding to each root certificate, wherein the upload time is within the working period of the secondary CA certificates included in the certificate group corresponding to the target root certificate. In this implementation, the secondary CA certificates included in the certificate groups corresponding to each target root certificate can be flexibly determined according to different upload times.

[0016] In one possible implementation, the second device sends a first certificate group to the first device, which includes: the second device sending the certificate group corresponding to the root certificate with the earliest validity period among at least two root certificates to the first device.

[0017] In one possible implementation, before the second device sends the first certificate group to the first device, the method further includes: the second device receiving at least one root certificate identifier sent by the first device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device;

[0018] The second device sends a first certificate group to the first device, including: the second device sending a certificate group corresponding to a root certificate trusted by the first device, wherein the root certificate trusted by the first device is at least one of at least two root certificates.

[0019] In one possible implementation, the method also includes:

[0020] The second device receives a second certificate set sent by the first device. The second certificate set includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate.

[0021] The second device verifies the legitimacy of at least one digital certificate of the first device based on a root certificate trusted by the first device and a second certificate set, wherein the root certificate trusted by the first device is at least one of at least two root certificates.

[0022] Thirdly, a digital certificate verification device is provided. The device is applied to a first device, which stores a root certificate trusted by the first device. The device includes:

[0023] The receiving module is used to receive a first certificate group sent by the second device. The second device stores at least two valid root certificates and certificate groups corresponding to each root certificate. The first certificate group is at least one of the certificate groups corresponding to each root certificate. A certificate group corresponding to a root certificate includes a secondary CA certificate signed by the root certificate and a digital certificate of the second device generated based on the secondary CA certificate.

[0024] The verification module is used to verify the legitimacy of a digital certificate of at least one second device based on a root certificate trusted by the first device and a first certificate group, wherein the root certificate trusted by the first device is at least one of at least two root certificates;

[0025] Among them, the certificate group corresponding to the target root certificate whose validity period is not the latest among at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate.

[0026] In one possible implementation, there are at least two backup secondary CA certificates, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

[0027] In one possible implementation, the start time of the working period of the first backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate.

[0028] In one possible implementation, the receiving module is used to receive the certificate group corresponding to the oldest of the two root certificates sent by the second device.

[0029] In one possible implementation, the apparatus further includes: a first sending module, configured to send at least one root certificate identifier to the second device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device;

[0030] The receiving module is used to receive the certificate group corresponding to the root certificate trusted by the first device, sent by the second device.

[0031] In one possible implementation, the device further includes:

[0032] The second sending module is used to send a second certificate group to the second device. The second certificate group includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate. The second certificate group is used by the second device to verify the legality of at least one digital certificate of the first device.

[0033] Fourthly, a digital certificate verification device is provided. The device is applied to a second device, which stores at least two valid root certificates and certificate sets corresponding to each root certificate. Each certificate set corresponding to a root certificate includes a secondary CA certificate signed by the root certificate, and a digital certificate for the second device generated based on the secondary CA certificate. The device includes:

[0034] The sending module is used to send a first certificate group to the first device. The first certificate group is used by the first device to verify the legality of the digital certificate of at least one second device. The first certificate group is at least one of the certificate groups corresponding to each root certificate.

[0035] Among them, the certificate group corresponding to the target root certificate whose validity period is not the latest among at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate.

[0036] In one possible implementation, there are at least two backup secondary CA certificates, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

[0037] In one possible implementation, the start time of the working period of the first backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate.

[0038] In one possible implementation, the device further includes:

[0039] The upload module is used to upload at least two root certificates and the certificate groups corresponding to each root certificate. The upload time is within the working period of the secondary CA certificate included in the certificate group corresponding to the target root certificate.

[0040] In one possible implementation, the sending module is used to send the certificate group corresponding to the root certificate with the earliest validity period among at least two root certificates to the first device.

[0041] In one possible implementation, the apparatus further includes: a first receiving module, configured to receive at least one root certificate identifier sent by the first device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device;

[0042] The sending module is also used to send the certificate group corresponding to the root certificate trusted by the first device to the first device, wherein the root certificate trusted by the first device is at least one of at least two root certificates.

[0043] In one possible implementation, the device further includes:

[0044] The second receiving module is used to receive a second certificate group sent by the first device. The second certificate group includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate.

[0045] The verification module is used to verify the legitimacy of at least one digital certificate of the first device based on a root certificate trusted by the first device and a second certificate group, wherein the root certificate trusted by the first device is at least one of at least two root certificates.

[0046] Fifthly, a digital certificate verification device is provided, comprising: a network interface, a memory, and a processor. The network interface is used for communication by the device, and the memory stores at least one instruction, which is loaded and executed by the processor to cause the device to perform the methods described in the preceding aspects.

[0047] Optionally, there may be one or more processors and one or more memories.

[0048] Alternatively, the memory can be integrated with the processor, or the memory can be set up separately from the processor.

[0049] In a sixth aspect, a communication system is provided, comprising a first device and a second device for communication connection, the first device being used to perform the method of the first aspect, and the second device being used to perform the method of the second aspect.

[0050] In a seventh aspect, a computer program (product) is provided, comprising: computer program code, which, when executed by a computer, causes the computer to perform the methods described in the foregoing aspects.

[0051] In an eighth aspect, a computer-readable storage medium is provided that stores a program or instructions, wherein when the program or instructions are run on a computer, the methods in the above aspects are performed.

[0052] In a ninth aspect, a chip is provided, including a processor for retrieving and executing instructions stored in a memory, causing a computer equipped with the chip to perform the methods described in the preceding aspects.

[0053] In a tenth aspect, another chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, the processor is used to execute code in the memory, and when the code is executed, a computer with the chip installed performs the methods in the above aspects. Attached Figure Description

[0054] Figure 1 A schematic diagram of the structure of a digital certificate verification system provided in an embodiment of this application;

[0055] Figure 2 A flowchart illustrating a digital certificate verification method provided in this application embodiment;

[0056] Figure 3 A schematic diagram illustrating the working period and dormancy period of a certificate provided in an embodiment of this application;

[0057] Figure 4 A schematic diagram illustrating the working period and dormancy period of another certificate provided in this application embodiment;

[0058] Figure 5 A schematic diagram illustrating the working period and dormancy period of another certificate provided in an embodiment of this application;

[0059] Figure 6 A schematic diagram illustrating the working period and dormancy period of another certificate provided in an embodiment of this application;

[0060] Figure 7A schematic diagram illustrating the working period and dormancy period of a certificate provided for an embodiment of this application;

[0061] Figure 8 This application provides an embodiment of an interaction diagram between a first device and a second device.

[0062] Figure 9 A flowchart illustrating a digital certificate verification method provided in an embodiment of this application;

[0063] Figure 10 A flowchart illustrating another digital certificate verification method provided in this application embodiment;

[0064] Figure 11 A flowchart illustrating another digital certificate verification method provided in this application embodiment;

[0065] Figure 12 A schematic diagram of the structure of a digital certificate verification device provided in an embodiment of this application;

[0066] Figure 13 A schematic diagram of another digital certificate verification device provided in an embodiment of this application;

[0067] Figure 14 This is a schematic diagram of the structure of a digital certificate verification device provided in an embodiment of this application. Detailed Implementation

[0068] The terminology used in the implementation section of this application is for the purpose of explaining specific embodiments of this application only, and is not intended to limit this application.

[0069] In the ICT field, public key infrastructure (PKI) architecture provides the foundation for the use of public key cryptography (PKC).

[0070] In a PKI architecture, there are at least two levels of CAs. The top-level CA is the Level 1 CA, also known as the root CA. Below the root CA are subordinate CAs, each consisting of at least a Level 2 CA, and possibly other levels (e.g., Level 3, Level 4, etc.). A CA holds a CA certificate and a private key, and the CA certificate has a certain validity period. A CA certificate includes a subject, the public key held by the CA, and a signature. The subject includes relevant information about the CA, and the public key corresponds to the private key held by the CA. That is, content signed using the private key held by the CA can be verified using the public key held by the CA.

[0071] The root CA holds a root CA certificate, also known as the root certificate. A root certificate includes a subject (i.e., information about the root CA), the public key held by the root CA, and a self-signed signature. Using the private key held by the root CA and a specific cryptographic algorithm, the information about the root CA and the public key held by the root CA are signed to obtain the self-signed signature. Because the root certificate includes a self-signed signature, it is also called a self-signed root certificate.

[0072] Each CA within a SubCA also holds its own CA certificate. A CA certificate held by a SubCA includes a subject (i.e., information about the SubCA), the SubCA's public key, and a signature. Using the private key held by the SubCA's parent CA and a specific cryptographic algorithm, the SubCA's information and public key are signed to obtain the signature included in the SubCA's CA certificate. The CA certificate held by the SubCA is thus a certificate signed by the parent CA certificate. For example, a second-level CA holds a second-level CA certificate; the signature in the second-level CA certificate is obtained by signing the root CA's private key and a specific cryptographic algorithm. Similarly, a third-level CA holds a third-level CA certificate; the signature in the third-level CA certificate is obtained by signing the second-level CA certificate.

[0073] Furthermore, the CA certificate of the lowest-level CA in at least two levels is also used to sign the device's digital certificate. This device digital certificate can also be called a device certificate, business certificate, etc., and it has a certain validity period. A device holds its own digital certificate and private key. The device's digital certificate includes a subject (i.e., information about the device), the device's public key (corresponding to its private key), and a signature (obtained by signing the device's information and public key using the lowest-level CA's private key and a specific cryptographic algorithm). For example, when the second-level CA is the lowest-level CA, the device's digital certificate is signed by the second-level CA certificate.

[0074] Based on the PKI architecture described above, certificate signing is nested, forming a certificate chain. The certificate chain sequentially includes the root certificate, SubCA certificates (at least including secondary CA certificates, and possibly tertiary CA certificates, etc.), and the device's digital certificate. It's important to note that the validity of each certificate in the certificate chain is verified by the next higher-level certificate that signed it. If the public key included in the higher-level certificate can verify the signature included in the certificate, then the certificate is considered valid. Taking a certificate chain including the root certificate, secondary CA certificates, and the device's digital certificate as an example, the validity of the device's digital certificate is verified by the secondary CA certificate, and the validity of the secondary CA certificate is verified by the root certificate.

[0075] For a device to be valid, it needs to trust at least one root CA and the root certificates held by that root CA. Based on this, the device trusts all certificates signed using the trusted root certificates. Accordingly, when verifying the validity of another device's digital certificate, the device needs to verify the validity of all certificates included in the certificate chain containing the other device's digital certificate, level by level, until it traces back to the root certificate and confirms its validity. According to Request for Comments (RFC) 5280 provided by the Internet Engineering Task Force (IETF), when all certificates in the certificate chain are valid, the validity of another device's digital certificate can be confirmed.

[0076] The verification methods for the legitimacy of certificates other than the root certificate have been explained above and will not be repeated here. When verifying the legitimacy of the root certificate, the device can confirm the legitimacy of the traced root certificate if it determines that the traced root certificate is a trusted root certificate. Alternatively, the device can use the public key included in the trusted root certificate to verify the signature included in the traced root certificate; if the signature can be verified, the traced root certificate is considered legitimate. In short, the verification of the legitimacy of a device's digital certificates relies on the root certificate.

[0077] It's important to note that the validity period of a SubCA certificate cannot exceed that of the root certificate, and the validity period of a device's digital certificate cannot exceed that of the SubCA certificate. Furthermore, because new device digital certificates with specific validity periods need to be signed frequently, root certificate updates cannot be performed after one root certificate expires (i.e., after one root certificate becomes invalid or expires). Instead, root certificate updates must be performed in advance to ensure the proper distribution of device digital certificates. Therefore, at least two root certificates can coexist.

[0078] For situations where at least two root certificates coexist, embodiments of this application provide a digital certificate verification method, which is applied to... Figure 1 The digital certificate verification system shown. For example... Figure 1 As shown, the system includes a first device 101 and a second device 102 connected by communication. The first device 101 has a communication function for interacting with the second device 102. The second device 102 has both a communication function and an upload function. The communication function is used for communication between the second device 102 and the first device 101, and the upload function is used for the second device 102 to obtain the various certificates required in the digital certificate verification method. The first device 101 may or may not have an upload function; this is not limited here. The first device 101 can verify the legitimacy of the digital certificate of the second device 102; the verification process is described below. Figures 2 to 11 The method embodiment shown.

[0079] This application provides a method for verifying digital certificates, for example, based on... Figure 1 The digital certificate verification system shown uses a method implemented through interaction between a first device and a second device. For example... Figure 2 As shown, the method includes the following steps 201 and 202.

[0080] Step 201: The second device sends the first certificate group to the first device.

[0081] The second device stores at least two valid root certificates and their corresponding certificate sets. The first certificate set sent by the second device to the first device is at least one of the certificate sets corresponding to each root certificate. The second device has an upload function; for example, the second device interacts with a management device to upload and store the at least two root certificates and their corresponding certificate sets. Exemplarily, the management device includes, but is not limited to, controllers, servers, and network management (network management) systems. The second device may also obtain and store the at least two root certificates and their corresponding certificate sets through other means, which are not limited here.

[0082] Next, we will explain at least two root certificates, the certificate groups corresponding to each root certificate, and the first certificate group.

[0083] First, we will explain at least two root certificates.

[0084] At least two root certificates are trusted by the second device. Each root certificate has a validity period. For example, the validity periods of different root certificates may be the same or different. As mentioned earlier, a root certificate can sign secondary CA certificates. The validity period of a root certificate can be divided into a working period and a dormant period, depending on whether it can sign a secondary CA certificate with a full validity period. During the working period, the root certificate can sign secondary CA certificates with a full validity period. During the dormant period, the root certificate cannot sign secondary CA certificates with a full validity period. Furthermore, after entering the dormant period, the private key of the root certificate is often sealed and deactivated; therefore, during the dormant period, the root certificate no longer signs secondary CA certificates.

[0085] Based on the explanation of the working period and dormancy period of the root certificate, it can be seen that the difference between the end time of the working period of the root certificate (i.e., the start time of the dormancy period) and the end time of the validity period of the root certificate (i.e., the end time of the dormancy period), which is the duration of the dormancy period, is equal to the full validity period of the secondary CA certificate signed by the root certificate. The validity period of the root certificate and the full validity period of the secondary CA certificate can be set according to actual needs or experience, and are not limited here.

[0086] For example, see Figure 3 The root certificate is valid from T to (T+30), with a total validity period of 30 years. The secondary CA certificate has a full validity period of 20 years. At any point between T and (T+10), the root certificate can sign a secondary CA certificate with a full validity period. For example, Figure 3 The secondary CA certificate shown has a validity period of (T+5) to (T+25), which is a secondary CA certificate with a full validity period. Therefore, T to (T+10) is the working period of the root certificate. However, at any time between (T+10) and (T+30), the root certificate cannot sign a secondary CA certificate with a full validity period, and therefore (T+10) to (T+30) is the dormant period of the root certificate.

[0087] Furthermore, the validity period of a secondary CA certificate signed by the root certificate can also be divided into an active period and a dormant period. During the active period, the secondary CA certificate can sign subordinate certificates with a full validity period. During the dormant period, the secondary CA certificate cannot sign subordinate certificates with a full validity period. The difference between the end time of the active period (i.e., the start time of the dormant period) and the end time of the validity period (i.e., the end time of the dormant period), i.e., the duration of the dormant period, is equal to the full validity period of the subordinate certificate signed by the secondary CA certificate. During the active period, the secondary CA certificate can sign subordinate certificates. During the dormant period, the secondary CA certificate no longer signs subordinate certificates. This subordinate certificate can be a tertiary CA certificate or a digital certificate for a second device.

[0088] For example, see still Figure 3 The validity period of a Level 2 CA certificate is from (T+5) to (T+25), with a total validity of 20 years. The full validity period of a lower-level certificate is 10 years. At any point between (T+5) and (T+15), the Level 2 CA certificate can sign a lower-level certificate with a full validity period; therefore, the working period of the Level 2 CA certificate is from (T+5) to (T+15). However, at any point between (T+15) and (T+25), the Level 2 CA certificate cannot sign a lower-level certificate with a full validity period; therefore, the dormant period of the Level 2 CA certificate is from (T+15) to (T+25).

[0089] Similarly, if other levels of CA certificates exist besides the Level 2 CA certificate (e.g., Level 3, Level 4, etc.), the validity period of these other levels of CA certificates can also be divided into a working period and a dormant period, which will not be elaborated here. However, since the digital certificate of the second device is not used to sign other certificates, the validity period of the digital certificate of the second device does not include the dormant period. In other words, the validity period of the digital certificate of the second device is equal to the working period.

[0090] Secondly, the certificate groups corresponding to each root certificate are explained.

[0091] A certificate set corresponding to a root certificate includes a secondary CA certificate signed by the root certificate, and a digital certificate for a second device generated based on the secondary CA certificate. In some implementations, the digital certificate for the second device can be directly signed by the secondary CA certificate, in which case the certificate set corresponding to the root certificate only includes the secondary CA certificate and the digital certificate for the second device. In other implementations, the secondary CA certificate signs other levels of CA certificates (e.g., third-level CA certificates, fourth-level CA certificates, etc.), and these other levels of CA certificates sign the digital certificate for the second device, in which case the certificate set corresponding to the root certificate includes not only the secondary CA certificate and the digital certificate for the second device, but also other levels of CA certificates. Thus, a root certificate and its corresponding certificate set form a complete certificate chain.

[0092] Among at least two root certificates, there exists a root certificate with the latest expiration date. The certificate set corresponding to this latest-expiring root certificate includes a secondary CA certificate signed by the latest-expiring root certificate, and a digital certificate for the second device generated based on the secondary CA certificate signed by the latest-expiring root certificate. The legitimacy of the digital certificate for the second device included in the certificate set corresponding to the latest-expiring root certificate can be verified by the latest-expiring root certificate.

[0093] As explained above, a root certificate will not sign secondary CA certificates during its dormant period. Therefore, the second device needs to be deployed before the latest-expiring root certificate enters its dormant period, that is, within the working period of the latest-expiring root certificate. Only then can the latest-expiring root certificate be used to sign secondary CA certificates and generate the digital certificate for the second device that can be verified by the latest-expiring root certificate. In some implementations, the deployment time of the second device is equal to the start time of the validity period of the latest-expiring root certificate. In other words, the latest-expiring root certificate is introduced when the second device is deployed. Furthermore, exemplarily, the time when the second device uploads the at least two root certificates and their corresponding certificate sets is the upload time, which is also within the working period of the latest-expiring root certificate. This ensures that the second device stores root certificates within their working period after the upload is completed, and these root certificates include at least the latest-expiring root certificate.

[0094] Of the at least two root certificates, the one with a non-latest expiration date is the target root certificate, and there must be at least one target root certificate. A target root certificate signs at least one backup secondary CA certificate and at least one other secondary CA certificate. The secondary CA certificates included in the certificate set corresponding to a target root certificate are among the backup secondary CA certificates signed by that target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, while the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate. Furthermore, the working periods of the backup secondary CA certificate and the other secondary CA certificates cover the dormancy period of the target root certificate.

[0095] As explained above, during the dormant period of a root certificate, that root certificate will not sign any secondary CA certificates. Therefore, the at least one backup secondary CA certificate and at least one other secondary CA certificate signed by a target root certificate are all secondary CA certificates signed by that target root certificate during its working period.

[0096] As explained above, the difference between the start and end times of a root certificate's dormancy period is the full validity period of the secondary CA certificate signed by that root certificate. Based on this, since the start time of the working period of other secondary CA certificates (i.e., the start time of their validity period) is earlier than the start time of the target root certificate's dormancy period, the end time of their validity period is also earlier than the end time of the target root certificate's dormancy period. Therefore, when only other secondary CA certificates exist, even if an other secondary CA certificate is signed at the last minute before the target root certificate enters its dormancy period, the validity period of that other secondary CA certificate cannot cover the target root certificate's dormancy period. Furthermore, since the validity period of other secondary CA certificates includes both the working period and the dormancy period, the working period of other secondary CA certificates is only a part of their validity period. Therefore, if the validity period of other secondary CA certificates cannot cover the target root certificate's dormancy period, the working period of other secondary CA certificates also cannot cover the target root certificate's dormancy period. In other words, during the target root certificate's dormancy period, a portion of the time cannot be covered by the working period of other secondary CA certificates. This period will be referred to as the uncovered period below for ease of explanation. It should be understood that during this uncovered period, there are no other secondary CA certificates in operation.

[0097] For example, see Figure 3 The dormancy period for the target root certificate is (T+10) to (T+30), while that for other secondary CA certificates (in... Figure 3The validity period of the secondary CA certificate (shown in the image) includes a working period from (T+5) to (T+15) and a dormant period from (T+15) to (T+25). It can be seen that the working period of other secondary CA certificates does not cover the dormant period of the target root certificate. Within the dormant period of the target root certificate, the uncovered period is from (T+15) to (T+30).

[0098] If a second device needs to be deployed during this uncovered period, the lack of other active secondary CA certificates during this period prevents the use of other secondary CA certificates to sign the second device's digital certificate. Therefore, a certificate chain cannot be formed, consisting of the target root certificate, other secondary CA certificates, and the second device's digital certificate, making it impossible to verify the legitimacy of the second device's digital certificate using the target root certificate.

[0099] To address this, this embodiment eliminates the uncovered period that occurs when only other secondary CA certificates are present by ensuring that the working periods of the backup secondary CA certificate and other secondary CA certificates cover the dormant period of the target root certificate. Therefore, regardless of when the second device is deployed during the dormant period of the target root certificate, there will always be a working secondary CA certificate, which is at least one of the backup secondary CA certificate and other secondary CA certificates. Thus, the digital certificate of the second device can be signed using a working secondary CA certificate at the time of deployment, forming a certificate chain including the target root certificate, the working secondary CA certificate, and the digital certificate of the second device. This allows the legitimacy of the digital certificate of the second device corresponding to a target root certificate to be verified by that target root certificate. Therefore, even after deploying the second device and introducing the root certificate with the latest expiration among at least two root certificates, the legitimacy of the digital certificate of the second device can still be verified using the target root certificate, which is not the latest expiration among at least two root certificates.

[0100] In an exemplary embodiment, if the number of backup secondary CA certificates is at least two, then the relationship between the working periods of the at least two backup secondary CA certificates can be either Relationship 1 or Relationship 2 as follows.

[0101] Relationship 1: The working periods of at least two backup secondary CA certificates are consecutive, or in other words, the working periods of different backup secondary CA certificates do not overlap. In other words, among at least two backup secondary CA certificates, for any two backup secondary CA certificates with adjacent working periods, the end time of the working period of the former backup secondary CA certificate is the start time of the working period of the latter backup secondary CA certificate.

[0102] For example, see Figure 4The working period for the first backup secondary CA certificate is from (T+10) to (T+20), and the working period for the second backup secondary CA certificate is from (T+20) to (T+30). The working periods of the first and second backup secondary CA certificates are consecutive and do not overlap.

[0103] Relationship 2: The working periods of at least two backup secondary CA certificates overlap. For example, in two backup secondary CA certificates with adjacent working periods, the start time of the working period of the preceding backup secondary CA certificate is earlier than or equal to the start time of the working period of the following backup secondary CA certificate, and the end time of the working period of the preceding backup secondary CA certificate is between the start and end times of the working period of the following backup secondary CA certificate.

[0104] For example, see Figure 5 The working period for the first backup secondary CA certificate is from (T+10) to (T+25), and the working period for the second backup secondary CA certificate is from (T+15) to (T+30). The working periods of the first and second backup secondary CA certificates overlap, specifically from (T+15) to (T+25).

[0105] For example, if there are at least three backup secondary CA certificates, the relationship between the working periods of the at least three backup secondary CA certificates can be only relationship one mentioned above, or only relationship two mentioned above, or it can include both relationship one and relationship two mentioned above. For example, the working period of the first backup secondary CA certificate is consecutive to the working period of the second backup secondary CA certificate, and the working period of the second backup secondary CA certificate overlaps with the working period of the third backup secondary CA certificate.

[0106] In at least one backup secondary CA certificate, the start time of the working period for the first backup secondary CA certificate includes, but is not limited to, the following two exemplary cases.

[0107] In scenario one, the start time of the working period of the first backup secondary CA certificate in at least one backup secondary CA certificate is equal to the start time of the dormant period of the target root certificate.

[0108] As mentioned earlier, the working period of the backup secondary CA certificate and the working periods of other secondary CA certificates need to cover the dormancy period of the target root certificate. Therefore, as long as the working period of the backup secondary CA certificate covers the dormancy period of the target root certificate, it can be guaranteed that the working periods of the backup secondary CA certificate and the working periods of other secondary CA certificates cover the dormancy period of the target root certificate.

[0109] Based on this, the start time of the dormancy period of the target root certificate is taken as the start time of the working period of the first backup secondary CA certificate. However, since the difference between the start and end times of the dormancy period of the target root certificate is equal to the full validity period of the backup secondary CA certificate, and the full validity period of the backup secondary CA certificate includes both the working period and the dormancy period, the working period of the first backup secondary CA certificate cannot cover the dormancy period of the target root certificate. Therefore, it is necessary to set up subsequent backup secondary CA certificates after the first backup secondary CA certificate. In other words, Case 1 applies when there are at least two backup secondary CA certificates.

[0110] For example, Figure 4 One implementation of scenario one is illustrated. In this scenario, the first backup secondary CA certificate is... Figure 4 The first backup secondary CA certificate is shown. The start time of the working period of the first backup secondary CA certificate is (T+10), which is the same as the start time (T+10) of the dormancy period of the target root certificate.

[0111] Scenario 2: The start time of the working period of the first backup secondary CA certificate among at least one backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate among the other secondary CA certificates.

[0112] In Scenario 2, compared to Scenario 1 above, the working period of the backup secondary CA certificate does not need to cover the dormancy period of the target root certificate. Instead, it only needs to cover the portion of the target root certificate's dormancy period that cannot be covered by other secondary CA certificates (i.e., the uncovered period mentioned above). In other words, the working period of the backup secondary CA certificate only needs to cover the period after the end of the working period of the last other secondary CA certificate. Because the period that the backup secondary CA certificate needs to cover is shorter in Scenario 2, the number of backup secondary CA certificates required may be reduced. Scenario 2 applies when there is at least one backup secondary CA certificate.

[0113] For example, Figure 6 One implementation of scenario two is shown. In this scenario, the last other secondary CA certificate is... Figure 6 Other secondary CA certificates shown, the first backup secondary CA certificate is Figure 6 The first backup secondary CA certificate is shown. The end time of the working period for the last other secondary CA certificate is (T+15), which is the same as the start time (T+15) of the working period for the first backup secondary CA certificate.

[0114] It should be understood that, because the validity period of a backup secondary CA certificate cannot exceed that of the target root certificate—meaning the end date of the backup secondary CA certificate's validity period must be earlier than or equal to the end date of the target root certificate's validity period—at least one backup secondary CA certificate may contain one without a complete validity period. In other words, although a backup secondary CA certificate is signed within the working period of the target root certificate, and the target root certificate is capable of signing a backup secondary CA certificate with a complete validity period within that period, it is not guaranteed that the backup secondary CA certificate signed by the target root certificate will necessarily have a complete validity period.

[0115] For example, see Figures 4 to 6 The second backup secondary CA certificate has only a working period and no dormant period, therefore it does not have a full validity period.

[0116] In an exemplary embodiment, before the second device sends the first certificate group to the first device, the method further includes: the second device uploading at least two root certificates and certificate groups corresponding to each root certificate.

[0117] When deploying the second device, at least two root certificates and their corresponding certificate sets need to be uploaded to it. For example, the difference between the upload time and the end date of the validity period of the reference root certificate needs to be greater than or equal to the validity period of the digital certificate of the second device. The reference root certificate is the root certificate whose validity period is adjacent to that of the root certificate with the latest validity period among the at least two root certificates. That is, the reference root certificate is the root certificate with the second latest validity period among the at least two root certificates. If the difference between the upload time and the end date of the validity period of the reference root certificate is less than the validity period of the digital certificate of the second device, it will result in the inability to sign a digital certificate for the second device with a full validity period. In some implementations, the start date of the dormancy period of the reference root certificate is used as the upload time. Of course, the upload time can be set according to actual needs or experience, and is not limited here.

[0118] Specifically, the upload time must fall within the validity period of the secondary CA certificate included in the certificate group corresponding to the target root certificate. In other words, the secondary CA certificate that was signed by the target root certificate will be used as the secondary CA certificate included in the certificate group corresponding to the target root certificate, depending on which secondary CA certificate the upload time falls within.

[0119] In some implementations, if the working periods of different backup secondary CA certificates are consecutive, and the upload time falls within the working period of only one backup secondary CA certificate, then this backup secondary CA certificate can be used as the secondary CA certificate included in the certificate group corresponding to the target root certificate. For example, see... Figure 4If the upload time is between (T+10) and (T+20), the first backup secondary CA certificate is included in the certificate group corresponding to the target root certificate. The certificate group corresponding to the target root certificate then includes the first backup secondary CA certificate and the digital certificate of the second device generated based on the first backup secondary CA certificate. If the upload time is between (T+20) and (T+30), the second backup secondary CA certificate is included in the certificate group corresponding to the target root certificate. The certificate group corresponding to the target root certificate then includes the second backup secondary CA certificate and the digital certificate of the second device generated based on the second backup secondary CA certificate.

[0120] In other implementations, the working periods of different backup secondary CA certificates overlap, meaning the upload time may fall within the working periods of different backup secondary CA certificates. Therefore, a backup secondary CA certificate can be randomly selected from among the different backup secondary CA certificates as the secondary CA certificate included in the certificate group corresponding to the target root certificate. For example, see... Figure 5 If the upload time is between (T+15) and (T+25), it is within the working period of both the first backup secondary CA certificate and the second backup secondary CA certificate. Therefore, either the first backup secondary CA certificate or the second backup secondary CA certificate can be selected as the secondary CA certificate included in the certificate group corresponding to the target root certificate.

[0121] See Figure 7 , Figure 7 The diagram illustrates a scenario with three root certificates, whose expiration dates, from earliest to latest, are: Root Certificate A, Root Certificate B, and Root Certificate C. Therefore, the target root certificates are Root Certificate A and Root Certificate B, the root certificate with the latest expiration date is Root Certificate C, and the reference root certificate is Root Certificate B. Root Certificate A has a working period from T to (T+10), and a dormant period from (T+10) to (T+30). During Root Certificate A's working period, backup secondary CA certificates X1 and X2 are signed. Backup secondary CA certificate X1 has a working period from (T+10) to (T+20), and backup secondary CA certificate X2 has a working period from (T+20) to (T+30). The working period of root certificate B is from (T+10) to (T+20), and its dormancy period is from (T+20) to (T+40). During the working period of root certificate B, backup secondary CA certificates Y1 and Y2 are signed. The working period of backup secondary CA certificate Y1 is from (T+20) to (T+30), and the working period of backup secondary CA certificate Y2 is from (T+30) to (T+40). The working period of root certificate C is from (T+20) to (T+30), and its dormancy period is from (T+30) to (T+50).

[0122] The difference between the upload time and the end time of the validity period of root certificate B (T+40) can be greater than or equal to the validity period of the digital certificate of the second device. Taking a validity period of 10 years for the digital certificate of the second device as an example, the upload time can be earlier than (T+30). Here, taking an upload time between (T+20) and (T+30) as an example, the process of the second device uploading at least two root certificates and the certificate groups corresponding to each root certificate is explained.

[0123] For root certificate A, since the upload time falls within the working period of the backup secondary CA certificate X2, the certificate group corresponding to root certificate A includes the secondary CA certificate of the backup secondary CA certificate X2. The certificate group corresponding to root certificate A also includes the digital certificate M of the second device generated based on the backup secondary CA certificate X2. Therefore, the second device uploads root certificate A, backup secondary CA certificate X2, and the digital certificate M of the second device, forming the certificate chain A corresponding to root certificate A.

[0124] For root certificate B, since the upload time falls within the working period of the backup secondary CA certificate Y1, the certificate group corresponding to root certificate B includes the secondary CA certificate of the backup secondary CA certificate Y1. The certificate group corresponding to root certificate B also includes the digital certificate N of the second device generated based on the backup secondary CA certificate Y1. Therefore, the second device uploads root certificate B, backup secondary CA certificate Y1, and the digital certificate N of the second device, forming the certificate chain B corresponding to root certificate B.

[0125] For root certificate C, since the upload time falls within the working period of root certificate C, root certificate C is signed to obtain a secondary CA certificate, and a digital certificate Q for the second device is generated based on this secondary CA certificate. Accordingly, the second device uploads root certificate C, the secondary CA certificate, and the digital certificate Q of the second device, forming a certificate chain C corresponding to root certificate C.

[0126] Furthermore, an explanation of the first certificate group will be provided.

[0127] As previously mentioned, the first certificate group is at least one of the certificate groups corresponding to each root certificate. In an exemplary embodiment, the first certificate group includes, but is not limited to, the following three types.

[0128] Type 1: The first certificate group is the certificate group corresponding to the root certificate with the earliest expiration among at least two root certificates. Then, the second device sending the first certificate group to the first device includes: the second device sending the certificate group corresponding to the root certificate with the earliest expiration.

[0129] Type 1 applies to scenarios where the first device trusts the root certificate with the earliest expiration date by default. For example, the first device only trusts the root certificate with the earliest expiration date. Another example is that the first device trusts the root certificate with the earliest expiration date, but also trusts at least one of the root certificates with expiration dates that are not the earliest.

[0130] Type 2, where the target root certificate is the certificate set corresponding to a second trusted root certificate. Before the second device sends the first certificate set to the first device, the method further includes: the second device receiving at least one root certificate identifier sent by the first device. A root certificate identifier indicates a root certificate trusted by the first device. The second device sending the first certificate set to the first device includes: the second device sending the certificate set corresponding to the root certificate trusted by the first device.

[0131] In this embodiment, a root certificate identifier uniquely indicates a root certificate trusted by the first device. For example, the information constituting the root certificate identifier includes, but is not limited to, the identifier of the root CA holding the root certificate, and the version identifier of the root certificate. For instance, if the identifier of the root CA holding the root certificate is CompanyA, then the version identifiers of the various root certificates held by this root CA are V1, V2, and so on. Therefore, the root certificate identifier of the root certificate with the earliest validity period held by this root CA can be CompanyA V1, the root certificate identifier of the root certificate with the second earliest validity period held by this root CA can be CompanyA V2, and so on. Of course, the embodiments of this application do not limit the representation of the root certificate identifier, as long as it ensures that the root certificate identifier can uniquely indicate a root certificate trusted by the first device.

[0132] For example, the second device receives at least one root certificate identifier sent by the first device via a certain security protocol. Through this security protocol, the first device sends a first message to the second device, carrying at least one root certificate identifier indicating a root certificate trusted by the first device in the target field of the first message. Furthermore, when the second device sends a first certificate group to the first device, the second device carries the first certificate group in a second message.

[0133] In some implementations, the security protocol includes, but is not limited to, the Transport Layer Security (TLS) protocol. For example, this security protocol is TLS version 1.3. Accordingly, the first message is the client handshake message ClientHello{}, with the target field being the extended certificate authentication field ext{certificate_authorities{}}. The second message is the server certificate message ServerCertificate{}.

[0134] For example, Figure 8An exemplary process for interaction between a first device and a second device is illustrated. The first device sends a first message to the second device, `ClientHello{ext{certificate_authorities{CompanyA V1}}}`, and the second device determines, based on this first message, that the root certificate trusted by the first device is the root certificate indicated by `CompanyA V1`. The second device then sends a second message to the first device, `ServerCertificate{certificate group 1 corresponding to the root certificate indicated by CompanyA V1}`, where certificate group 1 includes: a secondary CA certificate signed by the root certificate indicated by CompanyA V1, and a digital certificate of the second device generated based on this secondary CA certificate.

[0135] In some implementations, if the second device determines, based on at least one root certificate identifier, that the first device trusts at least two root certificates, then the second device selects the certificate set corresponding to the root certificate with the latest expiration date from the root certificates trusted by the first device as the first certificate set, and sends the first certificate set to the first device. This implementation allows the first certificate set to correspond to the root certificate with the latest expiration date, which is beneficial for improving security. Of course, the second device may also randomly select one or more certificate sets corresponding to root certificates trusted by the first device as the first certificate set.

[0136] In addition to determining the root certificate trusted by the first device based on at least one root certificate identifier sent by the first device, the second device can also determine the root certificate trusted by the first device through other means. For example, the management device stores the root certificate trusted by the first device. The second device can send a query request to the management device, which carries the device identifier of the first device. Based on the query request, the management device returns the root certificate trusted by the first device to the second device, thereby enabling the second device to determine the root certificate trusted by the first device.

[0137] Type 3: The first certificate group is the certificate group corresponding to each root certificate. Then, the second device sends the first certificate group to the first device, which includes: the second device sending the certificate groups corresponding to each root certificate to the first device.

[0138] In Type 3, the second device does not need to select the first certificate group from the certificate groups corresponding to each root certificate. Instead, it directly uses the certificate groups corresponding to each root certificate as the first certificate group and sends it to the first device.

[0139] In summary, the second device can determine the first certificate group according to any one of type one to type three, and send the first certificate group to the first device.

[0140] Step 202: The first device receives a first certificate group sent by the second device, and verifies the legitimacy of at least one digital certificate of the second device based on the root certificate trusted by the first device and the first certificate group.

[0141] After the first device receives the first certificate set sent by the second device, it first verifies the legitimacy of the secondary CA certificates included in the first certificate set based on the root certificate trusted by the first device. That is, it confirms whether the public key included in the root certificate trusted by the first device can verify the signature of the secondary CA certificates included in the first certificate set. If the signature can be verified, it indicates that the secondary CA certificates included in the first certificate set are legitimate.

[0142] In some implementations, the number of first certificate groups is one (for example, the second device may determine the first certificate group according to type one or type two in step 201, which may result in one first certificate group). The first device then verifies the legitimacy of the secondary CA certificates included in this first certificate group based on the root certificate trusted by the first device. In other implementations, the number of first certificate groups is at least two (for example, the second device may determine the first certificate group according to type two or type three in step 201, which may result in at least two first certificate groups). The first device can randomly select one first certificate group from at least two first certificate groups, and after verifying the legitimacy of the secondary CA certificates included in the selected first certificate group, determine that the secondary CA certificates included in the first certificate group are legitimate. Alternatively, the first device can also iterate through each first certificate group, and after verifying that all secondary CA certificates included in all first certificate groups are legitimate, determine that the secondary CA certificates included in the first certificate group are legitimate.

[0143] After verifying the legitimacy of the secondary CA certificates included in the first certificate set, the first device then verifies the legitimacy of the second device's digital certificate based on the legitimate secondary CA certificates. This means confirming whether the public key included in the legitimate secondary CA certificate can be used to verify the signature included in the second device's digital certificate. For example, can the public key included in the legitimate secondary CA certificate directly verify the signature included in the second device's digital certificate? Or, can the public key included in the legitimate secondary CA certificate verify the signature included in other levels of CA certificates (such as tertiary CA certificates, etc.), and if so, can the public keys included in those other levels of CA certificates verify the signature included in the second device's digital certificate? This achieves the verification of the legitimacy of the second device's digital certificate.

[0144] For example, if the first device verifies the validity of the second device's digital certificate, the first device can communicate with the second device based on the second device's digital certificate. For instance, the second device sends information signed with its private key to the first device. The first device can then verify the signature using the second device's public key included in the second device's digital certificate, thereby achieving secure communication with the second device. Conversely, if the first device verifies the second device's digital certificate as invalid, the first device will no longer communicate with the second device.

[0145] Therefore, the first device only needs to use the root certificate it trusts and receive the first certificate set sent by the second device to verify the digital certificate of the second device. During this verification process, the first device does not need to upload any additional certificates, nor does it need to increase the number of certificate verification levels or support new cryptographic algorithms. In summary, this embodiment of the application enables the first device to verify the legitimacy of the digital certificate of the second device when at least two root certificates coexist, without making any modifications to the first device.

[0146] The verification method provided in this application has strong applicability and is applicable to scenarios including but not limited to: the first device cannot upload, the first device has difficulty or slow upload, the certificate verification level of the first device cannot be increased, the first device cannot support multiple signature algorithms, etc.

[0147] Furthermore, in an exemplary embodiment, the method further includes: a first device sending a second certificate set to a second device, the second certificate set including a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate. The second device receives the second certificate set and verifies the legitimacy of at least one digital certificate of the first device based on the root certificate trusted by the first device and the second certificate set.

[0148] The second certificate set is at least one of the certificate sets corresponding to the root certificates trusted by the first device. Since the root certificates trusted by the first device are at least one of at least two root certificates stored by the second device, regardless of which root certificate the first device selects from its trusted root certificates and sends the certificate set corresponding to the selected root certificate as the second certificate set to the second device, the second device can verify the legitimacy of the first device's digital certificate based on the root certificates trusted by the first device and the second certificate set. The method by which the first device determines the second certificate set is described above, and the method by which the second device verifies the legitimacy of the first device's digital certificate is described above, and will not be repeated here.

[0149] For example, during the process of determining the second certificate group, the first device may receive a root certificate identifier sent by the second device to indicate the root certificates trusted by the second device, thereby designating the certificate group corresponding to the root certificates trusted by the second device as the second certificate group. For example, the first device receives at least one root certificate identifier sent by the second device through a certain security protocol. Through this security protocol, the second device may send a third message to the first device, carrying at least one root certificate identifier indicating the root certificates trusted by the second device in the target field of the third message. When the first device sends the second certificate group to the second device, the first device carries the second certificate group in a fourth message.

[0150] In some implementations, the security protocol includes, but is not limited to, TLS version 1.3. Accordingly, the third message is a CertificateRequest message (CertificateRequest{}), with the target field being the extended certificate authentication field ext{certificate_authorities{}}. The second message is a ClientCertificate message (ClientCertificate{}).

[0151] For example, Figure 8 An exemplary process for interaction between a first device and a second device is illustrated. The second device sends a third message to the first device: `CertificateRequest{ext{certificate_authorities{CompanyA V1,CompanyA V2}}}`. Based on this third message, the first device determines that the root certificates trusted by the second device are the root certificates indicated by `CompanyA V1` and `CompanyA V2`. Correspondingly, the first device sends a fourth message to the second device: `ClientCertificate{Certificate group 2 corresponding to the root certificate indicated by `CompanyA V1`}`. Certificate group 2 corresponding to the root certificate indicated by `CompanyA V1` includes: a secondary CA certificate signed by the root certificate indicated by `CompanyA V1`, and a digital certificate of the first device generated based on this secondary CA certificate.

[0152] Next, taking the example of devices A and B, and valid root certificates including both new and old root certificates, we will illustrate the verification process of digital certificates between devices A and B.

[0153] In the first scenario, device A is the older device, trusting only the old root certificate. Device A corresponds to the first device mentioned above, and the first device only trusts the root certificate with the earliest expiration date. Device B is the newer device, trusting both the old and new root certificates. Device B corresponds to the second device mentioned above.

[0154] See Figure 9Device A stores the old root certificate, secondary CA certificate P1 (obtained by normally signing the old root certificate), and old digital certificate A1 of device A (obtained by signing secondary CA certificate P1). Device B stores the old root certificate, backup secondary CA certificate S1 (obtained by additionally signing the old root certificate), and old digital certificate B1 of device B (obtained by signing backup secondary CA certificate S1). Device B also stores the new root certificate, secondary CA certificate S2 (obtained by normally signing the new root certificate), and new digital certificate B2 of device B (obtained by signing secondary CA certificate S2).

[0155] Before the old root certificate expires, device A sends a secondary CA certificate P1 and an old digital certificate A1 to device B. Device B verifies the legitimacy of the secondary CA certificate P1 using the old root certificate, and verifies the legitimacy of the old digital certificate A1 using the secondary CA certificate P1.

[0156] Before the old root certificate expires, device B sends a backup secondary CA certificate S1 and an old digital certificate B1 to device A. Device A verifies the legitimacy of the backup secondary CA certificate S1 using the old root certificate, and verifies the legitimacy of the old digital certificate B1 using the backup secondary CA certificate S1.

[0157] After the old root certificate expires, device A stops operating and goes offline, and device A no longer interacts with device B.

[0158] In the second scenario, both Device A and Device B are new devices, and both trust the old root certificate and the new root certificate, corresponding to the second device mentioned above.

[0159] See Figure 10 Device A stores the old root certificate, a backup secondary CA certificate P2 (obtained by additional signing of the old root certificate), and Device A's old digital certificate A2 (obtained by signing the backup secondary CA certificate P2). Device A also stores the new root certificate, a secondary CA certificate P3 (obtained by normal signing of the new root certificate), and Device A's new digital certificate A3 (obtained by signing the secondary CA certificate P3). The certificates stored in Device B are the same as in the first case, and will not be described further here.

[0160] Before the old root certificate expires, device A sends a backup secondary CA certificate P2 and an old digital certificate A2 to device B. Device B verifies the legitimacy of the backup secondary CA certificate P2 using the old root certificate, and verifies the legitimacy of the old digital certificate A2 using the backup secondary CA certificate P2.

[0161] Before the old root certificate expires, device B sends a backup secondary CA certificate S1 and an old digital certificate B1 to device A. Device A verifies the legitimacy of the backup secondary CA certificate S1 using the old root certificate, and verifies the legitimacy of the old digital certificate B1 using the backup secondary CA certificate S1.

[0162] After the old root certificate expires, device A sends a secondary CA certificate P3 and a new digital certificate A3 to device B. Device B verifies the legitimacy of the secondary CA certificate P3 using the new root certificate, and verifies the legitimacy of the new digital certificate A3 using the secondary CA certificate P3.

[0163] After the old root certificate expires, device B sends a secondary CA certificate S2 and a new digital certificate B2 to device A. Device A verifies the validity of the secondary CA certificate S2 using the new root certificate, and verifies the validity of the new digital certificate B2 using the secondary CA certificate S2.

[0164] In the third scenario, both devices A and B are old devices, and both only trust the old root certificate, corresponding to the first device mentioned above. The first device only trusts the root certificate with the earliest validity period.

[0165] See Figure 11 The certificate stored on device A is the same as in the first case, and will not be described again here. Device B stores the old root certificate, the secondary CA certificate S3 (obtained by signing the old root certificate normally), and the old digital certificate B3 of device B (obtained by signing the secondary CA certificate S3).

[0166] Before the old root certificate expires, device A sends a secondary CA certificate P1 and an old digital certificate A1 to device B. Device B verifies the legitimacy of the secondary CA certificate P1 using the old root certificate, and verifies the legitimacy of the old digital certificate A1 using the secondary CA certificate P1.

[0167] Before the old root certificate expires, device B sends a secondary CA certificate S3 and an old digital certificate B3 to device A. Device A verifies the legitimacy of the secondary CA certificate S3 using the old root certificate, and verifies the legitimacy of the old digital certificate B3 using the secondary CA certificate S3.

[0168] After the old root certificate expired, both device A and device B stopped operating and went offline, and no longer interacted with each other.

[0169] It is important to emphasize that in the first scenario, device A verifies the backup secondary CA certificate S1, which is additionally signed by the old root certificate. As mentioned earlier, device A verifies the legitimacy of the backup secondary CA certificate S1 using the old root certificate, and verifies the legitimacy of the old digital certificate B1 using the backup secondary CA certificate S1. In the third scenario, device A verifies the secondary CA certificate S3, which is normally signed by the old root certificate. As mentioned earlier, device A verifies the legitimacy of the secondary CA certificate S3 using the old root certificate, and verifies the legitimacy of the old digital certificate B3 using the secondary CA certificate S3. Therefore, the process of device A verifying the legitimacy of the second device's digital certificate (i.e., the old digital certificate B3) based on the normally signed secondary CA certificate of the old root certificate and the process of device A verifying the legitimacy of the second device's digital certificate (i.e., the old digital certificate B1) based on the additionally signed backup secondary CA certificate of the old root certificate involves the exact same number of certificate levels verified by device A. In other words, device A does not need to increase the number of certificate verification levels. Furthermore, in both processes, device A uses the old root certificate that it trusts. Therefore, device A does not need to support any cryptographic algorithms other than those corresponding to the old root certificate in these two processes.

[0170] In summary, in the case of at least two root certificates coexisting, the present application's embodiments use the target root certificate to sign backup secondary CA certificates and other secondary CA certificates before the target root certificate (which has a validity period not the latest) enters its dormant period. Furthermore, the working periods of the backup secondary CA certificate and the other secondary CA certificates cover the dormant period of the target root certificate. Therefore, even if a second device is deployed after the target root certificate enters its dormant period, the backup secondary CA certificate can still be used to sign the digital certificate of the second device, thus making it possible to verify the legitimacy of the second device's digital certificate through the target root certificate.

[0171] For a first device that stores and trusts at least one of the two root certificates, even if the first device trusts the target root certificate, it only needs to use the root certificate it trusts and the first certificate set received from the second device to verify the legitimacy of the second device's digital certificate. Therefore, the first device does not need to upload any additional certificates, increase the number of certificate verification levels, or support new cryptographic algorithms. In other words, the first device does not need any modifications to verify the legitimacy of the second device's digital certificate when at least two root certificates coexist. This method not only has a wide range of applications but also reduces the cost of root certificate updates.

[0172] The above describes the digital certificate verification method provided in the embodiments of this application. Corresponding to the above method, the embodiments of this application also provide a digital certificate verification device. This device is applied to a first device, which stores root certificates trusted by the first device. The device is used to verify digital certificates... Figure 12Each module shown performs the above... Figure 2 The verification method for the digital certificate executed by the first device in the process. For example... Figure 12 As shown in the embodiments of this application, the digital certificate verification device includes the following modules.

[0173] The receiving module 1201 is used to receive a first certificate group sent by the second device. The second device stores at least two valid root certificates and certificate groups corresponding to each root certificate. The first certificate group is at least one of the certificate groups corresponding to each root certificate. A certificate group corresponding to a root certificate includes a secondary CA certificate signed by the root certificate and a digital certificate of the second device generated based on the secondary CA certificate.

[0174] Verification module 1202 is used to verify the legality of at least one digital certificate of a second device based on the root certificate trusted by the first device and the first certificate group, wherein the root certificate trusted by the first device is at least one of at least two root certificates;

[0175] Among them, the certificate group corresponding to the target root certificate whose validity period is not the latest among at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate.

[0176] In an exemplary embodiment, the number of backup secondary CA certificates is at least two, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

[0177] In an exemplary embodiment, the start time of the working period of the first backup secondary CA certificate in the backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate in the other secondary CA certificates.

[0178] In an exemplary embodiment, the receiving module 1201 is configured to receive the certificate group corresponding to the root certificate with the earliest validity period among at least two root certificates sent by the second device.

[0179] In an exemplary embodiment, the apparatus further includes: a first sending module, configured to send at least one root certificate identifier to the second device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device;

[0180] The receiving module 1201 is used to receive the certificate group corresponding to the root certificate trusted by the first device sent by the second device.

[0181] In an exemplary embodiment, the apparatus further includes: a second sending module, configured to send a second certificate set to a second device, the second certificate set including a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate, the second certificate set being used by the second device to verify the legality of at least one digital certificate of the first device.

[0182] This application also provides another digital certificate verification device. This device is applied to a second device, which stores at least two valid root certificates and certificate sets corresponding to each root certificate. Each certificate set includes a secondary CA certificate signed by the root certificate and a digital certificate for the second device generated based on the secondary CA certificate. This device is used to verify digital certificates... Figure 13 Each module shown performs the above... Figure 2 The verification method for digital certificates performed by the second device. For example... Figure 13 As shown in the embodiments of this application, the digital certificate verification device includes the following modules.

[0183] The sending module 1301 is used to send a first certificate group to the first device. The first certificate group is used by the first device to verify the legality of the digital certificate of at least one second device. The first certificate group is at least one of the certificate groups corresponding to each root certificate.

[0184] Among them, the certificate group corresponding to the target root certificate whose validity period is not the latest among at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificates is earlier than the start time of the dormancy period of the target root certificate.

[0185] In an exemplary embodiment, the number of backup secondary CA certificates is at least two, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

[0186] In an exemplary embodiment, the start time of the working period of the first backup secondary CA certificate in the backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate in the other secondary CA certificates.

[0187] In an exemplary embodiment, the apparatus further includes an upload module for uploading at least two root certificates and certificate groups corresponding to each root certificate, wherein the upload time is within the working period of the secondary CA certificate included in the certificate group corresponding to the target root certificate.

[0188] In an exemplary embodiment, the sending module 1301 is configured to send the certificate group corresponding to the root certificate with the earliest validity period among at least two root certificates to the first device.

[0189] In an exemplary embodiment, the apparatus further includes: a first receiving module, configured to receive at least one root certificate identifier sent by the first device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device;

[0190] The sending module 1301 is also used to send a certificate group corresponding to a root certificate trusted by the first device to the first device, wherein the root certificate trusted by the first device is at least one of at least two root certificates.

[0191] In an exemplary embodiment, the apparatus further includes: a second receiving module, configured to receive a second certificate group sent by the first device, the second certificate group including a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate;

[0192] The verification module is used to verify the legitimacy of at least one digital certificate of the first device based on a root certificate trusted by the first device and a second certificate group, wherein the root certificate trusted by the first device is at least one of at least two root certificates.

[0193] In summary, in the case of at least two root certificates coexisting, the present application's embodiments use the target root certificate to sign backup secondary CA certificates and other secondary CA certificates before the target root certificate (which has a validity period not the latest) enters its dormant period. Furthermore, the working periods of the backup secondary CA certificate and the other secondary CA certificates cover the dormant period of the target root certificate. Therefore, even if a second device is deployed after the target root certificate enters its dormant period, the backup secondary CA certificate can still be used to sign the digital certificate of the second device, thus making it possible to verify the legitimacy of the second device's digital certificate through the target root certificate.

[0194] For a first device that stores and trusts at least one of the two root certificates, even if the first device trusts the target root certificate, it only needs to use the root certificate it trusts and the first certificate set received from the second device to verify the legitimacy of the second device's digital certificate. Therefore, the first device does not need to upload any additional certificates, increase the number of certificate verification levels, or support new cryptographic algorithms. In other words, the first device can verify the legitimacy of the second device's digital certificate without any modifications, provided that at least two root certificates coexist. This device not only has a wide range of applications but also reduces the cost of root certificate updates.

[0195] It should be understood that the above Figure 12 and Figure 13The provided device, in implementing its functions, is only illustrated by the division of the above-described functional modules. In practical applications, the functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the device and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.

[0196] In an exemplary embodiment, this application provides a digital certificate verification device, which includes a network interface, a memory, and a processor. The network interface is used for communication by the device, and the memory stores at least one instruction, which is loaded and executed by the processor to cause the device to perform the methods described above.

[0197] See Figure 14 , Figure 14 A schematic diagram of the structure of an exemplary digital certificate verification device 1400 of this application is shown. The digital certificate verification device 1400 includes at least one processor 1401, a memory 1403, and at least one network interface 1404.

[0198] Processor 1401 may be, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a GPU, a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits or application-specific integrated circuits (ASICs), programmable logic devices (PLDs), other general-purpose processors or other programmable logic devices, discrete gates, transistor logic devices, discrete hardware components, or any combination thereof for implementing the scheme of this application. A PLD may be, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor. It is worth noting that the processor may be a processor supporting an advanced reduced instruction set machine (RISC) machine (ARM) architecture. It can implement or execute various logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0199] Optionally, the digital certificate verification device 1400 also includes a bus 1402. The bus 1402 is used to transmit information between the components of the digital certificate verification device 1400. The bus 1402 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The bus 1402 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 14 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0200] The memory 1403 may be, for example, volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache.

[0201] By way of example, but not limitation, many forms of ROM and RAM are available. For example, ROM is a compact disc read-only memory (CD-ROM). RAM includes, but is not limited to, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0202] The memory 1403 can also be other types of storage devices capable of storing static information and instructions. Alternatively, it can be other types of dynamic storage devices capable of storing information and instructions. It can also be other optical disc storage, optical disk storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. The memory 1403 may exist independently, for example, and be connected to the processor 1401 via bus 1402. The memory 1403 may also be integrated with the processor 1401.

[0203] Network interface 1404 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), or wireless local area network (WLAN). Network interface 1404 may include wired network interfaces and wireless network interfaces. Specifically, network interface 1404 can be an Ethernet interface, such as Fast Ethernet (FE), Gigabit Ethernet (GE), Asynchronous Transfer Mode (ATM), WLAN, cellular network, or combinations thereof. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. In some embodiments of this application, network interface 1404 can be used by digital certificate verification device 1400 to communicate with other devices.

[0204] In specific implementations, as some embodiments, the processor 1401 may include one or more CPUs, such as Figure 14 The CPU0 and CPU1 shown are examples of processors. Each of these processors can be a single-core processor or a multi-core processor. A processor here can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0205] In specific implementations, as some methods, the digital certificate verification device 1400 may include multiple processors, such as... Figure 14 The processors 1401 and 1405 are shown. Each of these processors may be a single-core processor or a multi-core processor. A processor here may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0206] In some embodiments, memory 1403 is used to store program instructions 1410 for executing the scheme of this application, and processor 1401 can execute the program instructions 1410 stored in memory 1403. That is, the digital certificate verification device 1400 can implement the method provided in the method embodiment through processor 1401 and program instructions 1410 in memory 1403, i.e. Figure 2 The method executed by the first or second device. The program instructions 1410 may include one or more software modules. Optionally, the processor 1401 itself may also store program instructions for executing the scheme of this application.

[0207] In specific implementation, the digital certificate verification device 1400 of this application can correspond to the first network element device used to execute the above method. The processor 1401 in the digital certificate verification device 1400 reads the instructions in the memory 1403, causing... Figure 14 The digital certificate verification device 1400 shown is capable of performing all or part of the steps in the method embodiments.

[0208] The digital certificate verification device 1400 can also correspond to the above. Figure 12 or Figure 13 The digital certificate verification device shown. Figure 12 Each functional module in the device shown in diagram 13 is implemented using software from a digital certificate verification device 1400. In other words, Figure 12 The device shown in 13 includes a functional module that is generated by the processor 1401 of the digital certificate verification device 1400 after reading the program instructions 1410 stored in the memory 1403.

[0209] in, Figure 2 Each step of the method shown is implemented through integrated logic circuits in the hardware or instructions in the software form of the processor of the digital certificate verification device 1400. The steps of the method embodiments disclosed in this application can be directly implemented by the hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. Since the storage medium is located in memory, the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method embodiments; to avoid repetition, these will not be described in detail here.

[0210] In an exemplary embodiment, this application provides a computer program (product) comprising: computer program code, which, when executed by a computer, causes the computer to perform... Figure 2 The digital certificate verification method is shown.

[0211] In an exemplary embodiment, this application provides a computer-readable storage medium that stores a program or instructions, which, when executed on a computer, [perform the above-mentioned...]. Figure 2 The verification method for the digital certificate shown is executed.

[0212] In an exemplary embodiment, this application provides a chip including a processor for retrieving and executing instructions stored in a memory, causing a computer with the chip installed to perform... Figure 2 The digital certificate verification method shown.

[0213] In an exemplary embodiment, this application provides another chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected via internal interconnection paths. The processor is used to execute code in the memory. When the code is executed, a computer with the chip installed performs... Figure 2 The digital certificate verification method shown.

[0214] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).

[0215] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with substantially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another.

[0216] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0217] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple second devices means two or more second devices. The terms "system" and "network" are often used interchangeably herein.

[0218] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0219] It should also be understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and / or" describes an association between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects are in an "or" relationship.

[0220] It should also be understood that the terms “if” and “if” can be interpreted as meaning “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrases “if determination…” or “if detection [the stated condition or event]” can be interpreted as meaning “when determination…”, or “in response to determination…”, or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.

[0221] The above description is merely an embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for verifying a digital certificate, characterized in that, The method is applied to a first device, the first device storing a root certificate trusted by the first device, the method comprising: The first device receives a first certificate group sent by the second device. The second device stores at least two valid root certificates and certificate groups corresponding to each root certificate. The first certificate group is at least one of the certificate groups corresponding to each root certificate. A certificate group corresponding to a root certificate includes a secondary certification authority (CA) certificate signed by the root certificate and a digital certificate of the second device generated based on the secondary CA certificate. The first device verifies the legitimacy of at least one digital certificate of a second device based on a root certificate trusted by the first device and the first certificate group, wherein the root certificate trusted by the first device is at least one of the at least two root certificates; Wherein, the certificate group corresponding to the target root certificate whose validity period is not the latest among the at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificate is earlier than the start time of the dormancy period of the target root certificate. The working periods of the backup secondary CA certificate and the other secondary CA certificate are both used to sign lower-level certificates with full validity periods. The dormancy period of the target root certificate is not used to sign the at least one backup secondary CA certificate and the at least one other secondary CA certificate with full validity periods.

2. The method according to claim 1, characterized in that, The number of backup secondary CA certificates is at least two, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

3. The method according to claim 1 or 2, characterized in that, The start time of the working period of the first backup secondary CA certificate in the backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate in the other secondary CA certificates.

4. The method according to claim 1 or 2, characterized in that, The first device receives a first certificate group sent by the second device, including: the certificate group corresponding to the root certificate with the earliest validity period among the at least two root certificates sent by the second device.

5. The method according to claim 1 or 2, characterized in that, Before the first device receives the first certificate group sent by the second device, the method further includes: the first device sending at least one root certificate identifier to the second device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device; The first device receives a first certificate group sent by the second device, including: the first device receives a certificate group corresponding to the root certificate trusted by the first device sent by the second device.

6. The method according to claim 1 or 2, characterized in that, The method further includes: The first device sends a second certificate set to the second device. The second certificate set includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate. The second certificate set is used by the second device to verify the legitimacy of at least one digital certificate of the first device.

7. A method for verifying a digital certificate, characterized in that, The method is applied to a second device, which stores at least two valid root certificates and certificate sets corresponding to each root certificate. A certificate set corresponding to a root certificate includes a secondary certification authority (CA) certificate signed by the root certificate, and a digital certificate of the second device generated based on the secondary CA certificate. The method includes: The second device sends a first certificate group to the first device. The first certificate group is used by the first device to verify the legality of at least one digital certificate of the second device. The first certificate group is at least one of the certificate groups corresponding to each root certificate. Wherein, the certificate group corresponding to the target root certificate whose validity period is not the latest among the at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificate is earlier than the start time of the dormancy period of the target root certificate. The working periods of the backup secondary CA certificate and the other secondary CA certificate are both used to sign lower-level certificates with full validity periods. The dormancy period of the target root certificate is not used to sign the at least one backup secondary CA certificate and the at least one other secondary CA certificate with full validity periods.

8. The method according to claim 7, characterized in that, The number of backup secondary CA certificates is at least two, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

9. The method according to claim 7 or 8, characterized in that, The start time of the working period of the first backup secondary CA certificate in the backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate in the other secondary CA certificates.

10. The method according to claim 7 or 8, characterized in that, Before the second device sends the first certificate group to the first device, the method further includes: The second device uploads the at least two root certificates and the certificate groups corresponding to each root certificate, and the upload time is within the working period of the secondary CA certificate included in the certificate group corresponding to the target root certificate.

11. The method according to claim 7 or 8, characterized in that, The second device sends a first certificate group to the first device, including: the second device sends the certificate group corresponding to the root certificate with the earliest validity period among the at least two root certificates to the first device.

12. The method according to claim 7 or 8, characterized in that, Before the second device sends the first certificate group to the first device, the method further includes: the second device receiving at least one root certificate identifier sent by the first device, wherein a root certificate identifier is used to indicate a root certificate trusted by the first device; The second device sends a first certificate group to the first device, including: the second device sending a certificate group corresponding to a root certificate trusted by the first device to the first device, wherein the root certificate trusted by the first device is at least one of the at least two root certificates.

13. The method according to claim 7 or 8, characterized in that, The method further includes: The second device receives a second certificate group sent by the first device. The second certificate group includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate. The second device verifies the legitimacy of at least one digital certificate of the first device based on the root certificate trusted by the first device and the second certificate set, wherein the root certificate trusted by the first device is at least one of the at least two root certificates.

14. A digital certificate verification device, characterized in that, The apparatus is applied to a first device, the first device storing a root certificate trusted by the first device, the apparatus comprising: The receiving module is used to receive a first certificate group sent by the second device. The second device stores at least two valid root certificates and certificate groups corresponding to each root certificate. The first certificate group is at least one of the certificate groups corresponding to each root certificate. A certificate group corresponding to a root certificate includes a secondary certification center (CA) certificate signed by the root certificate and a digital certificate of the second device generated based on the secondary CA certificate. The verification module is used to verify the legitimacy of a digital certificate of at least one second device based on the root certificate trusted by the first device and the first certificate group, wherein the root certificate trusted by the first device is at least one of the at least two root certificates. Wherein, the certificate group corresponding to the target root certificate whose validity period is not the latest among the at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificate is earlier than the start time of the dormancy period of the target root certificate. The working periods of the backup secondary CA certificate and the other secondary CA certificate are both used to sign lower-level certificates with full validity periods. The dormancy period of the target root certificate is not used to sign the at least one backup secondary CA certificate and the at least one other secondary CA certificate with full validity periods.

15. The apparatus according to claim 14, characterized in that, The number of backup secondary CA certificates is at least two, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

16. The apparatus according to claim 14 or 15, characterized in that, The start time of the working period of the first backup secondary CA certificate in the backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate in the other secondary CA certificates.

17. The apparatus according to claim 14 or 15, characterized in that, The receiving module is used to receive the certificate group corresponding to the root certificate with the earliest validity period among the at least two root certificates sent by the second device.

18. The apparatus according to claim 14 or 15, characterized in that, The apparatus further includes: a first sending module, configured to send at least one root certificate identifier to the second device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device; The receiving module is used to receive the certificate group corresponding to the root certificate trusted by the first device, sent by the second device.

19. The apparatus according to claim 14 or 15, characterized in that, The device further includes: The second sending module is used to send a second certificate group to the second device. The second certificate group includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate. The second certificate group is used by the second device to verify the legality of at least one digital certificate of the first device.

20. A digital certificate verification device, characterized in that, The apparatus is applied to a second device, which stores at least two valid root certificates and certificate sets corresponding to each root certificate. A certificate set corresponding to a root certificate includes a secondary certification authority (CA) certificate signed by the root certificate, and a digital certificate for the second device generated based on the secondary CA certificate. The apparatus includes: The sending module is used to send a first certificate group to the first device. The first certificate group is used by the first device to verify the legality of the digital certificate of at least one second device. The first certificate group is at least one of the certificate groups corresponding to each root certificate. Wherein, the certificate group corresponding to the target root certificate whose validity period is not the latest among the at least two root certificates includes a secondary CA certificate that is one of at least one backup secondary CA certificate signed by the target root certificate. The working period of the backup secondary CA certificate and the working period of at least one other secondary CA certificate signed by the target root certificate cover the dormancy period of the target root certificate. The start time of the working period of the backup secondary CA certificate is later than or equal to the start time of the dormancy period of the target root certificate, and the start time of the working period of the other secondary CA certificate is earlier than the start time of the dormancy period of the target root certificate. The working periods of the backup secondary CA certificate and the other secondary CA certificate are both used to sign lower-level certificates with full validity periods. The dormancy period of the target root certificate is not used to sign the at least one backup secondary CA certificate and the at least one other secondary CA certificate with full validity periods.

21. The apparatus according to claim 20, characterized in that, The number of backup secondary CA certificates is at least two, and the working periods of the at least two backup secondary CA certificates are consecutive or overlap.

22. The apparatus according to claim 20 or 21, characterized in that, The start time of the working period of the first backup secondary CA certificate in the backup secondary CA certificate is equal to the end time of the working period of the last other secondary CA certificate in the other secondary CA certificates.

23. The apparatus according to claim 20 or 21, characterized in that, The device further includes: The upload module is used to upload the at least two root certificates and the certificate groups corresponding to each root certificate. The upload time is within the working period of the secondary CA certificate included in the certificate group corresponding to the target root certificate.

24. The apparatus according to claim 20 or 21, characterized in that, The sending module is used to send the certificate group corresponding to the root certificate with the earliest validity period among the at least two root certificates to the first device.

25. The apparatus according to claim 20 or 21, characterized in that, The device further includes: a first receiving module, configured to receive at least one root certificate identifier sent by the first device, wherein the root certificate identifier is used to indicate a root certificate trusted by the first device; The sending module is further configured to send to the first device a certificate group corresponding to the root certificate trusted by the first device, wherein the root certificate trusted by the first device is at least one of the at least two root certificates.

26. The apparatus according to claim 20 or 21, characterized in that, The device further includes: The second receiving module is used to receive a second certificate group sent by the first device. The second certificate group includes a secondary CA center certificate signed by a root certificate trusted by the first device, and a digital certificate of the first device generated based on the secondary CA center certificate. The verification module is used to verify the legitimacy of at least one digital certificate of the first device based on the root certificate trusted by the first device and the second certificate group, wherein the root certificate trusted by the first device is at least one of the at least two root certificates.

27. A digital certificate verification device, characterized in that, The device includes a network interface, a memory, and a processor; the network interface is used for communication by the device, and the memory stores at least one instruction, which is loaded and executed by the processor to enable the device to implement the digital certificate verification method according to any one of claims 1-13.

28. A digital certificate verification system, characterized in that, The system includes a first device and a second device connected by communication, the first device being used to perform the digital certificate verification method according to any one of claims 1-6, and the second device being used to perform the digital certificate verification method according to any one of claims 7-13.

29. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, which is loaded and executed by a processor to enable the computer to implement the digital certificate verification method as described in any one of claims 1-13.

30. A computer program product, characterized in that, The computer program product includes computer program code, which, when executed by a computer, causes the computer to perform the verification method for the digital certificate as described in any one of claims 1-13.

Images