A certificate verification method and apparatus based on certificate trust transparency technology

Abstract

This invention provides a certificate verification method and apparatus based on certificate trust transparency technology, relating to the field of information processing technology. The method is used for a website server and includes: generating a CA trust policy key pair and a certificate key pair to be applied for; generating a certificate issuance request based on the CA trust policy public key and the certificate public key, sending the certificate issuance request to the CA, receiving and storing the certificate issued by the CA; generating a CA trust policy record based on the issued certificate, signing the CA trust policy record with the CA trust policy private key, and securely sending the signed CA trust policy record and the CA trust policy public key to a trust policy transparency management server for storage; upon receiving an access request from a client, sending the certificate to the client for verification; if the verification result is untrusted, instructing the client to query the CA trust policy record from the trust policy transparency management server for supplementary verification of the certificate.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, and in particular to a certificate verification method and apparatus based on certificate trust transparency technology. Background Technology

[0002] Public Key Infrastructure (Web PKI) is the cornerstone of secure internet communication. Transport Layer Security (SSL / TLS) protocols rely on the support of Web PKI. Utilizing key technologies such as public key digital certificates, Certificate Authorities (CAs), certificate verification, and public key encryption, it provides a secure encrypted communication channel for the internet, helping communication terminals establish trust and protecting the confidentiality, integrity, authenticity, and authenticability of internet communications. CAs are responsible for issuing digital certificates used to verify the identity of websites and service entities; they are the trust anchors in the Web PKI system and typically include root CAs and intermediate CAs. A digital certificate is a data structure containing a public key, subject information, and a signature, used to establish a chain of trust.

[0003] In existing certificate verification systems, a typical component includes a Certificate Authority (CA), a web server, and a browser. (See [link to relevant documentation]). Figure 1 Typically, one-way authentication includes: the web server generating a Certificate Signature Request (CSR) and sending it to the Certificate Authority (CA); the CA verifies the CSR and generates a website certificate, which is then issued to the web server; the web server configures the certificate on the SSL gateway and enables HTTP; and the terminal browser accesses the HTTP URL, reads the website certificate during the TLS handshake, and queries the list of trusted root certificates to verify the validity of the website certificate.

[0004] However, existing technologies suffer from the following problems: the certificate verification process lacks flexibility and interoperability. Web servers, as domain owners, have no right to determine their own CA trust policies, and client verification of website certificates relies on a list of trusted root certificates. If an individual CA is mistakenly or improperly removed from the list of trusted root certificates, or if the website certificate for which the web server requests a CA signature is not on the list, irreversible consequences will occur. For example, all network services and encrypted communication services that rely on digital certificates issued by that CA will become unavailable.

[0005] Overcoming the lack of flexibility and interoperability in the certificate verification process of existing technologies is a technical problem that needs to be solved. Summary of the Invention

[0006] This invention provides a certificate verification method and apparatus based on certificate trust transparency technology to address the shortcomings of existing certificate verification processes in terms of flexibility and interoperability.

[0007] This invention provides a certificate verification method based on certificate trust transparency technology for a website server, wherein the website server is connected to a trust policy transparency management server, and the website server requests a signature certificate from a Certificate Authority (CA).

[0008] The method includes:

[0009] Generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes a certificate public key and a certificate private key of the certificate to be applied for;

[0010] A certificate issuance request is generated based on the CA's trust policy public key and the certificate public key, and the certificate issuance request is sent to the CA. The certificate issued by the CA is received and stored. The certificate includes the CA's trust policy public key.

[0011] Generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and then securely send the signed CA trust policy record and the CA trust policy public key to the trust policy transparent management server for storage.

[0012] Upon receiving an access request from a client, the certificate is sent to the client so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparency management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

[0013] According to a certificate verification method based on certificate trust transparency technology provided by the present invention, the website server is loaded with a trust anchor manager and the website server stores the CA root certificate corresponding to the CA.

[0014] Sending the certificate issuance request to the CA and receiving the certificate issued by the CA includes:

[0015] Determine a custom CA trust policy and identify at least one CA to which the certificate issuance request will be sent;

[0016] The certificate issuance request is sent to the at least one CA through the trust anchor manager; wherein the certificate public key in the certificate issuance request corresponding to each CA is different.

[0017] Receive at least one certificate issued by a CA through the trust anchor manager;

[0018] Generate a CA trust policy record based on the issued certificate, including:

[0019] The CA root certificate corresponding to the issued certificate is determined, and the CA trust policy record is generated based on the issued certificate and its corresponding CA root certificate, wherein the CA trust policy record includes a list of trusted CA root certificates.

[0020] According to a certificate verification method based on certificate trust transparency technology provided by the present invention, after sending the certificate issuance request to a CA and receiving the certificate issued by the CA, the method further includes:

[0021] If it is necessary to update the trusted CA root certificate, determine the target CA based on the CA root certificate in the saved CA trust policy record and the CA root certificate that needs to be updated.

[0022] Send a certificate issuance request to the target CA, receive the certificate issued by the target CA, and save it;

[0023] Based on the certificate issued by the target CA, the trusted certificate is updated. Based on the CA root certificate corresponding to the updated certificate, an updated CA trust policy record is generated. After signing the updated CA trust policy record with the CA trust policy private key, the updated CA trust policy record carrying the signature and the CA trust policy public key are sent to the trust policy transparent management server for storage.

[0024] According to the certificate verification method based on certificate trust transparency technology provided by the present invention, the website server further includes: an authoritative domain name server, used to store the node address of the trust policy transparency management server;

[0025] After securely sending the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage, the method further includes:

[0026] The system receives a trust policy deployment signature timestamp returned by the trust policy transparent management server. The trust policy deployment signature timestamp is generated by the trust policy transparent management server adding a timestamp to the signed CA trust policy record. The trust policy deployment signature timestamp carries a node address.

[0027] The node address corresponding to the deployment signature timestamp of the trust policy is stored in the authoritative domain name server.

[0028] According to the certificate verification method based on certificate trust transparency technology provided by the present invention, before enabling the client to query the CA trust policy record from the trust policy transparency management server, the method further includes:

[0029] Receive address query requests from clients;

[0030] Based on the address query request, the node address corresponding to the address query request is queried in the authoritative domain name server, so that the client can access the trust policy transparent management server based on the node address.

[0031] According to a certificate verification method based on certificate trust transparency technology provided by the present invention, the client is loaded with a terminal trust enhancement verifier;

[0032] Sending the certificate to the client allows the client to verify the certificate based on its own list of trusted root certificates, including:

[0033] The certificate is sent to the client's endpoint trust enhancement verifier so that the client's endpoint trust enhancement verifier can verify the certificate based on its own list of trusted root certificates.

[0034] If the verification result is untrusted, the client is instructed to query the CA trust policy record from the trust policy transparency management server, and to perform supplementary verification of the certificate based on the obtained CA trust policy record, including:

[0035] If the verification result is untrusted, the client's terminal trust enhancement verifier queries the trust policy transparency management server for CA trust policy records and performs supplementary verification of the certificate based on the obtained CA trust policy records.

[0036] According to the present invention, a certificate verification method based on certificate trust transparency technology securely sends the signed CA trust policy record and CA trust policy public key to a trust policy transparency management server for storage, including:

[0037] The signed CA trust policy record and CA trust policy public key are securely sent to the trust policy transparent management server so that the trust policy transparent management server can verify the signature of the signed CA trust policy record. After passing the trustworthiness and integrity check, the signed CA trust policy record is stored using Merkle tree and sparse Merkle tree.

[0038] The Merkle tree is used to store CA trust policy records, and the root of the Merkle tree is signed by the trust policy transparent management server to ensure data integrity; the sparse Merkle tree is used to provide proof of the non-existence of the CA trust policy records, so as to quickly determine the storage location of the CA trust policy records.

[0039] The present invention also provides a certificate verification device based on certificate trust transparency technology, which is set on a website server. The website server is connected to a trust policy transparency management server, and the website server requests a signature certificate from a certificate authority (CA).

[0040] The device includes:

[0041] A key pair generation module is used to generate CA trust policy key pairs and certificate key pairs to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes a certificate public key and a certificate private key of the certificate to be applied for;

[0042] The certificate receiving module is used to generate a certificate issuance request based on the CA trust policy public key and the certificate public key, send the certificate issuance request to the CA, receive the certificate issued by the CA and save it; wherein, the certificate includes the CA trust policy public key;

[0043] The trust policy upload module is used to generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and securely send the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage.

[0044] The request processing module is used to send the certificate to the client upon receiving an access request from the client, so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

[0045] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the certificate verification method based on certificate trust transparency technology as described above.

[0046] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the certificate verification method based on certificate trust transparency technology as described above.

[0047] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the certificate verification method based on certificate trust transparency technology as described above.

[0048] The certificate verification method and apparatus based on certificate trust transparency technology provided by this invention stores, queries, and monitors CA trust policy records through a newly added trust policy transparency management server, ensuring the integrity of CA trust policy records and providing proof of their existence. Website servers can declare CA trust policies according to their own security needs, enabling flexible deployment of CA trust policies. When the website server receives an access request from a client, it first sends the certificate to the client for verification based on its own maintained list of trusted root certificates. If the verification result is trusted, secure communication is established between the client and the server. If the verification result is untrusted, the client can query the CA trust policy transparency management server for CA trust policy records and supplement the certificate verification based on the obtained CA trust policy records. Thus, even if the signed certificate requested by the website server is not in the list of trusted root certificates, it will not affect the certificate verification process, thereby improving the flexibility and interoperability of certificate verification. Attached Figure Description

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

[0050] Figure 1 This is a schematic diagram of a certificate verification system in the existing technology.

[0051] Figure 2 This is a schematic diagram of the certificate trust transparency system provided in an embodiment of the present invention.

[0052] Figure 3 This is one of the flowcharts of a certificate verification method based on certificate trust transparency technology provided in an embodiment of the present invention.

[0053] Figure 4 This is the second flowchart of the certificate verification method based on certificate trust transparency technology provided in this embodiment of the invention.

[0054] Figure 5 This is the third flowchart of the certificate verification method based on certificate trust transparency technology provided in this embodiment of the invention.

[0055] Figure 6 This is the fourth flowchart of the certificate verification method based on certificate trust transparency technology provided in this embodiment of the invention.

[0056] Figure 7 This is a schematic diagram of the certificate verification device based on certificate trust transparency technology provided by the present invention.

[0057] Figure 8 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

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

[0059] First, the terminology used in this embodiment will be explained illustratively.

[0060] (1) Certificate Signing Request (CSR): This is a signature request file required to apply for a digital certificate from a certificate authority. It contains data such as public key, organization information, and domain name, which are used by the CA to verify and issue the certificate.

[0061] (2) Certificate Trust Policy (CTP): Used to declare PKI trust anchors (i.e., a list of root certificates trusted by the domain owner) for a specific domain name. It includes the domain name, request type, policy submission or update timestamp, certificate data, trust policy, and signature. The trust policy includes the effective date and a hash list of trusted root certificates. The CTP data structure is as follows:

[0062] Struct {

[0063] List <domain>domain_list;

[0064] Uint64 start_time;

[0065] Uint64 match_method;

[0066] String match_type;

[0067] List <trustedca>trust_ca_list;

[0068] SignatureAlgorithm algorithm;

[0069] SignatureValue signature;

[0070] CTP

[0071] Here, `domain_list` is the list of domains for which the domain owner needs to deploy CA trust policies. These can be wildcard or non-wildcard domains. Wildcard domains require conflict checks with already deployed non-wildcard domains when submitting policies. `start_time` indicates the effective time of the current trust policy record. `match_method` indicates the method used by the client to verify the record after receiving the trust policy. A value of 0 indicates that `trust_ca_list` stores a list of hashes of trusted CA root certificate files, while a value of 1 indicates a list of unique identifiers of trusted CAs. `match_type` specifies the storage format of the data in `trust_ca_list`. For example, a value of `original` indicates that `trust_ca_list` stores a list of raw binary certificate data, a value of `sha256` indicates that it stores the SHA 256 hash value of the trusted certificate, and a value of `sha512` indicates that it stores the SHA 512 hash value of the trusted certificate. `trust_ca_list` identifies the list of trusted certificates or trusted CAs. `algorithm` represents the signature algorithm that ensures CTP integrity, and `signature` is the signature value.

[0072] (3) CA Trust Public Key (TPK): The domain owner or certificate holder can use this public key to sign CTP data to prevent arbitrary entities from tampering with the CTP data and to ensure the trustworthiness of the CTP data. TPK data can be written into the certificate file through the custom X.509 certificate extension field trust_policy_public_key to complete the public key publication process.

[0073] (4) CA Trust Secret / Private Key (TSK): Private key data corresponding to TPK.

[0074] (5) Trust Policy Deployment Signed Policy Timestamp (SPT): This is generated by the Trust Policy Transparent Management Server after successful CTP data storage using public key signing and returned to the trust policy submitter.

[0075] To achieve the improved flexibility and interoperability of certificate verification as stated in this embodiment, and to overcome the technical shortcomings of existing technologies where certificate verification fails due to the deletion or addition of CA certificates, this embodiment of the invention designs a Certificate Trust Transparency (CTT) system with a domain owner-defined verification strategy. Before introducing the certificate verification method of this embodiment, the Certificate Trust Transparency system of this embodiment will first be introduced.

[0076] See Figure 2 The certificate trust transparency system in this embodiment includes the following parts:

[0077] Website server: As the domain owner, it requests a signed certificate from the certificate authority, saves the signed certificate in the trust policy transparent management server, and sends the certificate to the client for verification when the client requests verification.

[0078] Client: This includes TLS clients such as browsers. When a client accesses a website server, it needs to request the website server's certificate for verification. After successful verification, a secure channel is established with the server to enable communication.

[0079] Certificate Authority (CA): Used to issue certificates based on the server's certificate issuance request.

[0080] Trust Anchor Manager (T-Manager): Loaded in the web server, it is used to implement the above-mentioned functions of the web server.

[0081] Authoritative name servers: These are the node addresses used to store the transparent management server for trust policies. It is an abstract logical entity; the actual physical machines can be distributed in a hierarchical structure and managed by the website server. The website server can directly configure and modify the data stored in the authoritative name servers.

[0082] Terminal Trust Enhancement Validator (T-Validator): Loaded in the client, it is used to implement the above-mentioned functions of the client.

[0083] The Trust Policy Transparent Management Server (T-Publisher) is a new server added to this embodiment compared to existing technologies. It stores CA trust policy records and sends these records to the client when the client requests them. The Trust Policy Transparent Management Server ensures the integrity, reliability, and auditability of the CA trust policy records.

[0084] Safety Assumptions:

[0085] (1) All domain name owners and clients are trustworthy;

[0086] (2) A CA may issue unauthorized certificates or maliciously revoke valid certificates, and the root certificate list may intentionally remove trusted root certificates;

[0087] (3) The Trust Policy Transparency Management Server T-Publisher may promise to publish but fail to actually publish the CA trust policy data submitted by the domain name owner.

[0088] The following is combined with Figures 3-8 This invention describes a certificate verification method and apparatus based on certificate trust transparency technology.

[0089] This invention discloses a certificate verification method based on certificate trust transparency technology for a website server. The website server is connected to a trust policy transparency management server, and the website server requests a signature certificate from a Certificate Authority (CA).

[0090] See Figure 3 The method includes:

[0091] 301. Generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes a certificate public key and a certificate private key of the certificate to be applied for.

[0092] In this embodiment, the website server, as the domain name owner, can generate two key pairs simultaneously.

[0093] CA Trust Policy Key Pair<TSK,TPK> In this system, TSK is the CA trust policy private key, and TPK is the CA trust policy public key. The CA trust policy key pair is used to sign the trust policy record, where the CA trust policy public key is written into the certificate extension.

[0094] Certificate key pair to be applied for<SK,PK> In this context, SK is the private key and PK is the public key. The key pair for the certificate to be requested is used to apply for a certificate from a Certificate Authority (CA). Different CAs will have different key pairs for the certificate to be requested.

[0095] 302. Generate a certificate issuance request based on the CA trust policy public key and the certificate public key, send the certificate issuance request to the CA, receive the certificate issued by the CA, and save it.

[0096] It should be noted that during the process of a website server requesting a certificate from a CA, the certificate issuance request sent will only include the public key; the private key will not be sent to the CA.

[0097] In this embodiment, the Certificate Issuance Request (CSR) includes main information such as the certificate's common name, organization name, and address, and also requires the addition of the CA Trust Policy Public Key (TPK).

[0098] Specifically, step 302 includes: determining a custom CA trust policy, identifying at least one CA to which the certificate issuance request is to be sent; sending the certificate issuance request to at least one CA through a trust anchor manager; and receiving a certificate issued by at least one CA through the trust anchor manager.

[0099] In this case, the public key of the certificate in the certificate issuance request corresponding to each CA is different.

[0100] For example, if a CA includes CA1, CA2, and CA3, and the website server determines that the trusted CA root certificates are CA1 and CA2, then it sends certificate issuance requests to CA1 and CA2 respectively. Correspondingly, the website server generates a Certificate Issuance Request (CSR1) based on PK1 and TPK and sends it to CA1. CA1 signs the website certificate based on CSR1 and returns the signed certificate Cert1. Similarly, it generates a Certificate Issuance Request (CSR2) based on PK2 and TPK and sends it to CA2. CA2 signs the website certificate based on CSR2 and returns the signed certificate Cert2. The generated certificates can be stored in the website server's storage space and sent to the client upon receiving an access request from a client.

[0101] It's important to explain that the root certificate is the foundation upon which trust is established between the CA and the web server. A web certificate issued by a CA must have a trusted root certificate to be valid. In other words, the root certificate represents trust from the CA. A root certificate is a special type of certificate; its issuer is not the CA, but the certificate itself.

[0102] 303. Generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and securely send the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage.

[0103] The step of generating a CA trust policy record based on the issued certificate includes: determining the CA root certificate corresponding to the issued certificate, and generating a CA trust policy record based on the issued certificate and its corresponding CA root certificate, wherein the CA trust policy record includes a list of trusted CA root certificates.

[0104] For example, if a website server receives certificates issued by a CA including Cert1 and Cert2, it determines the corresponding root certificates RootCert1 and RootCert2 based on Cert1 and Cert2 respectively, and then generates a list of CA root certificates based on the root certificates RootCert1 and RootCert2.

[0105] Furthermore, after signing the CA trust policy record using the CA trust policy private key, the signed CA trust policy record and the CA trust policy public key are securely sent to the trust policy transparency management server. The trust policy transparency management server then verifies the signed CA trust policy record. After passing the trustworthiness and integrity checks, the signed CA trust policy record is stored using a Merkle tree and a sparse Merkle tree. The Merkle tree is used to store the CA trust policy record, and the trust policy transparency management server signs the root of the Merkle tree to ensure data integrity. The sparse Merkle tree provides proof of the non-existence of the CA trust policy record, quickly determining its storage location. The trust policy transparency management server ensures the integrity, trustworthiness, and auditability of the CA trust policy record.

[0106] Furthermore, after receiving the signed CA Trust Policy Record (CTP) or the updated CA Trust Policy Record (CTP'), the Trust Policy Transparency Management Server (T-Publisher) needs to verify the CTP or CTP'.

[0107] Generally, it includes the following four items: certificate validity verification; certificate domain name matching verification with trust policy domain name verification; trust policy validity verification; and verification of the trust policy submitter's ownership of the domain name.

[0108] After successful verification, the Trust Policy Transparent Management Server T-Publisher stores the received CA Trust Policy Record (CTP) or the updated CA Trust Policy Record (CTP').

[0109] 304. Upon receiving an access request from a client, the certificate is sent to the client so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

[0110] Specifically, the client maintains a list of trusted root certificates, containing root certificates corresponding to hundreds of CAs, used to verify requested certificates. This list of trusted root certificates can be maintained by a third-party vendor and stored in the client's browser. However, if a CA is lost, accidentally deleted, or if the certificate sent to the client by the server includes a newly added CA, the verification result will be untrusted. Under current technology, this could potentially disrupt the communication service.

[0111] However, in the method of this embodiment, if the verification result is untrusted, the client can query the CA trust policy record from the trust policy transparent management server and perform supplementary verification of the certificate based on the obtained CA trust policy record. With this setting, the website server can define its own CA trust policy according to its security needs. Even with newly added certificates, the client can still complete the verification without affecting the certificate verification process, thereby improving the flexibility and interoperability of certificate verification.

[0112] Specifically, the process of the client verifying the certificate based on its own list of trusted root certificates, as well as the process of querying the CA trust policy record from the trust policy transparent management server and supplementing the certificate verification based on the obtained CA trust policy record, can all be accomplished by the terminal trust enhancement validator T-Validator loaded by the client.

[0113] The certificate verification method based on certificate trust transparency technology provided in this invention uses a newly added trust policy transparent management server to store, query, and monitor CA trust policy records, ensuring the integrity of the CA trust policy records and providing proof of their existence. Website servers can declare CA trust policies according to their own security needs, enabling flexible deployment of CA trust policies. When a website server receives an access request from a client, it first sends the certificate to the client for verification based on its own maintained list of trusted root certificates. If the verification result is trusted, secure communication is established between the client and the server. If the verification result is untrusted, the client can query the trust policy transparent management server for CA trust policy records and supplement the certificate verification based on the obtained CA trust policy records. Thus, even if the signed certificate requested by the website server is not in the list of trusted root certificates, it will not affect the certificate verification process, thereby improving the flexibility and interoperability of certificate verification.

[0114] Furthermore, the website server may also update the CA trust policy. In this case, see [link to relevant documentation]. Figure 4 The method includes:

[0115] 401. If it is necessary to update the trusted CA root certificate, determine the target CA based on the CA root certificate in the saved CA trust policy record and the CA root certificate that needs to be updated.

[0116] For example, if a website server's existing CA trust policy includes CA1 and CA2 root certificates, and the website server needs to change to trusting both CA1 and CA3 root certificates, then since CA1 already exists, the website server needs to obtain CA3 to replace CA2. Therefore, the target CA is determined to be CA3.

[0117] 402. Send a certificate issuance request to the target CA, receive the certificate issued by the target CA, and save it.

[0118] 403. Based on the certificate issued by the target CA, update the trusted CA certificate, generate an updated CA trust policy record based on the CA root certificate corresponding to the updated CA certificate, sign the updated CA trust policy record with the CA trust policy private key, and securely send the updated CA trust policy record with the signature and the CA trust policy public key to the trust policy transparent management server for storage.

[0119] After obtaining and saving the certificate Cert3 issued by CA3, the website server determines the corresponding root certificate RootCert3 based on Cert3. Then, based on the root certificates RootCert1 and RootCert3, it generates an updated CA Trust Policy Record (CTP'). The CTP' is then signed using the CA Trust Policy Private Key (TSK) and sent to the Trust Policy Transparent Management Server (T-publisher) for storage. This process employs cryptographic techniques to ensure the integrity and authentication of the information.

[0120] Through steps 401-403, the website server can declare a CA trust policy according to its own security needs, that is, the domain name can independently select a list of CA root certificates; the domain name owner can independently select a CA trust policy management system to manage and maintain its trust policy, and only the domain name owner can deploy and update the trust policy record corresponding to its domain name.

[0121] Furthermore, after securely sending the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage, the trust policy transparent management server will also add a timestamp to the signed CA trust policy record, and after successfully storing the CA trust policy record, return the trust policy deployment signature timestamp SPT to the website server.

[0122] See Figure 5 The method further includes:

[0123] 501. Receive the Trust Policy Deployment Signature Timestamp (SPT) returned by the Trust Policy Transparent Management Server, wherein the Trust Policy Deployment Signature Timestamp is generated by the Trust Policy Transparent Management Server adding a timestamp to the signed CA Trust Policy Record; the Trust Policy Deployment Signature Timestamp carries the node address.

[0124] 502. Store the node address corresponding to the trust policy deployment signature timestamp in the authoritative domain name server.

[0125] Through steps 501-502, the website server can store the T-Publisher node address corresponding to the signed CA trust policy record in the authoritative name server. In subsequent steps, when the client requests access to the trust policy transparent management server T-Publisher, it can first obtain the corresponding T-Publisher node address from the authoritative name server.

[0126] Correspondingly, if the client's verification result of the certificate based on its own maintained list of trusted root certificates is untrusted, before querying the CA trust policy record from the trust policy transparency management server, see [link to relevant documentation]. Figure 6 The method further includes:

[0127] 601. Receive the address query request from the client.

[0128] 602. Based on the address query request, query the authoritative domain name server for the node address corresponding to the address query request, so that the client can access the trust policy transparent management server based on the node address.

[0129] Since the client itself does not know the node address of the Trust Policy Transparent Management Server T-Publisher, through steps 601-602, the client can determine the node address to be accessed, and access T-Publisher according to the node address to request the CA Trust Policy Record, and perform supplementary verification of the certificate based on the obtained CA Trust Policy Record.

[0130] To facilitate understanding of the overall scheme of this embodiment, this embodiment also discloses a method to provide a detailed explanation of the execution steps of the certificate trust transparency system of this embodiment.

[0131] by Figure 2 For example, the certificate verification method in this embodiment includes:

[0132] S1. Trust Policy Key Pair Generation. The domain owner generates the CA trust policy key pair.<TSK,TPK> The key pair is used to sign the trust policy record data; and the certificate key pair is used to apply for a website certificate from the CA.

[0133] In this embodiment, the domain name owner is the website server.

[0134] S2. Certificate Request and Issuance. The domain owner sends a certificate issuance request to at least one CA through T-Manager to request the issuance of a certificate.

[0135] The Certificate Issuance Request (CSR) includes key information such as the certificate's common name, organization name, and address, and also requires the addition of the CA Trust Policy Public Key (TPK).

[0136] S3. CA Trust Policy Submission. The domain owner generates a CA Trust Policy Record (CTP) based on the current trust policy for anchors such as the CA root certificate, signs the CTP using the CA Trust Policy private key (TSK), and securely submits the signed CTP and the CA Trust Policy public key (TPK) to T-Publisher. This process uses cryptographic techniques to ensure the integrity, authentication, and non-repudiation of the information.

[0137] S4. CA Trust Policy Update. When updating the trust anchor (e.g., initially trusting the root certificate of CA1, then changing to the root certificate of CA2), the domain owner needs to generate a CA Trust Policy Record (CTP) 'based on the latest trust policy and sign the CTP ' using the TSK'. Then, the CTP ' and the CA trust policy public key (TPK) are securely submitted to the trust policy transparent management server, T-Publisher. This process uses cryptographic techniques to ensure the integrity and authentication of the information.

[0138] S5. Trust Policy Trustworthiness and Integrity Verification. After receiving a CTP submission or update request, the Trust Policy Transparent Management Server T-Publisher needs to complete the following verifications:

[0139] Validation of trust strategy effectiveness;

[0140] The trust policy submitter verifies the ownership of the domain name.

[0141] S6. CA Trust Policy Deployment and Public Disclosure. The Trust Policy Data Management System T-Publisher stores the CA Trust Policy Records (CTPs) submitted by domain owners, ensuring that CTPs are append-only, verifiable, and publicly auditable. T-Publisher allows user terminals and domain owners to query and monitor CTP data. After a domain owner submits a CTP, T-Publisher adds a timestamp to the record. After successful CTP data storage, T-Publisher returns the Trust Policy Deployment Signature Timestamp (SPT) to the domain owner or T-Manager. The node address corresponding to the Trust Policy Deployment Signature Timestamp (SPT) is stored in the authoritative name server.

[0142] T-Publisher can store CTP data using Merkle trees and sparse Merkle trees. Merkle trees are used to store CTP data, with T-Publisher signing the Merkle tree root to ensure data integrity. Sparse Merkle trees provide proof of CTP non-existence, enabling rapid determination of CTP storage location and providing efficient query capabilities. It is recommended that T-Publisher use different signing keys for the signing timestamp and the Merkle tree root.

[0143] S7. Terminal Acquisition and Verification of Certificates. After sending an access request to the server and obtaining the certificate returned by the server, the terminal trust enhancement authenticator (T-Validator) first performs a standardized TLS certificate verification process, including certificate validity and trustworthiness checks, based on the list of trusted root certificates maintained by the browser or operating system.

[0144] If the certificate verification result is "root certificate trusted", then a secure channel is established to conduct secure communication with the server.

[0145] If the certificate verification result is "root certificate untrusted", the terminal trust enhancement validator T-Validator queries the CA trust policy record (CTP) corresponding to the currently accessed domain name from the T-Publisher, and then completes the enhanced certificate trustworthiness verification according to the CA trust policy deployed in the CTP record.

[0146] The method of this embodiment can achieve the following technical effects:

[0147] (1) Flexible Trust: Domain owners can declare CA trust policies according to their own security needs, that is, the domain name can independently select a list of trusted CA root certificates. Domain owners can independently choose a CA trust policy management system to manage and maintain their trust policies, and only domain owners can deploy and update the trust policy data corresponding to their domains.

[0148] (2) Security enhancement: The present invention prioritizes the client to complete the certificate trustworthiness verification based on its own list of trusted root certificates. Only when the certificate is not trusted will it attempt to use the method of querying the CA trust policy record from the trust policy transparent management server to complete the certificate supplementary verification, ensuring compatibility with existing protocols.

[0149] (3) The trust policy can be publicly verified, which facilitates auditing and supervision. In this embodiment, the trust policy management system honestly records the CA trust policy declared by the domain name owner, ensuring the integrity of the CA trust policy and preventing the policy from being tampered with.

[0150] (4) Trust policy is easy to manage and maintain: In this embodiment, the certificate, CA trust policy and trust policy public key are decoupled. When adding a trusted root certificate or updating the CA trust policy, it is only necessary to complete the signing of the certificate issuance request for the new trusted certificate to generate a new certificate, without having to revoke the already issued certificate.

[0151] The certificate verification device based on certificate trust transparency technology provided in the embodiments of the present invention will be described below. The certificate verification device based on certificate trust transparency technology described below can be referred to in correspondence with the certificate verification method based on certificate trust transparency technology described above.

[0152] This invention provides a certificate verification device based on certificate trust transparency technology, which is set on a website server. The website server is connected to a trust policy transparency management server, and the website server requests a signature certificate from a certificate authority (CA).

[0153] See Figure 7 The device includes:

[0154] The key pair generation module 701 is used to generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes a certificate public key and a certificate private key of the certificate to be applied for.

[0155] The certificate receiving module 702 is used to generate a certificate issuance request based on the CA trust policy public key and the certificate public key, send the certificate issuance request to the CA, receive the certificate issued by the CA and save it; wherein, the certificate includes the CA trust policy public key;

[0156] The trust policy upload module 703 is used to generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and securely send the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage.

[0157] The request processing module 704 is used to send the certificate to the client upon receiving an access request from the client, so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

[0158] Optionally, the website server is loaded with a trust anchor manager, and the website server stores the CA root certificate corresponding to the CA.

[0159] Certificate receiving module 702 is specifically used for:

[0160] Determine a custom CA trust policy and identify at least one CA to which the certificate issuance request will be sent;

[0161] The certificate issuance request is sent to the at least one CA through the trust anchor manager; wherein the certificate public key in the certificate issuance request corresponding to each CA is different.

[0162] Receive at least one certificate issued by a CA through the trust anchor manager;

[0163] Trust policy upload module 703 is specifically used for:

[0164] The CA root certificate corresponding to the issued certificate is determined, and the CA trust policy record is generated based on the issued certificate and its corresponding CA root certificate, wherein the CA trust policy record includes a list of trusted CA root certificates.

[0165] Optionally, the device further includes:

[0166] The update module is used to, after sending the certificate issuance request to the CA and receiving the certificate issued by the CA, determine the target CA if it is necessary to update the trusted CA root certificate, based on the CA root certificate in the saved CA trust policy record and the CA root certificate to be updated.

[0167] The certificate receiving module 702 is used to send a certificate issuance request to the target CA, receive the certificate issued by the target CA, and save it.

[0168] The trust policy upload module 703 is used to update the trusted CA certificate according to the certificate issued by the target CA, generate an updated CA trust policy record according to the CA root certificate corresponding to the updated CA certificate, sign the updated CA trust policy record with the CA trust policy private key, and send the updated CA trust policy record with the signature and the CA trust policy public key to the trust policy transparent management server for storage.

[0169] Optionally, the website server further includes: an authoritative domain name server, used to store the node address of the trust policy transparent management server;

[0170] The device further includes a timestamp storage module for:

[0171] After sending the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage, the system receives the trust policy deployment signature timestamp returned by the trust policy transparent management server. The trust policy deployment signature timestamp is generated by the trust policy transparent management server adding a timestamp to the signed CA trust policy record, and the trust policy deployment signature timestamp carries the node address.

[0172] The node address corresponding to the deployment signature timestamp of the trust policy is stored in the authoritative domain name server.

[0173] Optionally, the apparatus further includes: an address query module, configured to receive an address query request from the client before enabling the client to query the CA trust policy record from the trust policy transparency management server;

[0174] Based on the address query request, the node address corresponding to the address query request is queried in the authoritative domain name server, so that the client can access the trust policy transparent management server based on the node address.

[0175] Optionally, the client is loaded with a terminal trust enhancement authenticator;

[0176] Request processing module 704 is specifically used for:

[0177] The certificate is sent to the client's endpoint trust enhancement verifier so that the client's endpoint trust enhancement verifier can verify the certificate based on its own list of trusted root certificates.

[0178] If the verification result is untrusted, the client's terminal trust enhancement verifier queries the trust policy transparency management server for CA trust policy records and performs supplementary verification of the certificate based on the obtained CA trust policy records.

[0179] Optionally, the trust policy upload module 703 is specifically used for:

[0180] The signed CA trust policy record and CA trust policy public key are securely sent to the trust policy transparent management server so that the trust policy transparent management server can verify the signature of the signed CA trust policy record. After passing the trustworthiness and integrity check, the signed CA trust policy record is stored using Merkle tree and sparse Merkle tree.

[0181] The Merkle tree is used to store CA trust policy records, and the root of the Merkle tree is signed by the trust policy transparent management server to ensure data integrity; the sparse Merkle tree is used to provide proof of the non-existence of the CA trust policy records, so as to quickly determine the storage location of the CA trust policy records.

[0182] The certificate verification device based on certificate trust transparency technology provided in this invention uses a newly added trust policy transparency management server to store, query, and monitor CA trust policy records, ensuring the integrity of the CA trust policy records and providing proof of their existence. Website servers can declare CA trust policies according to their own security needs, enabling flexible deployment of CA trust policies. When a website server receives an access request from a client, it first sends the certificate to the client for verification based on its own maintained list of trusted root certificates. If the verification result is trusted, secure communication is established between the client and the server. If the verification result is untrusted, the client can query the trust policy transparency management server for CA trust policy records and supplement the certificate verification based on the obtained CA trust policy records. Thus, even if the signed certificate requested by the website server is not in the list of trusted root certificates, it will not affect the certificate verification process, thereby improving the flexibility and interoperability of certificate verification.

[0183] Figure 8 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 8 As shown, the electronic device may include: a processor 810, a communications interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communications interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 can call logical instructions in the memory 830 to execute a certificate verification method based on certificate trust transparency technology, including:

[0184] Generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes the certificate public key and certificate private key of the certificate to be applied for;

[0185] A certificate issuance request is generated based on the CA's trust policy public key and the certificate public key, and the certificate issuance request is sent to the CA. The certificate issued by the CA is received and stored. The certificate includes the CA's trust policy public key.

[0186] Generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and then securely send the signed CA trust policy record and the CA trust policy public key to the trust policy transparent management server for storage.

[0187] Upon receiving an access request from a client, the certificate is sent to the client so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

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

[0189] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to execute the certificate verification method based on certificate trust transparency technology provided by the above methods, including:

[0190] Generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes the certificate public key and certificate private key of the certificate to be applied for;

[0191] A certificate issuance request is generated based on the CA's trust policy public key and the certificate public key, and the certificate issuance request is sent to the CA. The certificate issued by the CA is received and stored. The certificate includes the CA's trust policy public key.

[0192] Generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and then securely send the signed CA trust policy record and the CA trust policy public key to the trust policy transparent management server for storage.

[0193] Upon receiving an access request from a client, the certificate is sent to the client so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

[0194] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the certificate verification method based on certificate trust transparency technology provided by the above methods, including:

[0195] Generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes the certificate public key and certificate private key of the certificate to be applied for;

[0196] A certificate issuance request is generated based on the CA's trust policy public key and the certificate public key, and the certificate issuance request is sent to the CA. The certificate issued by the CA is received and stored. The certificate includes the CA's trust policy public key.

[0197] Generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and then securely send the signed CA trust policy record and the CA trust policy public key to the trust policy transparent management server for storage.

[0198] Upon receiving an access request from a client, the certificate is sent to the client so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

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

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

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

Claims

1. A certificate verification method based on certificate trust transparency technology, characterized in that, Used for a website server, the website server is connected to a trust policy transparent management server, and the website server requests a signing certificate from a certificate authority (CA). The method includes: Generate a CA trust policy key pair and a certificate key pair to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes a certificate public key and a certificate private key of the certificate to be applied for; A certificate issuance request is generated based on the CA's trust policy public key and the certificate public key, and the certificate issuance request is sent to the CA. The certificate issued by the CA is received and stored. The certificate includes the CA's trust policy public key. A CA trust policy record is generated based on the issued certificate. The CA trust policy record is then signed with the CA trust policy private key. The signed CA trust policy record and the CA trust policy public key are then securely sent to the trust policy transparent management server for storage. Upon receiving an access request from a client, the certificate is sent to the client so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparency management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

2. The certificate verification method based on certificate trust transparency technology according to claim 1, characterized in that, The website server is loaded with a trust anchor manager, and the website server stores the CA root certificate corresponding to the CA. Sending the certificate issuance request to the CA and receiving the certificate issued by the CA includes: Determine a custom CA trust policy and identify at least one CA to which the certificate issuance request will be sent; The certificate issuance request is sent to the at least one CA through the trust anchor manager; wherein the certificate public key in the certificate issuance request corresponding to each CA is different; Receive at least one certificate issued by a CA through the trust anchor manager; Generate a CA trust policy record based on the issued certificate, including: The CA root certificate corresponding to the issued certificate is determined, and the CA trust policy record is generated based on the issued certificate and its corresponding CA root certificate, wherein the CA trust policy record includes a list of trusted CA root certificates.

3. The certificate verification method based on certificate trust transparency technology according to claim 1, characterized in that, After sending the certificate issuance request to the CA and receiving the certificate issued by the CA, the method further includes: If it is necessary to update the trusted CA root certificate, determine the target CA based on the CA root certificate in the saved CA trust policy record and the CA root certificate that needs to be updated. Send a certificate issuance request to the target CA, receive the certificate issued by the target CA, and save it; Based on the certificate issued by the target CA, the trusted certificate is updated. Based on the CA root certificate corresponding to the updated certificate, an updated CA trust policy record is generated. After signing the updated CA trust policy record with the CA trust policy private key, the updated CA trust policy record carrying the signature and the CA trust policy public key are sent to the trust policy transparent management server for storage.

4. The certificate verification method based on certificate trust transparency technology according to claim 1, characterized in that, The website server also includes: an authoritative domain name server, used to store the node address of the trust policy transparent management server; After securely sending the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage, the method further includes: The system receives a trust policy deployment signature timestamp returned by the trust policy transparent management server. The trust policy deployment signature timestamp is generated by the trust policy transparent management server adding a timestamp to the signed CA trust policy record. The trust policy deployment signature timestamp carries a node address. The node address corresponding to the deployment signature timestamp of the trust policy is stored in the authoritative domain name server.

5. The certificate verification method based on certificate trust transparency technology according to claim 4, characterized in that, Before enabling clients to query CA trust policy records from the trust policy transparent management server, the following is also included: Receive address query requests from clients; Based on the address query request, the node address corresponding to the address query request is queried in the authoritative domain name server, so that the client can access the trust policy transparent management server based on the node address.

6. The certificate verification method based on certificate trust transparency technology according to claim 5, characterized in that, The client is loaded with a terminal trust enhancement verifier; Sending the certificate to the client allows the client to verify the certificate based on its own list of trusted root certificates, including: The certificate is sent to the client's endpoint trust enhancement verifier so that the client's endpoint trust enhancement verifier can verify the certificate based on its own list of trusted root certificates. If the verification result is untrusted, the client is instructed to query the CA trust policy record from the trust policy transparency management server, and to perform supplementary verification of the certificate based on the obtained CA trust policy record, including: If the verification result is untrusted, the client's terminal trust enhancement verifier queries the trust policy transparency management server for CA trust policy records and performs supplementary verification of the certificate based on the obtained CA trust policy records.

7. The certificate verification method based on certificate trust transparency technology according to claim 1, characterized in that, The signed CA trust policy record and CA trust policy public key are securely sent to the trust policy transparent management server for storage, including: The signed CA trust policy record and CA trust policy public key are securely sent to the trust policy transparent management server so that the trust policy transparent management server can verify the signature of the signed CA trust policy record. After passing the trustworthiness and integrity check, the signed CA trust policy record is stored using Merkle tree and sparse Merkle tree. The Merkle tree is used to store CA trust policy records, and the root of the Merkle tree is signed by the trust policy transparent management server to ensure data integrity; the sparse Merkle tree is used to provide proof of the non-existence of the CA trust policy records, so as to quickly determine the storage location of the CA trust policy records.

8. A certificate verification device based on certificate trust transparency technology, characterized in that, The website server is configured to connect to the Trust Policy Transparent Management Server, and the website server requests a signing certificate from the Certificate Authority (CA). The device includes: A key pair generation module is used to generate CA trust policy key pairs and certificate key pairs to be applied for; wherein, the CA trust policy key pair includes a CA trust policy public key and a CA trust policy private key, and the certificate key pair to be applied for includes a certificate public key and a certificate private key of the certificate to be applied for; The certificate receiving module is used to generate a certificate issuance request based on the CA trust policy public key and the certificate public key, send the certificate issuance request to the CA, receive the certificate issued by the CA and save it; wherein, the certificate includes the CA trust policy public key; The trust policy upload module is used to generate a CA trust policy record based on the issued certificate, sign the CA trust policy record with the CA trust policy private key, and securely send the signed CA trust policy record and CA trust policy public key to the trust policy transparent management server for storage. The request processing module is used to send the certificate to the client upon receiving an access request from the client, so that the client can verify the certificate based on its own list of trusted root certificates. If the verification result is trusted, a secure channel is established to enable secure communication between the client and the server. If the verification result is untrusted, the client queries the CA trust policy record from the trust policy transparent management server and performs supplementary verification of the certificate based on the obtained CA trust policy record.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the certificate verification method based on certificate trust transparency technology as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the certificate verification method based on certificate trust transparency technology as described in any one of claims 1 to 7.

Images