Hierarchical certificate issuing system, method, device and equipment

Abstract

The invention provides a hierarchical certificate issuing system, method, device and equipment, and the system comprises root CA equipment, strategy CA equipment and certificate issuing CA equipment: the root CA equipment is used for generating a self-signature root CA certificate based on a root CA key pair, and carrying out the signature of a strategy CA certificate signature request of the strategy CA equipment through employing a root CA private key, and obtaining the strategy CA certificate; the policy CA equipment is used for acquiring a policy CA certificate from the root CA equipment and signing a certificate issuing CA certificate signature request of the certificate issuing CA equipment by adopting a policy CA private key to obtain the certificate issuing CA certificate; the certificate issuing CA equipment is used for acquiring a certificate issuing CA certificate from the policy CA equipment and signing a terminal certificate signature request of the terminal equipment by adopting a certificate issuing CA private key to obtain a terminal entity certificate; and the certificate issuing CA equipment is also used for sending a certificate chain to the terminal equipment, and the certificate chain comprises a self-signature root CA certificate, a policy CA certificate, a certificate issuing CA certificate and a terminal entity certificate.

Description

Technical Field

[0001] This invention relates to the field of security management technology, and in particular to a tiered certificate issuance system, method, apparatus, and equipment. Background Technology

[0002] In IoT and robotics systems, a massive number of terminal devices need to communicate securely and authenticate with cloud platforms and other devices. A digital certificate system based on Public Key Infrastructure (PKI) is a core technology for achieving trusted device identities and establishing secure channels. As a device's "digital ID card," the reliability, efficiency, and scalability of its issuance, management, and verification mechanisms directly determine the security of the entire IoT system.

[0003] In existing technologies, a root Certificate Authority (CA) and a device-oriented certificate issuing CA are typically deployed. The root CA directly issues certificates to the issuing CA or directly issues device certificates to the terminal devices, thereby forming a centralized certificate trust and management system.

[0004] However, the above architecture results in lower security for certificate management. Summary of the Invention

[0005] This invention provides a hierarchical certificate issuance system, method, apparatus, and device to address the shortcomings of low security in certificate management in the prior art and to improve the security of certificate management.

[0006] This invention provides a hierarchical certificate issuance system, including a root CA device, a policy CA device, and an issuing CA device, wherein the root CA device is an offline device, and: The root CA device is used to generate a self-signed root CA certificate based on the root CA key pair, and to sign the policy CA certificate signing request from the policy CA device using the root CA private key to obtain the policy CA certificate. The policy CA device is used to obtain the policy CA certificate from the root CA device and use the policy CA private key in the generated policy CA key pair to sign the issuance CA certificate signing request from the issuing CA device to obtain the issuance CA certificate. The issuing CA device is used to obtain the issuing CA certificate from the policy CA device, and use the issuing CA private key in the generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain the terminal entity certificate. The issuing CA device is further configured to send a certificate chain to the terminal device, the certificate chain including the self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate.

[0007] According to a hierarchical certificate issuance system provided by the present invention, the root CA device is specifically used for: Generate the root CA key pair, and use the root CA private key to sign the root CA public key and the root CA extended information to obtain the self-signed root CA certificate. The root CA extended information includes at least one of the following: root CA path length constraint, root CA validity period, and root CA subject information.

[0008] According to a hierarchical certificate issuance system provided by the present invention, the policy CA certificate's policy CA extended information includes at least one of policy CA path length constraint, policy CA validity period, policy CA subject information, and certificate policy. The certificate policy is used to manage the security policies of different types of terminal devices.

[0009] According to a hierarchical certificate issuance system provided by the present invention, the issuing CA certificate's extended information includes at least one of the following: issuing CA path length constraint, certificate revocation list, and authorization information access address; wherein, the authorization information access address includes the address of the certificate status protocol query service.

[0010] According to a hierarchical certificate issuance system provided by the present invention, the certificate issuing CA device is specifically used for: If it is determined that the terminal identifier in the terminal certificate signing request is a registered identifier, the signature of the terminal certificate signing request is valid, and the extended fields in the terminal certificate signing request conform to the security policy corresponding to the terminal device in the certificate policy, the terminal certificate signing request is signed using the issuing CA private key to obtain the terminal entity certificate.

[0011] According to a hierarchical certificate issuance system provided by the present invention, the system further includes a terminal device, wherein the terminal device is used for: The certificate chain is parsed to obtain a certificate chain array, which includes the self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. Traverse each certificate in the certificate chain array, and determine the remaining path length corresponding to the currently traversed certificate based on the length of the certificate chain array and the index number of the currently traversed certificate in the certificate chain array; If the path length constraint in the currently traversed certificate is less than the remaining path length, the certificate chain verification is determined to have failed.

[0012] According to a hierarchical certificate issuance system provided by the present invention, the terminal device is further configured to obtain a certificate revocation list from the issuing CA extended information of the issuing CA certificate, and determine that the certificate currently being traversed has been revoked if it is determined that the certificate currently being traversed is in the certificate revocation list.

[0013] According to a hierarchical certificate issuance system provided by the present invention, the terminal device is further configured to: Obtain the authorization information access address from the issuing CA extended information of the issuing CA certificate, and send a query message to the server corresponding to the authorization information access address. The query message includes the identification information of the certificate being traversed. Receive the certificate status of the currently traversed certificates sent by the server, the certificate status including normal status or revoked status.

[0014] According to a hierarchical certificate issuance system provided by the present invention, the certificate issuing CA device is further configured to send a first notification message to the policy CA device when a suspicious event is detected; The policy CA device is further configured to revoke the issuing CA certificate sent to the issuing CA device based on the first notification message, add the identification information of the revoked issuing CA certificate to the certificate revocation list, and send a first update message to the server, wherein the first update message is used to instruct the server to update the certificate status of the revoked issuing CA certificate. The policy CA device is also used to sign a new issuing CA certificate signing request from the issuing CA device using the policy CA private key, thereby obtaining a new issuing CA certificate. The issuing CA device is further configured to obtain the new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate, and send the new certificate chain to the terminal device. The new certificate chain includes the self-signed root CA certificate, the policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0015] According to a hierarchical certificate issuance system provided by the present invention, the policy CA device is further configured to send a second notification message to the root CA device when a suspicious event is detected; The root CA device is further configured to revoke the policy CA certificate sent to the policy CA device based on the second notification message, add the identification information of the revoked policy CA certificate to the certificate revocation list, and send a second update message to the server, wherein the second update message is used to instruct the server to update the certificate status of the revoked policy CA certificate. The root CA device is also used to sign a new policy CA certificate signing request from the policy CA device using the root CA private key, thereby obtaining a new policy CA certificate. The policy CA device is also used to obtain the new policy CA certificate from the root CA device, and use the new policy CA private key in the newly generated policy CA key pair to sign the issuance CA certificate signing request from the issuing CA device to obtain a new issuance CA certificate. The issuing CA device is further configured to obtain the new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate, and send the new certificate chain to the terminal device. The new certificate chain includes the self-signed root CA certificate, the new policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0016] According to the hierarchical certificate issuance system provided by the present invention, the root CA private key is stored in the hardware security module (HSM) of the root CA device; the policy CA device is a semi-offline device, and the policy CA private key is stored in the HSM of the policy CA device; the certificate issuing CA device is an online device.

[0017] This invention also provides a method for issuing tiered certificates, comprising: Submit a policy CA certificate signing request to the root CA device; Obtain the policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key; Using the policy CA private key in the generated policy CA key pair, the issuing CA certificate signing request from the issuing CA device is signed to obtain the issuing CA certificate; The issuing CA certificate is sent to the issuing CA device. The issuing CA certificate is used to instruct the issuing CA device to sign the terminal certificate signing request from the terminal device using the issuing CA private key in the generated issuing CA key pair. After obtaining the terminal entity certificate, the certificate chain is sent to the terminal device. The certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. The self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

[0018] The present invention also provides a tiered certificate issuing device, comprising: The submission module is used to submit policy CA certificate signing requests to the root CA device; The acquisition module is used to acquire the policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key; The signature module is used to sign the issuing CA certificate signature request from the issuing CA device using the policy CA private key in the generated policy CA key pair, so as to obtain the issuing CA certificate. The sending module is used to send the issuing CA certificate to the issuing CA device. The issuing CA certificate is used to instruct the issuing CA device to use the issuing CA private key in the generated issuing CA key pair to sign the terminal certificate signing request from the terminal device. After obtaining the terminal entity certificate, the certificate chain is sent to the terminal device. The certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. The self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

[0019] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method for issuing hierarchical certificates as described above.

[0020] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method for issuing hierarchical certificates as described above.

[0021] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the method for issuing hierarchical certificates as described above.

[0022] The hierarchical certificate issuance system, method, apparatus, and device provided by this invention include a root CA device, a policy CA device, and an issuing CA device. The root CA device is an offline device. The root CA device generates a self-signed root CA certificate based on a root CA key pair and signs a policy CA certificate signing request from the policy CA device using the root CA private key to obtain a policy CA certificate. The policy CA device obtains the policy CA certificate from the root CA device and signs an issuing CA certificate signing request from the issuing CA device using the policy CA private key in the generated policy CA key pair to obtain an issuing CA certificate. The issuing CA device obtains the issuing CA certificate from the policy CA device and signs a terminal certificate signing request from a terminal device using the issuing CA private key in the generated issuing CA key pair to obtain a terminal entity certificate. The issuing CA device also sends a certificate chain to the terminal device, the certificate chain including the self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. By adopting a three-tier architecture that separates the offline root CA device, intermediate policy CA device, and online certificate issuing CA device, the offline root CA device performs policy CA certificate issuance, the intermediate policy CA device authorizes the certificate issuing CA device and defines its certificate constraints, and the online certificate issuing CA device performs the issuance of high-frequency terminal entity certificates. This reduces the risk of root CA key leakage by eliminating the need for frequent use of the root CA key. Furthermore, the hierarchical approach to certificate management, without requiring frequent use of the root CA key, enhances the security of certificate management. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of a tiered certificate issuance system provided in an embodiment of the present invention.

[0025] Figure 2 This is a flowchart illustrating the method for issuing hierarchical certificates provided in an embodiment of the present invention.

[0026] Figure 3 This is a schematic diagram of the structure of a tiered certificate issuing device provided in an embodiment of the present invention.

[0027] Figure 4 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0029] In IoT and robotics systems, secure communication between devices and the cloud relies on PKI for authentication and data encryption. Currently, a two-tier CA architecture is commonly used for device certificate management, such as deploying a root CA and a device-oriented issuing CA. The root CA directly issues certificates to the issuing CA or directly issues device certificates to the terminal devices. However, in this architecture, with the root CA directly issuing device certificates, the root CA needs to be frequently online to handle certificate issuance, renewal, and revocation, leading to a high risk of key leakage and thus lower security for certificate management.

[0030] This invention addresses the aforementioned problems by proposing a hierarchical certificate issuance system. This system employs a three-tiered CA architecture: a root CA device, a policy CA device, and an issuing CA device. The root CA device is configured as an offline device, solely responsible for issuing certificates to the policy CA device. The policy CA device is responsible for setting corresponding security policies for different types of terminal devices and issuing certificates to the issuing CA device. The issuing CA device efficiently executes the issuance of specific terminal entity certificates in an online cluster. Because the root CA device is configured as an offline device, the root CA key does not require frequent use, reducing the risk of root CA key leakage. Furthermore, the policy CA device acts as an intermediate layer, issuing issuing CA certificates to the issuing CA device, enabling the issuing CA device to issue terminal entity certificates for each terminal device, thus achieving secure management of device certificates.

[0031] The embodiments of the present invention can be applied to scenarios that require the construction of a highly secure public key infrastructure, such as IoT device access authentication, vehicle-to-everything (V2X) communication, and industrial control system device identity management.

[0032] Figure 1 This is a schematic diagram of a tiered certificate issuance system provided in an embodiment of the present invention, such as... Figure 1 As shown, the system includes a root CA device, a policy CA device, and an issuing CA device, with the root CA device being an offline device.

[0033] The system includes: a root CA device for generating a self-signed root CA certificate based on a root CA key pair, and signing a policy CA certificate signing request from a policy CA device using the root CA private key to obtain a policy CA certificate; a policy CA device for obtaining a policy CA certificate from a root CA device, and signing a certificate signing request from a certificate issuing CA device using the policy CA private key from the generated policy CA key pair to obtain a certificate issuing CA certificate; a certificate issuing CA device for obtaining a certificate issuing CA certificate from a policy CA device, and signing a certificate signing request from a terminal device using the certificate issuing CA private key from the generated certificate issuing CA key pair to obtain a terminal entity certificate; and a certificate issuing CA device for sending a certificate chain to a terminal device, the certificate chain including a self-signed root CA certificate, a policy CA certificate, a certificate issuing CA certificate, and a terminal entity certificate.

[0034] Specifically, the root CA device serves as the trust anchor for the hierarchical certificate issuance system and needs to operate completely offline. After generating an RSA 4096-bit root CA key pair in a physically isolated environment, the root CA device can generate a self-signed root CA certificate based on the root CA key pair.

[0035] In a semi-offline environment, the policy CA device generates an RSA 3072-bit policy CA key pair. Using the policy CA private key from this key pair, it digitally signs the policy CA public key and subject information, generating a Policy CA Certificate Signing Request (CSR). This CSR is then submitted to the root CA device. Since the root CA device is offline, a USB flash drive, hard drive, or other third-party storage medium can be used to submit the policy CA certificate signing request to the root CA device.

[0036] The root CA device uses its private key to sign the policy CA certificate signing request, generates a policy CA certificate, and returns the policy CA certificate to the policy CA device via a third-party storage medium.

[0037] In addition, the issuing CA device generates an RSA 2048-bit issuing CA key pair, and uses the issuing CA private key in the issuing CA key pair to digitally sign the issuing CA public key and subject information, generating an issuing CA certificate signature request (CSR), and then submits the issuing CA certificate signature request to the policy CA device.

[0038] The policy CA device uses the policy CA private key to sign the issuing CA certificate signing request, generates the issuing CA certificate, and returns the issuing CA certificate to the issuing CA device.

[0039] When a terminal device applies for a terminal entity certificate through a certificate issuing CA device, the terminal device generates an RSA 2048-bit or Elliptic Curve Cryptography Prime 256-bit (ECC P-256) key pair in a secure environment. The private key in the key pair is stored in the secure storage area of ​​the terminal device, such as a Trusted Execution Environment (TEE) or a secure chip, while the public key is used to create the terminal certificate signing request.

[0040] Specifically, the terminal device's public key, subject information, and extension request are signed using the terminal device's private key to prove ownership of the private key, thereby generating a terminal certificate signing request. The terminal device's subject information may include, for example, CN=Robot-UUID, O=Organization, OU=Robot Devices. In the terminal device's extension request, the subjectAltName extension field contains the Domain Name System (DNS) name and Uniform Resource Identifier (URI), and the keyUsage extension field contains the digital signature and keyEncipherment.

[0041] After the terminal device sends the terminal certificate signing request to the issuing CA device, the issuing CA device verifies the terminal device's identity information, the validity of the terminal certificate signing request, and whether the extended fields in the terminal certificate signing request meet the preset requirements. Upon successful verification, the issuing CA uses its own issuing CA private key to sign the terminal certificate signing request, obtaining the terminal entity certificate. The issuing CA then sets the extended field `basicConstraints` in the terminal entity certificate. For example, setting `CA=FALSE` indicates that the terminal entity certificate cannot sign other certificates, and the validity period is set to one year.

[0042] Furthermore, the issuing CA device can add a complete certificate chain, including the end entity certificate → issuing CA certificate → policy CA certificate → self-signed root CA certificate, and send the complete certificate chain to the end device.

[0043] The aforementioned terminal devices may include industrial robots, service robots, or consumer-grade devices. The issuing CA devices are deployed as a multi-instance cluster, providing high-availability services through load balancing.

[0044] The hierarchical certificate issuance system provided in this embodiment of the invention includes a root CA device, a policy CA device, and an issuing CA device. The root CA device is an offline device. The root CA device generates a self-signed root CA certificate based on a root CA key pair and signs a policy CA certificate signing request from the policy CA device using the root CA private key to obtain a policy CA certificate. The policy CA device obtains the policy CA certificate from the root CA device and signs an issuing CA certificate signing request from the issuing CA device using the policy CA private key in the generated policy CA key pair to obtain an issuing CA certificate. The issuing CA device obtains the issuing CA certificate from the policy CA device and signs a terminal certificate signing request from a terminal device using the issuing CA private key in the generated issuing CA key pair to obtain a terminal entity certificate. The issuing CA device also sends a certificate chain to the terminal device, the certificate chain including the self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. By adopting a three-tier architecture that separates the offline root CA device, intermediate policy CA device, and online certificate issuing CA device, the offline root CA device performs policy CA certificate issuance, the intermediate policy CA device authorizes the certificate issuing CA device and defines its certificate constraints, and the online certificate issuing CA device performs the issuance of high-frequency terminal entity certificates. This reduces the risk of root CA key leakage by eliminating the need for frequent use of the root CA key. Furthermore, the hierarchical approach to certificate management, without requiring frequent use of the root CA key, enhances the security of certificate management.

[0045] In addition, the three-tier architecture described above achieves the best balance between security and performance. This design avoids the security risks of two-tier architecture and the performance overhead of multi-tier architecture (>3 tiers).

[0046] For example, based on the above embodiments, the root CA device described above is specifically used for: Generate a root CA key pair, use the root CA private key to sign the root CA public key and the root CA extension information to obtain a self-signed root CA certificate. The root CA extension information includes at least one of the following: root CA path length constraint, root CA validity period, and root CA subject information.

[0047] Specifically, the root CA device generates an RSA 4096-bit root CA key pair in a physically isolated environment. The root CA key pair includes a root CA private key and a root CA public key. The root CA device uses the root CA private key to sign the root CA public key and root CA extended information, thereby generating a self-signed root CA certificate. The root CA extended information, `basicConstraints`, includes at least one of the following: CA path length constraint `pathLenConstraint`, root CA validity period, and root CA subject information. For example, the root CA extended information `basicConstraints` can be set to: CA=TRUE, path length constraint `pathLenConstraint=2`, indicating that this self-signed root CA certificate can issue CA certificates, and the certificate chain can have up to two levels of CAs. The validity period is set to 10 years, and the subject information includes CN=Root CA, O=Organization, C=CN, etc.

[0048] In this embodiment, a self-signed root CA certificate is obtained by signing the root CA public key and the root CA extended information using the root CA private key. This establishes the highest trust anchor point for the entire system, enabling all subsequently issued policy CA certificates, issuing CA certificates, and terminal entity certificates to be traced back and verified level by level through this anchor point, thus providing a foundation for certificate management.

[0049] For example, based on the above embodiments, the policy CA extended information of the policy CA certificate includes at least one of policy CA path length constraint, policy CA validity period, policy CA topic information, and certificate policy; wherein, the certificate policy is used to manage the security policies of different types of terminal devices.

[0050] Specifically, after the root CA device signs the policy CA certificate signing request using the root CA private key, it issues a policy CA certificate and sets the policy CA extended information in the policy CA certificate. The policy CA extended information includes at least one of the following: policy CA path length constraint, policy CA validity period, policy CA subject information, and certificate policy.

[0051] For example, you can set the policy CA path length constraint `pathLenConstraint=1`, indicating that the policy CA certificate can issue CA certificates, but the certificate chain can have a maximum of one level of CA, and the policy CA validity period is set to 5 years. Certificate policies can be used to manage the security policies of specific types of terminal devices.

[0052] In this embodiment, by adding certificate policies to the policy CA extension information of the policy CA certificate, security policies for different types of terminal devices, such as security attributes and lifecycles, can be managed through certificate policies. Therefore, differentiated security policies can be formulated for different application scenarios and different types of terminal devices, thereby improving the flexibility of certificate management and the scalability of the certificate management system.

[0053] For example, based on the above embodiments, the issuing CA extended information of the issuing CA certificate includes at least one of the issuing CA path length constraint, certificate revocation list, and authorization information access address; wherein, the authorization information access address includes the address of the certificate status protocol query service.

[0054] Specifically, the policy CA device signs the issuing CA certificate signing request using the policy CA private key, issues the issuing CA certificate, and sets the issuing CA extended information in the issuing CA certificate. The issuing CA extended information includes at least one of the following: issuing CA path length constraint, certificate revocation list, and authorized information access address.

[0055] For example, you can set the issuing CA path length constraint `pathLenConstraint=0`, indicating that the issuing CA certificate can issue CA certificates, but cannot issue sub-CAs, and the validity period is set to 2 years. Additionally, you can add the `crlDistributionPoints` extended field to specify the Certificate Revocation List (CRL). You can also add the `authorityInfoAccess` extended field to specify the access address for authorization information, such as the Online Certificate Status Protocol (OCSP) server address.

[0056] In this embodiment, by adding a certificate revocation list and authorized information access address to the issuing CA's extended information, the certificate verifier can query the certificate's revocation status in real time and efficiently, thus achieving dynamic and proactive security management of the entire certificate lifecycle.

[0057] For example, based on the above embodiments, the certificate issuing CA device is specifically used for: If it is determined that the terminal identifier in the terminal certificate signing request is a registered identifier, the signature of the terminal certificate signing request is valid, and the extended fields in the terminal certificate signing request conform to the security policy corresponding to the terminal device in the certificate policy, the issuing CA's private key is used to sign the terminal certificate signing request to obtain the terminal entity certificate.

[0058] Specifically, when a terminal device applies for a terminal entity certificate through the issuing CA device, it uses its private key to sign the terminal device's public key, subject information, and extension request to generate a terminal certificate signing request. The subject information of the terminal device includes its terminal identifier, such as a Universally Unique Identifier (UUID).

[0059] After the terminal device sends the terminal certificate signing request to the issuing CA device, the issuing CA device will verify the terminal device's identifier, such as verifying whether the UUID is a registered identifier. If it is a registered identifier, it means that the terminal device's identity is legitimate; if it is an unregistered identifier, it means that the terminal device's identity is illegitimate.

[0060] After confirming the legitimacy of the terminal device, it is also necessary to verify the validity of the terminal certificate signing request signature, such as by extracting the terminal's public key from the terminal certificate signing request. Furthermore, it can be verified whether the extended fields in the terminal certificate signing request conform to the security policy corresponding to the terminal device as defined in the certificate policy extension information of the policy CA certificate. For example, if the certificate policy OID defined in the policy CA certificate requires that industrial robot certificates must contain keyUsage=digitalSignature, keyEncipherment, and basicConstraints=CA:FALSE, and the extended fields of the terminal certificate signing request submitted by the terminal device do not contain keyEncipherment or incorrectly set CA:TRUE, then it can be determined that the terminal device's terminal certificate signing request does not conform to the security policy authorized by the policy CA certificate, and the issuing CA device will refuse to issue a certificate to the terminal device.

[0061] If the terminal identifier in the terminal certificate signing request is a registered identifier, the signature of the terminal certificate signing request is valid, and the extended fields in the terminal certificate signing request conform to the security policy corresponding to the terminal device in the certificate policy, it means that the terminal certificate signing request has been verified. Then, the issuing CA will use its own issuing CA private key to sign the terminal certificate signing request, obtain the terminal entity certificate, and set the extended field basicConstraints in the terminal entity certificate. For example, setting CA=FALSE indicates that the terminal entity certificate cannot issue other certificates, and the validity period is set to 1 year.

[0062] In this embodiment, the issuing CA device verifies the terminal identifier of the terminal device and the relevant information of the terminal certificate signing request, thereby ensuring that only registered and legitimate terminal devices can obtain valid certificates, and ensuring that all attributes of the issued certificates comply with the certificate policy defined by the superior policy CA. This achieves two-layer control from device identity to certificate content, further enhancing the security of certificate management.

[0063] Furthermore, based on the above embodiments, the tiered certificate issuance system also includes a terminal device, wherein the terminal device is used for: The certificate chain is parsed to obtain a certificate chain array, which includes the self-signed root CA certificate, policy CA certificate, issuing CA certificate, and terminal entity certificate. Each certificate in the certificate chain array is traversed, and the remaining path length corresponding to the currently traversed certificate is determined based on the length of the certificate chain array and the index number of the currently traversed certificate in the certificate chain array. If the path length constraint of the currently traversed certificate is less than the remaining path length, it is determined that the certificate chain verification has failed.

[0064] Specifically, after receiving the complete certificate chain, the terminal device starts with the self-signed root CA certificate, and then parses the policy CA certificate, issuing CA certificate, and terminal entity certificate in sequence. It then constructs a certificate chain array in the order of the self-signed root CA certificate, policy CA certificate, issuing CA certificate, and terminal entity certificate.

[0065] Iterate through each certificate in the certificate chain array to perform verification on each certificate in turn. For the currently being iterated certificate, you can use the getBasicConstraints() method to get the pathLenConstraint value of that certificate. If it returns -1, it means that the currently being iterated certificate is not a CA certificate. If the certificate has also issued other certificates, the certificate chain verification will fail.

[0066] If the pathLenConstraint value returns a value other than -1, the remaining path length (remainingDepth) corresponding to the currently traversed certificate can be calculated as follows: remainingDepth = chain.length - i - 2, where chain.length represents the length of the certificate chain array. In this embodiment, chain.length can be 4, and i represents the index number of the currently traversed certificate in the certificate chain array. For example, the index number of the self-signed root CA certificate is 0, the index number of the policy CA certificate is 1, the index number of the issuing CA certificate is 2, and the index number of the end entity certificate is 3.

[0067] For example, if the certificate being traversed is a self-signed root CA certificate, the remaining path length remainingDepth can be determined to be 2; if the certificate being traversed is a policy CA certificate, the remaining path length remainingDepth can be determined to be 1, and so on.

[0068] After determining the remaining path length of the currently traversed certificate, the path length constraint in the currently traversed certificate is compared with the determined remaining path length. If the path length constraint is less than the remaining path length, it means that the actual certificate chain length exceeds the maximum issuing level authorized by the CA certificate, i.e., a lower-level CA is issuing certificates beyond its authority. In this case, the path length constraint verification of the currently traversed certificate is determined to have failed, and the certificate chain verification is also determined to have failed, so the certificate chain will be rejected. Otherwise, the path length constraint verification of the currently traversed certificate is determined to have passed.

[0069] For example, if the pathLenConstraint of a self-signed root CA certificate is 2, and the determined remaining path length (remainingDepth) is also 2, then the path length constraint verification of the self-signed root CA certificate is successful.

[0070] In this embodiment, the remaining path length corresponding to the currently traversed certificate is determined by the length of the certificate chain array and the index number of the currently traversed certificate in the certificate chain array. The path length constraint in the currently traversed certificate is compared with the remaining path length to verify the path length constraint, ensuring that the certificate chain depth meets the requirements, thereby improving the security of certificate management.

[0071] In addition, the signature verification module in the terminal device also needs to verify the signature of each certificate in the certificate chain array. This can be done by traversing each certificate in the certificate chain array and using the public key of the parent CA device to verify the signature of the currently traversed certificate, ensuring that each certificate has not been tampered with and was issued by a legitimate CA device. For example, the signature of the policy CA certificate can be verified using the root CA device's root CA public key, and the signature of the issuing CA certificate can be verified using the policy CA device's policy CA public key.

[0072] Furthermore, the validity period verification module in the terminal device also needs to check the validity period of the currently traversed certificates to ensure that the current time is between the effective time (notBefore) and the expiration time (notAfter). If any certificate expires, the entire certificate chain verification will fail.

[0073] By verifying the signature and validity period of each certificate in the certificate chain array, the authenticity and integrity of the signature at each level of the certificate chain, as well as the validity of all certificates at the current moment, can be ensured, thereby establishing a complete and valid certificate chain that traces back from the terminal entity certificate to the trusted root CA.

[0074] For example, based on the above embodiments, the terminal device is further configured to obtain a certificate revocation list from the issuing CA extended information of the issuing CA certificate, and determine that the certificate being traversed has been revoked if it is determined that the certificate being traversed is in the certificate revocation list.

[0075] Specifically, after verifying the remaining depth, signature, and validity period of each certificate in the verification chain array, the terminal device needs to further verify the current status of each certificate. For example, the terminal device's CRL download module can extract the CRL download address from the issuing CA's extended information (crlDistributionPoints) of the issuing CA certificate and download the latest CRL file via Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS). The CRL file contains the sequence number and revocation time of all revoked certificates and is signed by the issuing CA device using the issuing CA's private key.

[0076] After downloading the CRL file, the terminal device will verify it using the issuing CA's public key to ensure that the CRL file was issued by a legitimate CA and has not been tampered with. It will also check the CRL file's validity period to determine if the current time is between the CRL file's issuance time (thisUpdate) and its expiration time (nextUpdate), ensuring the CRL file is up-to-date. Once verification is successful, the device will search the CRL file for the sequence number of the currently accessed certificate. If found, it indicates that the currently accessed certificate has been revoked, and the connection will be refused.

[0077] In this embodiment, by obtaining the certificate revocation list, it is possible to verify whether each certificate in the certificate chain array has been revoked, thereby enabling real-time and reliable verification of the certificate status, ensuring that each level of CA certificate and terminal entity certificate in the certificate chain is in a valid state, and thus constructing a complete and reliable certificate chain.

[0078] For example, based on the above embodiments, the terminal device is further configured to: obtain the authorization information access address from the issuing CA extended information of the issuing CA certificate, and send a query message to the server corresponding to the authorization information access address, wherein the query message includes the identification information of the currently traversed certificate; and receive the certificate status of the currently traversed certificate sent by the server, wherein the certificate status includes a normal status or a revoked status.

[0079] Specifically, when performing a certificate status query, the terminal device can also obtain the authorization information access address from the issuing CA's extended information, authorityInfoAccess, and send a query message to the Online Certificate Status Protocol (OCSP) server corresponding to that address. This query message can be an OCSP request, which includes the identification information of the certificate to be queried, such as the certificate serial number and issuer information. After the query, the OCSP server sends an OCSP response to the terminal device. This response includes the certificate status (good / revoked / unknown), response time, and signature of the currently traversed certificates. The terminal device verifies the signature of the OCSP response to ensure that it was issued by an authorized OCSP server. Furthermore, if the certificate status is "revoked," the terminal device will immediately refuse the connection; if the certificate status is "unknown," the terminal device will decide whether to accept the connection based on its policy; if the certificate status is "good," and the CRL check passes, the connection is allowed.

[0080] It should be noted that, in this embodiment of the invention, dual revocation checks of CRL and OCSP can be performed. The aforementioned revocation check mechanism can be executed during the Transport Layer Security (TLS) handshake process. First, the CRL is checked offline by downloading the CRL file, searching for the certificate sequence number, and determining whether the sequence number of the currently traversed certificate is in the CRL file. If it is, the connection is rejected. If not, the OCSP is checked online by sending an OCSP request and receiving an OCSP response, which includes the certificate status. The results of both checks are combined to determine whether to establish a TLS connection. In this dual authentication mechanism, CRL provides offline authentication capabilities, while OCSP provides real-time authentication capabilities, thereby ensuring the accuracy and reliability of the certificate status.

[0081] In this embodiment, by querying the certificate status of each certificate through the OCSP server, it is possible to achieve real-time, online, and accurate query of the certificate revocation status, thereby improving the efficiency of certificate status query.

[0082] Furthermore, based on the above embodiments, the hierarchical certificate issuance system provided by the present invention can also implement an emergency response mechanism, which can quickly handle key leakage events of CAs at different levels.

[0083] For example, the issuing CA device is also used to send a first notification message to the policy CA device in the event of a suspicious event.

[0084] The policy CA device is also used to revoke the issuing CA certificate sent to the issuing CA device based on the first notification message, add the identification information of the revoked issuing CA certificate to the certificate revocation list, and send a first update message to the server. The first update message is used to instruct the server to update the certificate status of the revoked issuing CA certificate.

[0085] The policy CA device is also used to sign new issuing CA certificate signing requests from the issuing CA device using the policy CA private key, thereby obtaining new issuing CA certificates.

[0086] The issuing CA device is also used to obtain a new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate. The new certificate chain is then sent to the terminal device, which includes a self-signed root CA certificate, a policy CA certificate, a new issuing CA certificate, and a new terminal entity certificate.

[0087] Specifically, the issuing CA device monitors abnormal behavior of the CA system. Once a suspicious event is detected, it will immediately trigger an emergency response process and send a first notification message to the policy CA device. Suspicious events include abnormal certificate issuance requests, abnormal key access logs, and HSM alarms.

[0088] Upon receiving the first notification message, the policy-based CA device will immediately revoke the leaked issuing CA certificates, add the identification information of these leaked issuing CA certificates to the CRL, and send a first update message to the OCSP server. The OCSP server, based on the identification information of the leaked issuing CA certificates contained in the first update message, will update the certificate status of these certificates to revoked. The identification information of the issuing CA certificate can be, for example, the serial number of the issuing CA certificate.

[0089] The issuing CA device will generate a new issuing CA key pair in a secure environment, create a new issuing CA certificate signing request based on the new issuing CA key pair, and submit the new issuing CA certificate signing request to the policy CA device.

[0090] The policy-based CA device uses its private key to sign new issuing CA certificate signing requests, thereby issuing new issuing CA certificates and deploying them in the production environment. The issuing CA device uses the new issuing CA private key to sign new terminal certificate signing requests submitted by terminal devices, obtaining new terminal entity certificates to notify all terminal devices that rely on issuing CA certificates to update their certificate chains. The new certificate chain sent to the terminal devices includes the self-signed root CA certificate, the policy-based CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0091] The entire emergency response process described above was completed within 1 hour, and the impact was limited to certificates issued by the issuing CA device.

[0092] In the above embodiments, after the key of the issuing CA device is leaked, the policy CA device will immediately revoke the leaked issuing CA certificate, reissue a new issuing CA certificate, and notify all terminal devices to update the new certificate chain. In this way, the impact of the key leak can be controlled within the business scope of a single issuing CA. Through the rapid isolation, replacement and recovery mechanism, the impact of the security event can be minimized without touching the upper-level root CA and other issuing CAs at the same level, so as to achieve rapid local self-healing of the system and the integrity of the overall trust chain.

[0093] For example, based on the above embodiments, the policy CA device is further configured to send a second notification message to the root CA device when a suspicious event is detected.

[0094] The root CA device is also used to revoke the policy CA certificate sent to the policy CA device based on the second notification message, add the identification information of the revoked policy CA certificate to the certificate revocation list, and send a second update message to the server. The second update message is used to instruct the server to update the certificate status of the revoked policy CA certificate.

[0095] The root CA device is also used to sign new policy CA certificate signing requests from policy CA devices using the root CA private key, thereby obtaining new policy CA certificates.

[0096] The policy CA device is also used to obtain a new policy CA certificate from the root CA device and use the new policy CA private key in the newly generated policy CA key pair to sign the issuance CA certificate signing request from the issuing CA device to obtain a new issuance CA certificate.

[0097] The issuing CA device is also used to obtain a new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate. The new certificate chain is then sent to the terminal device, which includes a self-signed root CA certificate, a new policy CA certificate, a new issuing CA certificate, and a new terminal entity certificate.

[0098] Specifically, the policy-based CA device monitors abnormal behavior of the CA system. Once a suspicious event is detected, it will immediately trigger an emergency response process and send a second notification message to the root CA device. Suspicious events include abnormal certificate issuance requests, abnormal key access logs, and HSM alarms.

[0099] Upon receiving the second notification message, the root CA device will immediately revoke the leaked policy CA certificates, add the identification information of these leaked policy CA certificates to the CRL, and send a second update message to the OCSP server. The OCSP server, based on the identification information of the leaked policy CA certificates contained in the second update message, will update the certificate status of these certificates to revoked. The identification information of the policy CA certificates can be, for example, the serial number of the policy CA certificate.

[0100] The policy CA device will generate a new policy CA key pair in the secure environment, create a new policy CA certificate signing request based on the new policy CA key pair, and submit the new policy CA certificate signing request to the policy CA device.

[0101] The root CA device uses the root CA private key to sign the new policy CA certificate signing request in order to issue a new policy CA certificate.

[0102] Similarly, the issuing CA device will recreate the new issuing CA certificate signing request. The policy CA will then sign the new issuing CA certificate signing request based on the new policy CA private key, thereby obtaining a new issuing CA certificate.

[0103] The issuing CA device uses the new issuing CA's private key to sign the new terminal certificate signing request submitted by the terminal device, obtaining a new terminal entity certificate, and notifies all terminal devices that rely on the issuing CA's certificate to update their certificate chains. The new certificate chain sent to the terminal device includes the self-signed root CA certificate, the new policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0104] The entire emergency response process described above was completed within one day, and the impact was limited to the certificates issued by the CA device under this policy.

[0105] In the above embodiments, when the policy CA key is leaked, the root CA device revokes the leaked policy CA certificate. The policy CA device generates a new policy CA key pair, the root CA issues a new policy CA certificate, the policy CA device reissues the certificates of all issuing CA devices under it, and notifies all terminal devices to update the complete certificate chain. Thus, while ensuring the absolute security of the highest trust anchor point (root CA) without any changes, the entire certificate system rooted in the leaked policy CA can be rebuilt through a step-by-step key and certificate update process. This effectively controls the impact of the leak and maintains the integrity and sustainability of the entire PKI architecture.

[0106] The above methods can achieve layered isolation, minimize the impact of key leakage, and significantly improve the system's emergency response capability and recovery speed.

[0107] In addition, to further enhance the security of certificate management, a key rotation process is automatically triggered for each level of certificate three months before its expiration. This involves generating a new key pair, applying for a new certificate, and having the old and new certificates coexist for a period (usually 1-3 months) to ensure a smooth transition. The old certificate automatically expires upon its expiration, completing the key rotation.

[0108] For example, based on the above embodiments, the root CA's private key is stored in the hardware security module (HSM) of the root CA device; the policy CA device is a semi-offline device, and its private key is stored in its HSM; the issuing CA device is an online device. The root CA device is only used during initialization and key rotation (2-3 times within 10 years), greatly reducing the risk of leakage. The policy CA device only connects to the network when issuing issuing CA certificates and is offline normally. The issuing CA device is responsible for high-frequency daily certificate issuance; even if a leakage occurs, it will only affect a localized area. This mechanism achieves an organic balance between security and availability.

[0109] This configuration provides the highest level of physical security for the private keys of the root CA and policy CA devices, eliminating the risk of key extraction by software. By completely taking the root CA offline, the possibility of it being attacked by the network is fundamentally eliminated. By making the policy CA semi-offline, the risk of leakage is minimized while still meeting the needs of policy management and issuance. Through this layered and differentiated protection strategy, a balance between security strength and business availability is achieved while ensuring the absolute security of the highest-level trust anchor.

[0110] The following describes the method for issuing hierarchical certificates provided by the present invention. The hierarchical certificate issuance method described below can be referred to in correspondence with the hierarchical certificate issuance system described above.

[0111] Figure 2 This is a flowchart illustrating the hierarchical certificate issuance method provided in an embodiment of the present invention, wherein... Figure 2 The execution entity of the method shown is the policy CA device described in the foregoing embodiments. For example... Figure 2 As shown, the method includes: Step 201: Submit a policy CA certificate signing request to the root CA device.

[0112] Step 202: Obtain the policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key.

[0113] Step 203: Use the policy CA private key from the generated policy CA key pair to sign the issuing CA certificate signing request from the issuing CA device to obtain the issuing CA certificate.

[0114] Step 204: Send the issuing CA certificate to the issuing CA device. The issuing CA certificate is used to instruct the issuing CA device to sign the terminal certificate signing request from the terminal device using the issuing CA private key in the generated issuing CA key pair. After obtaining the terminal entity certificate, send the certificate chain to the terminal device. The certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. The self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

[0115] In one example embodiment, the policy CA extended information of the policy CA certificate includes at least one of policy CA path length constraint, policy CA validity period, policy CA subject information, and certificate policy. The certificate policy is used to manage the security policies of different types of terminal devices.

[0116] In one example embodiment, the issuing CA extended information of the issuing CA certificate includes at least one of the following: issuing CA path length constraint, certificate revocation list, and authorization information access address; wherein, the authorization information access address includes the address of the certificate status protocol query service.

[0117] In one example embodiment, the method further includes: Receive a first notification message sent by the issuing CA device, wherein the first notification message is sent by the issuing CA device in response to the detection of a suspicious event; Based on the first notification message, the issuing CA certificate sent to the issuing CA device is revoked, the identification information of the revoked issuing CA certificate is added to the certificate revocation list, and a first update message is sent to the server. The first update message is used to instruct the server to update the certificate status of the revoked issuing CA certificate. Using the policy CA private key, a new issuing CA certificate signing request from the issuing CA device is signed to obtain a new issuing CA certificate. The new issuing CA certificate is used to instruct the issuing CA device to obtain the new issuing CA certificate from the policy CA device. Using the new issuing CA private key in the newly generated issuing CA key pair, a terminal certificate signing request from the terminal device is signed to obtain a new terminal entity certificate. The new certificate chain is then sent to the terminal device. The new certificate chain includes the self-signed root CA certificate, the policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0118] In one example embodiment, the method further includes: Upon detecting a suspicious event, a second notification message is sent to the root CA device. The second notification message is used to instruct the root CA device to revoke the policy CA certificate sent to the policy CA device based on the second notification message, add the identification information of the revoked policy CA certificate to the certificate revocation list, and send a second update message to the server. The second update message is used to instruct the server to update the certificate status of the revoked policy CA certificate. A new policy CA certificate is obtained from the root CA device, and the new policy CA private key in the newly generated policy CA key pair is used to sign the issuing CA certificate signing request from the issuing CA device to obtain a new issuing CA certificate. The new policy CA certificate is obtained by the root CA device using the root CA private key to sign the new policy CA certificate signing request from the policy CA device. The new issuing CA certificate is used to instruct the issuing CA device to obtain the new issuing CA certificate from the policy CA device, and to sign the terminal certificate signing request from the terminal device using the new issuing CA private key in the newly generated issuing CA key pair to obtain a new terminal entity certificate. The new certificate chain is then sent to the terminal device, and the new certificate chain includes the self-signed root CA certificate, the new policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0119] In one example embodiment, the root CA private key is stored in the hardware security module (HSM) of the root CA device; the policy CA device is a semi-offline device, and the policy CA private key is stored in the HSM of the policy CA device; the issuing CA device is an online device.

[0120] The method in this embodiment can be used in any embodiment of the hierarchical certificate issuance system side embodiment. Its specific implementation process and technical effects are similar to those in the hierarchical certificate issuance system side embodiment. For details, please refer to the detailed description in the hierarchical certificate issuance system side embodiment, which will not be repeated here.

[0121] The following describes the hierarchical certificate issuing apparatus provided by the present invention. The hierarchical certificate issuing apparatus described below can be referred to in correspondence with the hierarchical certificate issuing method described above.

[0122] Figure 3 This is a schematic diagram of the structure of the tiered certificate issuing device provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the tiered certificate issuing device 300 includes: Submission module 11 is used to submit a policy CA certificate signing request to the root CA device; The acquisition module 12 is used to acquire the policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key; The signature module 13 is used to sign the issuance CA certificate signature request from the issuance CA device using the policy CA private key in the generated policy CA key pair, so as to obtain the issuance CA certificate. The sending module 14 is used to send the issuing CA certificate to the issuing CA device. The issuing CA certificate is used to instruct the issuing CA device to use the issuing CA private key in the generated issuing CA key pair to sign the terminal certificate signing request from the terminal device. After obtaining the terminal entity certificate, the certificate chain is sent to the terminal device. The certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. The self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

[0123] In one example embodiment, the policy CA extended information of the policy CA certificate includes at least one of policy CA path length constraint, policy CA validity period, policy CA subject information, and certificate policy. The certificate policy is used to manage the security policies of different types of terminal devices.

[0124] In one example embodiment, the issuing CA extended information of the issuing CA certificate includes at least one of the following: issuing CA path length constraint, certificate revocation list, and authorization information access address; wherein, the authorization information access address includes the address of the certificate status protocol query service.

[0125] In one example embodiment, the device further includes: The receiving module is used to receive a first notification message sent by the issuing CA device, wherein the first notification message is sent by the issuing CA device when a suspicious event is detected; The processing module is configured to revoke the issuing CA certificate sent to the issuing CA device based on the first notification message, add the identification information of the revoked issuing CA certificate to the certificate revocation list, and send a first update message to the server, wherein the first update message is used to instruct the server to update the certificate status of the revoked issuing CA certificate. The signature module 13 is further configured to use the policy CA private key to sign a new issuing CA certificate signing request from the issuing CA device to obtain a new issuing CA certificate; the new issuing CA certificate is used to instruct the issuing CA device to obtain the new issuing CA certificate from the policy CA device, and to use the new issuing CA private key in the newly generated issuing CA key pair to sign a terminal certificate signing request from the terminal device to obtain a new terminal entity certificate, and to send the new certificate chain to the terminal device, the new certificate chain including the self-signed root CA certificate, the policy CA certificate, the new issuing CA certificate and the new terminal entity certificate.

[0126] In one example embodiment, the sending module The sending module 14 is further configured to send a second notification message to the root CA device when a suspicious event is detected. The second notification message is configured to instruct the root CA device to revoke the policy CA certificate sent to the policy CA device based on the second notification message, add the identification information of the revoked policy CA certificate to the certificate revocation list, and send a second update message to the server. The second update message is configured to instruct the server to update the certificate status of the revoked policy CA certificate. The processing module is further configured to obtain a new policy CA certificate from the root CA device, and use the new policy CA private key in the newly generated policy CA key pair to sign the issuing CA certificate signing request from the issuing CA device to obtain a new issuing CA certificate; the new policy CA certificate is obtained by the root CA device using the root CA private key to sign the new policy CA certificate signing request from the policy CA device. The new issuing CA certificate is used to instruct the issuing CA device to obtain the new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate, and send the new certificate chain to the terminal device. The new certificate chain includes the self-signed root CA certificate, the new policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

[0127] In one example embodiment, the root CA private key is stored in the hardware security module (HSM) of the root CA device; the policy CA device is a semi-offline device, and the policy CA private key is stored in the HSM of the policy CA device; the issuing CA device is an online device.

[0128] The apparatus of this embodiment can be used in any of the methods in the hierarchical certificate issuance method side embodiment. Its specific implementation process and technical effects are similar to those in the hierarchical certificate issuance method side embodiment. For details, please refer to the detailed description in the hierarchical certificate issuance method side embodiment, which will not be repeated here.

[0129] Figure 4 This is a schematic diagram of the physical structure of an electronic device provided in an embodiment of the present invention, such as... Figure 4 As shown, the electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communications bus 440, wherein the processor 410, the communications interface 420, and the memory 430 communicate with each other through the communications bus 440. The processor 410 can invoke logical instructions in the memory 430 to execute a hierarchical certificate issuance method, the method comprising: submitting a policy CA certificate signing request to a root CA device; obtaining a policy CA certificate from the root CA device, the policy CA certificate being obtained by the root CA device signing the policy CA certificate signing request using a root CA private key; signing an issuance CA certificate signing request from an issuing CA device using a policy CA private key from a generated policy CA key pair, thereby obtaining an issuance CA certificate; sending the issuance CA certificate to the issuing CA device, the issuance CA certificate being used to instruct the issuing CA device to sign a terminal certificate signing request from a terminal device using a generated issuance CA private key from a generated issuance CA key pair, thereby obtaining a terminal entity certificate, and then sending a certificate chain to the terminal device, the certificate chain comprising a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate, wherein the self-signed root CA certificate is a certificate generated by the root CA device based on a root CA key pair.

[0130] Furthermore, the logical instructions in the aforementioned memory 430 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0131] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the hierarchical certificate issuance method provided by the above methods. The method includes: submitting a policy CA certificate signing request to a root CA device; obtaining a policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key; signing the issuance CA certificate signing request from the issuing CA device using the policy CA private key in the generated policy CA key pair to obtain an issuance CA certificate; sending the issuance CA certificate to the issuing CA device, wherein the issuance CA certificate is used to instruct the issuing CA device to sign a terminal certificate signing request from a terminal device using the issuance CA private key in the generated issuance CA key pair to obtain a terminal entity certificate; and sending a certificate chain to the terminal device, wherein the certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate, wherein the self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

[0132] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for issuing hierarchical certificates provided by the above methods. The method includes: submitting a policy CA certificate signing request to a root CA device; obtaining a policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using a root CA private key; signing an issuing CA certificate signing request from an issuing CA device using a policy CA private key in a generated policy CA key pair to obtain an issuing CA certificate; sending the issuing CA certificate to the issuing CA device, wherein the issuing CA certificate instructs the issuing CA device to sign a terminal certificate signing request from a terminal device using a generating issuing CA private key in a issuing CA key pair to obtain a terminal entity certificate; and sending a certificate chain to the terminal device, wherein the certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate, wherein the self-signed root CA certificate is a certificate generated by the root CA device based on a root CA key pair.

[0133] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0134] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0135] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A tiered certificate issuance system, characterized in that, It includes a root CA device, a policy CA device, and a certificate issuing CA device, wherein the root CA device is an offline device, and: The root CA device is used to generate a self-signed root CA certificate based on the root CA key pair, and to sign the policy CA certificate signing request from the policy CA device using the root CA private key to obtain the policy CA certificate. The policy CA device is used to obtain the policy CA certificate from the root CA device and use the policy CA private key in the generated policy CA key pair to sign the issuance CA certificate signing request from the issuing CA device to obtain the issuance CA certificate. The issuing CA device is used to obtain the issuing CA certificate from the policy CA device, and use the issuing CA private key in the generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain the terminal entity certificate. The issuing CA device is further configured to send a certificate chain to the terminal device, the certificate chain including the self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate.

2. The tiered certificate issuance system according to claim 1, characterized in that, The root CA device is specifically used for: Generate the root CA key pair, and use the root CA private key to sign the root CA public key and the root CA extended information to obtain the self-signed root CA certificate. The root CA extended information includes at least one of the following: root CA path length constraint, root CA validity period, and root CA subject information.

3. The tiered certificate issuance system according to claim 1, characterized in that, The policy CA certificate's extended policy CA information includes at least one of the following: policy CA path length constraint, policy CA validity period, policy CA subject information, and certificate policy. The certificate policy is used to manage the security policies of different types of terminal devices.

4. The tiered certificate issuance system according to claim 1, characterized in that, The extended information of the issuing CA certificate includes at least one of the following: issuing CA path length constraint, certificate revocation list, and authorization information access address; wherein the authorization information access address includes the address of the certificate status protocol query service.

5. The tiered certificate issuance system according to claim 3, characterized in that, The issuing CA device is specifically used for: If it is determined that the terminal identifier in the terminal certificate signing request is a registered identifier, the signature of the terminal certificate signing request is valid, and the extended fields in the terminal certificate signing request conform to the security policy corresponding to the terminal device in the certificate policy, the terminal certificate signing request is signed using the issuing CA private key to obtain the terminal entity certificate.

6. The tiered certificate issuance system according to claim 1, characterized in that, The system further includes a terminal device, wherein the terminal device is used for: The certificate chain is parsed to obtain a certificate chain array, which includes the self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. Traverse each certificate in the certificate chain array, and determine the remaining path length corresponding to the currently traversed certificate based on the length of the certificate chain array and the index number of the currently traversed certificate in the certificate chain array; If the path length constraint in the currently traversed certificate is less than the remaining path length, the certificate chain verification is determined to have failed.

7. The tiered certificate issuance system according to claim 6, characterized in that, The terminal device is further configured to obtain a certificate revocation list from the issuing CA extended information of the issuing CA certificate, and if it is determined that the certificate currently being traversed is in the certificate revocation list, determine that the certificate currently being traversed has been revoked.

8. The tiered certificate issuance system according to claim 7, characterized in that, The terminal device is also used for: Obtain the authorization information access address from the issuing CA extended information of the issuing CA certificate, and send a query message to the server corresponding to the authorization information access address. The query message includes the identification information of the certificate being traversed. Receive the certificate status of the currently traversed certificates sent by the server, the certificate status including normal status or revoked status.

9. The tiered certificate issuance system according to claim 8, characterized in that, The issuing CA device is also used to send a first notification message to the policy CA device when a suspicious event is detected. The policy CA device is further configured to revoke the issuing CA certificate sent to the issuing CA device based on the first notification message, add the identification information of the revoked issuing CA certificate to the certificate revocation list, and send a first update message to the server, wherein the first update message is used to instruct the server to update the certificate status of the revoked issuing CA certificate. The policy CA device is also used to sign a new issuing CA certificate signing request from the issuing CA device using the policy CA private key, thereby obtaining a new issuing CA certificate. The issuing CA device is further configured to obtain the new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate, and send the new certificate chain to the terminal device. The new certificate chain includes the self-signed root CA certificate, the policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

10. The tiered certificate issuance system according to claim 8, characterized in that, The policy CA device is also used to send a second notification message to the root CA device when a suspicious event is detected. The root CA device is further configured to revoke the policy CA certificate sent to the policy CA device based on the second notification message, add the identification information of the revoked policy CA certificate to the certificate revocation list, and send a second update message to the server, wherein the second update message is used to instruct the server to update the certificate status of the revoked policy CA certificate. The root CA device is also used to sign a new policy CA certificate signing request from the policy CA device using the root CA private key, thereby obtaining a new policy CA certificate. The policy CA device is also used to obtain the new policy CA certificate from the root CA device, and use the new policy CA private key in the newly generated policy CA key pair to sign the issuance CA certificate signing request from the issuing CA device to obtain a new issuance CA certificate. The issuing CA device is further configured to obtain the new issuing CA certificate from the policy CA device, and use the new issuing CA private key in the newly generated issuing CA key pair to sign the terminal certificate signing request from the terminal device to obtain a new terminal entity certificate, and send the new certificate chain to the terminal device. The new certificate chain includes the self-signed root CA certificate, the new policy CA certificate, the new issuing CA certificate, and the new terminal entity certificate.

11. The tiered certificate issuance system according to any one of claims 1-10, characterized in that, The root CA private key is stored in the hardware security module (HSM) of the root CA device; the policy CA device is a semi-offline device, and the policy CA private key is stored in the HSM of the policy CA device; the issuing CA device is an online device.

12. A method for issuing tiered certificates, characterized in that, include: Submit a policy CA certificate signing request to the root CA device; Obtain the policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key; Using the policy CA private key in the generated policy CA key pair, the issuing CA certificate signing request from the issuing CA device is signed to obtain the issuing CA certificate; The issuing CA certificate is sent to the issuing CA device. The issuing CA certificate is used to instruct the issuing CA device to sign the terminal certificate signing request from the terminal device using the issuing CA private key in the generated issuing CA key pair. After obtaining the terminal entity certificate, the certificate chain is sent to the terminal device. The certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. The self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

13. A tiered certificate issuing device, characterized in that, include: The submission module is used to submit policy CA certificate signing requests to the root CA device; The acquisition module is used to acquire the policy CA certificate from the root CA device, wherein the policy CA certificate is obtained by the root CA device signing the policy CA certificate signing request using the root CA private key; The signature module is used to sign the issuing CA certificate signature request from the issuing CA device using the policy CA private key in the generated policy CA key pair, so as to obtain the issuing CA certificate. The sending module is used to send the issuing CA certificate to the issuing CA device. The issuing CA certificate is used to instruct the issuing CA device to use the issuing CA private key in the generated issuing CA key pair to sign the terminal certificate signing request from the terminal device. After obtaining the terminal entity certificate, the certificate chain is sent to the terminal device. The certificate chain includes a self-signed root CA certificate, the policy CA certificate, the issuing CA certificate, and the terminal entity certificate. The self-signed root CA certificate is a certificate generated by the root CA device based on the root CA key pair.

14. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the method for issuing hierarchical certificates as described in claim 12.

15. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for issuing hierarchical certificates as described in claim 12.

16. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the method for issuing hierarchical certificates as described in claim 12.

Images