Communication method and apparatus

Abstract

A communication method and apparatus, said method comprising: after receiving a first request from a first device, in response to the first request, determining a target CA on the basis of configuration information of the receiver, the first request being a CMPv2 protocol message; and then, determining whether the target CA supports an ACME protocol or a CMPv2 protocol, and, if it is determined that the target CA supports an ACME protocol, applying for a certificate for the first device on the basis of the ACME protocol; or, if it is determined that the target CA supports a CMPv2 protocol, applying for a certificate for the first device on the basis of the CMPv2 protocol. In this way, the first device is enabled to indirectly apply for a certificate from the target CA, not requiring the first device to directly communicate with the target CA, and thus not requiring software and hardware updating and upgrading to be performed on the first device that uses the CMPv2 protocol, said first device being enabled to apply for a certificate on the basis of the ACME protocol.

Description

A communication method and apparatus

[0001] Cross-reference of related applications

[0002] This application claims priority to Chinese Patent Application No. 202410178192.9, filed on February 8, 2024, entitled "A Communication Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field

[0003] This application relates to the field of wireless communication technology, and in particular to a communication method and apparatus. Background Technology

[0004] In fifth-generation (5G) mobile communication networks, the functions of network elements can be subdivided into different network functions (NFs) and deployed on the network platform in a virtualized form, enabling rapid deployment of network functions. Interaction between different NF network elements is based on the certificates of the NF network elements. These certificates are typically issued by a third-party certificate authority (CA).

[0005] One proposed solution allows NF network elements to apply for certificates via the Automatic Certificate Management Environment (ACME) protocol or the CMPv2 protocol. However, NF network elements using the CMPv2 protocol may be unable to communicate with CAs that provide ACME protocol interfaces, meaning they cannot apply for certificates from CAs that only provide ACME protocol interfaces. This prevents NF network elements using the CMPv2 protocol from applying for certificates using the ACME protocol. If an NF network element using the CMPv2 protocol wants to apply for a certificate according to the ACME protocol, it needs to be upgraded, but this upgrade is not easy, making it difficult for the NF network element to automatically apply for certificates using the ACME protocol. Summary of the Invention

[0006] This application provides a communication method and apparatus for enabling a device that needs to apply for a certificate using the CMPv2 protocol to communicate with a CA that provides an ACME protocol interface, and then apply for a certificate according to the ACME protocol.

[0007] Firstly, a communication method is provided, which can be implemented by a first communication device. The first communication device can be a proxy device or a chip, unit, or module within the proxy device. The proxy device can be a terminal device, access network device, server, etc. The following description uses the proxy device as the executing entity. The method can include the following steps: the proxy device receives a first request from the first device, then responds to the first request, and determines a target CA based on its own configuration information; then, if the proxy device determines that the target CA supports the ACME protocol, it applies for a certificate for the first device according to the ACME protocol; or, if the proxy device determines that the target CA supports the CMPv2 protocol, it applies for a certificate for the first device according to the CMPv2 protocol. Wherein, the first request is a CMPv2 protocol message;

[0008] In this method, the first device can be understood as a device that needs to apply for a certificate (which can be understood as an application device). This first device can be a terminal device, an access network device, an NF network element, or a component within an NF network element. The components in this application may include, for example, at least one of a chip, a chip system, a processor, a transceiver, a processing unit, a transceiver unit, or a module. The NF network element can be a network element deployed in a core network with a service-oriented architecture.

[0009] Optionally, a first CMPv2 client is deployed on the first device. Therefore, the first device can be understood as a device using the CMPv2 protocol, which can send a first request to the proxy device through the first CMPv2 client.

[0010] Optionally, a first CMPv2 server is deployed on the proxy device. Therefore, the proxy device can receive the first request through the first CMPv2 server. After responding to the first request, the proxy device can select a target CA for the first device based on its own configuration information. This target CA is used to issue a certificate to the first device.

[0011] Optionally, the proxy device is equipped with an ACME client and a second CMPv2 client. Therefore, the proxy device can be understood as a device using both the ACME and CMPv2 protocols. The target CA is equipped with an ACME server, thus the target CA can be understood as a device providing the ACME protocol interface (such as a CA server). Based on this, the proxy device can communicate with the target CA according to the ACME protocol, thereby obtaining a certificate from the target CA for the first device, without requiring direct communication between the first device and the CA. In other words, the first device using the CMPv2 protocol can indirectly communicate with the CA providing the ACME protocol interface through the proxy device, enabling the first device using the CMPv2 protocol to apply for a certificate according to the ACME protocol. Therefore, no software or hardware updates or upgrades are required for the first device using the CMPv2 protocol to apply for a certificate according to the ACME protocol.

[0012] Optionally, a second CMPv2 server is deployed on the target CA. This means the target CA may not provide an ACME protocol interface, preventing the proxy device from requesting a certificate from the target CA using the ACME protocol. However, the proxy device can request a certificate from the target CA using the CMPv2 protocol, thus increasing the flexibility of requesting certificates for the first device.

[0013] Optionally, the target CA may have an ACME server and a second CMPv2 server deployed on it. This means the target CA may support two certificate management protocols (CMPv2 and ACME), thereby improving the comprehensiveness of certificate applications.

[0014] In one possible implementation, the proxy device applies for a certificate for the first device according to the ACME protocol, including: the proxy device applying to the target CA for a certificate order to create an ACME protocol certificate based on the first request. Then, after obtaining authorization to issue the certificate order, the proxy device generates a completion order request based on the first request and sends the completion order request to the target CA, so that the target CA can challenge and verify the proxy device and issue a certificate to the proxy device. The proxy device obtains the certificate of the first device from the target CA and sends a first response to the first device, the first response including the certificate of the first device.

[0015] In the above implementation, the proxy device essentially communicates with the target CA on behalf of the first device, requests a certificate from the target CA, and obtains the certificate after completing the application process. This certificate is equivalent to one issued by the target CA to the proxy device. The proxy device then sends this certificate to the first device. This can be understood as the proxy device requesting the certificate from the target CA on behalf of the first device, or as the first device indirectly requesting the certificate from the target CA, eliminating the need for the first device to directly obtain the certificate from the CA. Therefore, no software or hardware updates or upgrades are required for the first device using the CMPv2 protocol to apply for certificates according to the ACME protocol.

[0016] In one possible implementation, the proxy device requests a certificate for the first device according to the CMPv2 protocol. The method includes: the proxy device sending a CMPv2 certificate request to the target CA according to the first request; then, the proxy device receiving a second response from the CA, wherein the second response includes the certificate of the first device; and finally, the proxy device sending the certificate to the first device.

[0017] In the above implementation, the proxy device also supports requesting a certificate from the target CA according to the CMPv2 protocol. Optionally, the proxy device can request a certificate by directly forwarding the first request to the target CA.

[0018] In one possible implementation, the configuration information of the agent device includes a list of CAs and a decision strategy; wherein, the list of CAs includes one or more of the following information: at least one CA, the certificate management protocol supported by any CA, and the usage priority of the certificate management protocol supported by any CA; the certificate management protocol supported by any CA includes the CMPv2 protocol and / or the ACME protocol, wherein the ACME protocol has a higher priority than the CMPv2 protocol; the decision strategy is used to determine the target CA from the at least one CA.

[0019] In the above implementation, the target CA may support both the CMPv2 protocol and the ACME protocol. In this scenario, the protocol to be used can be selected by prioritizing the protocol. For example, the ACME protocol can be used first to apply for a certificate for the first device, thereby improving the flexibility of applying for a certificate using the certificate management protocol.

[0020] Secondly, a communication method is provided, which may include the following steps: a proxy device receives a first challenge request from a first device, obtains challenge information from a first server according to the first challenge request, and then stores the challenge information in a second server. The challenge information is generated by the first device and stored in the first server; the first server and the first device are located in a first network; the second server is located in a second network; and the challenge information is used to verify the challenge information after the target CA receives a second challenge request from the first device, i.e., the second challenge request instructs the target CA to verify the challenge information.

[0021] Optionally, the first network is a Local Area Network (LAN), which can be understood as an intranet; the second network is a Wide Area Network (WAN), which can be understood as an external network.

[0022] Optionally, the address of the first server can be determined by the DNS records of the internal network; for example, the address of the first server is determined by A records, AAAA records, CNAME records, etc. in the DNS records of the internal network. Optionally, the address of the first server can be the address of the first device.

[0023] Optionally, the address of the second server can be determined by external DNS records; for example, the address of the second server can be determined by NS records, A records, AAAA records, CNAME records, etc. in the external DNS records. Optionally, the address of the second server can be the address of the proxy device.

[0024] In some embodiments, the ACME protocol process includes certificate identifier verification, also known as challenge verification. Only after successful challenge verification is it determined that the first device has control over the identifier for which the certificate needs to be applied, thus allowing the first device to apply for the certificate. However, during the challenge verification process of the ACME protocol, the first device needs to modify resources (such as DNS records) on a specific server (such as a web server or DNS domain name server). Therefore, granting each first device the permission to modify server resources poses a security risk to network communication. Furthermore, if the first device and the target CA are on different networks, the first device may be unable to communicate directly with the target CA, thus preventing the first device from completing the challenge verification and therefore from applying for a certificate through the ACME protocol.

[0025] In this scheme, the first device deploys an ACME client, and the target CA deploys an ACME server. Therefore, the first device can directly request a certificate order for the ACME protocol from the target CA. The target CA then generates a token and sends the token, along with the supported challenge types, to the first device. The first device then selects a target challenge from the supported challenge types, generates challenge information based on the token and the target challenge, records the challenge information on the first server, and sends a first challenge request to the proxy device. Upon receiving the first challenge request, the proxy device records the challenge information on a second server. The first device then sends a second challenge request to the target CA, enabling the target CA to retrieve the challenge information from the second server and verify the challenge information from the first device, thus completing the challenge verification. In other words, the proxy device communicates with the first device on the intranet, and with the target CA on the internet. Therefore, even if the first device on the internal network cannot access the target CA on the external network, or the target CA on the external network cannot access the internal network, the challenge verification between the first device and the target CA can be completed through the proxy device, thereby enabling the first device, which is on a different network from the target CA, to apply for a certificate according to the ACME protocol.

[0026] Furthermore, because the first device only needs to upload the challenge information to a first server located on the intranet, it does not need to access a second server located on the wide area network, nor does it need to be accessed from the external network, thus ensuring the network security of the first device. Therefore, it is not necessary to grant the first device permission to access the external network, or permission to modify resources on specific servers, thereby preventing network communication security issues caused by network attacks on the first device.

[0027] In one possible implementation, the first server is an HTTP server and the second server is a DNS server.

[0028] Optionally, the first server may also be a Transport Layer Security (TLS) server; the second server may also be an HTTP server or a TLS server.

[0029] In this scheme, the first server is not a DNS server, so the first device does not need to be granted permission to access the DNS server, that is, the first device does not need to be granted permission to modify DNS records.

[0030] Thirdly, a communication method is provided, which can be implemented by a second communication device. The second communication device can be a server corresponding to the CA (such as an ACME server, CA server, CMPv2 server, etc.), a chip, unit, or module within the server. The following description, with the execution subject as the target CA, includes the following steps:

[0031] The target CA verifies the challenge information of the first device based on a third challenge request from the proxy device. This challenge information includes the public key fingerprint of the first public key. The third challenge request is associated with a first authorized object in the certificate order, and the public key fingerprint of the first public key is associated with the first authorized object. The certificate order is generated by the target CA based on a first certificate order request from the proxy device. Then, the target CA receives a completion order request from the proxy device, which includes a second public key. Based on this, when the target CA determines that the public key fingerprint corresponding to at least one authorized object in the certificate order is the public key fingerprint of the first public key, if the public key fingerprint of the first public key is identical to the public key fingerprint of the second public key, then the target CA issues a certificate to the first device.

[0032] In this scheme, the certificate order includes at least one authorized object. The first authorized object is any one of the at least one authorized objects. The authorized object represents the CA's authorization of a specific identifier (such as a domain name) in the ACME protocol and contains multiple challenge types and corresponding challenge data (including tokens and other data). The order completion request includes a Certificate Signing Request (CSR), which includes a second public key. If the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key, it indicates that both the challenge information and the order completion request were generated by the first device, and the proxy device has not tampered with the information in the order completion request (such as the CSR information). Therefore, the target CA can verify the public key in the CSR based on the public key fingerprint in the challenge information. When it is determined that the public key fingerprint in the challenge information matches the public key fingerprint in the CSR, the CSR verification is successful, indicating that the proxy device has not forged the CSR, thereby preventing the proxy device from forging the CSR and ensuring the accuracy and security of the CSR.

[0033] In one possible implementation, the method further includes: the target CA receiving a first certificate order request from the proxy device, and sending a first certificate order response to the proxy device according to the first certificate order request, wherein the first certificate order response is used to indicate obtaining a token. The first certificate order request is used to apply for the creation of a certificate order for the ACME protocol, and the token is used to determine first information with the public key fingerprint of the proxy device, the first information being used to determine challenge information with the public key fingerprint of the first public key.

[0034] Optionally, the public key fingerprint of the proxy device can be understood as the public key fingerprint of the ACME account, that is, the public key fingerprint of the public key corresponding to the ACME account, which is registered by the ACME account proxy device. For example, the proxy device (with an ACME client deployed) generates a key pair (including a public key and a private key), and then registers an ACME account with the target CA (which can be understood as an ACME server, with an ACME server deployed) based on this key pair. Optionally, the proxy device can register a corresponding ACME account for each first device, or register a corresponding ACME account for each certificate order of the first device.

[0035] Optionally, the first public key refers to the public key of the first device. The first public key is obtained by the first device after generating a key pair (including a public key and a private key), which is used to generate the CSR. Therefore, the public key fingerprint of the first public key can be understood as the public key fingerprint of the CSR or the certificate public key fingerprint, that is, the public key fingerprint of the public key corresponding to the CSR.

[0036] Optionally, the challenge information can be generated using hash operations, XOR operations, concatenation, or other methods.

[0037] In this scheme, the proxy device deploys an ACME client, and the target CA deploys an ACME server. Therefore, the first device can apply for and create an ACME protocol certificate order through the proxy device. For example, the first device sends a second certificate order request to the proxy device, which then generates a first certificate order request based on the second request and sends it to the target CA, thus requesting the creation of a certificate order. The target CA then creates the certificate order and sends a first certificate order response (which can be understood as a certificate order feedback) back to the proxy device. This first certificate order response includes the address corresponding to at least one authorized object, and each authorized object's address records a token corresponding to that object. After receiving the first certificate order response, the proxy device obtains the corresponding token based on the address of at least one authorized object. The proxy device can then generate first information based on this token and its own public key fingerprint (ACME account public key fingerprint) and send this first information to the first device. The first device then generates challenge information based on the public key fingerprint of the first public key and the first information, and stores this challenge information in an external DNS server so that the target CA can obtain the challenge information from the DNS server and complete the challenge verification.

[0038] Similarly, after completing the challenge verification, the first device can send an order completion request to the target CA through a proxy device. For example, the first device sends an order completion request to the proxy device, which then forwards the request to the target CA. The order completion request includes a CSR, which contains a second public key. Therefore, the target CA can verify the CSR based on the public key fingerprint in the challenge information and the public key fingerprint of the second public key in the CSR. If the two public key fingerprints match, the CSR verification is successful, indicating that the proxy device has not forged the CSR, thus preventing the proxy device from forging the CSR and ensuring its accuracy and security.

[0039] Fourthly, a communication apparatus is provided, comprising a unit or module for performing the method as described in any one of the first, second, or third aspects above.

[0040] Fifthly, a communication device is provided, comprising: one or more processors configured to perform the method described in any one of the first, second, or third aspects above.

[0041] In one possible implementation, the communication device further includes one or more memories; wherein the one or more memories store one or more programs that, when executed by the one or more processors, cause the device to perform the method described in any one of the first, second, or third aspects above.

[0042] A sixth aspect provides a chip system comprising at least one chip and a memory, the at least one chip being configured to read and execute a program stored in the memory to implement the method described in any one of the first, second, or third aspects above.

[0043] A seventh aspect provides a readable storage medium comprising a program that, when executed on a device, causes the device to perform any of the methods described in the first, second, or third aspect above.

[0044] Eighthly, a program product is provided that, when operated on a device, causes the device to perform the method described in any one of the first, second, or third aspects above.

[0045] Based on the implementations provided in the above aspects, the embodiments of this application can be further combined to provide more implementations.

[0046] The technical effects that can be achieved in any of the fourth to eighth aspects mentioned above can be described with reference to the technical effects that can be achieved in the first, second and / or third aspects mentioned above, and the repetitions will not be discussed. Attached Figure Description

[0047] Figure 1 is a schematic diagram of the architecture of the wireless communication system used in the embodiments of this application;

[0048] Figure 2 is a schematic diagram of a system architecture for an ACME protocol applicable to an embodiment of this application;

[0049] Figure 3 is a schematic diagram of the application process for a certificate of the ACME protocol provided in an embodiment of this application;

[0050] Figure 4 is a flowchart illustrating a communication method provided in an embodiment of this application;

[0051] Figure 5 is a schematic diagram of a process for applying for a certificate for a first device according to the ACME protocol, applicable to an embodiment of this application;

[0052] Figure 6 is a schematic diagram of another process for applying for a certificate for the first device according to the ACME protocol provided in an embodiment of this application;

[0053] Figure 7 is a schematic diagram of a process for applying for a certificate for a first device according to the CMPv2 protocol, provided by an embodiment of this application;

[0054] Figure 8 is a schematic diagram of a system architecture for applying for a certificate for a first device according to the CMPv2 protocol, which is applicable to an embodiment of this application.

[0055] Figure 9 is a flowchart illustrating another communication method provided in an embodiment of this application;

[0056] Figure 10 is a schematic diagram of a certificate application process using the HTTP-01 challenge type applicable to an embodiment of this application;

[0057] Figure 11 is a schematic diagram of a DNS-01 challenge type certificate application process provided in an embodiment of this application;

[0058] Figure 12 is a flowchart illustrating another communication method provided in an embodiment of this application;

[0059] Figure 13 is a schematic diagram of another HTTP-01 challenge type certificate application process provided in an embodiment of this application;

[0060] Figure 14 is a structural diagram of a communication device provided in an embodiment of this application;

[0061] Figure 15 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0062] This application provides a communication method and apparatus. The method and apparatus are based on the same inventive concept. Since the principles by which the method and apparatus solve problems are similar, their implementations can be mutually referenced, and repeated details will not be repeated.

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The specific operating methods in the method embodiments can also be applied to the device embodiments or system embodiments.

[0064] The following explanations and descriptions of some technologies and terms involved in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0065] (1) Service-based architecture (SBA)

[0066] The fifth-generation (5G) mobile communication network provides Network Functions Virtualization (NFV) technology, which subdivides the functions of network elements into different Network Functions (NFs) and deploys them on the network platform in a virtualized form, enabling rapid deployment of network functions. To simplify communication and access control between NF network elements, the 5G network adopts a Service-Based Architecture (SBA), through which virtualized network elements interact. Hypertext Transfer Protocol Secure (HTTPS) is used between different NF network elements.

[0067] Referring to Figure 1, this service-oriented architecture can encompass service-oriented architectures in 5G and future mobile communication systems. The network architecture shown in Figure 1 may include terminal devices, access network devices, and core network devices. Terminal devices access the data network (DN) through access network devices and core network devices. The core network devices include various network elements (NFs). For example, the NFs in a service-oriented network architecture may include some or all of the following network elements:

[0068] The network elements include: Network Slice Selection Function (NSSF), Authentication Server Function (AUSF), Unified Data Management (UDM), Network Exposure Function (NEF), Network Data Repository Function (NRF), Access and Mobility Management Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Application Function (AF), and Service Communication Proxy (SCP). Descriptions and functional specifications of these network elements can be found in relevant 5G protocols and will not be elaborated upon here.

[0069] Access network equipment can be radio access network (RAN) equipment. Examples include: base stations, evolved NodeBs (eNodeBs), transmission reception points (TRPs), next-generation NodeBs (gNBs) in 5G mobile communication systems, future mobile communication systems, open RAN (O-RAN or ORAN) mobile communication systems, cloud radio access network (CRAN) mobile communication systems, and access nodes in wireless fidelity (WiFi) systems. It can also be modules or units that perform some of the functions of a base station; for example, it can be a central unit (CU) or a distributed unit (DU). Access network equipment can be macro base stations, micro base stations, indoor stations, relay nodes, or donor nodes. The access network equipment can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. The access network equipment can also be a communication system integrating two or more of the above systems. The embodiments of this application do not limit the specific technology or device form used in the wireless access network equipment.

[0070] Terminal devices can be user equipment (UE), mobile stations, mobile terminals, etc. They can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), the Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, and smart cities. Terminal devices can include mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, urban air mobility vehicles (such as drones and helicopters), ships, robots, robotic arms, and smart home devices.

[0071] Access network equipment and terminal equipment can be fixed or mobile. They can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can be deployed in the air on aircraft, balloons, and satellites. The embodiments of this application do not limit the application scenarios of the access network equipment and terminal equipment.

[0072] It is understood that the above network elements and communication devices are examples of one implementation of 5G networks under a service-oriented architecture. This application does not exclude the possibility that network elements or devices with the above network element functions may have other names or other forms in future communication systems.

[0073] In Figure 1, Nnef, Nausf, Nudm, Nnef, Nnrt, Namf, Nsmf, Npct, Naf, and Nscp are the service interfaces provided by NSSF, AUSF, UDM, NEF, NRF, AMF, SMF, PCF, AF, and SCP, respectively, used to invoke the corresponding service operations. N1, N2, N3, N4, and N6 are interface sequence numbers, and the meanings of these interface sequence numbers are as follows:

[0074] 1) N1: The interface between the AMF network element and the terminal device, which can be used to transmit non-access stratum (NAS) signaling (such as QoS rules from the AMF network element) to the terminal device.

[0075] 2) N2: The interface between the AMF network element and the access network equipment, which can be used to transmit radio bearer control information from the core network side to the access network equipment.

[0076] 3) N3: The interface between the access network equipment and the UPF network element, mainly used to transmit uplink and downlink user plane data between the access network equipment and the UPF network element.

[0077] 4) N4: The interface between SMF network elements and UPF network elements. It can be used to transmit information between the control plane and the user plane, including the distribution of forwarding rules, QoS rules, traffic statistics rules, etc. from the control plane to the user plane, as well as the reporting of information from the user plane.

[0078] 5) N6: The interface between the UPF network element and the DN, used to transmit uplink and downlink user data streams between the UP network element F and the DN.

[0079] It is understood that the aforementioned network element or function can be a network component in a hardware device, a software function running on dedicated hardware, or a virtualization function instantiated on a platform (e.g., a cloud platform). As one possible implementation method, the aforementioned network element or function can be implemented by a single device, multiple devices working together, or a functional module within a single device; this application does not specifically limit this.

[0080] In addition, the above-mentioned NF network elements can also be abbreviated as NF. For example, the AMF network element can be abbreviated as AMF.

[0081] It is understood that Figure 1 is an example of a 5G service-oriented network architecture. This application can also be applied to service-oriented architectures in other 5G or future mobile networks besides Figure 1 to implement certificate issuance for NF network elements in the service-oriented network architecture.

[0082] (2) Automatic Certificate Management Environment (ACME) protocol

[0083] In the authentication of NF network elements under a service-oriented architecture, a Certificate Authority (CA) needs to issue public key certificates to the NF network element. The ACME protocol provides an extensible certificate management framework for automating certificate identifier (including domain name, IP address, etc.) verification (or challenge verification) and certificate application, certificate revocation, and other management processes covering the certificate lifecycle, thereby simplifying NF network element authentication and improving its efficiency.

[0084] Referring to Figure 2, the user has installed the ACME client and registered an ACME account on the device requiring a certificate (described below using an NF network element as an example). The CA runs the ACME server, where miniCA is a lightweight certificate authority tool. The NF network element requests the certificate from the CA through the ACME client. After receiving the certificate from the CA, the NF network element deploys the certificate to the corresponding device (such as a web server). The NF network element and the CA can communicate via HTTPS JSON messages.

[0085] For example, Figure 3 illustrates a flowchart of an ACME protocol certificate application process. The ACME client can be deployed within an NF network element; for example, the ACME client can be a functional module within the NF network element. The ACME server can be deployed within a CA; for example, the ACME server can be a functional module within a CA server. As shown in Figure 3, the NF network element sends an account registration request to the CA to register a public-private key pair and an account. The public-private key pair can be used for encrypted communication between the ACME client and the ACME server. The ACME account can be used to manage metadata related to domain name verification. After completing registration, the NF network element executes a challenge verification process (this application uses domain name challenge verification as an example).

[0086] The challenge verification process includes: the NF network element (NF) requests a certificate order from the CA (Certificate Authority) and submits a certificate identifier (including the domain name and the domain name verification request). The CA responds to the domain name verification request and sends a random token and the challenge type supported by the domain name to the NF network element. The challenge type can include HTTP-01, TLS-ALPN-01, and / or Domain Name System (DNS)-01, etc. The NF network element can then select the challenge type and allocate a key for authorization. The NF network element can also request challenge information to be written to the corresponding device, function, or service based on the selected challenge type. The challenge information can be generated based on the random token. The challenge information can be generated by concatenating the random token with the ACME client's account public key and the challenge verification method (e.g., HTTP-01) into a string, inputting it into a hash function, and obtaining a hash value, which serves as the challenge information.

[0087] After generating the challenge information, the NF network element uploads the challenge information to the storage location corresponding to the challenge type (such as a web server or DNS server) and notifies the CA to complete the challenge. Then, the CA retrieves the challenge information from that storage location and verifies it against its own stored challenge information. If the CA confirms that its stored challenge information matches the retrieved challenge information, it determines that the certificate identifier verification is successful, and the challenge verification is complete.

[0088] After completing the challenge verification, the NF network element submits a Certificate Signing Request (CSR) to the CA so that the CA can issue a certificate for the NF network element.

[0089] (3) CMPv2 protocol

[0090] The CMPv2 protocol is a certificate acquisition protocol within a Public Key Infrastructure (PKI) system, capable of operating over HTTP or other transport protocols. Requesting a certificate for a device using the CMPv2 protocol can involve the following process: An initial trust is established between the NF (Network Functions) element and the CA / Registration Authority (RA). This initial trust may include an initial certificate issued by the CA, an initial verification key, and the Operations Administration and Maintenance (OAM) device's signature on the NF profile parameters. Then, the NF element generates a certificate request, including its ID and the initial trust, and sends the request to the CA / RA. The CA / RA verifies the NF element's ID and initial trust; upon successful verification, it generates a certificate and sends it to the NF element.

[0091] However, for communication security reasons, devices applying for certificates may be unable to access the Certificate Authority (CA) according to the ACME protocol. For example, the device applying for a certificate might be located on an internal network (also known as a Local Area Network, LAN) without an external access address, or it might be unable to access the external network (also known as a Wide Area Network, WAN). Alternatively, a device on an internal network might not allow a CA on an external network to access it, or vice versa. This prevents the device from communicating directly with the CA, meaning it cannot obtain the CA's random token, complete the challenge verification, and thus cannot obtain a certificate through the ACME protocol. Furthermore, each device applying for a certificate needs to perform a challenge verification, requiring each device to be granted access to the server storing the challenge information (such as access to a DNS server) or DNS record modification permissions. Therefore, if a device engaging in network attacks, the DNS server could be compromised, leading to network communication security vulnerabilities.

[0092] Furthermore, the initial trust establishment process (including initial certificate, initial verification key, and NF parameter signature) in the traditional CMPv2 protocol is quite complex, affecting the efficiency of certificate issuance. Also, due to difficulties in device upgrades, devices currently using the CMPv2 protocol to apply for certificates cannot use the ACME protocol to apply for certificates.

[0093] Therefore, how to enable devices on different networks to apply for certificates, ensure network communication security, and improve the efficiency of certificate application are technical problems that need to be solved. To this end, this application provides a communication method that uses a proxy device to apply for a certificate for a first device that needs to apply for a certificate, thereby enabling certificate application on different networks and ensuring network communication security. See Figure 4 for the specific flowchart and related description.

[0094] The communication method provided in this application is described using a first device, a proxy device, and a CA as examples. The first device in this application can be any NF network element shown in Figure 1, a terminal device, or a chip, unit, or module within a communication device with terminal functionality. The proxy device can be a proxy device, a chip, unit, or module within a proxy device, a communication device with network device functionality, or a chip, unit, or module within a communication device with network device functionality. A CA can be understood as a server, such as an ACME server, a CMPv2 server, or a CA server.

[0095] To make the purpose, technical solution and advantages of this application clearer, some terms involved in the embodiments of this application will be explained below.

[0096] (1) First Request

[0097] When the first device requests a certificate according to CMPv2, it sends a first request to the agent device. The first request is a CMPv2 protocol message, which instructs the agent device to request a certificate for the first device according to either the ACME protocol or the CMPv2 protocol. The first device can be any of the devices that need to request a certificate.

[0098] (2) Certificate Order

[0099] When the agent device applies for a certificate for the first device according to the ACME protocol, the agent device requests the creation of a certificate order from the target CA, which is generated by the target CA.

[0100] (3) Certificate Request

[0101] When the agent device requests a certificate for the first device according to the CMPv2 protocol, the agent device sends a certificate request to the target CA, which is used by the target CA to generate and issue the certificate.

[0102] The present application will now be described in further detail with reference to the accompanying drawings. The specific operational methods in the method embodiments can also be applied to the device embodiments or system embodiments. It is understood that the present application can also be applied to service-oriented architectures in other 5G or future mobile networks besides those shown in Figure 1, or to communication architectures in 5G or future mobile networks, or to any network scenario using digital certificates, such as the Internet, to issue certificates to devices that require certificates.

[0103] Figure 4 illustrates a flowchart of a communication method provided in an embodiment of this application. The scheme in Figure 4 is illustrated using the interaction between a first device, a proxy device, and a target CA as an example. The relevant descriptions of the first device, the proxy device, and the target CA are as described above and will not be repeated here.

[0104] As shown in Figure 4, the communication method may include the following steps:

[0105] Step 410: The agent device receives a first request from the first device, which is a message in the CMPv2 protocol.

[0106] In this process, a first CMPv2 client is deployed on the first device, and a first CMPv2 server is deployed on the proxy device. The first device can send a first request to the first CMPv2 server through the first CMPv2 client, that is, send a first request to the proxy device. This first request is used to instruct the proxy device to apply for a certificate for the first device.

[0107] Step 420: The agent device responds to the first request and determines the target CA based on its own configuration information.

[0108] Optionally, the agent device's configuration information includes a list of CAs and a decision-making strategy. The CA list includes one or more of the following: at least one CA, the certificate management protocols supported by each CA, and the usage priority of the certificate management protocols supported by each CA. The decision-making strategy is used to determine the target CA from the at least one CA.

[0109] Optionally, the proxy device determines the target CA based on the first request. The first request includes one or more of the following information: the type of the first device, its IP address, the identifier of the first device, and the identifier of the CA.

[0110] Optionally, any CA may support the CMPv2 certificate management protocol, or any CA may support the ACME certificate management protocol, or any CA may support both the CMPv2 and ACME certificates. For example, the CA list may include CA1, CA2, and CA3, where CA1 supports the CMPv2 certificate management protocol, CA2 supports the ACME certificate management protocol, and CA3 supports both the CMPv2 and CME certificates.

[0111] Optionally, the ACME protocol takes precedence over the CMPv2 protocol. That is, if the target CA supports both CMPv2 and ACME protocols for certificate management, the ACME protocol will be used first.

[0112] Step 430: If the agent device determines that the target CA supports the ACME protocol, then proceed to step 440; if it determines that the target CA supports the CMPv2 protocol, then proceed to step 450.

[0113] Optionally, based on step 420 above, if the agent device determines that the target CA supports both the ACME protocol and the CMPv2 protocol, it selects the protocol with the highest priority from the CMPv2 protocol and the ACME protocol according to the usage priority of the protocols, and applies for a certificate for the first device according to the protocol with the highest priority.

[0114] Step 440: The agent device applies for a certificate for the first device according to the ACME protocol.

[0115] In this process, a proxy device acts on behalf of the first device to apply for a certificate from the target CA. This process includes the following steps: The proxy device requests a certificate order for the ACME protocol from the target CA based on a first request, then performs a challenge verification process (refer to the challenge verification process in the ACME protocol in Figure 3 above). After obtaining authorization to issue the certificate order (which can be understood as the challenge verification passing), it generates a completion order request based on the first request and sends this completion order request to the target CA, so that the target CA sends the certificate to the proxy device. After obtaining the first device's certificate from the target CA, the proxy device sends a first response to the first device. The first response includes the first device's certificate and corresponds to the first request.

[0116] In one possible implementation, referring to Figure 5, a first CMPv2 client is deployed on the first device, and a first CMPv2 server and an ACME client are deployed on the proxy device. The target CA can be an ACME server, on which the ACME server is deployed. Taking the DNS-01 challenge as an example, an external DNS record is pre-configured. This external DNS record points to the address required during the challenge verification process (such as the address of the proxy device). The process for applying for a certificate for the first device according to the ACME protocol is as follows:

[0117] Step 501: The first device sends a first request to the first CMPv2 server on the agent device according to the first CMPv2 client. The first request is a CMPv2 protocol message. This first request can be understood as an instruction to apply for a certificate.

[0118] Step 502: The proxy device sends a certificate response to the first CMPv2 client on the first device based on the first CMPv2 server. The certificate response is used to indicate the processing status of the first request (such as in progress or waiting).

[0119] Step 503: The agent device determines the target CA based on its own configuration information (refer to step 420).

[0120] Step 504: The agent device determines that the target CA supports the ACME protocol and completes challenge verification with the target CA (refer to the description in Figure 9 below).

[0121] Step 505: The agent device sends an order completion request to the ACME server deployed on the ACME server based on the ACME client. The order completion request includes a Certificate Signing Request (CSR).

[0122] Step 506: The target CA issues a certificate to the ACME client on the agent device based on the ACME server.

[0123] Step 507: The proxy device sends a first response to the first CMPv2 client on the first device based on the first CMPv2 server. The first response includes the certificate of the first device.

[0124] In one possible implementation, referring to Figure 6, the proxy device may include a first module and a second module. The first module is equipped with a first CMPv2 server, and the second module is equipped with an ACME client. The first module communicates with the first device, executing steps 501, 502, 503, and 507. The second module continues to communicate with the target CA, executing steps 504, 505, and 506. The first and second modules forward information to each other, such as by executing the following steps: Step 601, the first module sends a second request to the second module, which is generated by the first module based on the first request. This second request can be understood as an instruction to apply for a certificate. Step 602, the second module sends a third response to the first module, which includes a certificate. The third response is used by the first module to generate the first response.

[0125] Optionally, after receiving the certificate response (which can be understood as after step 502 is completed), the first device may periodically send a polling request to request the processing status of the first request until the processing status of the first request is "completed" (which can be understood as the agent device has issued a certificate to the first device).

[0126] Step 450: The agent device applies for a certificate for the first device according to the CMPv2 protocol.

[0127] In this process, a proxy device acts on behalf of the first device to request a certificate from the target CA. This process includes the following steps: the proxy device sends a CMPv2 certificate request to the target CA based on the first request, then receives a second response from the target CA and sends the first device's certificate to the first device. The second response includes the first device's certificate. Sending the first device's certificate to the first device can also include the following steps: the proxy device forwards the second response to the first device; or, the proxy device generates a fourth response based on the second response and sends the fourth response to the first device, the fourth response including the first device's certificate.

[0128] In one possible implementation, referring to Figure 7, a first CMPv2 client is deployed on the first device, and a first CMPv2 server and a second CMPv2 client are deployed on the proxy device. The target CA can be a CMPv2 server, and a second CMPv2 server is deployed on the CMPv2 server. The process for applying for a certificate for the first device according to the CMPv2 protocol is as follows:

[0129] Step 701: The first device sends a first request to the first CMPv2 server on the agent device according to the first CMPv2 client. The first request is a message of the CMPv2 protocol.

[0130] Step 702: The proxy device sends a certificate response to the first CMPv2 client on the first device based on the first CMPv2 server. The certificate response includes an indication of the processing status of the first request (such as in progress or waiting).

[0131] Step 703: The agent device determines the target CA based on its own configuration information (refer to step 420).

[0132] Step 704: The agent device determines that the target CA supports the CMPv2 protocol.

[0133] Step 705: The agent device sends a CMPv2 protocol certificate request to the second MPv2 server deployed on the CMPv2 server based on the second CMPv2 client.

[0134] Step 706: The target CA issues a certificate to the second CMPv2 client on the agent device based on the second CMPv2 server.

[0135] Step 707: The proxy device sends a second response to the first CMPv2 client on the first device based on the first CMPv2 server. The second response includes the certificate of the first device.

[0136] In one possible implementation, the proxy device may include a first module and a second module. The first module deploys a first CMPv2 server, and the second module deploys a second CMPv2 client. The first module communicates with the first device, executing steps 701, 702, 703, and 707. The second module continues to communicate with the target AC, executing steps 704, 705, and 706. The first and second modules forward information to each other, such as by performing the following steps: the first module sends a third request to the second module, which is generated by the first module based on the first request and can be understood as an instruction to request a certificate. The second module sends a fourth response to the first module, which includes a certificate, and this fourth response is used by the first module to generate the second response.

[0137] Optionally, after receiving the certificate response (which can be understood as after step 702 is completed), the first device may periodically send a polling request to request the processing status of the first request until the processing status of the first request is "completed" (which can be understood as the agent device has issued a certificate to the first device).

[0138] Referring to Figure 8, in the above technical solution, communication between the proxy device and the first device is achieved through a first CMPv2 server deployed on the proxy device and a CMPv2 client deployed on the first device. Communication between the proxy device and the target CA is achieved through an ACME client deployed on the proxy device and an ACME server deployed on the target CA, or through a second CMPv2 client deployed on the proxy device and a second CMPv2 server deployed on the target CA. Essentially, the proxy device communicates with the target CA on behalf of the first device, applies for a certificate from the target CA, and obtains the certificate after completing the application process. This certificate is equivalent to the target CA issuing the certificate to the proxy device. The proxy device sends this certificate to the first device, which can be understood as the proxy device applying for the certificate from the target CA on behalf of the first device, or as the proxy device issuing the certificate to the first device on behalf of the target CA. In other words, the first device using the CMPv2 protocol can communicate indirectly with the target CA providing the ACME protocol interface through the proxy device, without needing to communicate directly with the target CA. That is, the first device can indirectly apply for a certificate from the target CA, no longer needing to obtain the certificate directly from the target CA. Therefore, without needing to update or upgrade the software and hardware of the first device using the CMPv2 protocol, the first device using the CMPv2 protocol can apply for a certificate according to the ACME protocol.

[0139] Figure 9 illustrates a possible flowchart of a communication method provided in an embodiment of this application. The scheme in Figure 9 is illustrated using the interaction between a first device, a proxy device, and a target CA as an example. The first device is equipped with an ACME client, and the target CA is equipped with an ACME server; therefore, the first device and the target CA can communicate directly according to the ACME protocol. As shown in Figure 9, the communication method may include the following steps:

[0140] Step 901: The first device sends a first challenge request to the agent device.

[0141] Optionally, the first challenge request can be used to indicate the challenge type, and can also be used to instruct the agent device to store the challenge information on the external network; the first challenge request can also be used to instruct the agent device to obtain the challenge information from the first server.

[0142] In one possible implementation, before executing step 901, the first device sends a certificate order request to the target CA. This certificate order request is used to apply for the creation of a certificate order for the ACME protocol; that is, the first device requests the target CA, which is the CA selected by the first device, to create a certificate order for the ACME protocol. Then, the target CA generates the certificate order and sends a certificate order response back to the first device. The certificate order response is sent by the target CA based on the certificate order request and indicates the supported challenge types and their corresponding tokens. Optionally, the first device can select a target challenge from the supported challenge types based on the certificate order response, and then generate challenge information based on the token corresponding to the target challenge. Optionally, each challenge type corresponds to one token, or the tokens corresponding to each challenge type are different.

[0143] Step 902: The agent device obtains challenge information from the first server according to the first challenge request. The challenge information is generated by the first device and stored in the first server, which is located in the first network.

[0144] In this process, the first network is a local area network (also known as an intranet). That is, the first device is on the intranet. For network communication security reasons, in one possible implementation, the first device is not allowed to access the external network, nor is it allowed to be accessed by a CA on the external network.

[0145] Optionally, the first server is an HTTP server.

[0146] Optionally, the first server is a TLS server.

[0147] Step 903: The agent device stores the challenge information to the second server, which is located on the second network.

[0148] In this process, the challenge information is used to verify the challenge information after the target CA receives the second challenge request from the first device. The second network is a wide area network (also known as an external network). Optionally, the second server is an HTTP server; optional, the second server is a TLS server; optional, the second server is a DNS server.

[0149] In this process, after receiving the second challenge request, the target CA can obtain challenge information from the second server and verify the challenge information of the first device, thus completing the challenge verification. In other words, the proxy device communicates with the first device on a local area network (LAN), and with the target CA on a wide area network (WAN). Therefore, even if the first device on the LAN cannot access the target CA on the WAN, or the target CA on the WAN cannot access the first device on the LAN, the proxy device can still complete the challenge verification between the first device and the target CA, enabling the first device, located on a different network from the target CA, to apply for a certificate according to the ACME protocol. Furthermore, because the first device only needs to upload the challenge information to the first server and does not need to access the second server on the WAN or be accessible from the external network, the network security of the first device is ensured. Therefore, it is not necessary to grant the first device access to the external network or permission to modify resources on a specific server, thus preventing network communication security issues caused by network attacks on the first device.

[0150] The ACME protocol supports challenge types including HTTP-01, TLS-ALPN-01, and DNS-01. To better illustrate the above technical solutions, the following descriptions focus on the HTTP-01 and DNS-01 challenge types, with specific details provided in Examples 1 and 2 below.

[0151] Example 1

[0152] Pre-configure external and internal DNS records. The external DNS records point the domain name to the address of a second server (such as the address of a proxy device, an external HTTP server, etc.), and the internal DNS records point the domain name to the address of a first server (such as the address of the first device, an internal HTTP server, etc.). The first device generates a key pair and registers an ACME account with the target CA. Based on this, referring to Figure 10, the process for applying for a certificate using the HTTP-01 challenge type includes:

[0153] Step 1001: The first device sends a certificate order request to the target CA. The certificate order request is used to apply for the creation of a certificate order for the ACME protocol.

[0154] In this process, after the target CA receives the certificate order request, it will generate a certificate order.

[0155] Step 1002: The target CA sends a certificate order response to the first device. The certificate order response is used to indicate the acquisition of a token and the supported challenge types. This certificate order response is sent by the target CA in accordance with the certificate order request.

[0156] In this process, the certificate order response can be understood as a certificate order, meaning the target CA sends the generated certificate order back to the first device. The certificate order response includes the address of the authorized object, which contains a token and supported challenge types. Therefore, the first device can obtain the token and supported challenge types based on the address of the authorized object. Optionally, challenge types include HTTP-01, DNS-01, and TLS-ALPN-01, and tokens include token 1 for HTTP-01, token 2 for DNS-01, and token 3 for TLS-01. The tokens can be random numbers.

[0157] Step 1003: The first device selects the HTTP-01 challenge, generates challenge information key authorization based on the token corresponding to the HTTP-01 challenge, and stores the key authorization to the internal network HTTP server (i.e., the first server).

[0158] Step 1004: The first device sends a first challenge request to the agent device. The first challenge request is used to request an HTTP challenge. The request includes the DNS record of the internal network and the storage method of the key authorization (HTTP storage).

[0159] Step 1005: The proxy device queries the domain name based on the DNS records of the internal network to obtain the storage address of the key authorization, and obtains the key authorization based on the HTTP challenge.

[0160] Step 1006: The proxy device stores the key authorization to an external HTTP server (i.e., a second server).

[0161] Step 1007: The proxy device sends a second challenge request to the target CA. The second challenge request is used to request an HTTP challenge. The request includes the external DNS record and the storage method of the key authorization (HTTP storage).

[0162] Step 1008: The target CA verifies the challenge information.

[0163] In this process, after receiving the second challenge request, the target CA first resolves the domain name in the DNS record from the external DNS server to obtain the IP address corresponding to the domain name. Then, it uses the IP address to access the corresponding HTTP server and downloads the challenge information from the directory specified in the HTTP server. The target CA compares the downloaded verification information with the challenge data it has saved. If they match, it means that the challenge information has been successfully verified, and the target CA modifies the verification status of the corresponding certificate order to pass.

[0164] At this point, the challenge verification between the first device and the target CA is completed through the proxy device. After completing the challenge verification, the following steps are also included:

[0165] Step 1009: When the challenge verification is successful, the first device sends a completion order request to the target CA, which includes a CSR.

[0166] [Revised according to Rule 91, 21.02.2025] Step 1010: When the target CA verifies the validity of the CSR (see step 1203 below for details), it issues a certificate to the first device.

[0167] In this process, the ACME server places the aforementioned certificate in the corresponding directory on the ACME server, and the first device downloads the aforementioned certificate and deploys it to the corresponding device for use.

[0168] In Example 1, the proxy device obtains the challenge information required for the ACME protocol challenge verification process from an HTTP server located on the internal network. The target CA does not need to access the internal network HTTP server to obtain the challenge information, thus ensuring the security of the first device. The proxy device stores the challenge information required for the ACME protocol challenge verification process on an external network HTTP server that the target CA is allowed to access. Therefore, the first device does not need to be granted permission to access the external network HTTP server, preventing the first device from attacking the HTTP server and ensuring the security of network communication. Furthermore, during the challenge verification process, the first device and the target CA do not need to communicate directly, thus enabling the first device, located on a different network than the target CA, to apply for a certificate according to the ACME protocol.

[0169] Example 2

[0170] Pre-configure internal DNS records, which are used to point domain names to the address of a first server (such as the address of the first device, an internal HTTP server, etc.). The first device generates a key pair and registers an ACME account with the target CA. Based on this, referring to Figure 11, the process for applying for a certificate using the DNS-01 challenge type includes:

[0171] Step 1101: The first device sends a certificate order request to the target CA. The certificate order request is used to apply for the creation of a certificate order for the ACME protocol.

[0172] Step 1102: The target CA sends a certificate order response to the first device. The certificate order response is used to indicate the acquisition of a token and the supported challenge types. This certificate order response is sent by the target CA in accordance with the certificate order request.

[0173] Step 1103: The first device selects the HTTP-01 challenge, generates challenge information key authorization based on the token corresponding to the HTTP-01 challenge, and stores the key authorization to the internal network HTTP server (i.e., the first server).

[0174] Step 1104: The first device sends a first challenge request to the agent device. The first challenge request is used to request an HTTP challenge. The request includes the DNS record of the internal network and the storage method of the key authorization (HTTP storage).

[0175] Step 1105: The proxy device queries the domain name based on the DNS records of the internal network to obtain the storage address of the key authorization, and obtains the key authorization based on the HTTP challenge.

[0176] It can be seen that the process of the first device generating and storing challenge information is the same as steps 1001-1005 in the above embodiment 1, so steps 1101-1105 will not be described in detail.

[0177] Step 1106: The proxy device configures the key authorization into the domain name record of the external DNS server (the external DNS server can be understood as a second server).

[0178] Step 1107: The proxy device sends a second challenge request to the target CA. The second challenge request is used to request a DNS challenge. The request includes the external DNS records and the storage method of the key authorization (DNS storage).

[0179] Step 1108: The target CA verifies the challenge information.

[0180] In this process, the proxy device configures the challenge information into the corresponding domain name record on the external DNS server (i.e., the second server) and then notifies the target CA to retrieve the challenge information. The target CA obtains the record for that domain name from the external DNS server through the DNS resolution service and extracts the corresponding challenge information from the record. The target CA compares the extracted verification information with its own stored challenge data. If they match, it means the challenge information has been successfully verified, and the target CA modifies the verification status of the corresponding certificate order to "passed".

[0181] At this point, the challenge verification between the first device and the target CA is completed through the proxy device. After completing the challenge verification, the following steps are also included:

[0182] Step 1109: When the challenge verification is successful, the first device sends a completion order request to the target CA, which includes a CSR.

[0183] Step 1110: When the target CA verifies the validity of the CSR (see steps 1212-1214 below for details), it issues a certificate to the first device.

[0184] In this process, the ACME server places the aforementioned certificate in the corresponding directory on the ACME server, and the first device downloads the aforementioned certificate and deploys it to the corresponding device for use.

[0185] In Example 2, the DNS server can be used to implement domain name registration and the resolution of domain names to Internet Protocol (IP) addresses. The proxy device configures the challenge information required for the ACME protocol challenge verification process into the external network's DNS records, without granting the first device access to the external network's DNS server, thus ensuring the DNS server's security. Furthermore, during the challenge verification process, the first device and the target CA do not need to communicate directly; therefore, the first device, located on a different network than the target CA, can apply for a certificate according to the ACME protocol.

[0186] Figure 12 illustrates a possible flowchart of a communication method provided in an embodiment of this application. The scheme in Figure 12 is illustrated using the interaction between a first device, a proxy device, and a target CA as an example. The proxy device is equipped with an ACME client, and the target CA is equipped with an ACME server; therefore, the first device and the target CA need to communicate indirectly through the proxy device. As shown in Figure 12, the communication method may include the following steps:

[0187] Step 1201: The target CA verifies the challenge information of the first device based on the third challenge request from the agent device.

[0188] In this process, the first device can send a first certificate order request to the proxy device, which then forwards the first certificate order request to the target CA; alternatively, the first device can send a second certificate order request to the proxy device, which then generates a first certificate order request based on the second certificate order request and sends it to the target CA. This first certificate order request is used to apply for the creation of a certificate order for the ACME protocol. Then, the target CA generates a certificate order based on the first certificate order request. This certificate order includes at least one authorized object, and each authorized object (hereinafter referred to as the first authorized object for ease of description) includes multiple challenge objects (which can be understood as challenge types). Each challenge object corresponds to a token, which is used to generate challenge information.

[0189] For example, the challenge information generation process includes: the proxy device receiving a first certificate order response from the target CA (which can be understood as obtaining a generated certificate order from the target CA), the first certificate order response including the address of the first authorized object. Then, the proxy device obtains a token from the first authorized object based on the address of the first authorized object, and then the proxy device can generate first information based on the token and its own public key fingerprint (ACME account public key fingerprint). For example, the first information is denoted as ka0, the challenge information is denoted as ka1, and ka0 = token || "." || ACME account public key fingerprint. Afterwards, the proxy device sends the first information to the first device, so that the first device generates challenge information based on the public key fingerprint of the first public key and the first information. For example, the challenge information is denoted as ka1, and ka1 = ka0 || "." || public key fingerprint of the first public key. It can be seen that the challenge information includes the public key fingerprint of the first public key. Because the third challenge request is used to verify the challenge information, the third challenge request is associated with the first authorized object, and the public key fingerprint of the first public key is associated with the first authorized object. For example, after obtaining the challenge information, the target CA determines whether the challenge information includes the public key fingerprint of the first public key. If so, it binds the public key fingerprint of the first public key to the certificate order, thereby establishing an association between the public key fingerprint of the first public key and the first authorized object.

[0190] Step 1202: The target CA receives a completion order request from the agent device, which includes the second public key.

[0191] In this process, the order completion request includes a CSR, which contains a second public key.

[0192] Step 1203: When the target CA determines that the public key fingerprint of at least one authorized object in the certificate order is the public key fingerprint of the first public key, if the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key, then the target CA issues a certificate to the first device.

[0193] In this process, at least one authorized object's public key fingerprint is the public key fingerprint of the first public key, indicating that at least one authorized object has the same public key fingerprint. Optionally, if at least one authorized object has a different public key fingerprint, the CSR is rejected. To better illustrate the above technical solution, refer to the following embodiment 3.

[0194] Example 3

[0195] The first device generates a key pair and registers an ACME account with the target CA through a proxy device. Based on this, referring to Figure 13, the process of applying for a certificate using the HTTP-01 challenge type includes:

[0196] Step 1301: The first device sends a first certificate order request to the agent device. The first certificate order request is used to apply for a certificate order to create the ACME protocol.

[0197] In this process, the first certificate order request contains a certificate identifier. After receiving the first certificate order request, the target CA generates a certificate order.

[0198] Step 1302: The agent device forwards the first certificate order request to the target CA.

[0199] Step 1303: The target CA sends a first certificate order response to the agent device. The first certificate order response is used to indicate the supported challenge type and the corresponding token.

[0200] In this process, the first certificate order response is sent by the target CA based on the first certificate order request. The first certificate order response includes the address of the first authorized object. The proxy device uses the address of the first authorized object to obtain the supported challenge types and corresponding tokens from the first authorized object. Optionally, the challenge types include HTTP-01, DNS-01, and TLS-ALPN-01, and the tokens include token 1 for HTTP-01, token 2 for DNS-01, and token 3 for TLS-01. The tokens can be random numbers.

[0201] Step 1304: The agent device selects the target challenge and then generates the first information based on its own public key fingerprint and the token corresponding to the target challenge.

[0202] In this process, assuming the target challenge is HTTP-01, the proxy device generates the first information based on its own public key fingerprint (hereinafter referred to as the ACME account public key fingerprint) and token 1 corresponding to HTTP-01. For example, the first information ka0 = token1 || "." || ACME account public key fingerprint.

[0203] Step 1305: The agent device sends a second certificate order response to the first device, which includes the first information.

[0204] Step 1306: The first device generates challenge information based on the first information and the public key fingerprint of the first public key, and stores the challenge information on an external HTTP server.

[0205] In this process, the challenge information (key authorization) ka1 = ka0 || "." || the public key fingerprint of the first public key.

[0206] Step 1307: The first device sends a fourth challenge request to the agent device. The fourth challenge request is used to instruct the agent device to verify the challenge information of the first device. The agent device uses the fourth challenge request to generate a third challenge request.

[0207] In this process, the third challenge request is used to request an HTTP challenge. The request includes the external DNS record and the storage method of the key authorization (HTTP storage).

[0208] Step 1308: The agent device sends a third challenge request to the target CA. The third challenge request is used to instruct the verification of the challenge information of the first device.

[0209] Step 1309: The target CA verifies the challenge information.

[0210] In this process, after the target CA confirms that the challenge information has been successfully verified (refer to step 1008 above), it determines whether the challenge information includes the public key fingerprint of the first public key; if so, it associates the public key fingerprint of the first public key with the first authorized object.

[0211] Step 1310: When the challenge verification is successful, the first device sends a completion order request to the agent device. The completion order request includes a CSR, and the CSR includes the second public key.

[0212] Step 1311: The agent device forwards the order completion request to the target CA.

[0213] Step 1312: The target CA verifies the order completion request based on the public key in the CSR. If the verification is successful, proceed to step 1313; otherwise, reject the order completion request.

[0214] In one possible implementation, a certificate order can correspond to multiple authorized objects. Based on this, if multiple authorized objects are all associated with the public key fingerprint of the first public key, then the second public key in the CSR needs to be verified; if none of the multiple authorized objects are associated with a public key fingerprint, then the second public key in the CSR does not need to be verified; if multiple authorized objects are associated with different public key fingerprints, or if some authorized objects are associated with a public key fingerprint while others are not, then the certificate order is determined to be invalid, i.e., no certificate will be issued for this certificate order.

[0215] In this process, if the target CA determines that the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key in the CSR, then step 1313 is executed; otherwise, the order completion request is rejected.

[0216] Step 1313: The target CA issues a certificate to the agent device.

[0217] Step 1314: The proxy device forwards the certificate to the first device.

[0218] In Example 3, the challenge information includes the public key fingerprint of the first public key, and the order completion request includes a CSR, which in turn includes the second public key. If the public key fingerprint of the first public key is the same as that of the second public key, it indicates that both the challenge information and the order completion request were generated and sent by the first device, and the proxy device has not tampered with the information in the CSR within the order completion request. Therefore, the target CA can verify the CSR based on the public key fingerprint in the challenge information and the public key fingerprint in the CSR. If the two public key fingerprints match, the CSR verification is successful, indicating that the proxy device has not forged the CSR, thus preventing the proxy device from forging the CSR and ensuring its accuracy and security.

[0219] It is understood that, in order to achieve the functions in the above embodiments, the first device, the agent device, or the target CA includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and method steps of the various examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0220] Figures 14 and 15 are schematic diagrams of possible communication devices provided in embodiments of this application. These communication devices can be used to implement the functions of the first device, proxy device, or target CA in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0221] As shown in Figure 14, the communication device 1400 includes a processing unit 1410 and a transceiver unit 1420. The communication device 1400 is used to implement the functions of the first device, the proxy device, or the target CA in the method embodiments shown in Figures 4, 9, and 12.

[0222] When the communication device 1400 is used to implement the function of the proxy device in the method embodiment shown in FIG4: the processing unit 1410 is used to receive a first request from the first device through the transceiver unit 1420, wherein the first request is a message of the CMPv2 protocol; the processing unit 1410 is also used to respond to the first request and determine the target CA according to its own configuration information; if it is determined that the target CA supports the ACME protocol, then apply for a certificate for the first device according to the ACME protocol; if it is determined that the target CA supports the CMPv2 protocol, then apply for a certificate for the first device according to the CMPv2 protocol.

[0223] When the communication device 1400 is used to implement the function of the proxy device in the method embodiment shown in FIG9: the processing unit 1410 is used to receive a first challenge request from the first device through the transceiver unit 1420; the processing unit 1410 is also used to obtain challenge information from the first server according to the first challenge request, and store the challenge information in the second server, wherein the challenge information is generated by the first device and stored in the first server; the first server and the first device are in a first network, the second server is in a second network, and the challenge information is used to verify the challenge information after the target CA receives the second challenge request from the first device.

[0224] When the communication device 1400 is used to implement the function of the target CA in the method embodiment shown in FIG12: the processing unit 1410 is used to verify the challenge information of the first device according to the third challenge request from the proxy device, wherein the challenge information includes the public key fingerprint of the first public key, the third challenge request is associated with the first authorized object in the certificate order, the public key fingerprint of the first public key is associated with the first authorized object, and the certificate order is generated by the target CA according to the first certificate order request from the proxy device; the processing unit 1410 is also used to receive the completion order request from the proxy device through the transceiver unit 1420, wherein the completion order request includes the second public key; the processing unit 1410 is also used to issue a certificate to the first device if it is determined that the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key when it is determined that the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key when it is determined that the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key.

[0225] A more detailed description of the processing unit 1410 and the transceiver unit 1420 can be obtained directly from the relevant descriptions in the method embodiments shown in Figures 4, 9 or 12, and will not be repeated here.

[0226] As shown in Figure 15, the communication device 1500 includes a processor 1510 and an interface circuit 1520. The processor 1510 and the interface circuit 1520 are coupled to each other. It is understood that the interface circuit 1520 can be a transceiver or an input / output interface. Optionally, the communication device 1500 may also include a memory 1530 for storing instructions executed by the processor 1510, or storing input data required by the processor 1510 to execute instructions, or storing data generated after the processor 1510 executes instructions.

[0227] When the communication device 1500 is used to implement the method shown in FIG4, FIG9 or FIG12, the processor 1510 is used to implement the function of the processing unit 1410, and the interface circuit 1520 is used to implement the function of the transceiver unit 1420.

[0228] When the aforementioned communication device is a chip applied to a first device, a proxy device, or a target CA, the chip implements the functions of the first device, the proxy device, or the target CA in the above method embodiments. The chip receives information from other modules (such as radio frequency modules or antennas) in the first device, the proxy device, or the target CA; or, the chip sends information to other modules (such as radio frequency modules or antennas) in the first device, the proxy device, or the target CA.

[0229] When the aforementioned communication device is a module applied to the first device, proxy device, or target CA, the module implements the functions of the first device, proxy device, or target CA in the above method embodiments. The module receives information from other modules (such as radio frequency modules or antennas) in the first device, proxy device, or target CA; or, the module sends information to other modules (such as radio frequency modules or antennas) in the first device, proxy device, or target CA. The module here can be a baseband chip, a DU, or other modules. The DU here can be a DU under an open radio access network (O-RAN) architecture.

[0230] It is understood that the processor in the embodiments of this application may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor may be a microprocessor or any conventional processor.

[0231] This application provides another example of a communication device, which includes at least one processor and at least one memory coupled together. The at least one processor and the at least one memory are used to store instructions that, when executed by the at least one processor, cause the communication device to perform the methods described in the above embodiments. Taking a communication device including a processor and a memory as an example, as shown in FIG15, communication device 1500 includes a processor 1510 and a memory 1530. The processor 1510 and the memory 1530 are coupled together. The memory 1530 stores instructions. When the instructions stored in the memory 1530 are executed by the processor 1510, communication device 1500 performs the methods executed by the first device, the proxy device, or the target CA in the above embodiments.

[0232] The method steps in the embodiments of this application can be implemented in hardware or in software instructions executable by a processor. The software instructions can consist of corresponding software modules, which can be stored in random access memory, flash memory, read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, registers, hard disks, portable hard disks, CD-ROMs, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. The storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a first device, a proxy device, or a target CA. The processor and storage medium can also exist as discrete components in the first device, the proxy device, or the target CA.

[0233] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user equipment, or other programmable device. The computer program or instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video optical disc; or it can be a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or non-volatile storage medium, or may include both types of storage media.

[0234] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0235] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. In the textual description of this application, the character " / " generally indicates an "or" relationship between the preceding and following related objects; in the formulas of this application, the character " / " indicates a "division" relationship between the preceding and following related objects. "Including at least one of A, B, and C" can mean: including A; including B; including C; including A and B; including A and C; including B and C; including A, B, and C.

[0236] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

Claims

1. A communication method, characterized in that, include: Receive a first request from a first device, wherein the first request is a message of the CMPv2 protocol; In response to the first request, the target CA is determined based on its own configuration information; If it is determined that the target CA supports the ACME protocol, then apply for a certificate for the first device in accordance with the ACME protocol; If it is determined that the target CA supports the CMPv2 protocol, then a certificate is applied for for the first device according to the CMPv2 protocol.

2. The method according to claim 1, characterized in that, The agent device applies for a certificate for the first device according to the ACME protocol, including: In accordance with the first request, apply to the target CA for a certificate order to create an ACME protocol; After obtaining the authorization to issue the certificate order, a completion order request is generated based on the first request; Send the order completion request to the target CA; Obtain the certificate for the first device from the target CA; Send a first response to the first device, the first response including the certificate of the first device.

3. The method according to claim 1, characterized in that, The proxy device applies for a certificate for the first device according to the CMPv2 protocol, and the method includes: Send a CMPv2 protocol certificate request to the target CA according to the first request; Receive a second response from the CA, the second response including the certificate of the first device; Send the certificate of the first device to the first device.

4. The method according to any one of claims 1-3, characterized in that, The configuration information includes a list of CAs and a decision-making strategy; the list of CAs includes one or more of the following: at least one CA, the certificate management protocol supported by any CA, and the usage priority of the certificate management protocol supported by any CA. The certificate management protocols supported by any of the CAs include the CMPv2 protocol and / or the ACME protocol, with the ACME protocol having a higher priority than the CMPv2 protocol; the decision strategy is used to determine the target CA from the at least one CA.

5. A communication method, characterized in that, include: Receive the first challenge request from the first device; Challenge information is obtained from the first server according to the first challenge request, wherein the challenge information is generated by the first device and stored in the first server; The challenge information is stored in a second server. The first server and the first device are on a first network, and the second server is on a second network. The challenge information is used to verify the challenge information after the target CA receives a second challenge request from the first device.

6. The method according to claim 5, characterized in that, The first server is an HTTP server, and the second server is a DNS server.

7. A communication method, characterized in that, include: According to the third challenge request from the proxy device, the challenge information of the first device is verified. The challenge information includes the public key fingerprint of the first public key. The third challenge request is associated with the first authorized object in the certificate order. The public key fingerprint of the first public key is associated with the first authorized object. The certificate order is generated by the target CA according to the first certificate order request from the proxy device. Receive a completion order request from the agent device, the completion order request including a second public key; When it is determined that the public key fingerprint of at least one authorized object in the certificate order is the public key fingerprint of the first public key, if it is determined that the public key fingerprint of the first public key is the same as the public key fingerprint of the second public key, then a certificate is issued to the first device.

8. The method according to claim 7, characterized in that, The method further includes: Receive a first certificate order request from the agent device, the first certificate order request being used to request the creation of a certificate order for the ACME protocol; Based on the first certificate order request, a first certificate order response is sent to the proxy device. The first certificate order response is used to instruct the acquisition of a token. The token is used to determine first information with the public key fingerprint of the proxy device. The first information is used to determine challenge information with the public key fingerprint of the first public key.

9. A communication device, characterized in that, It includes units or modules for performing the method as described in any one of claims 1-4, or units or modules for performing the method as described in claims 5 and 6, or units or modules for performing the method as described in claims 7 and 8.

10. A readable storage medium, characterized in that, The readable storage medium includes a program that, when run on the device, causes the device to perform the method as described in any one of claims 1-4, or the method as described in claims 5 and 6, or the method as described in claims 7 and 8.

11. A chip system, characterized in that, The chip system includes at least one chip and a memory, wherein the at least one chip is used to read and execute program instructions stored in the memory to implement the method as described in any one of claims 1-4, or the method as described in claims 5 and 6, or the method as described in claims 7 and 8.

12. A program product, characterized in that, When the program product is run on the device, the device performs the method as described in any one of claims 1-4, or the method as described in claims 5 and 6, or the method as described in claims 7 and 8.

Images