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

Communication method and device

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of the People's Republic of China on February 8, 2024, with application number 202410178192.9 and application name "A Communication Method and Device", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of wireless communication technology, and in particular to a communication method and device. Background Art

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

[0005] There is a proposal that NF network elements can apply for certificates through the Automatic Certificate Management Environment (ACME) protocol or the CMPv2 protocol. However, NF network elements using the CMPv2 protocol may not be able to communicate with CAs that provide ACME protocol interfaces, that is, they cannot apply for certificates from CAs that only provide ACME protocol interfaces, which in turn makes it impossible for NF network elements using the CMPv2 protocol to apply for certificates using the ACME protocol. If an NF network element using the CMPv2 protocol wants to apply for a certificate using the ACME protocol, it needs to be upgraded. However, the NF network element cannot be easily upgraded, so it is difficult for the NF network element to automatically apply for a certificate using the ACME protocol. Summary of the Invention

[0006] The embodiments of the present application provide a communication method and apparatus for enabling a device that uses the CMPv2 protocol and needs to apply for a certificate to communicate with a CA that provides an ACME protocol interface, and then apply for a certificate according to the ACME protocol.

[0007] In a first aspect, 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 inside the proxy device, and the proxy device can be a terminal device, an access network device, a server, etc. The following description is made with the execution subject being a proxy device. 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 the 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 message of the CMPv2 protocol;

[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 applying device). The first device can be a terminal device, an access network device, a NF network element, or a component in a NF network element. Among them, the component in this application can 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, and the first request can be sent 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. The target CA is used to issue a certificate for the first device.

[0011] Optionally, an ACME client and a second CMPv2 client are deployed on the proxy device, so the proxy device can be understood as a device that uses the ACME protocol and the CMPv2 protocol. An ACME server is deployed on the target CA, so the target CA can be understood as a device that provides an 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, and then obtain a certificate from the target CA for the first device, without the need for communication and interaction between the first device and the CA. In other words, the first device that uses the CMPv2 protocol can indirectly communicate with the CA that provides the ACME protocol interface through the proxy device, and then enable the first device that uses the CMPv2 protocol to apply for a certificate according to the ACME protocol. Therefore, there is no need to update or upgrade the software and hardware of the first device that uses the CMPv2 protocol, and the first device that uses the CMPv2 protocol can apply for a certificate according to the ACME protocol.

[0012] Optionally, a second CMPv2 server is deployed on the target CA. This means that the target CA may not provide an ACME protocol interface, meaning the proxy device cannot request 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, thereby increasing the flexibility of requesting a certificate for the first device.

[0013] Optionally, the target CA may deploy an ACME server and a second CMPv2 server. In other words, the target CA may support two certificate management protocols (CMPv2 and ACME), thereby improving the comprehensiveness of the certificate application.

[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 applies to the target CA for an ACME protocol certificate order based on the first request. Then, after obtaining authorization to issue the certificate order, the proxy device generates an order completion request based on the first request and sends the order completion request to the target CA, so that the target CA performs a challenge verification on the proxy device and issues a certificate for 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, where the first response includes the certificate of the first device.

[0015] In the above implementation, the proxy device communicates with the target CA on behalf of the first device, applies for a certificate from the target CA, and obtains a certificate after completing the certificate application process. This certificate is equivalent to the certificate issued by the target CA to the proxy device. The proxy device sends this certificate to the first device, which can be understood as the proxy device applying for a certificate from the target CA on behalf of the first device, or it can be understood as the first device indirectly applying for a certificate from the target CA, eliminating the need for the first device to obtain the certificate directly from the CA. Therefore, there is no need to update or upgrade the software and hardware of the first device using the CMPv2 protocol in order to enable the first device using the CMPv2 protocol to apply for a certificate according to the ACME protocol.

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

[0017] In the above implementation, the proxy device further supports applying for a certificate from the target CA according to the CMPv2 protocol. Optionally, the proxy device may apply for a certificate by directly forwarding the first request to the target CA.

[0018] In one possible implementation, the configuration information of the proxy device includes a CA list and a decision-making policy; wherein the CA list 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, and the ACME protocol has a higher priority than the CMPv2 protocol; the decision-making policy 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 based on the protocol priority. For example, ACME protocol can be used to apply for a certificate for the first device, thereby improving the flexibility of applying for certificates using the certificate management protocol.

[0020] According to a second aspect, a communication method is provided. The method may include the following steps: a proxy device receives a first challenge request from a first device, obtains challenge information from a first server based on the first challenge request, and then stores the challenge information on a second server. The challenge information is generated by the first device and stored on the first server, the first server and the first device are in a first network, and the second server is in 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, i.e., the second challenge request is used to instruct the target CA to verify the challenge information.

[0021] Optionally, the first network is a local area network (LAN), that is, the first network can be understood as an intranet; the second network is a wide area network (WAN), that is, the second network can be understood as an extranet.

[0022] Optionally, the address of the first server may be determined by the DNS record of the intranet; for example, the address of the first server may be determined by an A record, an AAAA record, a CNAME record, etc. in the DNS record of the intranet. Optionally, the address of the first server may be the address of the first device.

[0023] Optionally, the address of the second server may be determined by an external network DNS record; for example, the address of the second server may be determined by an NS record, an A record, an AAAA record, a CNAME record, etc. in the external network DNS record. Optionally, the address of the second server may be the address of the proxy device.

[0024] In some embodiments, the process of the ACME protocol includes certificate identifier verification, and certificate identifier (domain name, IP address, etc.) verification can also be called challenge verification. Only after the challenge verification is passed, it is determined that the first device has control over the identifier for which the certificate is to be applied for, and the first device is allowed 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 a DNS domain name server). Therefore, each first device is granted permission to modify server resources, which poses a security risk to network communications. In addition, if the first device and the target CA are in different networks, the first device may be unable to communicate directly with the target CA, resulting in the first device being unable to complete the challenge verification and thus being unable to apply for a certificate through the ACME protocol.

[0025] In this solution, the first device is deployed with an ACME client, and the target CA is deployed with an ACME server. Therefore, the first device can directly apply to the target CA to create a certificate order for the ACME protocol, and then the target CA generates a token and sends the token and the supported challenge types to the first device. Then, the first device selects the target challenge from the supported challenge types, and then generates challenge information based on the token and the target challenge, records the challenge information to the first server, and sends a first challenge request to the proxy device. After receiving the first challenge request, the proxy device records the challenge information to the second server. Then, the first device sends a second challenge request to the target CA, so that the target CA obtains the challenge information from the second server, and then verifies the challenge information of the first device, thereby completing the challenge verification. That is, the proxy device communicates with the first device in the intranet, and the proxy device communicates with the target CA in the extranet. Therefore, even if the first device in the intranet cannot access the target CA in the external network, or the target CA in the external network cannot access the intranet, the challenge verification between the first device and the target CA can be completed through the proxy device, and then the first device in a different network from the target CA can apply for a certificate according to the ACME protocol.

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

[0027] In a 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 solution, the first server is not a DNS server, so the first device may not be granted permission to access the DNS server, that is, the first device may not be granted permission to modify the DNS record.

[0030] In a third aspect, a communication method is provided, which can be implemented by a second communication device. The second communication device can be a CA-compatible server (e.g., an ACME server, a CA server, a CMPv2 server, etc.), or a chip, unit, or module within the server. The following description uses the target CA as the execution subject, and the method can include the following steps:

[0031] The target CA verifies the challenge information of the first device based on 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 authorization object in the certificate order, the public key fingerprint of the first public key is associated with the first authorization object, and the certificate order is generated by the target CA based on the first certificate order request from the proxy device; then, the target CA receives a completion order request from the proxy device, wherein the completion order request includes the second public key. Based on this, when the target CA determines that the public key fingerprint corresponding to at least one authorization 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 the target CA issues a certificate to the first device.

[0032] In this solution, the certificate order includes at least one authorization object, and the first authorization object is any authorization object among the at least one authorization object. The authorization object represents the authorization of the CA to a specific identifier (such as a domain name) in the ACME protocol, and includes multiple challenge types and corresponding challenge data (including tokens and other data). The order completion request includes a certificate signing request (CSR), and the CSR 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 means that the challenge information and the order completion request are both generated by the first device, and the proxy device has not tampered with the information in the order completion request (such as 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 is consistent with the public key fingerprint of the public key in the CSR, it is determined that the CSR verification has passed, 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 based on the first certificate order request, wherein the first certificate order response is used to instruct the proxy device to obtain a token. The first certificate order request is used to apply for the creation of an ACME protocol certificate order, the token is used to determine first information with a public key fingerprint of the proxy device, and the first information is used to determine challenge information with the public key fingerprint of the first public key.

[0034] Optionally, the proxy device's public key fingerprint can be understood as the ACME account public key fingerprint, i.e., the public key fingerprint of the public key corresponding to the ACME account, registered by the ACME account proxy device. For example, the proxy device (deployed with an ACME client) 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, deployed with an ACME server) 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 placed by the first device.

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

[0036] Optionally, the challenge information may be generated by hashing, XORing, concatenating, or the like.

[0037] In this solution, the proxy device is deployed with an ACME client, and the target CA is deployed with an ACME server. Therefore, a first device can apply to create an ACME certificate order through the proxy device. For example, the first device sends a second certificate order request to the proxy device. The proxy device then generates a first certificate order request based on the second certificate order request and sends the first certificate order request to the target CA, thereby requesting the target CA to create a certificate order. The target CA then creates the certificate order and returns a first certificate order response (which can be understood as "returning the certificate order") to the proxy device. The first certificate order response includes the address of at least one authorized object, and each authorized object's address contains a token corresponding to that authorized object. After receiving the first certificate order response, the proxy device obtains the token corresponding to the at least one authorized object's address. The proxy device then generates first information based on the token and its own public key fingerprint (ACME account public key fingerprint) and sends the 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 the challenge information on a DNS server on the external network, 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 a complete order request to the target CA through the proxy device. For example, the first device sends the complete order request to the proxy device, which then forwards the complete order request to the target CA. The complete order request includes a CSR, which includes the 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 are consistent, the CSR verification is determined to be successful, indicating that the proxy device has not forged the CSR. This prevents the proxy device from forging the CSR, ensuring the accuracy and security of the CSR.

[0039] In a fourth aspect, a communication device is provided, comprising a unit or module for executing the method as described in any one of the first aspect, second aspect or third aspect above.

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

[0041] In one possible implementation, the communication device also includes one or more memories; wherein the one or more memories store one or more programs, and when the programs are executed by the one or more processors, the device executes any one of the methods described in the first, second or third aspects above.

[0042] In a sixth aspect, a chip system is provided, comprising at least one chip and a memory, wherein the at least one chip is used 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] In a seventh aspect, a readable storage medium is provided, wherein the readable storage medium includes a program, and when the program is run on a device, the device executes any one of the methods described in the first aspect, the second aspect or the third aspect.

[0044] In an eighth aspect, a program product is provided. When the program product is run on a device, the device is caused to execute the method described in any one of the first, second or third aspects.

[0045] Based on the implementations provided in the above aspects, the embodiments of the present 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 here. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] FIG1 is a schematic diagram of the architecture of a wireless communication system used in an embodiment of the present application;

[0048] FIG2 is a schematic diagram of a system architecture of an ACME protocol applicable to an embodiment of the present application;

[0049] FIG3 is a schematic diagram of a process for applying for a certificate using the ACME protocol according to an embodiment of the present application;

[0050] FIG4 is a flow chart of a communication method provided in an embodiment of the present application;

[0051] FIG5 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 the present application;

[0052] FIG6 is a schematic diagram of another process of applying for a certificate for a first device according to the ACME protocol according to an embodiment of the present application;

[0053] FIG7 is a schematic diagram of a process of applying for a certificate for a first device according to the CMPv2 protocol according to an embodiment of the present application;

[0054] FIG8 is a schematic diagram of a system architecture for applying for a certificate for a first device according to the CMPv2 protocol applicable to an embodiment of the present application;

[0055] FIG9 is a flow chart of another communication method provided in an embodiment of the present application;

[0056] FIG10 is a schematic diagram of a process for applying for a certificate using an HTTP-01 challenge type applicable to an embodiment of the present application;

[0057] FIG11 is a schematic diagram of a DNS-01 challenge type certificate application process according to an embodiment of the present application;

[0058] FIG12 is a flow chart of another communication method provided in an embodiment of the present application;

[0059] FIG13 is a schematic diagram of a process for applying for a certificate using another HTTP-01 challenge type according to an embodiment of the present application;

[0060] FIG14 is a structural diagram of a communication device provided in an embodiment of the present application;

[0061] FIG15 is a schematic structural diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0062] The present application provides a communication method and apparatus. The method and apparatus are based on the same inventive concept. Since the method and apparatus solve similar problems, the implementation of the apparatus and method can refer to each other, and the repetitive parts will not be repeated.

[0063] In order to make the purpose, technical solutions and advantages of this application more clear, the application will be further described in detail below with reference to the accompanying drawings. The specific operation methods in the method embodiments can also be applied to the device embodiments or system embodiments.

[0064] Below, some technologies and terms involved in the embodiments of the present application are explained to facilitate understanding by those skilled in the art.

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

[0066] The fifth generation (5G) mobile communication network utilizes Network Function Virtualization (NFV) technology, which breaks down network element functions into distinct network functions (NFs) and deploys them in a virtualized form on the network platform, enabling rapid deployment of network functions. To simplify communication and access control between NFs, 5G networks employ a service-based architecture (SBA), enabling virtualized NFs to interact with each other. HTTPS (Hypertext Transfer Protocol Secure) is used between NFs.

[0067] Referring to Figure 1, the service-oriented architecture may include the service-oriented architecture 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. Among them, the core network devices include multiple NF network elements. For example, the NF network elements in the service-oriented network architecture include some or all of the following network elements:

[0068] Network Slice Selection Function (NSSF) network element, Authentication Server Function (AUSF) network element, Unified Data Management (UDM) network element, Network Exposure Function (NEF) network element, Network Node Repository Function (NRF) network element, Access and Mobility Management Function (AMF) network element, Session Management Function (SMF) network element, Policy Control Function (PCF) network element, Application Function (AF), Service Communication Proxy (SCP) network element. The description and function of the above network elements can be referred to the relevant 5G protocols and will not be expanded here.

[0069] Access network equipment can be radio access network (RAN) equipment. For example, a base station, an evolved NodeB (eNodeB), a transmission reception point (TRP), a next-generation NodeB (gNB) in a 5G mobile communication system, a future mobile communication system, an open access network (O-RAN or ORAN) mobile communication system, or a next-generation base station in a cloud radio access network (CRAN) mobile communication system, a base station in a future mobile communication system, or an access node in a wireless fidelity (WiFi) system. It can also be a module or unit that performs some of the functions of a base station, such as a centralized unit (CU) or a distributed unit (DU). Access network equipment can be a macro base station, a micro base station, an indoor station, a relay node, or a donor node. The access network device may also be an open access network (open RAN, O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. The access network device may also be a communication system that integrates two or more of the above systems. The embodiments of the present application do not limit the specific technology and specific device form used by the wireless access network device.

[0070] Terminal devices can be user equipment (UE), mobile stations, mobile terminals, etc. Terminal devices 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 be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, urban air vehicles (such as drones and helicopters), ships, robots, robotic arms, smart home devices, etc.

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

[0072] It can be understood that the above network elements and communication equipment are examples of an implementation method of a 5G network under a service-oriented architecture. This application does not exclude the existence of network elements or devices with the above network element functions in future communication systems with other names or other forms.

[0073] In Figure 1, Nnef, Nausf, Nudm, Nnef, Nnrt, Namf, Nsmf, Npct, Naf, and Nscp are service-oriented interfaces provided by the NSSF, AUSF, UDM, NEF, NRF, AMF, SMF, PCF, AF, and SCP, respectively, and are used to invoke corresponding service-oriented operations. N1, N2, N3, N4, and N6 are interface serial numbers, and their meanings 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 the SMF network element and the UPF network element, which can be used to transmit information between the control plane and the user plane, including controlling the issuance of forwarding rules, QoS rules, traffic statistics rules, etc. for the user plane and reporting information on the user plane.

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

[0079] It is understood that the above-mentioned network element or function can be a network element in a hardware device, a software function running on dedicated hardware, or a virtualized function instantiated on a platform (e.g., a cloud platform). As a possible implementation method, the above-mentioned network element or function can be implemented by a single device, or can be implemented by multiple devices together, or can be a functional module within a single device, which is not specifically limited in the embodiments of the present application.

[0080] In addition, each of the above NF network elements can also be referred to as NF for short. For example, the AMF network element can be referred to as AMF for short.

[0081] It can be understood that Figure 1 is an example of a 5G service-oriented network architecture. The present application can also be applied to service-oriented architectures in other 5G or future mobile networks other than 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] Authentication of NFs within a service-oriented architecture requires the issuance of public key certificates by a Certificate Authority (CA). The ACME protocol provides a scalable certificate management framework that automates the verification (or challenge verification) of certificate identifiers (including domain names and IP addresses), as well as certificate application and revocation, covering the entire certificate lifecycle. This simplifies and improves NF authentication.

[0084] As shown in Figure 2, the user installs the ACME client on the device requiring a certificate (using a NF network element as an example below), registers an ACME account, and runs the ACME server on the CA. miniCA is a lightweight certificate authority tool. The NF network element requests a 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). Communication between the NF network element and the CA can be performed using JSON messages over HTTPS.

[0085] Exemplarily, FIG3 exemplarily provides a flow chart of applying for a certificate of an ACME protocol, wherein an ACME client can be deployed in an NF network element, for example, the ACME client can be a functional module in the NF network element. An ACME server can be deployed in a CA, for example, the ACME server can be a functional module in a CA server. As shown in FIG3 , an account registration request is sent by the NF network element 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 the registration, the NF network element performs a challenge verification process (this application takes the challenge verification of a domain name as an example).

[0086] The challenge verification process includes: the NF network element applies to the CA to create a certificate order and submits a certificate identifier (including a domain name and a verification request for the domain name). The CA can respond to the verification request for the domain name and send a random token and the challenge type supported by the domain name to the NF network element. Among them, the challenge type may include HTTP-01, TLS-ALPN-01 and / or Domain Name System (DNS)-01, etc. Then, the NF network element can select the challenge type and deploy key authorization. The NF network element can also write challenge information to the device, function or service request corresponding to the challenge type based on the selected challenge type. Among them, the challenge information can be generated based on a random token. The challenge information can be generated by concatenating the random token with the account public key of the ACME client and the challenge verification method such as HTTP-01 into a string of characters and inputting it into a hash function to obtain a hash value, which is used as the challenge information.

[0087] After generating the challenge information, the NF uploads it to a storage location corresponding to the challenge type (such as a web server or DNS server) and notifies the CA that the challenge has been completed. The CA then retrieves the challenge information from this storage location and verifies it against its own stored challenge information. If the stored challenge information matches the retrieved challenge information, the CA determines that the certificate identifier has been verified, completing the challenge verification.

[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 protocol for obtaining certificates in a public key infrastructure (PKI) system and can work over HTTP or other transport protocols. Applying for a certificate for a device through the CMPv2 protocol may include the following process: establishing initial trust between the NF network element and the CA / Registration Authority (RA). The initial trust may include the initial certificate issued by the CA, the initial verification key, and the signature of the NF profile parameters by the Operation Administration and Maintenance (OAM) device. Then, the NF network element generates a certificate request, which includes the ID and initial trust of the NF network element, and sends the certificate request to the CA / RA. The CA / RA verifies the ID and initial trust of the NF network element, generates a certificate after the verification is passed, and sends the certificate to the NF network element.

[0091] However, based on communication security considerations, the device applying for a certificate may not be able to access the CA according to the ACME protocol. For example, the device applying for a certificate may be in an intranet (also known as a local area network (LAN)) that does not provide an external access address, or the device applying for a certificate cannot access the external network (also known as a wide area network (WAN)). It is also possible that the device applying for a certificate in the intranet does not allow the CA in the external network to access it, or the CA in the external network cannot access the device applying for a certificate in the intranet, resulting in the device applying for a certificate being unable to communicate directly with the CA, that is, the device applying for a certificate cannot obtain the CA's random token, cannot complete the challenge verification, and thus cannot obtain a certificate through the ACME protocol. In addition, each device applying for a certificate needs to perform a challenge verification when applying for a certificate, so each device applying for a certificate needs to be granted access to the server that stores the challenge information (such as access to the DNS server) or DNS record modification permission. Therefore, when the device applying for a certificate has a network attack behavior, it will cause the DNS server to be attacked, and thus there will be a security risk in network communication.

[0092] Furthermore, the traditional CMPv2 protocol's process for establishing initial trust (including the initial certificate, initial verification key, and NF parameter signatures) is complex, impacting the efficiency of certificate issuance. Furthermore, due to difficulties in device upgrades, devices currently using the CMPv2 protocol for certificate applications cannot use the ACME protocol.

[0093] Therefore, how to enable devices in different networks to apply for certificates, ensure the security of network communications, and improve the efficiency of certificate applications is a technical problem that needs to be solved. To this end, an embodiment of the present 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 applications in different networks and ensuring the security of network communications. For details, please refer to the process and related descriptions in Figure 4.

[0094] The execution subject of the communication method provided in the embodiment of the present application is introduced by taking the first device, the proxy device and the CA as examples. The first device in the embodiment of the present application can be any NF network element described in Figure 1 above, a terminal device, a chip, a unit or a module inside a communication device with a terminal function. The proxy device can be a proxy device, a chip, a unit or a module inside a proxy device, a communication device with a network device function, or a chip, a unit or a module inside a communication device with a network device function. CA can be understood as a server, such as an ACME server, a CMPv2 server, a CA server, etc.

[0095] In order to make the purpose, technical solutions and advantages of this application clearer, some terms involved in the embodiments of this application are first explained below.

[0096] (1) First Request

[0097] When a first device applies for a certificate according to CMPv2, it sends a first request to a proxy device. The first request is a CMPv2 protocol message, and the first request is used to instruct the proxy device to apply for a certificate for the first device according to the ACME protocol or the CMPv2 protocol. The first device is any device that needs to apply for a certificate.

[0098] (2) Certificate Order

[0099] When the proxy device applies for a certificate for the first device according to the ACME protocol, the proxy device applies to the target CA for creating a certificate order, and the certificate order is generated by the target CA.

[0100] (3) Certificate Request

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

[0102] The present 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 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 other than Figure 1, or applied to the communication architecture of 5G or future mobile networks, or any network scenario using digital certificates such as the Internet, to implement the issuance of certificates to devices that need to apply for certificates.

[0103] Figure 4 illustrates a flow chart of a communication method provided by an embodiment of the present application. The solution in Figure 4 is introduced by taking the interaction between the first device, the proxy device, and the target CA as an example. The relevant descriptions of the first device, the proxy device, and the target CA are referred to above and will not be repeated here.

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

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

[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 the first request to the proxy device. The first request is used to instruct the proxy device to apply for a certificate for the first device.

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

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

[0109] Optionally, the proxy device determines the target CA according to the first request, wherein the first request includes one or more of the following information: the type of the first device, the IP address, the identifier of the first device, and the identifier of the CA.

[0110] Optionally, the certificate management protocol supported by any CA includes the CMPv2 protocol, or the certificate management protocol supported by any CA includes the ACME protocol, or the certificate management protocols supported by any CA include the CMPv2 protocol and the ACME protocol. For example, the CA list includes CA1, CA2, and CA3, where the certificate management protocol supported by CA1 is the CMPv2 protocol, the certificate management protocol supported by CA2 is the ACME protocol, and the certificate management protocols supported by CA3 are the CMPv2 protocol and the CME protocol.

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

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

[0113] Optionally, based on the above step 420, if the proxy 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 based on the protocol with the highest priority.

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

[0115] In this process, the proxy device executes the process of applying for a certificate from the target CA on behalf of the first device. The process includes the following steps: the proxy device applies to the target CA for the creation of an ACME protocol certificate order based on the first request, and then performs a challenge verification process (refer to the challenge verification process in the ACME protocol in Figure 3 above). After obtaining the issuance authorization of the certificate order (which can be understood as the challenge verification is passed), a completion order request is generated based on the first request, and the completion order request is sent to the target CA so that the target CA sends a certificate to the proxy device. After the proxy device obtains the certificate of the first device from the target CA, it sends a first response to the first device. The first response includes the certificate of the first device, and the first response corresponds to the first request.

[0116] In one possible implementation, referring to Figure 5 , a first CMPv2 client is deployed on the first device, a first CMPv2 server and an ACME client are deployed on the proxy device, the target CA may be an ACME server, and an ACME server is deployed on the ACME server. This process uses the DNS-01 challenge as an example, with a pre-configured external DNS record that points to the address required for challenge verification (e.g., the proxy device's address). 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 proxy device according to the first CMPv2 client. The first request is a CMPv2 protocol message and can be understood as an instruction to apply for a certificate.

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

[0119] Step 503: The proxy device determines the target CA according to its own configuration information (see step 420).

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

[0121] Step 505: The proxy device sends an order completion request to the ACME server deployed on the ACME server according to 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 proxy 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 according to the first CMPv2 server. The first response includes the certificate of the first device.

[0124] In one possible implementation, referring to FIG6 , a proxy device may include a first module and a second module, wherein a first CMPv2 server is deployed on the first module, and an ACME client is deployed on the second module. The first module is used to communicate with the first device, executing steps 501, 502, 503, and 507; the second module is used to continue communicating with the target CA, executing steps 504, 505, and 506; the first module and the second module are used to forward information, such as executing the following steps between the first and second modules: Step 601: The first module sends a second request to the second module. The second request is generated by the first module based on the first request and can be understood as an instruction to apply for a certificate; Step 602: The second module sends a third response to the first module. The third response includes the certificate, and 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 can periodically send a polling request, which is used 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 proxy device has issued a certificate to the first device).

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

[0127] In this process, a proxy device executes the process of requesting a certificate from a target CA on behalf of the first device. The process includes the following steps: the proxy device sends a certificate request using the CMPv2 protocol 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. The proxy device sending the first device's certificate to the first device may include the following process: 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 a first device, a first CMPv2 server and a second CMPv2 client are deployed on a proxy device, the target CA may 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: A first device sends a first request to a first CMPv2 server on a proxy device according to a first CMPv2 client. The first request is a CMPv2 protocol message.

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

[0131] Step 703: The proxy device determines the target CA according to its own configuration information (see step 420).

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

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

[0134] Step 706: The target CA issues a certificate to the second CMPv2 client on the proxy 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 according to the first CMPv2 server, where 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, wherein a first CMPv2 server is deployed on the first module, and a second CMPv2 client is deployed on the second module. The first module is used to communicate with the first device and execute steps 701, 702, 703, and 707; the second module is used to continue communicating with the target AC and execute steps 704, 705, and 706; the first module and the second module are used to forward information, such as executing the following steps between the first module and the second module: the first module sends a third request to the second module, the third request is generated by the first module based on the first request, and the third request can be understood as an instruction to apply for a certificate. The second module sends a fourth response to the first module, the fourth response includes a certificate, and the fourth response is used by the first module to generate a second response.

[0137] Optionally, after receiving the certificate response (which can be understood as after step 702 is completed), the first device can periodically send a polling request, which is used 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 proxy 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 using 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 using an ACME client deployed on the proxy device and an ACME server deployed on the target CA, or communication between the proxy device and the target CA is achieved using a second CMPv2 client deployed on the proxy device and a second CMPv2 server deployed on the target CA. This is equivalent to the proxy device communicating with the target CA on behalf of the first device, applying for a certificate from the target CA, and obtaining a certificate after completing the certificate 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 a certificate from the target CA on behalf of the first device, or as the proxy device issuing a certificate to the first device on behalf of the target CA. In other words, a first device using the CMPv2 protocol can indirectly communicate with a target CA that provides an ACME protocol interface through the proxy device, without the first device having to communicate directly with the target CA. That is, the first device can indirectly apply for a certificate from the target CA, without having to obtain a certificate directly from the target CA. Therefore, the first device using the CMPv2 protocol can apply for a certificate according to the ACME protocol without having to update or upgrade the software or hardware of the first device using the CMPv2 protocol.

[0139] FIG9 exemplarily shows a possible flow diagram of a communication method provided by an embodiment of the present application. The scheme in FIG9 is introduced by taking the interaction between the first device, the proxy device, and the target CA as an example. Among them, the first device is deployed with an ACME client, and the target CA is deployed with an ACME server, so the first device and the target CA can communicate directly according to the ACME protocol. As shown in FIG9 , the communication method may include the following steps:

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

[0141] Optionally, the first challenge request is used to indicate a challenge type. The first challenge request may also be used to instruct the proxy device to store the challenge information in an external network. The first challenge request may also be used to instruct the proxy 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, where the certificate order request is used to apply for the creation of a certificate order for the ACME protocol, that is, the first device applies to the target CA for the creation of a certificate order for the ACME protocol, where the target CA is the CA selected by the first device. Then, the target CA generates a certificate order and feeds back a certificate order response to the first device. The certificate order response is sent by the target CA based on the certificate order request, and the certificate order response is used to indicate the supported challenge types and the 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 a token, or the token corresponding to each challenge type is different.

[0143] Step 902: The proxy 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. The first server is located in a first network.

[0144] In this process, the first network is a local area network (also called an intranet). That is, the first device is in the intranet. For the sake of network communication security, in one possible implementation, the first device is not allowed to access the external network, nor is it allowed to be accessed by the CA in 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 proxy device stores the challenge information in a second server, where the second server is located in a 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 extranet). Optionally, the second server is an HTTP server; optionally, the second server is a TLS server; optionally, the second server is a DNS server.

[0149] In this process, after receiving the second challenge request, the target CA can obtain the challenge information from the second server, and then verify the challenge information of the first device, thereby completing the challenge verification. That is, the proxy device communicates with the first device in the local area network, and the proxy device communicates with the target CA in the wide area network. Therefore, even if the first device in the local area network cannot access the target CA in the wide area network, or the target CA in the wide area network cannot access the first device in the local area network, the challenge verification between the first device and the target CA can be completed through the proxy device, and the first device in a different network from the target CA can apply for a certificate according to the ACME protocol. In addition, because the first device only needs to upload the challenge information to the first server, it does not need to access the second server in the wide area network, and it does not need to be accessed by the external network, thereby ensuring the network security of the first device. Therefore, there is no need to grant the first device permission to access the external network, or there is no need to grant the first device permission to modify resources on a specific server, thereby 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 solution, the HTTP-01 and DNS-01 challenge types are described below. For detailed descriptions, please refer to the following Examples 1 and 2.

[0151] Example 1

[0152] Pre-configure external DNS records and internal DNS records. The external DNS records are used to point the domain name to the address of the second server (such as the address of the proxy device, the HTTP server on the external network, etc.), and the internal DNS records are used to point the domain name to the address of the first server (such as the address of the first device, the HTTP server on the internal network, 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 of applying for a certificate using the HTTP-01 challenge type includes:

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

[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 feeds back a certificate order response to the first device. The certificate order response is used to indicate the acquisition of the token and the supported challenge types. The certificate order response is sent by the target CA according to the certificate order request.

[0156] In this process, the certificate order response can be understood as a certificate order, that is, the target CA feeds back the generated certificate order to the first device. The certificate order response includes the address of the authorization object, and the authorization object includes the token and the supported challenge types. Therefore, the first device can obtain the token and the supported challenge types based on the address of the authorization object. Optionally, the challenge types include HTTP-01, DNS-01, and TLS-ALPN-01, and the tokens include token 1 corresponding to HTTP-01, token 2 corresponding to DNS-01, and token 3 corresponding to TLS-01. The token can be a random number.

[0157] Step 1003: The first device selects an HTTP-01 challenge, generates challenge information key Authorization according to the token corresponding to the HTTP-01 challenge, and stores the key Authorization to the HTTP server (ie, the first server) in the intranet.

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

[0159] Step 1005: The proxy device queries the domain name according to the DNS record of the intranet, obtains the storage address of the key authorization, and obtains the key authorization according to the HTTP challenge.

[0160] Step 1006: The proxy device stores the key Authorization to the HTTP server (ie, the second server) on the external network.

[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 DNS record of the external network 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 network DNS server and obtains 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 are consistent, it means that the challenge information verification is successful, and the target CA modifies the verification status of the corresponding certificate order to passed.

[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 succeeds, the first device sends a completion order request to the target CA, where the completion order request includes the CSR.

[0166] [Corrected 21.02.2025 according to Rule 91] Step 1010: When the target CA verifies that the CSR is legitimate (for detailed description, refer to step 1203 below), it issues a certificate to the first device.

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

[0168] In Example 1, the proxy device obtains the challenge information required for verification during the ACME protocol challenge verification process from an HTTP server on the intranet, eliminating the need for the target CA to access the intranet HTTP server to obtain the challenge information, thereby ensuring the security of the first device. The proxy device stores the challenge information required for verification during the ACME protocol challenge verification process on an HTTP server on the external network that the target CA is allowed to access, eliminating the need to grant the first device permission to access the HTTP server on the external network. This prevents the first device from attacking the HTTP server and ensures the security of network communications. Furthermore, during the challenge verification process, the first device and the target CA do not need to communicate directly, allowing the first device, located on a different network from the target CA, to apply for a certificate according to the ACME protocol.

[0169] Example 2

[0170] Pre-configure the intranet DNS record, which is used to point the domain name to the address of the first server (such as the address of the first device, the HTTP server of the intranet, 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 of applying for a certificate with 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 creating an ACME protocol certificate order.

[0172] Step 1102: The target CA feeds back a certificate order response to the first device. The certificate order response is used to indicate the acquisition of the token and the supported challenge types. The certificate order response is sent by the target CA according to the certificate order request.

[0173] Step 1103: The first device selects the HTTP-01 challenge, generates challenge information key Authorization according to the token corresponding to the HTTP-01 challenge, and stores the key Authorization to the HTTP server (ie, the first server) in the intranet.

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

[0175] Step 1105: The proxy device queries the domain name according to the DNS record of the intranet, obtains the storage address of the key authorization, and obtains the key authorization according to the HTTP challenge.

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

[0177] Step 1106: The proxy device configures the key authorization into the domain name record of the DNS server of the external network (the DNS server of the external network can be understood as the 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 DNS record of the external network 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 obtain the challenge information. The target CA obtains the domain name record 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 the challenge data it has stored. If they are consistent, it means that the challenge information has been verified successfully, and the target CA changes 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 succeeds, the first device sends a complete order request to the target CA, where the complete order request includes the CSR.

[0183] Step 1110: When the target CA verifies that the CSR is legitimate (for detailed description, refer to steps 1212-1214 below), it issues a certificate to the first device.

[0184] In this process, the ACME server places the certificate in a corresponding directory on the ACME server, and the first device downloads the 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 functions and domain name and Internet Protocol (IP) address resolution functions. The proxy device configures the challenge information required for verification during the ACME protocol challenge verification process into the DNS record of the external network, eliminating the need to grant the first device permission to access the DNS server of the external network, thereby ensuring the security of the DNS server. Furthermore, during the challenge verification process, the first device and the target CA do not need to communicate directly, so the first device can apply for a certificate according to the ACME protocol even if it is on a different network from the target CA.

[0186] FIG12 exemplarily shows a possible flow diagram of a communication method provided by an embodiment of the present application. The scheme in FIG12 is introduced by taking the interaction between the first device, the proxy device, and the target CA as an example. Among them, the proxy device is deployed with an ACME client, and the target CA is deployed with an ACME server. Therefore, the first device and the target CA need to communicate indirectly through the proxy device. As shown in FIG12 , the communication method may include the following steps:

[0187] Step 1201: The target CA verifies the challenge information of the first device according to the third challenge request from the proxy device.

[0188] In this process, the first device can send a first certificate order request to the proxy device, which is then forwarded by the proxy device's 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 the first certificate order request to the target CA. The first certificate order request is used to apply for the creation of an ACME protocol certificate order. The target CA then generates a certificate order based on the first certificate order request. The certificate order includes at least one authorization object. Any authorization object (hereinafter referred to as the first authorization object for ease of description) includes multiple challenge objects (which can be understood as challenge types). Any challenge object corresponds to a token, which is used to generate challenge information.

[0189] Exemplarily, the challenge information generation process includes: the proxy device receives 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 authorization object. The proxy device then obtains a token from the first authorization object based on the address of the first authorization object. The proxy device then generates the 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, and the challenge information is denoted as ka1, where ka0 = token || "." || ACME account public key fingerprint. The proxy device then sends the first information to the first device, causing the first device to generate the 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, where ka1 = ka0 || "." || public key fingerprint of the first public key. Therefore, 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 authorization object, and the public key fingerprint of the first public key is associated with the first authorization 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, the public key fingerprint of the first public key is bound 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 request from the agent device to complete the order, where the request includes the second public key.

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

[0192] Step 1203: 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 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, a certificate is issued to the first device.

[0193] In this process, if the public key fingerprint corresponding to at least one authorization object is the public key fingerprint of the first public key, it means that the public key fingerprints corresponding to at least one authorization object are the same. Optionally, if the public key fingerprints corresponding to at least one authorization object are different, the CSR is rejected. To better illustrate the above technical solution, refer to the following Example 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 requesting a certificate using the HTTP-01 challenge type includes:

[0196] Step 1301: The first device sends a first certificate order request to the proxy device, where the first certificate order request is used to apply for creating an ACME protocol certificate order.

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

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

[0199] Step 1303: The target CA feeds back a first certificate order response to the proxy device. The first certificate order response is used to indicate the supported challenge types and corresponding tokens.

[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 authorization object. The address of the first authorization object is used by the proxy device to obtain supported challenge types and corresponding tokens from the first authorization object based on the address of the first authorization object. Optionally, the challenge types include HTTP-01, DNS-01, and TLS-ALPN-01, and the tokens include token 1 corresponding to HTTP-01, token 2 corresponding to DNS-01, and token 3 corresponding to TLS-01. The token can be a random number.

[0201] Step 1304: The proxy device selects a target challenge, and then generates first information based on its own public key fingerprint and a 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 proxy device sends a second certificate order response to the first device, where the second certificate order response 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 to an HTTP server on the external network.

[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 proxy device. The fourth challenge request is used to instruct verification of the challenge information of the first device. The fourth challenge request is used by the proxy device 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 DNS record of the external network and the storage method of the key authorization (HTTP storage).

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

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

[0210] In this process, after determining that the challenge information verification is successful (refer to the above step 1008), the target CA determines whether the challenge information includes the public key fingerprint of the first public key; if so, the public key fingerprint of the first public key is associated with the first authorization object.

[0211] Step 1310: When the challenge verification succeeds, the first device sends an order completion request to the proxy device, where the order completion request includes a CSR, and the CSR includes the second public key.

[0212] Step 1311: The proxy 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, execute 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 associated with the public key fingerprint of the first public key, the second public key in the CSR needs to be verified. If multiple authorized objects are not associated with a public key fingerprint, 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, the certificate order is determined to be invalid, that is, 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, step 1313 is executed; otherwise, the order completion request is rejected.

[0216] Step 1313: The target CA issues a certificate to the proxy 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, the completed order request includes the CSR, and the CSR includes the 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 means that the challenge information and the completed order request are both generated and sent by the first device, and the proxy device has not tampered with the information of the CSR in the completed order request. 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 public key in the CSR. When it is determined that the two public key fingerprints are consistent, it is determined that the CSR verification has passed, 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.

[0219] It is understood that, to implement the functions described in the above embodiments, the first device, proxy device, or target CA includes hardware structures and / or software modules corresponding to the respective functions. Those skilled in the art should readily appreciate that, in conjunction with the various exemplary units and method steps described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is implemented 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 the present 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, thereby also achieving 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, proxy device or target CA in the method embodiments shown in Figures 4, 9 and 12 above.

[0222] When the communication device 1400 is used to implement the function of the proxy device in the method embodiment shown in Figure 4: the processing unit 1410 is used to receive a first request from the first device through the transceiver unit 1420, where 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 based on its own configuration information; if it is determined that the target CA supports the ACME protocol, 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, 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 Figure 9: 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, 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, and 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 Figure 12: the processing unit 1410 is used to verify the challenge information of the first device based on the third challenge request from the proxy device, the challenge information includes the public key fingerprint of the first public key, the third challenge request is associated with the first authorization object in the certificate order, the public key fingerprint of the first public key is associated with the first authorization object, and the certificate order is generated by the target CA based on the first certificate order request from the proxy device; the processing unit 1410 is also used to receive a completion order request from the proxy device through the transceiver unit 1420, and the completion order request includes the second public key; the processing unit 1410 is also used to, when it is determined that the public key fingerprints corresponding to at least one authorization object in the certificate order are all the public key fingerprints 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 issue a certificate to the first device.

[0225] A more detailed description of the processing unit 1410 and the transceiver unit 1420 can be directly obtained by referring to the relevant description in the method embodiment shown in Figure 4, Figure 9 or Figure 12, and will not be repeated here.

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

[0227] When the communication device 1500 is used to implement the method shown in Figure 4, Figure 9 or Figure 12, the processor 1510 is used to implement the functions of the above-mentioned processing unit 1410, and the interface circuit 1520 is used to implement the functions of the above-mentioned transceiver unit 1420.

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

[0229] When the above-mentioned 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-mentioned method embodiment. The module receives information from other modules (such as a radio frequency module or antenna) in the first device, proxy device, or target CA; or the module sends information to other modules (such as a radio frequency module or antenna) in the first device, proxy device, or target CA. The module here can be a baseband chip, or it can be a DU or other module. The DU here can be a DU under the open radio access network (O-RAN) architecture.

[0230] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0231] The present application provides another example of a communication device, which includes at least one processor and at least one memory, the at least one processor and the at least one memory being coupled together, the at least one memory being used to store instructions. When the instructions are executed by the at least one processor, the communication device performs the method in the above-described embodiment. For example, as shown in FIG15 , a communication device 1500 includes a processor 1510 and a memory 1530. The processor 1510 and the memory 1530 are coupled together, and the memory 1530 stores instructions. When the instructions stored in the memory 1530 are executed by the processor 1510, the communication device 1500 performs the method performed by the first device, proxy device, or target CA in the above-described embodiment.

[0232] The method steps in the embodiments of the present application can be implemented in hardware or in software instructions that can be executed by a processor. The software instructions can be composed of corresponding software modules, and the software modules 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 disk, mobile hard disk, CD-ROM or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. The storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in the first device, the proxy device or the 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, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented 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 the present application are performed in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, or other programmable device. The computer program or instructions may 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 may 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 may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video disk; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or nonvolatile storage medium, or may include both volatile and nonvolatile types of storage media.

[0234] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0235] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the previous and next associated objects are in an "or" relationship; in the formula of this application, the character " / " indicates that the previous and next associated objects are in a "division" relationship. "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 numbers used in the embodiments of this application are merely for ease of description and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above-mentioned processes does not necessarily imply a specific order of execution; the order of execution of the processes should be determined by their functions and inherent logic.

Claims

1. A communication method, characterized in that: include: receiving a first request from a first device, where the first request is a CMPv2 protocol message; In response to the first request, determining a target CA according to its own configuration information; If it is determined that the target CA supports the ACME protocol, applying for a certificate for the first device according to the ACME protocol; If it is determined that the target CA supports the CMPv2 protocol, a certificate is applied for the first device according to the CMPv2 protocol.

2. The method according to claim 1, characterized in that The proxy device applies for a certificate for the first device according to the ACME protocol, including: Applying to the target CA for creating an ACME protocol certificate order according to the first request; After obtaining the issuance authorization for the certificate order, generating a completion order request according to the first request; Sending the order fulfillment request to the target CA; Obtaining a certificate for the first device from the target CA; A first response is sent to the first device, where the first response includes a 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: Sending a certificate request using the CMPv2 protocol to the target CA according to the first request; receiving a second response from the CA, the second response including a certificate of the first device; The certificate of the first device is sent to the first device.

4. The method according to any one of claims 1 to 3, characterized in that The configuration information includes a CA list and a decision policy; the CA list includes one or more of the following information: at least one CA, a certificate management protocol supported by any CA, and a priority for use of a certificate management protocol supported by any CA; The certificate management protocols supported by any one of the CAs include the CMPv2 protocol and / or the ACME protocol, and 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.

5. A communication method, characterized in that: include: receiving a first challenge request from a first device; acquiring challenge information from a first server according to the first challenge request, where the challenge information is generated by the first device and stored in the first server; The challenge information is stored in a second server, where the first server and the first device are in a first network and the second server is 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.

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: verifying challenge information of the first device based on a third challenge request from the proxy device, the challenge information including a public key fingerprint of the first public key, the third challenge request being associated with a first authorization object in a certificate order, the public key fingerprint of the first public key being associated with the first authorization object, and the certificate order being generated by the target CA based on the first certificate order request from the proxy device; receiving an order completion request from the proxy device, wherein the order completion request includes a second public key; When it is determined that the public key fingerprints corresponding to at least one authorized object in the certificate order are all the public key fingerprints 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, a certificate is issued to the first device.

8. The method according to claim 7, characterized in that The method further comprises: receiving a first certificate order request from the proxy device, where the first certificate order request is used to apply for creating an ACME protocol certificate order; According to the first certificate order request, a first certificate order response is sent to the proxy device, wherein the first certificate order response is used to indicate the acquisition of a token, wherein the token is used to determine first information with the public key fingerprint of the proxy device, and 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: The method comprises a unit or module for executing the method according to any one of claims 1 to 4, or a unit or module for executing the method according to claims 5 and 6, or a unit or module for executing the method according to claims 7 and 8.

10. A readable storage medium, characterized in that: The readable storage medium includes a program, and when the program is run on a device, the device executes the method according to any one of claims 1 to 4, or the method according to claims 5 and 6, or the method according to claims 7 and 8.

11. A chip system, characterized in that: The chip system includes at least one chip and a memory, and 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 to 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 a device, the device is caused to execute the method according to any one of claims 1 to 4, or the method according to claims 5 and 6, or the method according to claims 7 and 8.

Images