Safety verification method and system based on ACME protocol and related device

Abstract

The invention discloses a security verification method based on an ACME protocol, a security verification system based on the ACME protocol, a computer program product, a CA server, ACME client equipment and a computer readable storage medium. The method comprises the steps that a to-be-verified ACME client sends a certificate request to the CA server based on a target ACME account; if the CA server does not query an effective client authorization record of the to-be-verified ACME client based on the to-be-verified identification information, selecting at least one target domain name from the at least one verified domain name, and re-verifying the ownership of the to-be-verified ACME client to the at least one target domain name; and if the verification of the ownership is passed, the CA server generates an effective client authorization record for the to-be-verified ACME client based on the to-be-verified identification information, and issues a certificate for the to-be-verified ACME client based on the generated effective client authorization record and the effective domain name authorization record of the at least one verified domain name. The security of certificate issuing can be improved.

Description

Technical Field

[0001] This application relates to the field of security verification, and in particular, to a security verification method based on the ACME protocol, a security verification system based on the ACME protocol, a computer program product, a CA server, an ACME client device, and a computer-readable storage medium. Background Art

[0002] Web Public Key Infrastructure (PKI) is an architecture designed to ensure the security of communication between websites and users. This architecture uses certificates to bind the public keys used by websites to encrypt information to the identities of the websites (usually domain names). The core components of Web PKI mainly include a Certificate Authority (CA) and an End Entity (EE). The CA plays a core role in the Web PKI framework and is responsible for issuing, managing, and revoking all EE certificates. As an EE, the Web server establishes a secure Hypertext Transfer Protocol Secure (HTTPS) connection with the user's client (such as a browser) by deploying a Secure Socket Layer (SSL) certificate.

[0003] The CA can automate the management of the life cycle of SSL certificates based on the Automated Certificate Management Environment (ACME) protocol, including certificate requests, issuances, renewals, and revocations.

[0004] The Web server can use an ACME client to request an SSL certificate from the CA server based on the ACME protocol. However, for a domain name with a valid domain name authorization (Authz) record cached on the CA server, an attacker can use this valid domain name authorization record to skip the verification of the ownership of the corresponding domain name and directly obtain a fraudulent certificate (fraudulent) for that domain name, resulting in relatively low security for certificate issuance. Summary of the Invention

[0005] In view of the above technical problems, this application provides a navigation method, a navigation device, an electronic device, and a computer-readable storage medium, and the technical solutions are as follows:

[0006] According to a first aspect of this application, there is provided a security verification method based on the ACME protocol, and the method includes:

[0007] The to-be-verified ACME client sends a certificate request to the CA server based on the target ACME account. The certificate request is used to request a certificate for at least one verified domain name and carries the to-be-verified identification information of the to-be-verified ACME client. The verified domain name is a domain name with a valid domain name authorization record associated with the target ACME account.

[0008] If the CA server fails to query a valid client authorization record of the to-be-verified ACME client based on the to-be-verified identification information, at least one target domain name is selected from the at least one verified domain name, and the ownership of the to-be-verified ACME client for the at least one target domain name is re-verified.

[0009] If the verification of the ownership passes, the CA server generates a valid client authorization record for the to-be-verified ACME client based on the to-be-verified identification information, and issues the certificate for the to-be-verified ACME client based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

[0010] According to a second aspect of the present application, there is provided a security verification method based on the ACME protocol, which is applied to a CA server. The method includes:

[0011] Receiving a certificate request sent by a to-be-verified ACME client based on a target ACME account. The certificate request is used to request a certificate for at least one verified domain name and carries the to-be-verified identification information of the to-be-verified ACME client. The verified domain name is a domain name with a valid domain name authorization record associated with the target ACME account.

[0012] If a valid client authorization record of the to-be-verified ACME client cannot be queried based on the to-be-verified identification information, at least one target domain name is selected from the at least one verified domain name, and the ownership of the to-be-verified ACME client for the at least one target domain name is re-verified.

[0013] If the verification of the ownership passes, a valid client authorization record is generated for the to-be-verified ACME client based on the to-be-verified identification information, and the certificate is issued for the to-be-verified ACME client based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

[0014] According to a third aspect of the present application, there is provided a security verification method based on the ACME protocol, which is applied to an ACME client. The method includes:

[0015] Send a certificate request to the CA server based on the target ACME account, where the certificate request is used to request a certificate for at least one verified domain name and carries the unverified identification information of the ACME client; the verified domain name is a domain name associated with the target ACME account that has a valid domain name authorization record.

[0016] Receive an indication from the CA server to re-verify the ownership of at least one target domain name, where the at least one target domain name is selected from the at least one verified domain name when the CA server fails to query a valid client authorization record of the ACME client based on the unverified identification information.

[0017] Receive the certificate issued by the CA server, where the certificate is issued by the CA server for the ACME client based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name when the verification of the ownership passes, and the CA server generates a valid client authorization record for the ACME client based on the unverified identification information.

[0018] According to the fourth aspect of the present application, a security verification system based on the ACME protocol is provided, which includes: an unverified ACME client and a CA server;

[0019] The unverified ACME client is used to send a certificate request to the CA server based on the target ACME account, where the certificate request is used to request a certificate for at least one verified domain name and carries the unverified identification information of the unverified ACME client; the verified domain name is a domain name associated with the target ACME account that has a valid domain name authorization record.

[0020] The CA server is used to select at least one target domain name from the at least one verified domain name and re-verify the ownership of the at least one target domain name by the unverified ACME client if a valid client authorization record of the unverified ACME client cannot be queried based on the unverified identification information; if the verification of the ownership passes, a valid client authorization record is generated for the unverified ACME client based on the unverified identification information, and the certificate is issued for the unverified ACME client based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

[0021] According to the fifth aspect of the present application, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the method described in any one of the first to third aspects.

[0022] According to a sixth aspect of the present application, a CA server is provided, the CA server comprising:

[0023] processor;

[0024] a memory for storing processor-executable instructions;

[0025] The processor is configured to implement the method as described in any one of the first to third aspects.

[0026] According to a seventh aspect of the present application, an ACME client device is provided, the ACME client device comprising:

[0027] processor;

[0028] a memory for storing processor-executable instructions;

[0029] The processor is configured to implement the method as described in any one of the first to third aspects.

[0030] According to an eighth aspect of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the method described in any one of the first to third aspects are implemented.

[0031] The technical solution provided by the present application is that for a verified domain name with a valid domain name authorization record associated with a target ACME account cached on a CA server, when an ACME client applies for a certificate based on the target ACME account, it is necessary to verify the legitimacy of the ACME client itself. Only when it proves its legitimacy can it use the valid domain name authorization record to skip the ownership verification of the verified domain name and directly obtain the corresponding certificate.

[0032] The result of the ACME client's legitimacy authentication is associated with the ACME client's identification information. If the result of the legitimacy authentication (valid client authorization record) cannot be queried based on the ACME client's identification information, legitimacy authentication is required. Specifically, the target domain name is selected from the verified domain names to re-verify ownership. Only if the ACME client passes the verification can it obtain the right to use the valid domain name authorization record of the verified domain name, that is, it can skip the ownership verification of the verified domain name and directly obtain the corresponding certificate. This can prevent attackers from using valid domain name authorization records to bypass domain name ownership verification and obtain fraudulent certificates as much as possible, thereby improving the security of certificate issuance.

[0033] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] To more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings described below are only some embodiments recorded in the present application. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings.

[0035] Figure 1 is a schematic diagram of the network architecture of Web PKI in related technologies;

[0036] Figure 2 is a schematic diagram of a process in which a Web server uses an ACME client to request an SSL certificate from a CA server in related technologies;

[0037] Figure 3 is a schematic diagram of a process in which an attacker uses an Authz record associated with an ACME account cached by a CA server for an attack in related technologies;

[0038] Figure 4 is a schematic diagram of the process of a security verification method based on the ACME protocol according to an embodiment of the present application;

[0039] Figure 5 is a schematic diagram of a specific application scenario of security verification based on the ACME protocol according to an embodiment of the present application;

[0040] Figure 6 is a schematic diagram of the structure of a security verification system based on the ACME protocol according to an embodiment of the present application;

[0041] Figure 7 is a schematic diagram of the structure of a CA server according to an embodiment of the present application;

[0042] Figure 8 is a schematic diagram of the structure of an ACME client device according to an embodiment of the present application. Detailed implementation manners

[0043] To enable those skilled in the art to better understand the technical solutions in the present application, the following will describe the technical solutions in the embodiments of the present application in detail in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art shall fall within the protection scope of the present application.

[0044] The following will be combined with Figure 1 , and an exemplary description will be given of the network architecture of Web PKI in related technologies:

[0045] Web Public Key Infrastructure (PKI) is an architecture designed to ensure the security of communication between websites and users. This architecture uses certificates to bind the public keys that websites use to encrypt information to the identities of the websites (usually domain names). When users communicate with websites using the Transport Layer Security (TLS) protocol, they can verify the identities of the websites through certificates, which can be used to prevent data tampering and man-in-the-middle attacks (MITM).

[0046] As Figure 1 shown in the organizational structure of Web PKI, where each label represents: ① CA Certificate Issuance, which is used to establish the starting point of the trust chain and provide a trust basis for subsequent intermediate CA or end-entity (EE) certificates. ② Request Certificate, which is used to trigger the certificate issuance process and ensure the legitimacy and integrity of the applicant's identity. ③ EE Certificate Issuance, which enables the EE to participate in encrypted communication securely (such as HTTPS, code signing, etc.). ④ Direct Manage Transactions, which is used to support the dynamic management of the certificate lifecycle. ⑤ Archive CRL / Certificate, which is used to ensure the traceability of historical records and support certificate status queries (such as verifying whether a certain certificate has been revoked). ⑥ Validate Certificate, which is used to prevent the use of revoked or expired certificates and ensure communication security. ⑦ Monitor Repository, which is used to detect anomalies in a timely manner (such as certificate leakage, CRL not updated) and trigger alarm or repair processes.

[0047] As can be seen, the core components of Web PKI mainly include the Certificate Authority (CA) and the End Entity (EE). The CA plays a central role in the Web PKI framework and is responsible for issuing, managing, and revoking the certificates of all EEs. As an EE, the Web server establishes a secure Hypertext Transfer Protocol Secure (HTTPS) connection with the user's client (such as a browser) by deploying a Secure Socket Layer (SSL) certificate. The format content of the SSL certificate can be based on the X.509 standard, which includes fields such as the validity period, issuer, and X.509 extensions. The SSL certificate is issued and signed by a trusted CA.

[0048] In Web PKI, certificates have a "chain-like" trust relationship. The certificates required by the EE are issued by the CA, and the certificates of a certain level of CA are issued by a higher-level CA, forming a "certificate trust chain" with the certificate of the trusted root CA as the "trust anchor". When a user accesses a website using a browser, the website returns this certificate trust chain, and the browser verifies the entire certificate trust chain to ensure the authenticity of the website's identity. Through this design, Web PKI enables users to verify the identity of the Web server hosting the website and ensure the privacy and integrity of data transmission.

[0049] In a large-scale cluster Web server environment, manually deploying and updating the SSL certificates on each Web server not only takes a lot of time but also is prone to configuration errors. Once a configuration error occurs, such as the certificate expiration not being updated or the key leakage not being revoked, it may have a huge impact on the service accessibility of the website hosted by the Web server, resulting in economic losses. To alleviate the challenges and inefficiencies caused by manually managing SSL certificates in a large-scale cluster environment, the CA can automate the management of the SSL certificate lifecycle based on the Automated Certificate Management Environment (ACME) protocol, including certificate requests, issuance, updates, and revocation.

[0050] During the interaction between the EE and the CA server, the CA server provides the EE with a Directory object, which contains the unique Uniform Resource Locator (URL) corresponding to the request when the EE sends a request to the CA server.

[0051] As shown in Table 1, Table 1 lists all available services in the directory object of the CA server and the corresponding URLs for each service.

[0052] Table 1

[0053]

[0054]

[0055] In addition to the directory object, the CA server can also provide the URLs of a series of resources for the ACME client to retrieve the corresponding objects. For example, the ACME client can access the corresponding authorization record (Authz) through the URL suffix / acme / authz / <authz_id>, where <authz_id> is the unique identifier of the object.

[0056] Next, in combination with Figure 2 An exemplary introduction to a process in which a Web server uses an ACME client to request an SSL certificate from a CA server in the related art is as follows:

[0057] This process generally includes: ① Account Registration, ② Order Request, ③ Challenge Retrieval, ④ Challenge Response, ⑤ Certificate Signing Request Application. The following gives an example of the specific process:

[0058] First, the ACME client submits a newAccount request to the CA server (see Table 1, this request is used to register a new ACME account) and provides the email address and public key to be bound to the ACME account. The CA server creates an ACME account based on this request and returns a unique account identifier (account ID) to the ACME client. After creating the ACME account, the ACME client can send a newOrder request (see Table 1) to the CA server to apply for a certificate and specify the requested domain name.

[0059] Before issuing a certificate to the ACME client, the CA server needs to verify the ACME client's ownership of the specified domain name. The CA server will issue one or more challenges for the specified domain name (using the HTTP-01 or DNS-01 challenge type). After the ACME client successfully completes these challenges, the CA server will cache the verification result of the ownership of the specified domain name as a domain name authorization record (Authz) and cache it according to a preset expiration period (e.g., 30 days). This caching mechanism allows the CA server to reissue certificates for the same domain name more quickly without having to re-verify the domain name ownership. When the ACME client requests a certificate for a domain name with a valid Authz record, the CA server will skip the verification of the domain name ownership, directly receive the Certificate Signing Request (CSR) from the ACME client and issue a certificate to it.

[0060] Since the Authz records corresponding to the ACME accounts created by the ACME client will be cached by the CA server for 30 days after verification, attackers can reuse these records, enabling them to obtain fraudulent SSL certificates with the victim's domain name without actually owning the domain name.

[0061] The following combines Figure 3 to provide an exemplary introduction to a process in which an attacker uses the Authz records cached by the CA server associated with the ACME account in related technologies for an attack:

[0062] As Figure 3 shown, the attack process is mainly divided into four stages: ① Associated Domain Identification, ② ACME Account Rebuild, ③ Valid Authz Retrieval, and ④ Certificate Retrieval.

[0063] In this example, the victim (such as a web server, etc.) has an ACME account and has applied for corresponding certificates for domain names such as a.com, b.com, and sub.c.org. The Authz records for these domain names are still valid during the attack (e.g., within the 30-day expiration period), and it is assumed that the attacker knows that the victim provides services for the domain name a.com.

[0064] The following provides an exemplary introduction to the specific process of stage ①: Associated Domain Identification:

[0065] In this attack model, the attacker hopes to include more domain names owned by the victim in the final fraudulent SSL certificate. Therefore, the attacker first needs to discover as many domain names of the victim as possible. Since the victim's domain name a.com is known, the other domain names of the victim except a.com are hereinafter referred to as associated domain names. To discover these associated domain names, the attacker can look for all the certificates previously applied for and issued by the victim. To reduce the operating costs and the complexity of applying for certificates, website operators usually place multiple domain names hosted on the same web server in the Subject Alternative Name (SAN) list of the same SSL certificate. If the attacker can discover the certificate with a.com in the SAN, the associated domain names included therein can be discovered.

[0066] The attacker can search for certificates in the publicly available Certificate Transparency (CT) log. The CT log is a publicly queryable log that contains all the certificates issued by all major CAs. In this attack model, the attacker can identify the certificates issued for the domain name a.com in the past 30 days and find the corresponding associated domain names in the SAN of the certificate. Suppose the associated domain names found include *.a.com, www.a.com, b.com, and sub.c.org.

[0067] The following gives an exemplary introduction to the specific process of Phase ②: Stealing ACME account information:

[0068] To obtain the valid Authz record associated with the ACME account cached on the CA server of the victim, the attacker needs to first obtain the ACME account credentials of the victim and use these ACME account credentials to pretend to be the victim and communicate with the CA server. Suppose that usually, the attacker and the victim are not in the same subnet, and the attacker can only obtain the ACME account credentials of the victim through network scanning and by exploiting vulnerabilities in the web server. In actual scenarios, there are various situations. For example, web server configuration errors, using software with vulnerable versions, and improper management of private keys by web operation and maintenance personnel can all enable the attacker to obtain the ACME account credentials. The following are two exemplary ways for the attacker to obtain the ACME account credentials of the victim:

[0069] (1) The attacker exploits the Path Traversal Vulnerability, which, due to a web server configuration error, enables the attacker to access files outside the service root directory of the web server without authorization. This vulnerability allows the attacker to read and obtain the ACME account credentials.

[0070] (2) An attacker exploits a remote code execution vulnerability in a web server, such as Apache Log4j, to execute arbitrary code on the web server. Subsequently, the attacker can perform privilege escalation by using vulnerabilities such as Dirty COW, and ultimately obtain the ACME account credentials.

[0071] The following gives an exemplary introduction to the specific process of Phase ③: Retrieving Valid Authorization Records:

[0072] Based on having the ACME account credentials of the victim and having queried the associated domains corresponding to the ACME account, the attacker will attempt to discover whether there are valid Authz records for the associated domains corresponding to the victim's ACME account. The attacker will submit a new certificate request to the CA server based on the ACME account credentials, and this request includes all the discovered associated domains corresponding to this ACME account. The CA server will return an order object containing the URL of the Authz records for all the domains associated with this ACME account based on this certificate request. Subsequently, the attacker can send a request to the URL / acme / authz / <authz_id> corresponding to the resource provided by the CA server to check the status of the Authz records for each associated domain, so as to distinguish the domains with valid Authz caches from those without valid Authz caches. In the example, the attacker's order request can include a.com, *.a.com, www.a.com, b.com, and sub.c.org. Assume that among all the Authz records returned by the CA server, the three domains a.com, b.com, and sub.c.org have valid Authz records cached on the CA server.

[0073] The following gives an exemplary introduction to the specific process of Phase ④: Obtaining Fraudulent Certificates:

[0074] After the attacker obtains that the three domains a.com, b.com, and sub.c.org have valid Authz records cached on the CA server as returned by the CA server, the attacker can resubmit a certificate request to the CA server, and this request only includes the domains with valid Authz records (i.e., a.com, b.com, and sub.c.org). Since the Authz records of these domains are all in a valid state, the attacker's client can bypass the verification of domain ownership and directly obtain an SSL fraudulent certificate. In the example, the attacker successfully obtains a fraudulent certificate with a.com, b.com, and sub.c.org.

[0075] It is worth noting that the above description of the scenario in which an attacker uses the Authz record associated with the ACME account cached by the CA server to attack is only an exemplary display. In actual applications, other attack scenarios are not excluded and are not specifically limited to this.

[0076] It can be seen that the Web server can use the ACME client to request an SSL certificate from the CA server based on the ACME protocol. However, for a domain name with a valid domain name authorization (Authz) record cached on the CA server, if an attacker steals the credentials of the ACME account associated with it, the attacker can use the ACME account credentials to apply for a certificate for the domain name from the CA server, and use the valid domain name authorization record corresponding to the domain name to skip the verification of the ownership of the domain name and directly obtain a fraudulent certificate for the domain name. The security of certificate issuance is low.

[0077] In response to the above problems, this application provides a security verification method based on the ACME protocol, which can prevent attackers from using valid domain name authorization records to bypass domain name ownership verification and obtain fraudulent certificates, thereby improving the security of certificate issuance. Figure 4 As shown, the method may include the following steps:

[0078] S401. The ACME client to be verified sends a certificate request to the CA server based on the target ACME account.

[0079] The certificate request is used to request a certificate for at least one verified domain name and carries the identification information of the ACME client to be verified; the verified domain name is a domain name associated with the target ACME account and having a valid domain name authorization record.

[0080] S402: If the CA server fails to find a valid client authorization record of the ACME client to be verified based on the identification information to be verified, at least one target domain name is selected from the at least one verified domain name, and ownership of the ACME client to be verified over the at least one target domain name is re-verified.

[0081] S403. If the ownership verification passes, the CA server generates a valid client authorization record for the ACME client to be verified based on the identification information to be verified, and issues the certificate to the ACME client to be verified based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

[0082] In the technical solution provided by the embodiments of the present application, for a verified domain name whose valid domain name authorization record associated with the target ACME account is cached on the CA server, when the ACME client applies for a certificate based on the target ACME account, it is necessary to verify the legitimacy of the ACME client itself. Only when it is proved to be legal can it use the valid domain name authorization record to skip the verification of the ownership of the verified domain name and directly obtain the corresponding certificate. The result of the ACME client legitimacy authentication is associated with the identification information of the ACME client. If the result of the legitimacy authentication (valid client authorization record) cannot be queried based on the identification information of the ACME client, then the legitimacy authentication needs to be performed. Specifically, a target domain name is selected from the verified domain names to re-perform the ownership verification. Only when the verification passes can the ACME client obtain the right to use the valid domain name authorization record of the verified domain name, that is, it can skip the ownership verification of the verified domain name and directly obtain the corresponding certificate, which can prevent attackers from using the valid domain name authorization record to bypass the domain name ownership verification and obtain fraudulent certificates as much as possible, and improve the security of certificate issuance.

[0083] The above-mentioned to-be-verified identification information can have multiple specific implementations. As an example, the to-be-verified identification information includes the public IP address of the to-be-verified ACME client and the ID information generated for the to-be-verified ACME client. It should be noted that the above introduction of the specific implementation of the to-be-verified identification information is only an exemplary display. In actual applications, other specific implementations are not excluded, and no specific limitation is made thereto.

[0084] It can be understood that the public IP address of the to-be-verified ACME client is the IP address of the gateway device (or NAT device) of the to-be-verified ACME client.

[0085] The above ID information can be generated in various ways. As an example, the ID information can be a unique identifier generated by the to-be-verified ACME client itself to identify itself. As another example, the ID information can also be a unique identifier generated by the CA server for the to-be-verified ACME client to identify it. Therefore, no limitation is made on the generation method of the ID information.

[0086] Considering that the number of verified domain names requested by the to-be-verified ACME client may be extremely large, regardless of whether the to-be-verified ACME client is an attacker's client (that is, whether it is a legal client), if the ownership verification is re-performed for all the verified domain names it requests, it will undoubtedly cause a huge additional overhead to the CA server.

[0087] To address this issue and ensure that the additional verification steps are as lightweight as possible, minimizing the additional overhead on the CA server, as an example, in S402 during re-verification, at least one target domain name needs to be selected from at least one verified domain name for re-verification, and the number of selected target domain names is less than the number of verified domain names requested by the ACME client to be verified, thereby reducing the additional overhead of the CA server's re-verification steps.

[0088] There are multiple ways to select at least one target domain name from at least one verified domain name. As another example, on the premise that the number of selected target domain names is less than the number of verified domain names requested by the ACME client to be verified, at least one target domain name can be randomly selected from the above-mentioned at least one verified domain name. Random selection can ensure that the probability of each domain name being selected is as fair as possible, thus ensuring that risky domain names (over which the ACME client to be verified has no actual control) are not missed as much as possible.

[0089] There are multiple ways to determine the number of domain names to be selected (i.e., the number of selected target domain names) from the above-mentioned at least one verified domain name. As an example, a target number of target domain names can be selected from the above-mentioned at least one verified domain name; among them, the target number can be determined based on the logarithm related to the number of verified domain names requested by the ACME client to be verified. As another example, the target number of target domain names can be randomly selected from the above-mentioned at least one verified domain name. Randomly selecting the target number of target domain names determined according to the number of verified domain names can significantly reduce the order of magnitude of the domain names that ultimately need to be re-verified regardless of the number of verified domain names, further reducing the additional overhead of the CA server.

[0090] The above-mentioned target number is determined based on the logarithm related to the number of verified domain names requested by the ACME client to be verified. As an example, the determination method of the target number can refer to the following formula:

[0091]

[0092] Among them, N is the number of verified domain names requested by the ACME client to be verified, and n is the number of target domain names.

[0093] It should be noted that the above introduction to the selection method of the target domain name is only an exemplary display. In actual applications, there may be other selection methods, which are not specifically limited here.

[0094] There are multiple ways to re-verify the ownership of at least one target domain name selected from at least one verified domain name by the ACME client to be verified. As an example, the CA server can regenerate the challenge object corresponding to at least one target domain name and instruct the ACME client to be verified to challenge the challenge object, and then verify the ownership of the at least one target domain name by the ACME client to be verified based on the challenge result. The ACME client to be verified needs to complete the challenge of at least one target domain name to determine the ownership. Only the ACME client that actually owns the domain name can complete the challenge, while the attacker's client cannot complete the challenge.

[0095] When the CA server re-verifies the ownership of at least one target domain name by the ACME client to be verified in S402, as an example, it can send an indication of re-verifying the ownership of at least one target domain name to the ACME client. If the ACME client to be verified passes the re-verification of the ownership of at least one target domain name based on this indication, it can receive the corresponding certificate issued by the CA server based on the valid domain name authorization record of at least one verified domain name. As another example, if the ACME client to be verified fails to pass the verification of the ownership of at least one target domain name, the CA server needs to re-verify the ownership of at least one of the above-mentioned verified domain names by the ACME client to be verified and respond to the certificate request of the ACME client to be verified based on the verification result. That is, if the ACME client cannot prove its own legitimacy, it cannot use the valid authorization record of the requested domain name to skip the verification and needs to follow the original certificate application process based on the ACME protocol, that is, it needs to re-verify the ownership of all requested domain names, and the CA server decides whether to issue the certificate according to the verification result.

[0096] Considering that in S402 it is the case where there is no valid client authorization (client authz) record of the ACME client to be verified in the CA server ((has not been legally verified)), no valid client authorization (client authz) record can be queried based on the identification information to be verified of the ACME client to be verified. At this time, the legitimacy of the ACME client to be verified needs to be verified. However, if the ACME client to be verified has been legally verified in the CA server, there may be a valid client authorization record of the ACME client to be verified on the CA server.

[0097] For this problem, as an example, if the CA server queries a valid client authorization record of the to-be-verified ACME client based on the to-be-verified identification information, then based on the queried valid client authorization record and the valid domain name authorization record of at least one verified domain name requested by the certificate request sent by the to-be-verified ACME client, the CA server directly issues a certificate for the at least one verified domain name to the to-be-verified ACME client. If a valid client authorization record is queried, it indicates that the public IP address and ID information of the to-be-verified ACME client match the IP address and ID information reported to the CA server historically, and the legitimacy of the ACME client itself under this IP-ID pair has also been verified. At this time, the ACME client obtains the right to use the valid domain name authorization record of the requested verified domain name. The CA server can skip the verification of the ownership of the verified domain name at this time and directly issue a certificate to the ACME client based on the valid domain name authorization record.

[0098] Considering that the original introduction of the ACME caching mechanism (i.e., caching the valid domain name authorization (Authz) records of verified domain names) is to avoid repeated verification of the ownership of a certain domain name, thereby reducing the burden on the CA server. For this problem, as an example, if the verification of the ownership in S403 passes, the CA server generates a valid client authorization record for the to-be-verified ACME client based on the to-be-verified identification information. The generated valid client authorization record also needs to be cached in the CA server according to a preset expiration period. Since the embodiments of the present application introduce a new re-verification step in ACME, for the result of successful re-verification, that is, the generated valid client authorization (Client Authz) record also needs to follow the caching principle to ensure that the re-verification steps and results are as lightweight as possible and minimize the additional overhead of the CA server.

[0099] The above preset expiration period can have multiple specific implementations. As an example, the preset expiration period of the client authorization (ClientAuthz) record can be the same as the caching period of the domain name authorization (Authz) record on the CA server, both being 30 days. That is, the client authorization (Client Authz) record is valid within 30 days after caching and invalid after 30 days.

[0100] The following combines Figure 5 , and gives an exemplary introduction to a specific application scenario of the security verification based on the ACME protocol in the embodiments of the present application:

[0101] As Figure 5 shown, a specific application scenario of the security verification based on the ACME protocol may include:

[0102] ① Order Request, ② Challenge Retrieval, ③ Challenge Retrieval, ④ Challenge Response, ⑤ Rest ACME Certificate Request Process.

[0103] Specifically, first, an exemplary description is given of the data structure and service design in this specific application scenario:

[0104] Please refer to Table 2. Table 2 shows an exemplary data structure of the Client Authz object in the embodiments of the present application:

[0105] Table 2

[0106]

[0107] As shown in Table 2, the embodiments of the present application introduce a new Client Authz object for the legitimacy verification of ACME clients. As a unique verification token, it contains the unique identification information identifier, which associates the IP address of the ACME client and the ACME client-specific ID information with the ACME account. The IP address uses, to a certain extent, the public IP of the machine of the ACME client, and the ID information of the ACME client can be a random string generated by the ACME client. Using the identification information identifier as the unique identifier not only helps to distinguish legitimate ACME clients from potential attackers but also enhances the ability to resist brute-force attacks.

[0108] Similar to the original Authz record in the ACME protocol, after all challenges are completed, the Client Authz record introduced in the embodiments of the present application can also be cached by the CA server for 30 days. The Challenge field in the Client Authz record can contain multiple challenge objects in the original Authz record of ACME, and the ACME client must complete these challenges. At the same time, the embodiments of the present application introduce a new directory service newClientAuthz, which is used to generate a brand-new Client Authz object. In addition, the ACME client in the embodiments of the present application can access / acme / client-authz / <authz_id> through a POST-as-GET request to obtain the corresponding Client Authz object, where <authz_id> is the ID used to request the Client Authz object.

[0109] Next, an exemplary description will be given of the SSL certificate application process in a specific application scenario of the present application embodiment:

[0110] As Figure 5 shown, when the ACME client initiates a newOrder request, it includes its IP address, eight-digit random ID information, the key and UID of the ACME account in the request and sends them to the CA server. After receiving the request, the CA server can perform two additional validations on the ACME client: (1) check whether the IP address carried in the request of the ACME client matches the historically reported IP address, and (2) find whether there is a valid Client Authz record for this ACME client. If both of these conditions are met, the CA server will continue with the certificate issuance according to the standard ACME protocol (i.e., enter Figure 5 step ④). If the IP addresses do not match, the CA server will terminate this connection because the IP address mismatch may indicate that the ACME account credentials have been obtained by an attacker and this certificate application is initiated by the attacker in their network. If the CA does not retrieve a valid Client Authz record for this ACME client, the CA server will generate a new Client Authz object for this client, set its status field to "pending", and return the ID of this Client Authz object to this ACME client.

[0111] The generation method of the challenge field of the Client Authz object can be as follows: The CA server first retrieves all the verified domains corresponding to the valid Authz records associated with the ACME account based on which the newOrder request initiated by the ACME client is made, and randomly selects n domains as the target domains from all the verified domains corresponding to these records. Subsequently, the CA will regenerate the challenge objects for these n target domains as the content of the challenge in the Client Authz object, and the ACME client must complete these challenges to reconfirm the domain name ownership. After receiving the Client Authz object, the ACME client needs to use the HTTP-01 or DNS-01 challenge type to complete the required challenges. After the ACME client successfully completes all the challenges, the ACME client will pass the legitimacy verification, and the CA server will update the status field of the Client Authz object to "valid". At this time, the CA server can continue with the certificate issuance process (i.e., enter Figure 5In step ④). In addition, the verified Client Authz records will be cached by the CA for 30 days. During this period, the same ACME client (with the same IP-ID pair) can request more certificates for the same domain name without re-verifying the client's legitimacy.

[0112] As an example, the protocol implementation between the CA server and the ACME client mentioned in any embodiment of the present application can be based on the Python language. As another example, the CA server and the ACME client mentioned in any embodiment of the present application can be respectively deployed in two cloud servers located in different subnets. As another example, the ACME of the CA server can be configured to use the HTTP-01 type to implement the verification of the ownership of the domain name.

[0113] The security verification method based on the ACME protocol in the embodiments of the present application can be seamlessly integrated with the existing ACME framework, reusing some objects and processes of the existing ACME to minimize protocol modifications. The security verification method based on the ACME protocol in the embodiments of the present application is easy to deploy, which can be achieved only by seamlessly upgrading the existing ACME, with as few improvements as possible to the ACME client and the CA server, without introducing new components into the Web PKI. The security verification method based on the ACME protocol in the embodiments of the present application also has strong security, which can defend against attackers reusing the ACME cache for attacks as much as possible.

[0114] It should be noted that the above introduction to a specific application process of the security verification based on the ACME protocol in the embodiments of the present application is only an exemplary display. In actual applications, there may be other specific application processes, which are not specifically limited herein.

[0115] Corresponding to the above method embodiments, the embodiments of the present application also provide a security verification system based on the ACME protocol. Refer to Figure 6 As shown, the system may include: an ACME client 601 to be verified and a CA server 602;

[0116] The ACME client 601 to be verified is used to send a certificate request to the CA server 602 based on a target ACME account. The certificate request is used to request a certificate for at least one verified domain name and carries the identification information to be verified of the ACME client 601 to be verified; the verified domain name is a domain name with a valid domain name authorization record associated with the target ACME account;

[0117] The CA server 602 is configured to, if no valid client authorization record of the to-be-verified ACME client 601 is found based on the to-be-verified identification information, select at least one target domain name from the at least one verified domain name, and re-verify the ownership of the at least one target domain name by the to-be-verified ACME client 601; if the verification of the ownership passes, generate a valid client authorization record for the to-be-verified ACME client 601 based on the to-be-verified identification information, and issue the certificate for the to-be-verified ACME client 601 based on the generated valid client authorization record and the valid domain name authorization records of the at least one verified domain name.

[0118] As an example, the CA server 602 is further configured to, if a valid client authorization record of the to-be-verified ACME client is found based on the to-be-verified identification information, issue the certificate for the to-be-verified ACME client based on the found valid client authorization record and the valid domain name authorization records of the at least one verified domain name.

[0119] As an example, the CA server 602 is further configured to, if the verification of the ownership fails, re-verify the ownership of the at least one verified domain name by the to-be-verified ACME client, and respond to the certificate request based on the verification result.

[0120] As an example, the number of the target domain names is less than the number of the verified domain names, and the CA server 602 is specifically configured to randomly select at least one target domain name from the at least one verified domain name.

[0121] As an example, the CA server 602 is specifically configured to randomly select a target number of target domain names from the at least one verified domain name; wherein, the target number is determined based on the logarithm related to the number of the verified domain names.

[0122] As an example, the CA server 602 is specifically configured to regenerate the challenge objects corresponding to the at least one target domain name, and instruct the to-be-verified ACME client to challenge the challenge objects; verify the ownership of the at least one target domain name by the to-be-verified ACME client based on the challenge result.

[0123] As an example, the generated valid client authorization records are cached in the CA server according to a preset validity period.

[0124] As an example, the to-be-verified identification information includes the public IP address of the to-be-verified ACME client and the ID information generated for the to-be-verified ACME client.

[0125] The present application also provides a computer program product, including a computer program which, when executed by a processor, implements the security verification method based on the ACME protocol described in any of the above embodiments.

[0126] The present application also provides a CA server, as Figure 7 shown. The CA server includes:

[0127] a processor 701;

[0128] a memory 702 for storing processor-executable instructions;

[0129] wherein, the processor 701 is configured to implement the security verification method based on the ACME protocol described in any of the above embodiments.

[0130] The present application also provides an ACME client device, as Figure 8 shown. The ACME client device includes:

[0131] a processor 801;

[0132] a memory 802 for storing processor-executable instructions;

[0133] wherein, the processor 801 is configured to implement the security verification method based on the ACME protocol described in any of the above embodiments.

[0134] The present application also provides a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements the security verification method based on the ACME protocol described in any of the above embodiments.

[0135] The above are only specific embodiments of the present application. It should be noted that for those of ordinary skill in the art, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A security verification method based on the ACME protocol, characterized in that: The method comprises: The ACME client to be verified sends a certificate request to the CA server based on the target ACME account, wherein the certificate request is used to request a certificate for at least one verified domain name and carries the identification information to be verified of the ACME client to be verified; the verified domain name is a domain name associated with the target ACME account and having a valid domain name authorization record; If the CA server fails to find a valid client authorization record of the ACME client to be verified based on the identification information to be verified, then selecting at least one target domain name from the at least one verified domain name, and re-verifying the ownership of the ACME client to be verified over the at least one target domain name; If the ownership verification passes, the CA server generates a valid client authorization record for the ACME client to be verified based on the identification information to be verified, and issues the certificate to the ACME client to be verified based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

2. The method according to claim 1, characterized in that The method further comprises: If the CA server queries a valid client authorization record of the ACME client to be verified based on the identification information to be verified, the CA server issues the certificate to the ACME client to be verified based on the queried valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

3. The method according to claim 1, characterized in that The method further comprises: If the ownership verification fails, the CA server re-verifies the ownership of the to-be-verified ACME client to the at least one verified domain name, and responds to the certificate request based on the verification result.

4. The method according to claim 1, characterized in that The number of the target domain names is less than the number of the verified domain names, and selecting at least one target domain name from the at least one verified domain name includes: At least one target domain name is randomly selected from the at least one verified domain name.

5. The method according to claim 4, characterized in that The randomly selecting at least one target domain name from the at least one verified domain name comprises: A target number of target domain names are randomly selected from the at least one verified domain name; wherein the target number is determined based on a logarithm related to the number of the verified domain names.

6. The method according to claim 1, characterized in that The re-verifying the ownership of the at least one target domain name by the ACME client to be verified includes: Regenerate a challenge object corresponding to the at least one target domain name, and instruct the ACME client to be verified to challenge the challenge object; The ownership of the at least one target domain name by the ACME client to be verified is verified based on the challenge result.

7. The method according to claim 1, characterized in that The generated valid client authorization record is cached on the CA server according to the preset validity period.

8. The method according to claim 1, characterized in that: The identification information to be verified includes the public IP address of the ACME client to be verified and ID information generated for the ACME client to be verified.

9. A security verification method based on the ACME protocol, applied to a CA server, characterized in that: The method comprises: Receive a certificate request sent by the ACME client to be verified based on the target ACME account, where the certificate request is used to request a certificate for at least one verified domain name and carries the identification information to be verified of the ACME client to be verified; the verified domain name is a domain name associated with the target ACME account and having a valid domain name authorization record; If no valid client authorization record of the ACME client to be verified is found based on the identification information to be verified, selecting at least one target domain name from the at least one verified domain name, and re-verifying the ownership of the ACME client to be verified over the at least one target domain name; If the ownership verification passes, a valid client authorization record is generated for the ACME client to be verified based on the identification information to be verified, and the certificate is issued to the ACME client to be verified based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

10. A security verification method based on the ACME protocol, applied to the ACME client, characterized in that: The method comprises: Sending a certificate request to the CA server based on the target ACME account, wherein the certificate request is used to request a certificate for at least one verified domain name and carries the identification information of the ACME client to be verified; the verified domain name is a domain name associated with the target ACME account and having a valid domain name authorization record; receiving an instruction from the CA server to re-verify ownership of at least one target domain name, where the at least one target domain name is selected from the at least one verified domain name when the CA server fails to find a valid client authorization record of the ACME client based on the identification information to be verified; Receiving the certificate issued by the CA server, where the CA server generates a valid client authorization record for the ACME client based on the identification information to be verified when the ownership verification is passed, and issues the certificate to the ACME client based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

11. A security verification system based on ACME protocol, characterized in that: The system includes an ACME client to be verified and a CA server; The ACME client to be verified is used to send a certificate request to the CA server based on the target ACME account, where the certificate request is used to request a certificate for at least one verified domain name and carries the identification information to be verified of the ACME client to be verified; The verified domain name is a domain name associated with the target ACME account for which there is a valid domain name authorization record; The CA server is configured to select at least one target domain name from the at least one verified domain name and re-verify the ownership of the ACME client to be verified over the at least one target domain name if no valid client authorization record of the ACME client to be verified is found based on the identification information to be verified; If the ownership verification passes, a valid client authorization record is generated for the ACME client to be verified based on the identification information to be verified, and the certificate is issued to the ACME client to be verified based on the generated valid client authorization record and the valid domain name authorization record of the at least one verified domain name.

12. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

13. A CA server, characterized in that: include: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to implement the method of claim 9.

14. An ACME client device, characterized in that: include: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to implement the method of claim 10.

15. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

Images