A three-party collaborative double-certificate issuing method and system

Abstract

The application belongs to the technical field of password application, and discloses a three-party cooperative double-certificate issuing method and system, which comprises the following steps: generating an entity identifier of a certificate authority based on a hash digest, and combining a random task number to encapsulate a key service request; signing the key service request by using a hardware cryptographic machine to generate a request structure of the certificate authority, and extracting key data and registering a callback event after response verification; building an encrypted certificate through the hardware cryptographic machine; binding the signed certificate and the encrypted certificate through an association identifier field, and persisting in the same database transaction; building a certificate response message after the persistence is completed, and returning the certificate response message to the registration authority. The three-party cooperation of the RA, the CA and the KMC can be completed in a single CMP request, the double certificate and the encrypted private key ciphertext in the digital envelope format are returned at one time through the CMP response, and the state management complexity and the data inconsistency risk caused by multiple request interactions are avoided.

Description

Technical Field

[0001] This invention relates to the field of cryptographic application technology, and in particular to a three-party collaborative dual certificate issuance method and system. Background Technology

[0002] According to the requirements of GM / T0034-2014 "Cryptography and Related Security Technical Specifications for Certificate Authentication Systems Based on SM2 Cryptographic Algorithm", the national cryptographic PKI system adopts a "dual certificate" model—the same entity simultaneously holds a signature certificate and an encryption certificate. The key pair for the signature certificate is generated by the user to ensure the non-repudiation of the signing behavior; the key pair for the encryption certificate is uniformly generated and managed by the Key Management Center (KMC) to realize centralized management and recovery capabilities of encryption keys.

[0003] The dual-certificate issuance process involves collaboration among a Registration Authority (RA), a Certificate Authority (CA), and a Key Management Center (KMC), spanning two protocols: the Certificate Management Protocol (CMP) (RFC4210), used for communication between the RA and CA for certificate application, issuance, revocation, and other management operations; and the GM / T0014-2012 Cryptographic Protocol Specification for Digital Certificate Authentication Systems, used for communication between the CA and KMC for key application, key recovery, key revocation, and other key management operations. The CA must first apply for an encryption key from the KMC via the GM / T0014 protocol, then construct an encryption certificate based on the public key returned by the KMC, and finally persist it along with the signing certificate and return it to the RA via the CMP protocol. This process demands extremely high transaction consistency.

[0004] Furthermore, in the Chinese national cryptographic PKI system, the Hardware Cryptographic Machine (HSM) plays a fundamental role in cryptographic operations and secure key storage. The private key of the issuing CA is hosted in the HSM, and all signing operations involving the CA's private key (such as certificate signing and protocol message signing) are completed through the HSM interface, ensuring that the private key does not exceed the hardware security boundary.

[0005] However, traditional dual-certificate issuance technology has the following defects or shortcomings: 1. Lack of a complete solution for completing three-party collaborative signing in a single request: In the dual-certificate signing process, existing CA systems typically process the signing certificate and encryption certificate as independent processes, or require the RA to initiate multiple requests and maintain intermediate states of multi-step interactions. Existing technologies lack a complete solution for completing RA→CA→KMC three-party collaboration in a single CMP request, simultaneously issuing the signing certificate and encryption certificate, and atomically persisting them.

[0006] 2. Lack of cross-system transaction compensation mechanism between CA and KMC: In the dual certificate issuance process, if a business anomaly (such as database write failure) occurs after the CA successfully applies for an encryption key from the KMC via the GM / T0014 protocol but before the certificate is stored in the database, the CA's transaction is rolled back. However, the key already generated on the KMC side cannot be automatically rolled back with the CA's transaction, resulting in an "orphaned key" on the KMC. Existing CA systems generally lack cross-system transaction compensation mechanisms, and because the CA and KMC communicate via network, atomicity cannot be guaranteed using traditional distributed transactions (two-phase commit / XA protocol).

[0007] 3. Lack of a systematic communication security authentication mechanism between CA and KMC: In the dual certificate issuance process, key request and response between CA and KMC need to be transmitted over the network, which poses a risk of tampering or forgery. In existing technologies, some implementations lack two-way signature authentication for requests and responses, or use software signing methods that result in the private key existing in the application's memory, lacking hardware-level key protection and anti-replay mechanisms.

[0008] There are currently no effective solutions to the problems in the relevant technologies. Summary of the Invention

[0009] This invention provides a three-party collaborative dual-certificate issuance method and system to solve the problems mentioned above in the prior art.

[0010] According to a first aspect of the present invention, a method for issuing dual certificates through tripartite collaboration is provided.

[0011] In one embodiment, the tripartite collaborative dual-certificate issuance method includes: Signature certificate construction: The registration authority initiates a certificate management protocol request. The certificate authority receives the request and verifies the algorithm identifier of the user's public key. After the verification is successful, a signature certificate is constructed using a hardware cryptographic machine. Encryption key request: Generate the entity identifier of the Certificate Authority based on the hash digest, and encapsulate it with a random task number to obtain the key service request; use a hardware cryptographic machine to sign the key service request, generate the request structure of the Certificate Authority, and use the Certificate Authority to verify the response. After successful verification, extract the key data and register a callback event. Encryption certificate construction: Extract the encryption public key from the key data as the main public key, and combine it with the subject name, encryption certificate-specific extended configuration and the preset standard fields of the encryption certificate to construct the encryption certificate through a hardware cryptographic machine. The subject name and issuer subject name of the encryption certificate are the same as those of the signing certificate. Dual-certificate atomic persistence and response: The signing certificate and the encryption certificate are bound by the associated identifier field and persisted in the same database transaction; after persistence is completed, a certificate response message is constructed and the public key infrastructure message protected by the certificate authority is returned to the registration authority. Specifically, when an anomaly occurs during the construction of the encrypted certificate and the atomic persistence and response of the dual certificates, causing the business transaction to roll back, a distributed compensation based on the transaction event monitoring mechanism is executed to notify the key management center to clean up the allocated keys, so as to ensure the key consistency between the certificate authority and the key management center.

[0012] In one embodiment, the step of initiating a certificate management protocol request through a registration authority, the certificate authority receiving the request and verifying the algorithm identifier of the user's public key, and then constructing a signature certificate using a hardware cryptographic machine after successful verification includes: The registration authority initiates a certificate management protocol request to the certificate authority; the certificate authority receives the certificate management protocol request and extracts the user's public key and subject name from the request. Obtain the algorithm identifier of the user's public key. When the algorithm identifier is of general elliptic curve type, convert the user's public key into an elliptic curve public key object and extract the object identifier from the algorithm parameters. When the object identifier is the object identifier of the SM2 curve, the correction algorithm identifier is SM2, and the corrected algorithm identifier is compared with the key algorithm of the signature certificate template and the key algorithm of the encryption certificate template respectively. If any mismatch occurs, the issuance is rejected. Based on the subject name and user public key, combined with preset standard fields, a signature certificate is constructed by calling the private key of the issuer's certificate authority through a hardware cryptographic machine; The signature value of the signature certificate is verified using the public key of the certificate authority that issued the certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, the issuance is terminated and an error is displayed.

[0013] In one embodiment, the step of constructing a signature certificate by invoking the private key of the issuing certificate authority via a hardware cryptographic machine, based on the subject name and user public key, combined with preset standard fields, includes: Obtain the cryptographic token and key reference of the issuing certificate authority in the hardware cryptographic machine; Set the version number, signature certificate serial number, issuer subject name, validity period, subject name, subject public key information and signature algorithm identifier, and load the extended field configuration specific to the signature certificate in the certificate template; Use a key tool to obtain the content signer supported by the hardware cryptographic machine, and call the hardware cryptographic machine interface to sign using the private key of the issuer's certificate authority to generate a complete signature certificate.

[0014] In one embodiment, the process of generating a Certificate Authority (CA) entity identifier based on a hash digest and encapsulating it with a random task number to obtain a key service request; signing the key service request using a hardware cryptographic machine to generate a CA request structure; and verifying the response using the CA, followed by extracting key data and registering callback events after successful verification, includes: Extract the subject public key information structure from the issuer's certificate authority, calculate the SM3 hash digest of the DER-encoded byte sequence in the subject public key information structure, and use the obtained hash value as the public key fingerprint of the issuer's certificate authority. Integrate the hash value, the issuer's subject name, and the certificate serial number of the issuer's certificate authority to form the entity identifier structure of the certificate authority. The encryption certificate serial number, user signature public key, certificate validity period, key algorithm identifier and key length are encapsulated into a key request structure, and together with the entity identifier structure of the certificate authority and the randomly generated task number, they are encapsulated into a key service request structure. The key service request structure is DER encoded to obtain the byte sequence to be signed. The hardware cryptographic machine is called to sign the byte sequence to be signed using the private key of the issuing certificate authority. The signature algorithm identifier, signature value and key service request are encapsulated together into the certificate authority request structure and sent to the key management center. The key management center receives the request structure, processes it, and returns a key service response signed by the key management center's own private key; the certificate authority receives the key service response returned by the key management center and verifies the response; After successful verification, the SM2 public key and the encrypted private key in data envelope format are extracted from the key service response. The key management center callback event is then published to the application event bus via the in-process event publisher. The callback event payload includes the connection information of the key management center, the key reference of the issuer's certificate authority, the signature algorithm identifier, the issuer subject name, the encryption certificate serial number, and the key request type identifier.

[0015] In one embodiment, the response verification includes verifying the response signature using a pre-configured key management center certificate public key, verifying the consistency between the key management center certificate serial number in the response and the pre-configured value, and verifying the consistency between the task number in the response and the task number in the request.

[0016] In one embodiment, the extraction of the encryption public key from the key data as the subject public key, combined with the subject name, encryption certificate-specific extended configuration, and preset standard fields of the encryption certificate, to construct an encryption certificate via a hardware cryptographic machine includes: The public key information structure in the SM2 encryption public key is encoded and parsed into an elliptic curve public key object to obtain the parsed encryption public key. The parsed public key is used as the main public key of the encryption certificate, the subject name is used as the certificate subject name, and the encryption certificate is constructed by calling the private key of the issuing certificate authority through a hardware cryptographic machine, along with the encryption certificate’s exclusive extended configuration and the encryption certificate’s independent serial number and validity period standard fields. The signature value of the encrypted certificate is verified using the public key of the certificate authority that issued the certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, the issuance is terminated and an error message is displayed.

[0017] In one embodiment, binding the signing certificate and the encryption certificate through an association identifier field and persisting them in the same database transaction; constructing a certificate response message after persistence and returning the public key infrastructure message, protected by the certificate authority's signature, to the registration authority includes: In the data record of the signing certificate, the signing certificate and the encryption certificate are bound one-to-one through the encryption certificate association identifier field, and the fields of the signing certificate and the encryption certificate are persisted to the database in the same business transaction; After persistence is complete, a certificate response message for the certificate management protocol is constructed. The certificate response message includes a certificate response body carrying the signed certificate and a certificate response body carrying the encryption certificate and encryption key structure. The two certificate response bodies are encapsulated into a complete public key infrastructure message and returned to the registration authority after being signed and protected by the issuer's certificate authority.

[0018] In one embodiment, the execution of distributed compensation based on a transaction event monitoring mechanism, and the notification to the key management center to clean up the allocated keys, includes: The Key Management Center callback event listener receives callback events as input parameters and extracts compensation data from the event payload, including the connection information of the Key Management Center, the key reference of the issuer's certificate authority, the signature algorithm identifier, the issuer's subject name, the encryption certificate serial number, and the key request type identifier. Retrieve the fields of issuer subject name, encryption certificate serial number and key request type identifier, and serialize the fields into structured data in a preset format as the callback request body; Obtain the key reference and signature algorithm identifier of the issuing certificate authority, call the hardware cryptographic machine, sign the byte sequence of the callback request body in combination with the private key of the issuing certificate authority, put the signature value into the preset HTTP request header field, put the signature algorithm identifier into the signature algorithm request header field, and obtain the signature request header. Obtain the connection information of the key management center and send a callback request body and a signature request header to the callback interface of the key management center; The key management center receives the request, extracts the signature value and signature algorithm from the signature request header, uses the pre-configured public key of the issuer's certificate authority to sign and verify the request body, and cleans up the corresponding orphaned key according to the encryption certificate serial number and key request type identifier after the verification is successful. After the callback request is executed, in the transaction rollback awareness step, the compensation execution record is written to the rollback log table in an independent transaction started with an independent new transaction propagation strategy.

[0019] In one embodiment, after extracting the compensation data, a triple mechanism combination is used to ensure the reliable execution of the compensation. The triple mechanism combination includes transaction rollback phase monitoring, independent new transaction propagation, and asynchronous thread pool execution.

[0020] According to a second aspect of the present invention, a three-party collaborative dual certificate issuance system is provided.

[0021] In one embodiment, the tripartite collaborative dual-certificate issuance system includes: The signature certificate construction module is used to initiate a certificate management protocol request through the registration authority. The certificate authority receives the request and verifies the algorithm identifier of the user's public key. After the verification is successful, it uses a hardware cryptographic machine to construct a signature certificate. The encryption key request module is used to generate the entity identifier of the Certificate Authority based on the hash digest, and encapsulate it with a random task number to obtain the key service request; the key service request is signed using a hardware cryptographic machine to generate the request structure of the Certificate Authority, and the response is verified using the Certificate Authority. After successful verification, the key data is extracted and a callback event is registered. The encryption certificate building module is used to extract the encryption public key from the key data as the main public key, and combine it with the subject name, encryption certificate-specific extended configuration and the preset standard fields of the encryption certificate to build an encryption certificate through a hardware cryptographic machine. The subject name and issuer subject name of the encryption certificate are the same as those of the signing certificate. The dual-certificate atomic persistence and response module is used to bind the signing certificate and the encryption certificate through the association identifier field and persist them in the same database transaction; after persistence is completed, a certificate response message is constructed and the public key infrastructure message protected by the certificate authority is returned to the registration authority. The distributed compensation module is used to perform distributed compensation based on the transaction event monitoring mechanism when an exception occurs during the construction of the encrypted certificate and the atomic persistence and response of the dual certificate, causing the business transaction to roll back. This notifies the key management center to clean up the allocated keys, so as to ensure the key consistency between the certificate authority and the key management center.

[0022] According to a third aspect of the present invention, a computer device is provided.

[0023] In some embodiments, the computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the method described above.

[0024] According to a fourth aspect of the present invention, a computer-readable storage medium is provided.

[0025] In one embodiment, a computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the above method.

[0026] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: 1) Three-party collaborative atomic signing: This invention can complete the three-party collaboration of RA→CA→KMC in a single CMP request. The signing certificate (submitted by the user) and the encryption certificate (generated by KMC) are constructed and persisted in the same business transaction. The CMP response returns the encrypted private key ciphertext in the format of dual certificates and digital envelope in one go, avoiding the complexity of state management and the risk of data inconsistency caused by multiple request interactions.

[0027] 2) Hardware cryptographic machine full-link signature protection: The certificate signing, KMC key application request signing, and rollback compensation callback signing of this invention are all completed through a hardware cryptographic machine (HSM). The private key does not exceed the hardware security boundary. The CA and KMC achieve two-way identity authentication through request signing and response signing. Combined with random task number anti-replay verification, the integrity and unforgeability of the cross-system communication link are guaranteed.

[0028] 3) CA entity identifier using SM3 public key hash: This invention uses the SM3 algorithm to hash the SubjectPublicKeyInfo DER encoding of the issuer's CA public key to generate a CA entity identifier. This can uniquely identify the CA from which the request originates while avoiding the exposure of complete public key information in the protocol message, thus reducing the key information leakage surface.

[0029] 4) Distributed key consistency guarantee: This invention uses a triple mechanism combination of "transaction rollback phase listening (AFTER_ROLLBACK) + independent new transaction propagation (REQUIRES_NEW) + asynchronous thread pool execution" to automatically trigger the compensation process after the CA business transaction is rolled back. After hardware cryptographic machine signature authentication, the KMC is notified to clean up the allocated orphaned keys. The compensation operation is completely isolated from the business transaction and does not block the business thread. At the same time, the audit log is persisted regardless of whether the compensation is successful or not, thus achieving eventual consistency guarantee across systems.

[0030] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0031] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0032] Figure 1 This is a flowchart illustrating a three-party collaborative dual-certificate issuance method according to an exemplary embodiment; Figure 2 This is a structural block diagram illustrating a three-party collaborative dual-certificate issuance according to an exemplary embodiment; Figure 3 This is an overall architecture diagram of an SM2 dual-certificate collaborative issuance and key consistency guarantee system based on the GM / T 0014 protocol, according to an exemplary embodiment. Figure 4 This is a flowchart illustrating the collaborative issuance process of SM2 dual certificates according to an exemplary embodiment; Figure 5 This is a flowchart illustrating a transaction rollback compensation process according to an exemplary embodiment; Figure 6 This is a schematic diagram of the structure of a computer device according to an exemplary embodiment. Detailed Implementation

[0033] The following description and accompanying drawings fully illustrate specific embodiments described herein to enable those skilled in the art to practice them. Some portions and features of certain embodiments may be included in or replace portions and features of other embodiments. The scope of the embodiments herein includes the entire scope of the claims and all available equivalents thereof. The various embodiments described herein are presented in a progressive manner, with each embodiment focusing on its differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0034] The modules in the apparatus or system of this application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0035] Where there is no conflict, the embodiments and features in the embodiments of the present invention can be combined with each other.

[0036] Figure 1 An embodiment of a three-party collaborative dual certificate issuance method of the present invention is shown.

[0037] In this optional embodiment, the three-party collaborative dual-certificate issuance method includes: Step S101, Signature Certificate Construction: The registration authority initiates a certificate management protocol request. The certificate authority receives the request and verifies the algorithm identifier of the user's public key. After the verification is successful, a signature certificate is constructed using a hardware cryptographic machine. Step S102, Encryption Key Request: Generate the entity identifier of the Certificate Authority based on the hash digest, and encapsulate it with the random task number to obtain the key service request; use a hardware cryptographic machine to sign the key service request, generate the request structure of the Certificate Authority, and use the Certificate Authority to verify the response. After successful verification, extract the key data and register the callback event. Step S103, Encryption Certificate Construction: Extract the encryption public key from the key data as the main public key, and combine it with the subject name, encryption certificate-specific extended configuration and the preset standard fields of the encryption certificate to construct the encryption certificate through a hardware cryptographic machine. The subject name and issuer subject name of the encryption certificate are the same as those of the signing certificate. Step S104, Atomic Persistence and Response of Dual Certificates: Bind the signing certificate and the encryption certificate through the association identifier field and persist them in the same database transaction; after persistence is completed, construct the certificate response message and return the public key infrastructure message protected by the certificate authority's signature to the registration authority; Specifically, when an anomaly occurs during the construction of the encrypted certificate and the atomic persistence and response of the dual certificates, causing the business transaction to roll back, a distributed compensation based on the transaction event monitoring mechanism is executed to notify the key management center to clean up the allocated keys, so as to ensure the key consistency between the certificate authority and the key management center.

[0038] In this optional embodiment, the step of initiating a certificate management protocol request through a registration authority, the certificate authority receiving the request and verifying the algorithm identifier of the user's public key, and then constructing a signature certificate using a hardware cryptographic machine after successful verification includes: The registration authority initiates a certificate management protocol request to the certificate authority; the certificate authority receives the certificate management protocol request and extracts the user's public key and subject name from the request. Obtain the algorithm identifier of the user's public key. When the algorithm identifier is of general elliptic curve type, convert the user's public key into an elliptic curve public key object and extract the object identifier from the algorithm parameters. When the object identifier is the object identifier of the SM2 curve, the correction algorithm identifier is SM2, and the corrected algorithm identifier is compared with the key algorithm of the signature certificate template and the key algorithm of the encryption certificate template respectively. If any mismatch occurs, the issuance is rejected. Based on the subject name and user public key, combined with preset standard fields, a signature certificate is constructed by calling the private key of the issuer's certificate authority through a hardware cryptographic machine; The signature value of the signature certificate is verified using the public key of the certificate authority that issued the certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, the issuance is terminated and an error is displayed.

[0039] In this optional embodiment, the step of constructing a signature certificate by calling the private key of the issuer's certificate authority through a hardware cryptographic machine, based on the subject name and user public key, combined with preset standard fields, includes: Obtain the cryptographic token and key reference of the issuing certificate authority in the hardware cryptographic machine; Set the version number, signature certificate serial number, issuer subject name, validity period, subject name, subject public key information and signature algorithm identifier, and load the extended field configuration specific to the signature certificate in the certificate template; Use a key tool to obtain the content signer supported by the hardware cryptographic machine, and call the hardware cryptographic machine interface to sign using the private key of the issuer's certificate authority to generate a complete signature certificate.

[0040] In this optional embodiment, the step of generating a certificate authority entity identifier based on a hash digest and encapsulating it with a random task number to obtain a key service request; signing the key service request using a hardware cryptographic machine to generate a certificate authority request structure; and using the certificate authority to verify the response, extracting key data and registering callback events after successful verification includes: Extract the subject public key information structure from the issuer's certificate authority, calculate the SM3 hash digest of the DER-encoded byte sequence in the subject public key information structure, and use the obtained hash value as the public key fingerprint of the issuer's certificate authority. Integrate the hash value, the issuer's subject name, and the certificate serial number of the issuer's certificate authority to form the entity identifier structure of the certificate authority. The encryption certificate serial number, user signature public key, certificate validity period, key algorithm identifier and key length are encapsulated into a key request structure, and together with the entity identifier structure of the certificate authority and the randomly generated task number, they are encapsulated into a key service request structure. The key service request structure is DER encoded to obtain the byte sequence to be signed. The hardware cryptographic machine is called to sign the byte sequence to be signed using the private key of the issuing certificate authority. The signature algorithm identifier, signature value and key service request are encapsulated together into the certificate authority request structure and sent to the key management center. The key management center receives the request structure, processes it, and returns a key service response signed by the key management center's own private key; the certificate authority receives the key service response returned by the key management center and verifies the response; After successful verification, the SM2 public key and the encrypted private key in data envelope format are extracted from the key service response. The key management center callback event is then published to the application event bus via the in-process event publisher. The callback event payload includes the connection information of the key management center, the key reference of the issuer's certificate authority, the signature algorithm identifier, the issuer subject name, the encryption certificate serial number, and the key request type identifier.

[0041] In this optional embodiment, the response verification includes verifying the response signature using a pre-configured key management center certificate public key, verifying the consistency between the key management center certificate serial number in the response and the pre-configured value, and verifying the consistency between the task number in the response and the task number in the request.

[0042] In this optional embodiment, the extraction of the encryption public key from the key data, which serves as the principal public key, and the construction of the encryption certificate via a hardware cryptographic machine, in conjunction with the subject name, the encryption certificate's proprietary extended configuration, and the preset standard fields of the encryption certificate, includes: The public key information structure in the SM2 encryption public key is encoded and parsed into an elliptic curve public key object to obtain the parsed encryption public key. The parsed public key is used as the main public key of the encryption certificate, the subject name is used as the certificate subject name, and the encryption certificate is constructed by calling the private key of the issuing certificate authority through a hardware cryptographic machine, along with the encryption certificate’s exclusive extended configuration and the encryption certificate’s independent serial number and validity period standard fields. The signature value of the encrypted certificate is verified using the public key of the certificate authority that issued the certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, the issuance is terminated and an error message is displayed.

[0043] In this optional embodiment, the step of binding the signing certificate and the encryption certificate through the association identifier field and persisting them in the same database transaction; constructing a certificate response message after persistence and returning the public key infrastructure message protected by the certificate authority's signature to the registration authority includes: In the data record of the signing certificate, the signing certificate and the encryption certificate are bound one-to-one through the encryption certificate association identifier field, and the fields of the signing certificate and the encryption certificate are persisted to the database in the same business transaction; After persistence is complete, a certificate response message for the certificate management protocol is constructed. The certificate response message includes a certificate response body carrying the signed certificate and a certificate response body carrying the encryption certificate and encryption key structure. The two certificate response bodies are encapsulated into a complete public key infrastructure message and returned to the registration authority after being signed and protected by the issuer's certificate authority.

[0044] In this optional embodiment, the step of performing distributed compensation based on a transaction event monitoring mechanism and notifying the key management center to clean up the allocated keys includes: The Key Management Center callback event listener receives callback events as input parameters and extracts compensation data from the event payload, including the connection information of the Key Management Center, the key reference of the issuer's certificate authority, the signature algorithm identifier, the issuer's subject name, the encryption certificate serial number, and the key request type identifier. Retrieve the fields of issuer subject name, encryption certificate serial number and key request type identifier, and serialize the fields into structured data in a preset format as the callback request body; Obtain the key reference and signature algorithm identifier of the issuing certificate authority, call the hardware cryptographic machine, sign the byte sequence of the callback request body in combination with the private key of the issuing certificate authority, put the signature value into the preset HTTP request header field, put the signature algorithm identifier into the signature algorithm request header field, and obtain the signature request header. Obtain the connection information of the key management center and send a callback request body and a signature request header to the callback interface of the key management center; The key management center receives the request, extracts the signature value and signature algorithm from the signature request header, uses the pre-configured public key of the issuer's certificate authority to sign and verify the request body, and cleans up the corresponding orphaned key according to the encryption certificate serial number and key request type identifier after the verification is successful. After the callback request is executed, in the transaction rollback awareness step, the compensation execution record is written to the rollback log table in an independent transaction started with an independent new transaction propagation strategy.

[0045] In this optional embodiment, after extracting the compensation data, a triple mechanism combination is also used to ensure the reliable execution of the compensation. The triple mechanism combination includes transaction rollback phase monitoring, independent new transaction propagation, and asynchronous thread pool execution.

[0046] Figure 2 An embodiment of a three-party collaborative dual certificate issuance system of the present invention is shown.

[0047] In this optional embodiment, the tripartite collaborative dual-certificate issuance system includes: The signature certificate construction module 201 is used to initiate a certificate management protocol request through the registration authority. The certificate authority receives the request and verifies the algorithm identifier of the user's public key. After the verification is successful, the signature certificate is constructed using a hardware cryptographic machine. The encryption key application module 202 is used to generate the entity identifier of the certificate authority based on the hash digest, and encapsulate it with a random task number to obtain the key service request; the key service request is signed using a hardware cryptographic machine to generate the request structure of the certificate authority, and the response is verified using the certificate authority. After successful verification, the key data is extracted and a callback event is registered. The encryption certificate construction module 203 is used to extract the encryption public key from the key data as the main public key, and combine it with the subject name, encryption certificate-specific extended configuration and the preset standard fields of the encryption certificate to construct the encryption certificate through a hardware cryptographic machine. The subject name and issuer subject name of the encryption certificate are the same as those of the signing certificate. The dual-certificate atomic persistence and response module 204 is used to bind the signing certificate and the encryption certificate through the association identifier field and persist them in the same database transaction; after persistence is completed, a certificate response message is constructed and the public key infrastructure message protected by the certificate authority is returned to the registration authority. The distributed compensation module 205 is used to perform distributed compensation based on the transaction event monitoring mechanism when an exception occurs during the construction of the encrypted certificate and the atomic persistence and response of the dual certificate, causing the business transaction to roll back. This notifies the key management center to clean up the allocated keys, so as to ensure the key consistency between the certificate authority and the key management center.

[0048] To facilitate understanding of the above technical solutions of the present invention, the following further explains the above technical solutions of the present invention from the perspective of architecture and principle, as follows: This invention provides a method for collaborative issuance of SM2 dual certificates and key consistency assurance based on the GM / T0014 protocol, aiming to solve the three defects of the prior art: First, it provides a complete solution for completing the collaborative issuance and atomic persistence of RA→CA→KMC in a single CMP request; Second, it solves the key consistency problem between CA and KMC in the dual certificate issuance process through a distributed compensation mechanism based on transaction event monitoring; Third, it ensures the security of cross-system communication between CA and KMC through hardware cryptographic machine full-link signature protection, two-way identity authentication, and anti-replay mechanism.

[0049] Option 1: SM2 Dual Certificate Collaborative Issuance Method Based on CMP and GM / T 0014 Protocol This invention designs a three-party collaborative dual-certificate issuance method involving RA→CA→KMC, the complete process of which is as follows: (1) Signature certificate construction a) The CA (Certificate Authority) requests the user's public key and subject name from the CMP (Certificate Management Protocol); b) Verify the user's public key algorithm: Obtain the algorithm identifier of the user's public key. If the return value is a general elliptic curve type (EC or ECDSA), further identification of the specific curve is required to determine whether it is the SM2 algorithm. Specifically, the user's public key is passed in as the X.509 SubjectPublicKeyInfo structure (RFC 5280). This structure consists of two parts: AlgorithmIdentifier and subjectPublicKey. The AlgorithmIdentifier contains two fields: algorithm object identifier (algorithm) and algorithm parameters (parameters). For elliptic curve public keys, the algorithm object identifier is id-ecPublicKey (1.2.840.10045.2.1), and the algorithm parameter field carries ECParameters, the most common form of which is namedCurve, that is, directly specifying the elliptic curve used with an object identifier. After converting the public key into an elliptic curve public key object, the namedCurve object identifier is extracted from its algorithm parameters. It is then determined whether this identifier is 1.2.156.10197.1.301 (i.e., SM2 curve sm2p256v1). If it matches, the algorithm identifier is corrected to SM2. The corrected algorithm identifier is then compared with the key algorithm of the signature certificate template and the key algorithm of the encryption certificate template. If either does not match, the issuance is rejected. c) Using the subject name and user public key from a), combined with the signature certificate's exclusive extended configuration (key purpose: digital signature, non-repudiation) and standard fields such as signature certificate serial number and validity period, the issuer's CA private key is invoked through a hardware cryptographic machine (HSM) to complete the construction and signing of the X.509 v3 certificate; d) Verify the signature value of the signing certificate using the issuer's CA public key to confirm the certificate's integrity.

[0050] (2) Encryption key application a) Constructing the CA entity identifier: Extract the SubjectPublicKeyInfo structure (i.e., the subject public key information structure, which contains the algorithm identifier and public key bit string, as defined in RFC 5280) from the issuer CA certificate. Calculate the SM3 hash digest of the DER-encoded byte sequence of this structure to obtain a 32-byte hash value as the issuer CA's public key fingerprint. Combine this hash value with the issuer subject name and the certificate serial number of the issuer's certificate authority to form the CA entity identifier structure. This identifier structure is used as the requester identifier field in step b) for the KMC to identify the identity of the CA from which the request originates. b) Constructing a key request: Encapsulate parameters such as the encryption certificate serial number, user signature public key, certificate validity period, key algorithm identifier (SM2), and key length into a key request structure, and encapsulate it together with the CA entity identifier and the randomly generated task number into a key service request structure. c) Hardware Cryptographic Machine Signature: The Key Service Request structure generated in step b) is DER encoded to obtain the byte sequence to be signed; the hardware cryptographic machine (HSM) is invoked, and the private key held by the issuer CA in the HSM is used to perform a signature operation on the byte sequence using the SM2 signature algorithm (SM3WithSM2, corresponding to object identifier 1.2.156.10197.1.501)—that is, first calculate the SM3 digest of the data to be signed, and then use the SM2 private key to perform an elliptic curve signature on the digest value to generate a signature value (r,s); the signature algorithm identifier, signature value, and key service request are encapsulated together into a CA request structure and sent to the KMC. The purpose of this signature is to enable the KMC to use the issuer CA's public key to verify the integrity and authenticity of the request, preventing the key request from being tampered with or forged; d) Response Verification: After sending the CA request structure to the KMC in step c), the KMC processes the request and returns a key service response, which is also signed by the KMC using its private key. Upon receiving the response, the CA performs the following three verifications: First, it verifies the signature value in the KMC response using the public key in the pre-configured KM (Key Management) certificate to confirm that the response data has not been tampered with and indeed comes from a legitimate KMC (forming a symmetrical two-way authentication with the CA's signature of the request in step c); Second, it verifies that the KM certificate serial number carried in the response matches the pre-configured KM certificate serial number of the CA, preventing the KMC certificate from being replaced; Third, it verifies that the task number in the response matches the randomly generated task number in step b), ensuring that the response is a response to the current request and not a replay of a historical response. e) Extracting key data: After step d) verification is successful, the key return structure is extracted from the KMC key service response. This structure contains two key data: First, the SM2 encryption public key generated by KMC for the user, which is used as the main public key of the encryption certificate in step (3); Second, the encrypted private key ciphertext (i.e., the ciphertext data after KMC uses the user's signature public key or pre-shared key to encrypt the encrypted private key in an envelope) is encapsulated in digital envelope format. This private key ciphertext is returned to RA in step (4) along with the encryption certificate through the CMP response, and the end user decrypts it to obtain the encrypted private key. f) Register callback event: After step d) response verification is successful, immediately publish a KMC callback event to the application event bus through the in-process event publisher. The event payload includes: KMC connection information (service address, callback interface path), issuer CA key reference (used for hardware cryptographic machine signature for subsequent compensation requests), signature algorithm identifier, issuer subject name, encryption certificate serial number, and key request type identifier. This event is perceived by the transaction event listener within the lifecycle of the current business transaction: if an exception occurs in subsequent steps (3) and (4) causing the business transaction to roll back, the listener will consume the event and trigger the compensation process of scheme 2, notifying KMC to clean up the allocated keys; if the business transaction is committed normally, this event will not trigger any compensation operation.

[0051] (3) Encryption certificate construction a) Obtain the encryption public key from the key return structure extracted in step (e) of step (2). Specifically, the key return structure contains the SubjectPublicKeyInfo encoding of the SM2 encryption public key. Parse the AlgorithmIdentifier (the algorithm identifier should be SM2) and subjectPublicKey (i.e., the coordinates of the public key point on the SM2 elliptic curve) from it, and restore it to an elliptic curve public key object. This public key is used as the subject public key of the encryption certificate in step b). b) Using the encrypted public key restored in step a) as the main public key, the user subject name extracted in step (1) a) is used as the certificate subject name. Combined with the exclusive extended configuration of the encrypted certificate (key purpose: key encryption, data encryption) and the standard fields such as the independent serial number and validity period of the encrypted certificate, the X.509 v3 encrypted certificate is constructed and signed by calling the issuer's CA private key through the hardware cryptographic machine (HSM). c) Verify the signature value of the encryption certificate using the issuer's CA public key to confirm the certificate's integrity (consistent with the verification method for the signature certificate in step d) of step (1)). d) The signing certificate and the encryption certificate share the same subject name (both derived from the user subject name extracted from the CMP request in step (a) of step (1)) and issuer subject name (both from the same issuer CA), but use their own independent certificate serial numbers.

[0052] (4) Dual-certificate atomic persistence and response a) In the data record of the signing certificate, the signing certificate and the encryption certificate are bound one-to-one through the encryption certificate association identifier field (which stores the serial number of the encryption certificate). The signing certificate and the encryption certificate are persisted in the database within the same business transaction in steps (1) to (4). The persisted content includes the DER encoded data of the certificate, certificate status, subject name, serial number, and association identifier fields. If an exception occurs during the persistence process, the entire business transaction is rolled back, and the KMC callback event registered in step f) of step (2) is triggered at the same time; b) After successful persistence, construct a CMP certificate response message (CertRepMessage), which contains two certificate response bodies (CertResponse): The first certificate response body: carries the signature certificate constructed in step (1); The second certificate response body carries the encrypted certificate constructed in step (3) and the encrypted key structure—this structure encapsulates the encrypted private key ciphertext in digital envelope format extracted from the KMC key return structure in step (e) of step (2) and its corresponding KMC signature data, which is used by the end user to decrypt and obtain the encrypted private key; c) Encapsulate the two certificate response bodies into a complete PKI message (PKIMessage), protect it with the signature of the issuing CA, and return it to the RA.

[0053] Scheme 2: CA-KMC Key Consistency Guarantee Method Based on Transaction Rollback Compensation In the dual-certificate collaborative issuance process of Scheme 1, after the CA successfully applies for an encryption key from the KMC in step (2), subsequent steps (such as certificate construction and database persistence) may still encounter anomalies that cause transaction rollback. At this time, the key generated by the KMC cannot be automatically rolled back with the CA transaction, resulting in an "orphaned key". Scheme 2 is a compensation mechanism for this scenario - through the KMC callback event registered in step f) of step (2) of Scheme 1, it is automatically triggered when the transaction rollback occurs, notifying the KMC to clean up the allocated key, thereby ensuring end-to-end key consistency under the collaborative work of the two schemes.

[0054] Specifically, this invention designs a distributed compensation method based on a transaction event monitoring mechanism, comprising: (1) Transaction rollback awareness The callback processing method of the KMC callback event listener receives the KMC callback event published in step f) of step (2) of scheme 1 as the input parameter, extracts the KMC connection information, issuer CA key reference, signature algorithm identifier, issuer subject name, encryption certificate serial number, key request type identifier and other data required for compensation from the event payload, and adopts the following triple mechanism combination to ensure reliable execution of compensation: Transaction rollback phase listener: The callback handling method is registered as a transaction synchronization callback and bound to the transaction rollback phase (AFTER_ROLLBACK). The transaction manager automatically calls this method after the business transaction is rolled back; when the business transaction is committed normally, the transaction manager will not trigger this callback, thus avoiding accidental triggering of compensation operations; Independent New Transaction Propagation: The callback handling method is declared as an independent new transaction propagation strategy (REQUIRES_NEW). When executed, the transaction manager suspends the current transaction context (if it exists) and starts a brand new independent transaction. The compensation operation and the persistence of the compensation log in step (3) are both completed in this independent transaction and are not affected by the rolled-back business transaction; Asynchronous thread pool execution: The callback processing method is declared to be executed asynchronously, and a dedicated rollback compensation thread pool allocates worker threads to execute the callback. This thread pool is isolated from the business request thread pool, and the compensation operation does not occupy business thread resources or block the return of the current request's abnormal response. After the callback processing method is asynchronously scheduled, step (2) the callback request for hardware cryptographic machine signature and step (3) the compensation log persistence are executed in sequence.

[0055] (2) Callback request for hardware cryptographic machine signature a) Obtain the issuer subject name, encryption certificate serial number, and key request type identifier from the event payload extracted in step (1), and serialize the above fields into structured data in JSON format as the callback request body; b) Obtain the issuer's CA key reference and signature algorithm identifier from the event payload, call the hardware cryptographic machine (HSM), and use the issuer's CA private key to perform a signature operation on the callback request body byte sequence generated in step a) using the SM3WithSM2 signature algorithm (the signature process is consistent with the ratio c) of step (2) in scheme 1); put the signature value into a custom HTTP request header field (such as X-Signature), and put the signature algorithm identifier into the signature algorithm request header field (such as X-Signature-Algorithm); c) Obtain KMC connection information (service address, callback interface path) from the event payload, and send the request body from step a) and the signature request header from step b) to the KMC callback interface via HTTP POST. After receiving the request, KMC extracts the signature value and signature algorithm from the request header, verifies the signature of the request body using the pre-configured issuer CA public key, and cleans up the corresponding orphaned key according to the encryption certificate serial number and key request type identifier after successful verification.

[0056] (3) Compensation log persistence Regardless of whether the callback request in step (2) succeeds or fails, the compensation execution record is written to the rollback log table in an independent transaction started in step (1) with the REQUIRES_NEW strategy (new transaction propagation strategy). The record includes: callback type (key application rollback, key recovery rollback, key revocation rollback), encryption certificate serial number, issuer name, callback request time, execution status (success, failure), and reason for failure (if it fails, record the exception information; if it succeeds, leave it empty), ensuring audit integrity and supporting subsequent manual review and retry upon failure.

[0057] This invention has the following technical features: 1. Atomic issuance of three-party collaborative documents completed in a single request. Compared to existing technologies that lack a complete solution for achieving atomic persistence of dual certificates through RA→CA→KMC three-party collaboration within a single CMP request, this invention has the following advantages: 1) Process integrity: The entire process of signature certificate construction, KMC encryption key application, encryption certificate construction, and dual certificate persistence is completed in a single CMP request-response interaction, without the need for RA to initiate multiple requests or maintain intermediate states, thus reducing the complexity of process implementation; 2) Data Atomicity: The signing certificate and the encryption certificate are bound together through an associated identifier field and persisted in the same database transaction, avoiding the inconsistency problem of dual certificates caused by separate entry into the database (such as only the signing certificate exists while the corresponding encryption certificate is missing). 3) Response integrity: The CMP response carries the signature certificate, encryption certificate and encrypted private key ciphertext in digital envelope format in one go. The RA side can obtain the complete dual certificate and key data without a second request.

[0058] 2. Secure and reliable cross-system communication protection Compared to the shortcomings of existing technologies that lack a systematic security authentication mechanism between CA and KMC, this invention has the following advantages: 1) Hardware cryptographic machine full-link protection: Certificate signing, KMC key request signing, and rollback compensation callback signing are all completed through hardware cryptographic machines. The private key is always within the hardware security boundary, which eliminates the risk of the private key being extracted from memory compared to software signing schemes. 2) Two-way authentication: The CA uses its own private key to sign the request sent to the KMC, and the KMC uses its own private key to sign the response returned to the CA. Both parties use the other's pre-configured public key to verify the signature. Compared with one-way authentication or no authentication scheme, it can prevent both request forgery and response tampering. 3) Task number anti-replay: Each key request generates a random task number. The CA verifies that the task number in the response matches the request, strictly matching the request and response to prevent attackers from intercepting historical responses and replaying them. 4) SM3 Public Key Hash Identifier: The CA entity identifier uses SM3 to hash the SubjectPublicKeyInfo DER encoding of the issuer's CA public key, which uniquely identifies the CA while avoiding the exposure of the complete public key information in the GM / T0014 protocol message.

[0059] 3. Highly reliable distributed key consistency guarantee Compared to the shortcomings of existing technologies, such as the lack of a cross-system transaction compensation mechanism between CA and KMC and the tendency to generate isolated keys, this invention has the following advantages: 1) Precise rollback awareness: The transaction event listener is bound to the transaction rollback phase (AFTER_ROLLBACK) and compensation is only triggered after the business transaction is actually rolled back. It is not executed when the business transaction is committed normally, so as to avoid accidental triggering that could lead to the wrong cleanup of legitimate keys. 2) Independent transaction isolation: The compensation operation is executed with an independent new transaction propagation strategy (REQUIRES_NEW). The persistence of the compensation log is not affected by the rolled-back business transactions, ensuring that the compensation records will not be lost due to business rollback. 3) Asynchronous non-blocking execution: The compensation operation is executed asynchronously by a dedicated rollback compensation thread pool, which is isolated from the business request thread pool. It does not block the abnormal response return of the business thread and avoids the network latency of the compensation operation from affecting business performance. 4) Callback signature authentication: The callback request is signed by the hardware cryptographic machine. The KMC verifies the legality of the signature before performing key cleanup to prevent attackers from forging rollback notifications and causing legitimate keys to be deleted by mistake. 5) Audit integrity: Regardless of whether the compensation operation is successful or not, the execution record (including callback type, execution status, and failure reason) is written to the rollback log table in an independent transaction, which supports subsequent manual review and failure retry, and ensures the traceability of the compensation process.

[0060] Furthermore, to facilitate understanding of the above-mentioned technical solutions of the present invention, the following description, based on specific application examples, further illustrates the above-mentioned technical solutions of the present invention: like Figure 3 As shown, the system of the present invention comprises four components: Registration Authority (RA) system: Initiates certificate issuance requests to CAs via the CMP protocol and receives CMP responses from CAs containing dual certificates and encrypted private key ciphertext; The Certificate Authority (CA) core system receives and parses CMP requests from the RA, coordinates the construction of signature certificates, GM / T0014 key applications, encryption certificate construction, atomic persistence of dual certificates, and triggers compensation processes during business transaction rollbacks. The CA core system includes functional modules such as CMP request parsing, algorithm verification, certificate construction, key application, persistence, and transaction rollback compensation. Key Management Center (KMC) system: Communicates with CA via GM / T0014 protocol, receives key application, key recovery, and key revocation requests, generates SM2 encrypted key pairs and returns the encrypted public key and encrypted private key ciphertext in digital envelope format; it also provides a rollback callback interface, receives compensation notifications from CA and cleans up orphaned keys (shown by dashed lines in the diagram). Hardware Cryptographic Machine (HSM): Communicates with the CA through the cryptographic machine interface, provides support for SM2 / SM3 algorithm operations, and securely stores the issuer CA's private key. All signing operations involving the private key by the CA (certificate signing, KMC request signing, rollback callback signing) are completed through the HSM interface.

[0061] Example 1: SM2 Dual Certificate Collaborative Issuance This embodiment describes the complete process from the RA initiating a CMP request to the CA completing the dual certificate issuance, such as... Figure 4 As shown.

[0062] The implementation environment is shown in Table 1 below: Table 1 Implementation Environment The detailed process is as follows: S1. CMP Request Reception and Protocol Parsing 1) The CMP request dispatcher receives the HTTP request sent by the RA, reads the byte stream of the certificate management protocol from the request body, and parses it into a PKI message (PKIMessage) structure; 2) Perform the following protocol layer checks in sequence: Protocol version verification: Read the pvno field of the PKI message header to confirm that the protocol version is one of CMP1999 (v1), CMP2000 (v2) or CMP2021 (v3), otherwise return an error response indicating that the protocol version is not supported; Message timeliness verification: Read the messageTime field of the PKI message header and compare it with the current time of the CA server. A time deviation of 10 seconds is allowed. If the time deviation exceeds this, the message will be rejected to prevent expired messages from being replayed. Message protection signature verification: Read the protection field (signature value) and protectionAlg field (signature algorithm) of the PKI message, verify that the signature algorithm is within the whitelist range (supports SM3WithSM2, SHA256WithRSA, etc.), verify the signature value using the RA certificate public key, and confirm that the message source is legitimate and has not been tampered with; 3) Based on the type field of the PKI message body (PKIBody), route to the corresponding certificate request processing service (e.g., certificate issuance requests are routed to the issuance service, and certificate revocation requests are routed to the revocation service).

[0063] S2. Strategy Parameter Parsing and Verification 1) From the generalInfo field of the PKI message header, parse the policy parameters item by item according to the custom object identifier: issuing CA identifier (used to determine which CA issues the certificate), certificate template identifier (used to load certificate extension configuration), and key algorithm type (used for algorithm verification). 2) Load the corresponding certificate template configuration (including key usage, extended fields, validity period rules, etc.) according to the certificate template identifier, and verify whether the RA has the authority to issue certificates using this template; 3) Verify the activation status (whether it is active) and validity period (whether the CA certificate is within the validity period) of the issuer's CA. If either fails, return an issuance rejection response.

[0064] S3, Certificate Entity Creation and Algorithm Verification 1) In the main method of certificate issuance, the data entity of the signature certificate is first created (including fields such as signature certificate serial number, subject name, issuer subject name, validity period start and end time, certificate status, etc.). The serial number is generated by a secure random number generator to ensure global uniqueness. 2) Determine the certificate template type: When the template configuration indicates dual certificate mode, the data entity of the encryption certificate is created synchronously, and the encryption certificate uses an independent serial number; 3) Extract the SubjectPublicKeyInfo of the user's public key from the CertTemplate structure of the CMP request to obtain its algorithm identifier. If the algorithm identifier is a generic elliptic curve type (id-ecPublicKey, OID1.2.840.10045.2.1), convert the public key to an elliptic curve public key object, extract the namedCurve object identifier from the parameters field of AlgorithmIdentifier, and determine whether the identifier is 1.2.156.10197.1.301 (i.e., SM2 curve sm2p256v1). If it matches, correct the algorithm identifier to SM2. 4) Compare the corrected algorithm identifier with the key algorithm configured in the signature certificate template and the key algorithm configured in the encryption certificate template respectively. If any do not match, return an error response indicating that the algorithm does not match and terminate the issuance.

[0065] S4, Signature Certificate X.509 Construction and Signature Verification 1) Obtain the issuer CA's cryptographic token (used to establish an HSM session) and key reference (used to locate the CA's private key) in the hardware cryptographic machine. 2) Use the X.509 v3 certificate builder to build a signed certificate: Set the version number (v3), signature certificate serial number, issuer subject name, validity period, subject name, subject public key information (the user-submitted SM2 signature public key), and signature algorithm identifier (SM3WithSM2); Load the signature certificate-specific extended field configurations in the certificate template, including key usage extensions (KeyUsage: digitalSignature, nonRepudiation), basic constraints, CRL distribution point, and access to issuing authority information, etc. 3) Obtain the content signer supported by the hardware cryptographic machine through the key tool, call the HSM interface to use the issuer's CA private key to perform signing with the SM3WithSM2 algorithm, and generate a complete X.509 v3 signing certificate; 4) Use the issuer's CA public key to verify the signature value of the generated signature certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, terminate the issuance and throw an exception.

[0066] S5, GM / T 0014 Key Application and Response Verification 1) Construct CA entity identifier: Extract the SubjectPublicKeyInfo structure from the issuer's CA certificate, calculate the SM3 hash digest of its DER-encoded byte sequence to obtain a 32-byte public key fingerprint; combine this hash value with the issuer's subject name and the issuer's CA certificate serial number to form the CA entity identifier structure; 2) Construct a key request: Encapsulate parameters such as the encryption certificate serial number, user signature public key, certificate validity period, key algorithm identifier (SM2), and key length (256 bits) into a key request structure, and encapsulate them together with the CA entity identifier and the randomly generated task number (UUID format) into a key service request structure. 3) Hardware cryptographic machine signature: The key service request structure is DER encoded, and the HSM is called to use the issuer's CA private key to perform a signature operation on the encoded data using the SM3WithSM2 algorithm. The signature algorithm identifier, signature value and key service request are encapsulated together into a CA request structure and sent to the KMC key service interface via HTTP POST. 4) Response Verification: After receiving the key service response from KMC, CA performs three verifications: verifying the response signature using the pre-configured key management center certificate public key, verifying that the key management center certificate serial number in the response matches the pre-configured value, and verifying that the task number in the response matches the task number in the request. The meaning of the Key Management Center certificate is as follows: KM = Key Management, referring to the Key Management Center (KMC); Key Management Center Certificate = the digital certificate of the Key Management Center, used by the KMC to sign the response; its function is for the CA to use the pre-configured KMC certificate public key to verify the signature of the key service response returned by the KMC, ensuring that the response does indeed come from a legitimate KMC and has not been tampered with. 5) Extract key data: After successful verification, extract the SM2 public key (SubjectPublicKeyInfo format) and the encrypted private key ciphertext in digital envelope format from the key return structure in the KMC response; 6) Register callback events: Publish KMC callback events to the application event bus through the in-process event publisher. The event payload includes KMC connection information, issuer CA key reference, signature algorithm identifier, issuer subject name, encryption certificate serial number, and key request type identifier.

[0067] S6, Encryption Certificate X.509 Construction and Signature Verification 1) Obtain the SM2 encryption public key from the key data extracted from S5, and parse its SubjectPublicKeyInfo encoding (public key information structure encoding) into an elliptic curve public key object; 2) Build an encryption certificate using the X.509 v3 certificate builder: Set the subject public key information to the encryption public key generated by KMC, the subject name is shared with the signing certificate (both are user subject names extracted from CMP requests in S3), and the issuer subject name is the same as the signing certificate; load the encryption certificate-specific extended field configuration in the certificate template, including key usage extensions (KeyUsage: keyEncipherment, dataEncipherment, etc.); 3) Use HSM to call the issuer's CA private key and perform signing with the SM3WithSM2 algorithm to generate a complete X.509 v3 encryption certificate; 4) Use the issuer's CA public key to verify the signature value of the encrypted certificate and confirm the integrity of the certificate.

[0068] S7, Dual-Certificate Atomicity Persistence and CMP Response 1) In the data record of the signing certificate, the serial number of the encryption certificate is stored through the encryption certificate association identifier field to achieve a one-to-one binding between the signing certificate and the encryption certificate; 2) Within the same business transaction (database transaction isolation level is READ COMMITTED) from S1 to S7, persist the DER-encoded data of the signing certificate and encryption certificate, certificate status, subject name, serial number, and association identifier to the database. If a persistence exception occurs, the entire business transaction is rolled back, and the KMC callback event registered in S5 is triggered (entering the compensation process in Example 2). 3) After successful persistence, construct the CMP certificate response message (CertRepMessage), which contains two certificate response bodies (CertResponse): The first certificate response body carries the signing certificate; The second certificate response body carries the encryption certificate and the encryption key structure (encapsulating the encrypted private key ciphertext extracted from KMC in S5 in digital envelope format and KMC signature data). 4) Encapsulate the two certificate response bodies into a complete PKI message (PKIMessage), protect it with the signature of the issuing CA, and return it to the RA via an HTTP response.

[0069] In addition, this embodiment also includes an experimental verification section: Experimental environment: The above implementation environment was used, with the CA server and KMC server deployed on the same local area network (network latency <5ms). The HSM was directly connected to the CA server via a PCI-E interface. The database was a separately deployed PostgreSQL 16 instance.

[0070] Experiment: Comparative Analysis with Existing Technologies Experimental method: The scheme of this invention (single request dual certificate issuance) is compared with the traditional step-by-step issuance scheme (first issue a signature certificate, then issue an encryption certificate separately, for a total of 2 CMP requests). The tests are conducted under the same experimental environment, and the test comparison data is shown in Table 2 below.

[0071] Table 2 Test Comparison Data Conclusion: Compared with the traditional step-by-step approach, the present invention has significant improvements in terms of request count, issuance time, transaction atomicity, and consistency guarantee, verifying the actual effectiveness of the technical solution of this application.

[0072] Example 2: CA-KMC Key Consistency Guarantee for Transaction Rollback Compensation This embodiment describes how to notify the KMC to clean up the allocated keys after a CA service transaction is rolled back, such as... Figure 5 As shown. This embodiment is based on the implementation environment of Embodiment 1.

[0073] Preconditions: The triggering premise of this embodiment is that in embodiment 1, S5 successfully obtained the KMC response and published the KMC callback event, but the subsequent steps (S6 encryption certificate construction or S7 persistence) caused a business anomaly that led to transaction rollback.

[0074] The detailed process is as follows: S1. Callback event registration — Corresponding to step S5 in Example 1 In S5 of Example 1, after the CA successfully obtains the KMC key response and completes the response verification through the GM / T 0014 protocol, it publishes a KMC callback event to the application event bus through the in-process event publisher (ApplicationEventPublisher). 1) The event payload contains all the information required for the compensation operation: KMC connection information (service address such as https: / / kmc.example.com, callback interface path such as / api / v1 / key / rollback), issuer CA key reference (key alias in HSM, used to locate the CA private key), signature algorithm identifier (SM3WithSM2), issuer subject name, encryption certificate serial number (used by KMC to locate the key to be cleaned up), and key request type identifier (such as key request type code 1). 2) After the event is published, it is registered in the transaction synchronization manager of the current business transaction and waits for the final commit or rollback result during the transaction lifecycle.

[0075] S2, Transaction rollback triggered 1) In the business process after S1, if an exception occurs in a subsequent step (such as a unique constraint conflict or connection timeout during database persistence in S7), the business method throws a runtime exception. 2) The TransactionManager catches this exception, performs a rollback operation on the current business transaction, and undoes all database changes in the transaction; 3) After the rollback is completed, the transaction manager traverses the registered transaction synchronization callback list, identifies the KMC callback event listener's processing method that is bound to the transaction rollback phase (AFTER_ROLLBACK), and automatically calls the processing method, passing the KMC callback event published in S1 as the input parameter; 4) If the business transaction is committed normally (AFTER_COMMIT), the transaction manager will not trigger this callback, ensuring that the compensation operation is only executed when the transaction is actually rolled back.

[0076] S3, Independent Transactions and Asynchronous Scheduling 1) The KMC callback event listener's handling method declares two key semantics: Independent New Transaction Propagation Strategy (REQUIRES_NEW): When the transaction manager executes this method, it suspends the current transaction context (at which point the business transaction has been rolled back and the context is empty) and starts a completely new independent database transaction. Subsequent compensation operations in S4 and log persistence in S5 are completed within this independent transaction, unaffected by the rolled-back business transaction. Asynchronous execution (Async): This method uses a dedicated rollback compensation thread pool (4 core threads, 8 maximum threads, and a queue capacity of 100) to allocate worker threads for asynchronous execution. The business thread is immediately released after the callback is triggered and continues processing the return of exception responses, without being blocked by network latency during the compensation operation. The processing method extracts the necessary compensation data from the event payload, such as KMC connection information, issuer CA key reference, signature algorithm identifier, issuer subject name, encryption certificate serial number, and key request type identifier, and passes it to subsequent steps.

[0077] S4, Hardware cryptographic machine signature callback request 1) Construct the callback request body: Obtain the issuer name, encryption certificate serial number, and key request type identifier from the event payload transmitted by S3, and serialize the above fields into structured data in JSON format (such as {"issuerName":"CN=TestCA","certSerial":"ABC123","reqType":1}) as the HTTP request body; 2) HSM Signature: Obtain the issuer's CA key reference and signature algorithm identifier from the event payload, call the hardware cryptographic machine (HSM), and use the issuer's CA private key to perform a signature operation on the byte sequence of the callback request body using the SM3WithSM2 algorithm (the signature process is consistent with the KMC request signature in S5 of Example 1), and generate a signature value; 3) Assemble the HTTP request: After Base64 encoding the signature value, put it into the custom HTTP request header field X-Signature, and put the signature algorithm identifier into the request header field X-Signature-Algorithm; 4) Sending a callback request: Obtain the KMC service address and callback interface path from the event payload, and send a request to the KMC callback interface via HTTP POST. After receiving the request, KMC extracts the signature value and signature algorithm from the request header, performs SM3WithSM2 signature verification on the request body using the pre-configured issuer CA public key, and deletes the corresponding generated but unused orphaned key pair from the key storage based on the encryption certificate serial number and key request type identifier.

[0078] S5, Compensation Log Persistence 1) After S4 is completed (regardless of success or failure), the final fallback logic (try-finally structure) is entered. In the independent transaction started in S3 with the REQUIRES_NEW strategy, the rollback log persistence method is called to write the compensation execution record into the rollback log table. 2) The record content includes the following fields as shown in Table 3 below: Table 3 Record Content 3) After the log is written, an independent transaction is committed to ensure that the compensation record is persisted to the database, supporting subsequent manual review and retry on failure.

[0079] In addition, this embodiment also includes an experimental verification section: Experiment 1: Verification of the correctness of compensation after transaction rollback Experimental method: Send a dual certificate issuance request through the RA client. After the CA successfully obtains the KMC key but before the database is persisted, inject an exception (simulate database write failure) to verify whether the compensation process is correctly triggered and cleans up the KMC-side orphaned key.

[0080] Experimental steps: 1) Send a dual certificate issuance request, and the CA completes S1-S5 (KMC key application is successful and a callback event is published). 2) Inject a RuntimeException during the S7 persistence phase to trigger a rollback of the business transaction; 3) Wait for the asynchronous compensation thread to complete execution (maximum wait time 5 seconds); 4) Check the key status of the KMC end, the rollback log table of the CA end, and the certificate table of the CA end.

[0081] The experimental data are shown in Table 4 below: Table 4 Data from Experiment 1 Conclusion: After the transaction was rolled back, the compensation process was automatically triggered, the isolated key on the KMC side was correctly cleaned up, the compensation log was fully recorded, and there was no residual data on the CA side.

[0082] Experiment 2: Compensation does not trigger verification during normal submission. Experimental method: A dual certificate issuance request was sent through the RA client. The entire process was completed normally (without injection of exceptions), verifying that the compensation process was not triggered erroneously.

[0083] The experimental data are shown in Table 5 below: Table 5 Data from Experiment 2 Conclusion: When a business transaction is committed normally, the AFTER_ROLLBACK phase listener is not triggered, verifying the accuracy of the compensation operation and preventing the accidental deletion of legitimate keys.

[0084] Experiment 3: Log Guarantee Verification When Compensation Operation Fails Experimental method: After the CA successfully obtains the KMC key, a persistence exception is injected to trigger a rollback. At the same time, the KMC callback interface is simulated to be unreachable (KMC network is disconnected) to verify whether the log can still be persisted correctly when the compensation callback fails.

[0085] The experimental data are shown in Table 6 below: Table 6 Data from Experiment 3 Conclusion: Even if the KMC callback fails, the compensation log is still successfully persisted in an independent transaction, recording the reason for the failure. This verifies the effectiveness of the REQUIRES_NEW transaction isolation strategy and supports operations personnel to manually retry based on the logs.

[0086] Experiment 4: Verification that compensation operations do not block business threads Experimental method: Send dual certificate issuance requests under 100 concurrent requests, where 10% of the requests are injected with exceptions during the persistence phase to trigger rollback, and set the KMC callback interface response delay to 2 seconds (to simulate slow network). Measure the response time of normal requests and abnormal requests.

[0087] The experimental data are shown in Table 7 below: Table 7 Data from Experiment 4 Analysis: The response time for abnormal requests (average 152ms) is significantly shorter than the 2-second delay of the KMC callback, indicating that the compensation operation is executed in an asynchronous thread pool and does not block the abnormal response return of the business thread. The average response time for normal requests is 588ms, and the maximum response time is 810ms, both within the 800ms baseline range. Furthermore, there was no significant performance degradation due to the 10% of abnormal requests and their compensation operations, demonstrating the effectiveness of the isolation mechanism between the compensation thread pool and the business thread pool.

[0088] Experiment 5: Comparative Analysis with Schemes Without Compensation Mechanisms Experimental method: 1000 dual certificate issuance requests were executed under the scheme of this invention (with rollback compensation) and the scheme without compensation mechanism, respectively. 5% of the requests were injected with anomalies during the persistence phase. The number of isolated keys on the KMC side and the integrity of the audit records were counted.

[0089] The experimental data are shown in Table 8 below: Table 8 Data from Experiment 5 Conclusion: The proposed solution achieved 100% automatic cleanup of orphaned keys and complete audit log recording in all 50 transaction rollback scenarios, with compensation operations not blocking business threads. Compared to solutions without a compensation mechanism, it completely eliminates the risk of orphaned key residues and eliminates the cost of manual investigation.

[0090] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores static and dynamic information data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the above method embodiments.

[0091] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0092] In addition, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0093] In addition, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0094] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0095] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.

Claims

1. A three-party collaborative method for issuing dual certificates, characterized in that, include: Signature certificate construction: The registration authority initiates a certificate management protocol request. The certificate authority receives the request and verifies the algorithm identifier of the user's public key. After the verification is successful, a signature certificate is constructed using a hardware cryptographic machine. Encryption key request: Generate the entity identifier of the certificate authority based on the hash digest, and encapsulate it with a random task number to obtain the key service request; The key service request is signed using a hardware cryptographic machine to generate a request structure for a certificate authority, and the response is verified using a certificate authority. After successful verification, the key data is extracted and a callback event is registered. Encryption certificate construction: Extract the encryption public key from the key data as the main public key, and combine it with the subject name, encryption certificate-specific extended configuration and the preset standard fields of the encryption certificate to construct the encryption certificate through a hardware cryptographic machine. The subject name and issuer subject name of the encryption certificate are the same as those of the signing certificate. Dual-certificate atomic persistence and response: The signing certificate and the encryption certificate are bound by the associated identifier field and persisted in the same database transaction; after persistence is completed, a certificate response message is constructed and the public key infrastructure message protected by the certificate authority is returned to the registration authority. Specifically, when an anomaly occurs during the construction of the encrypted certificate and the atomic persistence and response of the dual certificates, causing the business transaction to roll back, a distributed compensation based on the transaction event monitoring mechanism is executed to notify the key management center to clean up the allocated keys, so as to ensure the key consistency between the certificate authority and the key management center.

2. The tripartite collaborative dual-certificate issuance method according to claim 1, characterized in that, The process of initiating a certificate management protocol request through a registration authority, receiving the request and verifying the algorithm identifier of the user's public key, and then constructing a signature certificate using a hardware cryptographic machine after successful verification includes: The registration authority initiates a certificate management protocol request to the certificate authority; the certificate authority receives the certificate management protocol request and extracts the user's public key and subject name from the request. Obtain the algorithm identifier of the user's public key. When the algorithm identifier is of general elliptic curve type, convert the user's public key into an elliptic curve public key object and extract the object identifier from the algorithm parameters. When the object identifier is the object identifier of the SM2 curve, the correction algorithm identifier is SM2, and the corrected algorithm identifier is compared with the key algorithm of the signature certificate template and the key algorithm of the encryption certificate template respectively. If any mismatch occurs, the issuance is rejected. Based on the subject name and user public key, combined with preset standard fields, a signature certificate is constructed by calling the private key of the issuer's certificate authority through a hardware cryptographic machine; The signature value of the signature certificate is verified using the public key of the certificate authority that issued the certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, the issuance is terminated and an error is displayed.

3. The tripartite collaborative dual-certificate issuance method according to claim 2, characterized in that, The process of constructing a signature certificate based on the topic name and user public key, combined with preset standard fields, and by using a hardware cryptographic machine to call the private key of the issuing certificate authority includes: Obtain the cryptographic token and key reference of the issuing certificate authority in the hardware cryptographic machine; Set the version number, signature certificate serial number, issuer subject name, validity period, subject name, subject public key information and signature algorithm identifier, and load the extended field configuration specific to the signature certificate in the certificate template; Use a key tool to obtain the content signer supported by the hardware cryptographic machine, and call the hardware cryptographic machine interface to sign using the private key of the issuer's certificate authority to generate a complete signature certificate.

4. The tripartite collaborative dual-certificate issuance method according to claim 1, characterized in that, The entity identifier of the certificate authority is generated based on the hash digest, and the key service request is obtained by combining it with the random task number; The key service request is signed using a hardware cryptographic machine to generate a certificate authority request structure. The response is then verified using the certificate authority. Upon successful verification, the key data is extracted, and callback events are registered, including: Extract the subject public key information structure from the issuer's certificate authority, calculate the SM3 hash digest of the DER-encoded byte sequence in the subject public key information structure, and use the obtained hash value as the public key fingerprint of the issuer's certificate authority. Integrate the hash value, the issuer's subject name, and the certificate serial number of the issuer's certificate authority to form the entity identifier structure of the certificate authority. The encryption certificate serial number, user signature public key, certificate validity period, key algorithm identifier and key length are encapsulated into a key request structure, and together with the entity identifier structure of the certificate authority and the randomly generated task number, they are encapsulated into a key service request structure. The key service request structure is DER encoded to obtain the byte sequence to be signed. The hardware cryptographic machine is called to sign the byte sequence to be signed using the private key of the issuing certificate authority. The signature algorithm identifier, signature value and key service request are encapsulated together into the certificate authority request structure and sent to the key management center. The key management center receives the request structure, processes it, and returns a key service response signed by the key management center's own private key; the certificate authority receives the key service response returned by the key management center and verifies the response; After successful verification, the SM2 public key and the encrypted private key in data envelope format are extracted from the key service response. The key management center callback event is then published to the application event bus via the in-process event publisher. The callback event payload includes the connection information of the key management center, the key reference of the issuer's certificate authority, the signature algorithm identifier, the issuer subject name, the encryption certificate serial number, and the key request type identifier.

5. The tripartite collaborative dual-certificate issuance method according to claim 4, characterized in that, The response verification includes verifying the response signature using a pre-configured key management center certificate public key, verifying the consistency between the key management center certificate serial number in the response and the pre-configured value, and verifying the consistency between the task number in the response and the task number in the request.

6. The tripartite collaborative dual-certificate issuance method according to claim 1, characterized in that, The process of extracting the public key from the key data and using it as the primary public key, combined with the subject name, the encryption certificate's dedicated extended configuration, and the encryption certificate's preset standard fields, to construct an encryption certificate via a hardware cryptographic machine includes: The public key information structure in the SM2 encryption public key is encoded and parsed into an elliptic curve public key object to obtain the parsed encryption public key. The parsed public key is used as the main public key of the encryption certificate, the subject name is used as the certificate subject name, and the encryption certificate is constructed by calling the private key of the issuing certificate authority through a hardware cryptographic machine, along with the encryption certificate’s exclusive extended configuration and the encryption certificate’s independent serial number and validity period standard fields. The signature value of the encrypted certificate is verified using the public key of the certificate authority that issued the certificate to confirm that the certificate data is complete and the signature is correct. If the verification fails, the issuance is terminated and an error message is displayed.

7. The tripartite collaborative dual-certificate issuance method according to claim 1, characterized in that, The signature certificate and encryption certificate are bound together by an associated identifier field and persisted within the same database transaction; After persistence is complete, a certificate response message is constructed, and the public key infrastructure message, signed and protected by the certificate authority, is returned to the registration authority, including: In the data record of the signing certificate, the signing certificate and the encryption certificate are bound one-to-one through the encryption certificate association identifier field, and the fields of the signing certificate and the encryption certificate are persisted to the database in the same business transaction; After persistence is complete, a certificate response message for the certificate management protocol is constructed. The certificate response message includes a certificate response body carrying the signed certificate and a certificate response body carrying the encryption certificate and encryption key structure. The two certificate response bodies are encapsulated into a complete public key infrastructure message and returned to the registration authority after being signed and protected by the issuer's certificate authority.

8. The tripartite collaborative dual-certificate issuance method according to claim 7, characterized in that, The execution of distributed compensation based on a transaction event monitoring mechanism, which notifies the key management center to clean up the allocated keys, includes: The Key Management Center callback event listener receives callback events as input parameters and extracts compensation data from the event payload, including the connection information of the Key Management Center, the key reference of the issuer's certificate authority, the signature algorithm identifier, the issuer's subject name, the encryption certificate serial number, and the key request type identifier. Retrieve the fields of issuer subject name, encryption certificate serial number and key request type identifier, and serialize the fields into structured data in a preset format as the callback request body; Obtain the key reference and signature algorithm identifier of the issuing certificate authority, call the hardware cryptographic machine, sign the byte sequence of the callback request body in combination with the private key of the issuing certificate authority, put the signature value into the preset HTTP request header field, put the signature algorithm identifier into the signature algorithm request header field, and obtain the signature request header. Obtain the connection information of the key management center and send a callback request body and a signature request header to the callback interface of the key management center; The key management center receives the request, extracts the signature value and signature algorithm from the signature request header, uses the pre-configured public key of the issuer's certificate authority to sign and verify the request body, and cleans up the corresponding orphaned key according to the encryption certificate serial number and key request type identifier after the verification is successful. After the callback request is executed, in the transaction rollback awareness step, the compensation execution record is written to the rollback log table in an independent transaction started with an independent new transaction propagation strategy.

9. The tripartite collaborative dual-certificate issuance method according to claim 8, characterized in that, After extracting the compensation data, a three-pronged mechanism is employed to ensure the reliable execution of the compensation. This three-pronged mechanism includes transaction rollback phase monitoring, independent new transaction propagation, and asynchronous thread pool execution.

10. A three-party collaborative dual-certificate issuance system, characterized in that, include: The signature certificate construction module is used to initiate a certificate management protocol request through the registration authority. The certificate authority receives the request and verifies the algorithm identifier of the user's public key. After the verification is successful, it uses a hardware cryptographic machine to construct a signature certificate. The encryption key request module is used to generate the entity identifier of the certificate authority based on the hash digest and encapsulate it with a random task number to obtain the key service request; The key service request is signed using a hardware cryptographic machine to generate a request structure for a certificate authority, and the response is verified using a certificate authority. After successful verification, the key data is extracted and a callback event is registered. The encryption certificate building module is used to extract the encryption public key from the key data as the main public key, and combine it with the subject name, encryption certificate-specific extended configuration and the preset standard fields of the encryption certificate to build an encryption certificate through a hardware cryptographic machine. The subject name and issuer subject name of the encryption certificate are the same as those of the signing certificate. The dual-certificate atomic persistence and response module is used to bind the signing certificate and the encryption certificate through the association identifier field and persist them in the same database transaction; after persistence is completed, a certificate response message is constructed and the public key infrastructure message protected by the certificate authority is returned to the registration authority. The distributed compensation module is used to perform distributed compensation based on the transaction event monitoring mechanism when an exception occurs during the construction of the encrypted certificate and the atomic persistence and response of the dual certificate, causing the business transaction to roll back. This notifies the key management center to clean up the allocated keys, so as to ensure the key consistency between the certificate authority and the key management center.

Images