Digital certificate management method and apparatus

Through the ACME client, the digital certificate issuance mechanism is provided for 5G network functions, which solves the security risks caused by manual configuration in the 5G service architecture, realizes NF's automated certificate management and security isolation, and improves the security and management efficiency of the system.

WO2025180329A1PCT designated stage Publication Date: 2025-09-04HUAWEI TECH CO LTD
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/CN2025/078824
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-02-26
Filing Date
2025-02-24
Publication Date
2025-09-04

Smart Images

  • Figure CN2025078824_04092025_PF_FP_ABST
    Figure CN2025078824_04092025_PF_FP_ABST
Patent Text Reader

Abstract

A digital certificate management method and apparatus, which relate to the technical field of communications, and are used for providing a digital certificate issuance mechanism to an NF by means of an ACME client. The method comprises: an ACME client receiving a CSR from an NF, wherein the CSR is generated on the basis of an ACME identifier and a certificate key pair of the NF, the certificate key pair of the NF is generated or acquired by the NF, and the ACME identifier is used for an ACME server to verify that the ACME client has control over the ACME identifier; the ACME client sending the CSR to the ACME server; the ACME client receiving a download address of a digital certificate from the ACME server, wherein the digital certificate is issued to the NF by the ACME server on the basis of the CSR; and the ACME client sending the download address of the digital certificate to the NF, or sending to the NF the digital certificate acquired on the basis of the download address of the digital certificate.
Need to check novelty before this filing date? Find Prior Art

Description

Digital certificate management 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 26, 2024, with application number 202410211840.6 and invention name "A Digital Certificate Management Method and Device", the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The embodiments of the present application relate to the field of communication technology, and in particular to a digital certificate management method and device. Background Art

[0004] The core network of the fifth generation (5G) mobile communication network utilizes network function virtualization (NFV) technology. This technology breaks down the functions of network elements 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 network elements, 5G networks employ a service-based architecture (SBA), through which virtualized network elements interact.

[0005] Considering network security, the interaction between different NFs is based on the NF's digital certificate (or public key certificate).

[0006] In the network element authentication scheme currently used in service-oriented architecture networks, a certificate authority (CA) issues a digital certificate to the NF.

[0007] In current 5G networks with a service-oriented architecture, NF digital certificates are typically configured in the NF's software or hardware by the operator through operations, administration, and maintenance (OAM). This manual digital certificate management method poses security risks. Therefore, in current 5G networks with a service-oriented architecture, how to automate digital certificate management based on the Automatic Certificate Management Environment (ACME) protocol to achieve automated digital certificate management and reduce security risks is a challenge that needs to be addressed. Summary of the Invention

[0008] The embodiments of the present application provide a digital certificate management method and apparatus, which are used to provide a digital certificate issuance mechanism for NF through an ACME client.

[0009] In a first aspect, a digital certificate management method is provided, the method comprising: an automatic certificate management environment (ACME) client receiving a certificate signing request (CSR) from a NF, the CSR being generated based on an ACME identifier and a certificate key pair of the NF, the certificate key pair of the NF being generated or obtained by the NF, the ACME identifier being used by an ACME server to verify that the ACME client has control over the ACME identifier; the ACME client sending the CSR to the ACME server; the ACME client receiving a download address of a digital certificate from the ACME server, the digital certificate being issued by the ACME server for the NF based on the CSR; and the ACME client sending the download address of the digital certificate to the NF, or sending a digital certificate obtained based on the download address of the digital certificate to the NF.

[0010] In this implementation, the NF can generate a CSR based on the certificate-key pair generated or obtained by the NF and send the CSR to the ACME client, thereby applying for a digital certificate through the ACME client. This is applicable to NF certificates in the SBA architecture of 5G systems. Furthermore, this embodiment complies with the ACME protocol framework and requires minimal changes to the ACME protocol.

[0011] In a possible implementation, before the ACME client receives the CSR from the NF, the process further includes: the ACME client receiving an NF identifier from the NF; and the ACME client sending the ACME identifier to the NF, where the ACME identifier is associated with the NF identifier.

[0012] In a possible implementation, the ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

[0013] In a possible implementation, the ACME identifier is the same as the NF identifier of the NF.

[0014] In a possible implementation, the NF identifier includes one or more of the following: an instance identifier of the NF, a domain name of the NF, or an Internet Protocol IP address of the NF.

[0015] In a possible implementation, before the ACME client sends the CSR to the ACME server, the process further includes: the ACME client receiving certification information from the NF, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the OAM; and the ACME client determining that the NF identifier certified based on the certification information matches the NF identifier in the CSR.

[0016] In the above implementation, the NF sends the certification information of the NF to the ACME client, so that the ACME client can verify the certification information to determine the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the OAM, thereby improving security.

[0017] In a possible implementation, the ACME client sending the CSR to the ACME server includes: the ACME client sending the CSR and the certification information to the ACME server.

[0018] In a possible implementation, the ACME client further includes: obtaining, by the ACME client, an ACME client account of the NF, where the ACME client account is associated with an NF identifier of the NF, and the account key pair of the ACME client account is used by the ACME client to apply for a digital certificate for the NF.

[0019] In the above implementation, the ACME client can determine the corresponding ACME client account based on the NF identifier and use the account key pair of the ACME client account to apply for a digital certificate for the NF. This allows different NFs to use different ACME client accounts, thereby achieving isolation between account keys and improving security.

[0020] Optionally, the ACME client sending the CSR to the ACME server includes: the ACME client sending a first message to the ACME server, where the first message includes the CSR and a public key in an account key pair of the ACME client account or an identifier of the public key, and the first message is signed using a private key in the account key pair.

[0021] In a possible implementation, the ACME client obtains the ACME client account of the NF, including: the ACME client determining, based on the NF identifier of the NF and the correspondence between the NF identifier and the ACME client account, the ACME client; or, the ACME client selecting an ACME client account from created ACME client accounts and establishing a correspondence between the ACME client account and the NF identifier of the NF; or, the ACME client requesting the ACME server to create an ACME client account, and the ACME client establishing a correspondence between the ACME client account and the NF identifier of the NF.

[0022] In a possible implementation, the ACME client further includes: obtaining an ACME client account, where the ACME client account is an ACME client account shared by multiple NFs including the NF; and using the account key pair of the ACME client account by the ACME client to apply for digital certificates for the multiple NFs, thereby enabling multiple NFs to share one ACME client account.

[0023] In a possible implementation, before the ACME client sends the CSR to the ACME server, the process further includes: the ACME client receiving an NF token from the NF, where the NF token is used to authorize the NF to use the ACME client to request a digital certificate; and the ACME client verifying the NF token.

[0024] In the above implementation, the NF may send its NF token to the ACME client, so that the ACME client can verify the NF token to determine whether the NF is authorized to use the ACME client to request a digital certificate, thereby improving security.

[0025] In a possible implementation, the method further includes: the ACME client sending the NF token of the NF to the ACME server.

[0026] In a possible implementation, the NF token is issued to the NF by a network repository function NRF according to configuration information of the NF; wherein the configuration information of the NF includes first indication information, and the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information of the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have the capability of a Hypertext Transfer Protocol server.

[0027] In a second aspect, a digital certificate management method is provided, the method comprising: a NF sending a CSR to an ACME client, the CSR being generated based on an ACME identifier and a certificate-key pair of the NF, the certificate-key pair of the NF being generated or obtained by the NF, the ACME identifier being used by an ACME server to verify that the ACME client has control over the ACME identifier; and the NF receiving a digital certificate or a download address of the digital certificate from the ACME client, the digital certificate being issued by the ACME server based on the CSR.

[0028] In a possible implementation, before the NF sends the CSR to the ACME client, the process further includes: the NF sending the NF identifier of the NF to the ACME client; and the NF receiving the ACME identifier from the ACME client, where the ACME identifier is associated with the NF identifier.

[0029] In a possible implementation, the ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

[0030] In a possible implementation, the ACME identifier is the same as the NF identifier of the NF.

[0031] Optionally, the NF identifier includes one or more of the following: an instance identifier of the NF, a domain name of the NF, or an Internet Protocol IP address of the NF.

[0032] In a possible implementation, the method further includes: the NF sending certification information of the NF to the ACME client, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the OAM.

[0033] In a possible implementation, the method further includes: the NF sending a NF token of the NF to the ACME client, where the NF token is used to authorize the NF to use the ACME client to request a digital certificate.

[0034] In a possible implementation, the NF token is issued to the NF by a network repository function NRF according to configuration information of the NF; wherein the configuration information of the NF includes first indication information, and the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information of the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have the capability of a Hypertext Transfer Protocol server.

[0035] According to a third aspect, a digital certificate management method is provided, the method comprising: an ACME client receiving an NF identifier from a NF; the ACME client determining an ACME identifier associated with the NF identifier, the ACME identifier being used by an ACME server to verify that the ACME client has control over the ACME identifier; the ACME client sending a CSR to the ACME server, the CSR being generated based on the ACME identifier and a certificate-key pair of the NF, the certificate-key pair of the NF being obtained or generated by the ACME client; the ACME client receiving a digital certificate download address from the ACME server, the digital certificate being issued by the ACME server for the NF based on the CSR; the ACME client sending the NF certificate-key pair and the digital certificate download address to the NF, or sending the NF certificate-key pair and the digital certificate obtained according to the digital certificate download address to the NF.

[0036] In the above implementation, the ACME client can determine the ACME identifier based on the NF identifier, generate a CSR based on the ACME identifier and a certificate-key pair generated or obtained by the ACME client, and send the CSR to the ACME client, thereby applying for a digital certificate through the ACME client. This is applicable to NF certificates in the SBA architecture of a 5G system. Furthermore, the above embodiment complies with the ACME protocol framework and makes minor changes to the ACME protocol.

[0037] In a possible implementation, the ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

[0038] In a possible implementation, before the ACME client sends the CSR to the ACME server, the ACME client further includes: receiving, by the ACME client, certification information from the NF, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the Operation, Maintenance and Management (OAM); and determining, by the ACME client, that the NF identifier certified based on the certification information matches the NF identifier in the CSR.

[0039] In a possible implementation, the ACME client sending the CSR to the ACME server includes: the ACME client sending the CSR and the certification information to the ACME server.

[0040] In a possible implementation, the ACME client further includes: obtaining, by the ACME client, an ACME client account of the NF, where the ACME client account is associated with an NF identifier of the NF, and the account key pair of the ACME client account is used by the ACME client to apply for a digital certificate for the NF.

[0041] In a possible implementation, the ACME client obtains the ACME client account of the NF, including: the ACME client determining, based on the NF identifier of the NF and the correspondence between the NF identifier and the ACME client account, the ACME client; or, the ACME client selecting an ACME client account from created ACME client accounts and establishing a correspondence between the ACME client account and the NF identifier of the NF; or, the ACME client requesting the ACME server to create an ACME client account, and the ACME client establishing a correspondence between the ACME client account and the NF identifier of the NF.

[0042] In a possible implementation, the ACME client further includes: obtaining an ACME client account, where the ACME client account is an ACME client account shared by multiple NFs including the NF, and an account key pair of the ACME client account is used by the ACME client to apply for digital certificates for the multiple NFs.

[0043] In a possible implementation, before the ACME client sends the CSR to the ACME server, the process further includes: the ACME client receiving an NF token from the NF, where the NF token is used to authorize the NF to use the ACME client to request a digital certificate; and the ACME client verifying the NF token.

[0044] In a possible implementation, the method further includes: the ACME sending the NF token of the NF to the ACME server.

[0045] In a possible implementation, the NF token is issued to the NF by a network repository function NRF according to configuration information of the NF; wherein the configuration information of the NF includes first indication information, and the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information of the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have the capability of a Hypertext Transfer Protocol server.

[0046] In a fourth aspect, a digital certificate management method is provided, the method comprising: a NF sending an NF identifier to an ACME client, the NF identifier being used by the ACME client to determine an ACME identifier associated with the NF identifier, and the ACME identifier being used by an ACME server to verify that the ACME client has control over the ACME identifier; the NF receiving a certificate-key pair and a download address of a digital certificate of the NF from the ACME client, or receiving a certificate-key pair and a digital certificate obtained according to the download address of the digital certificate from the ACME client, the certificate-key pair of the NF being generated or obtained by the ACME server, the digital certificate of the NF being issued by the ACME server based on a CSR, and the CSR being generated by the ACME client based on the ACME identifier and the certificate-key pair of the NF.

[0047] In a possible implementation, the ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

[0048] In a possible implementation, the method further includes: the NF sending certification information of the NF to the ACME client, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the operation, maintenance and management (OAM).

[0049] In a possible implementation, the method further includes: the NF sending a NF token of the NF to the ACME client, where the NF token is used to authorize the NF to use the ACME client to request a digital certificate.

[0050] In a possible implementation, the NF token is issued to the NF by a network repository function NRF according to configuration information of the NF; wherein the configuration information of the NF includes first indication information, and the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information of the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have the capability of a Hypertext Transfer Protocol server.

[0051] In a fifth aspect, a digital certificate management method is provided, the method comprising: an ACME server receiving a CSR and first information from an ACME client, where the first information is certification information of an NF or an NF token of the NF; if the ACME server verifies the authenticity of the NF identifier based on the first information, or determines that the NF is configured with the NF identifier by the OAM, a download address of a digital certificate is sent to the ACME client, where the digital certificate is issued by the ACME server for the NF based on the CSR.

[0052] In a possible implementation, the certification information of the NF includes one or more of the following: signature information of the NF on the NF identifier of the NF, signature information of the OAM on the NF identifier of the NF, or a hash verification code corresponding to the NF identifier of the NF.

[0053] In a possible implementation, the NF token of the NF includes an identifier of the NF.

[0054] In a possible implementation, the NF token is issued to the NF by a network repository function NRF according to configuration information of the NF; wherein the configuration information of the NF includes first indication information, and the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information of the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have the capability of a Hypertext Transfer Protocol server.

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

[0056] In the seventh aspect, a communication device is provided, comprising: one or more processors, wherein the one or more processors are configured to execute the method as described in any one of the first aspect, or the method as described in any one of the second aspect, or the method as described in any one of the third aspect, or the method as described in any one of the fourth aspect, or the method as described in any one of the fifth aspect.

[0057] In an eighth aspect, a readable storage medium is provided, wherein the readable storage medium includes a program. When the program is run on a device, the device executes any method as described in the first aspect, or executes any method as described in the second aspect, or executes any method as described in the third aspect, or executes any method as described in the fourth aspect, or executes any method as described in the fifth aspect.

[0058] In the ninth aspect, a chip system is provided, comprising: the chip system comprises at least one chip and a memory, the at least one chip being used to read and execute a program stored in the memory to implement the method as described in any one of the first aspects, or the method as described in any one of the second aspects, or the method as described in any one of the third aspects, or the method as described in any one of the fourth aspects, or the method as described in any one of the fifth aspects.

[0059] In the tenth aspect, a computer program product is provided. When the computer program product is run on a device, the device causes the device to execute the method as described in any one of the first aspect, or the method as described in any one of the second aspect, or the method as described in any one of the third aspect, or the method as described in any one of the fourth aspect, or the method as described in any one of the fifth aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] FIG1 is a schematic diagram of a basic process of the ACME protocol provided by the related art;

[0061] FIG2 is a schematic diagram of the structure of the network architecture in an embodiment of the present application;

[0062] FIG3 is a flow chart of a digital certificate management method provided in an embodiment of the present application;

[0063] FIG4 is a flow chart of another digital certificate management method provided in an embodiment of the present application;

[0064] FIG5 is a flow chart of a method in which an NF requests an NRF to issue an NF token to it in an embodiment of the present application;

[0065] FIG6 is a flow chart of a digital certificate management method based on FIG3 in an embodiment of the present application;

[0066] FIG7 is a flow chart of another digital certificate management method based on FIG3 in an embodiment of the present application;

[0067] FIG8 is a flow chart of a digital certificate management method based on FIG4 in an embodiment of the present application;

[0068] FIG9 is a flow chart of another digital certificate management method based on FIG3 in an embodiment of the present application;

[0069] FIG10 is a flow chart of another digital certificate management method based on FIG3 in an embodiment of the present application;

[0070] FIG11 is a schematic structural diagram of a communication device provided in an embodiment of the present application;

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

[0072] The Internet Engineering Task Force (IETF), an Internet standardization organization, has developed an ACME protocol for automated management of digital certificates, for example, automatically requesting digital certificates without manual intervention.

[0073] The main entities in the ACME protocol include the ACME client and the ACME server, which is typically hosted by a CA. Communication between the ACME client and the ACME server is based on the Hypertext Transfer Protocol Secure (HTTPS). The ACME client uses the ACME protocol to request digital certificate management, such as requesting the issuance of a digital certificate. The ACME server responds to the ACME client's requests, implementing digital certificate management.

[0074] Figure 1 shows a basic process of the ACME protocol provided by related technologies. The process can be divided into three phases: Phase A: account management phase, Phase B: order and challenge phase, and Phase C: certificate issuance phase.

[0075] The account management phase includes:

[0076] Step A1: The ACME client generates an account key pair, which includes the account public key AccPubKey and the account private key AccPriKey.

[0077] Step A2: The ACME client sends an account request message to the ACME server to request the creation of an ACME client account for the ACME client. The account request message includes the account public key AccPubKey in the ACME client account key pair. The account request message is signed with the account private key AccPriKey in the ACME client account key pair to prove that the ACME client account requested for creation belongs to the ACME client.

[0078] Step A3: The ACME server creates an ACME client account, stores the ACME client's account public key AccPubKey, and sends a response message to the ACME client. The response message includes the account public key identifier (key ID or kid) corresponding to the client's account public key AccPubKey. This account public key AccPubKey is used to verify the integrity of messages from the ACME client.

[0079] After the account is created, all messages sent by the ACME client to the ACME server include the account public key identifier (key ID or kid), and the message needs to be signed with the ACME client account private key AccPriKey so that the ACME server can find the stored ACME client account public key AccPubKey based on the account public key identifier to verify the message.

[0080] The process of the order and challenge phase includes:

[0081] Step B1: The ACME client sends an order request message to the ACME server. The order request message includes one or a group of ACME identifiers. The ACME identifier includes an identifier type and a name. The ACME identifier type can be a domain name or an IP address.

[0082] Step B2: The ACME server sends a challenge message to the ACME client. This challenge message includes the order "object," which represents the challenge the ACME client must complete before the ACME server can issue a digital certificate. The challenge message also includes a challenge token, which uniquely identifies the challenge type.

[0083] Challenges can be of various types, and the ACME server needs to use the corresponding verification method to verify the challenge. For example, if the challenge type is a Hypertext Transfer Protocol (HTTP) challenge, the ACME server will perform the corresponding HTTP verification method. If the challenge type is a Domain Name System (DNS) challenge, the ACME server will perform the corresponding DNS verification method.

[0084] Step B3: The ACME client performs corresponding operations based on the challenge type required by the ACME server so that the ACME server can verify it.

[0085] For example, for an HTTP challenge, the ACME client constructs the parameter keyAuthorization, whose value is equal to challenge token||'.'||base64url(Thumbprint(AccPubKey)). Here, '||' represents string concatenation, base64url represents the string encoding method, and Thumbprint represents the use of the SHA-256 hash function to generate a digest or hash value. The ACME client provisions the parameter keyAuthorization as a resource to the HTTP server corresponding to the domain name indicated by the ACME identifier.

[0086] For another example, for a DNS challenge, the ACME client constructs the keyAuthorization parameter according to the above method, calculates the digest of the keyAuthorization parameter using the SHA-256 hash function, and converts the digest into a string using base64url encoding as a DNS resource record (resource record). It then provisions the DNS server corresponding to the domain name indicated by the ACME identifier.

[0087] Step B4: The ACME client sends a Challenge Response message to the ACME server to confirm that the ACME server can verify the challenge.

[0088] Step B5: After receiving the challenge response message, the ACME server verifies the challenge.

[0089] The ACME server can perform multiple verifications, including, for example, verifying the signature of the challenge response message against the ACME client's ACME client account public key (AccPubKey). After successful verification, further verification is performed to confirm the challenge has been completed. For example, for an HTTP challenge, the ACME server determines the HTTP server corresponding to the domain name indicated by the ACME identifier, obtains the keyAuthorization parameter from the HTTP server, and compares it with the locally constructed keyAuthorization parameter. If they are identical, the verification is considered successful.

[0090] For another example, for a DNS challenge, the ACME server calculates the digest of the locally constructed parameter keyAuthorization, then obtains the DNS resource record for the domain name from the DNS server corresponding to the domain name indicated by the ACME identifier, and compares the content of the DNS resource record (i.e., the digest corresponding to keyAuthorization) with the locally calculated digest. If they are the same, the verification is considered successful.

[0091] The certificate issuance process includes:

[0092] Step C1: After determining that the ACME server has completed verification, the ACME client sends a certificate signing request (CSR) to the ACME server. The CSR may indicate the ACME identifier.

[0093] If the ACME client cannot determine whether the ACME server has completed authentication, the ACME client can first send an authentication / authorization status request message to obtain information from the ACME server whether authentication is complete.

[0094] Step C2: The ACME server verifies the CSR, for example, by verifying whether the ACME identifier in the CSR is the same as the ACME identifier in the order request message sent by the ACME client, and whether the ACME client account is authorized.

[0095] Step C3: After the ACME server verifies the CSR successfully, it sends an Acknowledgement message to the ACME client. The Acknowledgement message includes the download address of the digital certificate, such as the uniform resource locator (URL) of the digital certificate.

[0096] The ACME server updates the order status based on the verification status and notifies the ACME client. For example, if the ACME server verifies that the ACME client has completed the required authorization and has issued a digital certificate, the ACME server updates the order status to "valid" and notifies the ACME client of the URL for the digital certificate. Alternatively, if the ACME server verifies that the required authorization has not yet been completed, the ACME server updates the order status to "pending" and notifies the ACME client.

[0097] Step C4: The ACME client sends a request message to the corresponding server according to the URL of the digital certificate, requesting to download the digital certificate, and downloads the digital certificate from the server corresponding to the URL of the certificate.

[0098] The ACME protocol places certain requirements on the capabilities of ACME clients. For example, an ACME client must be able to complete the challenge required by the ACME server to prove control of the domain. For HTTP challenges, the ACME client must also be able to serve HTTP servers. Furthermore, the ACME client must complete a series of protocol operations required by the ACME protocol, such as account creation, account application, order placement, and order challenge completion.

[0099] In 5G systems, NF types and capabilities vary. Not all NFs possess the capabilities required by ACME clients. For example, some consumer NFs lack server functionality or even certain storage capabilities, making them incapable of performing ACME client functions. Another example is some stateless NFs, which cannot integrate ACME client functionality.

[0100] Currently, in 5G systems, NF digital certificates are typically configured by operators within the NF's software or hardware through Operational Management (OAM). This manual certificate management approach increases the risk of security incidents and attacks. Therefore, in the current service-oriented architecture of 5G networks, the NF digital certificate management mechanism needs to be improved.

[0101] To this end, embodiments of the present application provide a digital certificate management method and apparatus that can provide a digital certificate issuance mechanism for NFs using an ACME client. In particular, digital certificate management can be implemented using an ACME client or an NF equipped with an ACME client for NFs that lack ACME client capabilities or have not integrated an ACME client. The method and apparatus are based on the same inventive concept. Since the method and apparatus solve similar problems, their implementations can be referenced in conjunction with each other, and any repetitions will not be repeated.

[0102] The present application is described in detail below with reference to the accompanying drawings.

[0103] The embodiments of the present application can be applied to mobile communication network architecture, for example, 5G architecture. Figure 2 is a structural diagram of the network architecture 100 of an embodiment of the present application. Take the 5G network architecture based on the service-based architecture SBA in the non-roaming scenario defined in the 3GPP standardization process as an example. As shown in Figure 2, the network architecture 100 may include three parts, namely, a terminal device part, a data network (DN) part, and an operator's public land mobile network (PLMN) part. The functions of the network elements of each part are briefly described below.

[0104] The terminal equipment part may include UE 110, which may also be referred to as user equipment (UE). The UE 110 in the embodiment of the present application is a device with wireless transceiver functions, which can communicate with one or more core network (CN) devices via an access network device (or may also be referred to as an access device) in a (radio) access network (R)AN) 120. UE 110 may also be referred to as an access terminal, terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, user agent or user device, etc. UE 110 may be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it may also be deployed on water (such as ships, etc.); it may also be deployed in the air (such as airplanes, balloons and satellites, etc.). UE 110 may be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a smart phone, a mobile phone, a wireless local loop (WLL) station, a personal digital assistant (PDA), etc. Alternatively, UE 110 may be a handheld device with wireless communication capabilities, a computing device, or other device connected to a wireless modem, an in-vehicle device, a wearable device, an unmanned aerial vehicle (UAV), or a terminal in the Internet of Things (IoT), the Internet of Vehicles (IoV), any terminal in a 5G network or future networks, a relay user equipment (UE), or a terminal in a future evolution network, etc. The relay user equipment may be, for example, a 5G residential gateway (RG). For example, UE 110 can be a virtual reality (VR) terminal, an augmented reality (AR) terminal, a wireless terminal in industrial control, a wireless terminal in self-driving, a wireless terminal in remote medical, a wireless terminal in smart grid, a wireless terminal in transportation safety, a wireless terminal in smart city, a wireless terminal in smart home, etc. The terminal device here refers to a 3GPP terminal. The embodiments of the present application do not limit the type or category of the terminal device. For ease of explanation, this application will be described below using UE as an example to refer to a terminal device.

[0105] The operator PLMN part may include, but is not limited to, the (R)AN 120 and the CN part.

[0106] (R)AN 120 can be considered a sub-network of the operator network and is the implementation system between the service nodes in the operator network and UE 110. To access the operator network, UE 110 first passes through (R)AN 120 and then connects to the service nodes of the operator network through (R)AN 120. The access network device (RAN device) in the embodiment of the present application is a device that provides wireless communication functions for UE 110, and can also be called a network device. RAN devices include but are not limited to: the next generation node base station (gNB) in the 5G system, the evolved node B (eNB) in the long term evolution (LTE), the radio network controller (RNC), the node B (NB), the base station controller (BSC), the base transceiver station (BTS), the home base station (for example, home evolved node B, or home node B, HNB), the base band unit (BBU), the transmission point (TRP), the transmitting point (TP), the small base station device (pico), the mobile switching center, or the network device in the future network. In systems using different wireless access technologies, the name of the device with the access network device function may be different. For the convenience of description, in all embodiments of the present application, the above-mentioned device that provides wireless communication functions for UE 110 is collectively referred to as access network device or simply referred to as RAN or AN. It should be understood that the embodiments of the present application do not limit the specific type of access network equipment.

[0107] The CN part may include but is not limited to the following network functions (NF): user plane function (UPF) 130, network exposure function (NEF) 131, network function repository function (NRF) 132, policy control function (PCF) 133, unified data management function (UDM) 134, unified data repository function (UDR) 135, application function (AF) 136, authentication server function (AUSF) 137, access and mobility management function (AMF) 138, and session management function (SMF) 139.

[0108] DN 140, also known as a packet data network (PDN), is typically a network located outside of a carrier network, such as a third-party network. Of course, in some implementations, a DN may also be deployed by a carrier, meaning that the DN is part of a PLMN. The present embodiment does not restrict whether a DN is a PLMN. A carrier network PLMN can access multiple DNs 140, and a variety of services can be deployed on DN 140, providing data and / or voice services to terminal devices 110. For example, DN 140 may be the private network of a smart factory, where sensors installed in the workshop may be terminal devices 110. A control server for the sensors is deployed within DN 140, and the control server can provide services to the sensors. The sensors can communicate with the control server, obtain instructions from the control server, and transmit collected sensor data to the control server according to the instructions. For another example, DN 140 may be a company's internal office network, where employees' mobile phones or computers may be terminal devices 110, allowing them to access information and data resources on the company's internal office network. Terminal device 110 can establish a connection with the operator network through an interface provided by the operator network (e.g., N1) and use data and / or voice services provided by the operator network. Terminal device 110 can also access DN 140 through the operator network and use operator services deployed on DN 140 and / or services provided by third parties.

[0109] The following is a brief description of the NF functions included in CN.

[0110] UPF 130 is a gateway provided by the operator, serving as the gateway for communication between the operator's network and DN 140. UPF 130 includes user-plane-related functions such as packet routing and transmission, packet detection, service usage reporting, Quality of Service (QoS) processing, lawful interception, uplink packet detection, and downlink packet storage.

[0111] NEF 131 is a control plane function provided by the operator. It mainly enables third parties to use the services provided by the network, supports the network to open its capabilities, event and data analysis, provide PLMN security configuration information from external applications, and convert interactive information within and outside the PLMN.

[0112] NRF 132 is a control plane function provided by the operator and is used to maintain real-time information about network functions and services in the network. For example, it supports network service discovery, maintains the NF profile of NF instances and the services they support, supports service discovery of service communication proxies (SCPs), maintains the SCP profile of SCP instances, sends notifications about newly registered, deregistered, and updated NFs and SCPs, and maintains the health status of NFs and SCPs.

[0113] PCF 133 is a control plane function provided by the operator. It supports a unified policy framework to govern network behavior, provide policy rules to other control functions, and provide contract information related to policy decisions.

[0114] UDM 134 is a control plane function provided by the operator and is responsible for storing information such as the subscriber permanent identifier (SUPI), the generic public subscription identifier (GPSI), and credentials of subscribers in the operator network. The SUPI is first encrypted during transmission, and the encrypted SUPI is called a hidden subscriber subscription identifier (SUCI). This information stored in UDM 134 can be used for authentication and authorization of UE 110 to access the operator network. Subscribers of the above-mentioned operator network can specifically be users who use services provided by the operator network, such as users who use China Telecom's subscriber identity module (SIM) card or users who use China Mobile's SIM card. The credentials of the above-mentioned subscribers can be a small file storing long-term keys stored in the SIM card or information related to SIM card encryption, which is used for authentication and / or authorization. It should be noted that the permanent identifier, credentials, security context, authentication data (cookie), and token are equivalent to information related to verification / authentication and authorization. For the sake of convenience in description in the embodiments of this application, no distinction or limitation is made.

[0115] The UDR 135 is a control plane function provided by the operator, which provides functions for storing and retrieving subscription data for the UDM, storing and retrieving policy data for the PCF, and storing and retrieving user NF group ID information.

[0116] AF 136 is a control plane function provided by the operator. It interacts with other NFs in the PLMN to provide services such as providing roaming UEs with information about the network they wish to visit, guiding data flow routing, and providing access to NEF 131. The AF can be deployed by the operator within the PLMN or outside the operator's network.

[0117] AUSF 137 is a control plane function provided by the operator and is typically used for level 1 authentication, that is, authentication between UE 110 (subscriber) and the operator's network. After receiving an authentication request from a subscriber, AUSF 137 can authenticate and / or authorize the subscriber using authentication information and / or authorization information stored in UDM 134, or generate authentication and / or authorization information for the subscriber via UDM 134. AUSF 137 can also provide the subscriber with feedback on the authentication and / or authorization information.

[0118] AMF 138 is a control plane network function provided by the operator network, responsible for access control and mobility management of UE 110 accessing the operator network, including, for example, mobility state management, allocation of user temporary identities, authentication and authorization of users, and other functions.

[0119] SMF 139 is a control plane network function provided by the operator network and is responsible for managing protocol data unit (PDU) sessions for UE 110. A PDU session is a channel for transmitting PDUs, and terminal devices use PDU sessions to transfer PDUs to and from DN 140. SMF 139 is responsible for establishing, maintaining, and deleting PDU sessions. SMF 139 includes session management (such as session establishment, modification, and release, including tunnel maintenance between UPF 130 and (R)AN 120), selection and control of UPF 130, service and session continuity (SSC) mode selection, roaming, and other session-related functions.

[0120] It is understood that the above network elements or functions can be physical entities in hardware devices, software instances running on dedicated hardware, or virtualized functions instantiated on a shared platform (e.g., a cloud platform). Simply put, an NF can be implemented by hardware or software.

[0121] In Figure 2, Nnef, Nnrf, Npcf, Nudm, Nudr, Naf, Nausf, Namf, Nsmf, N1, N2, N3, N4, and N6 are interface serial numbers. For example, the meaning of the above interface serial numbers can be found in the meaning defined in the 3GPP standard protocol. The embodiment of the present application does not limit the meaning of the above interface serial numbers. The interface name between the various network functions in Figure 2 is only an example. In a specific implementation, the interface name of the system architecture may also be other names, which is not limited by the present application. In addition, the name of the message (or signaling) transmitted between the above network elements is only an example and does not constitute any limitation on the function of the message itself.

[0122] For ease of explanation, in the embodiments of this application, network functions (e.g., NEF 131 ... SMF 139) are collectively referred to as NFs. That is, the NFs described later in the embodiments of this application can be replaced with any network function. Furthermore, FIG2 schematically illustrates only some network functions, and the NFs described later are not limited to those shown in FIG2 .

[0123] It should be understood that the network architecture 100 applied to the embodiment of the present application is only a network architecture described from the perspective of a service-oriented architecture, and the network architecture applicable to the embodiment of the present application is not limited thereto. Any network architecture that can realize the functions of the above-mentioned network elements is applicable to the embodiment of the present application. In this service-based architecture, the PLMN can combine some or all network functions in an orderly manner as needed according to the requirements of specific scenarios, realize the customization of network capabilities and services, and thus deploy dedicated networks for different services, that is, realize 5G network slicing. Network slicing technology can enable operators to respond to customer needs more flexibly and quickly, and support flexible allocation of network resources.

[0124] The NF involved in the embodiments of the present application can be a network processing function used by 3GPP or defined by 3GPP (such as NEF 131 to SMF 139 in Figure 2, and can also be extended to UE 110, (R)AN 120, UPF 130, DN 140), or a network element that implements the network function, which can be a network element on dedicated hardware (such as a base station), a software instance running on dedicated hardware (such as instantiating multiple NRF instances on hardware dedicated to NRF) or as a virtualized function instantiated by a platform provider (such as instantiating NRF and other functional network elements on a cloud infrastructure). The embodiments of the present application take the use of digital certificates to establish connections between network elements in the core network as an example, but with future technological developments, it may be extended to between access network devices and access network devices, between access network devices and core networks, between access network devices and user devices, between user devices and user devices, and between user devices and network elements, and this application is not limited thereto. User devices or user terminals include mobile phones, smart terminals, vehicle-mounted terminals, vehicle-mounted devices, wearable devices, multimedia devices, streaming media devices, etc.; because it may involve a secure startup process that decouples the control plane and the user plane, the access network equipment can be base stations, relay stations, access points, vehicle-mounted devices, and network-side devices, etc.

[0125] The CA (certificate authority) in the present application example may be a digital certificate certification authority, which is responsible for managing the entire life cycle of the public key, including issuing certificates, defining certificate validity periods, and revoking certificates. It should be noted that the CA may also include a registration authority (RA), which is used to obtain and authenticate the user's identity and then submit a certificate issuance request to the CA. Among them, the RA may be a function integrated into the CA or deployed separately, which is not limited in this application. It should be further noted that the ACME server can be deployed separately from the CA or integrated together, which is not limited in this application. For the sake of convenience of description, no distinction is made between the ACME server and the CA in the following description, but this should not be considered a limitation.

[0126] Referring to Figure 3, a flowchart illustrating a digital certificate management method provided in an embodiment of the present application is provided. The NF in this method may be an NF that does not have ACME client capabilities, or an NF that has not integrated an ACME client. The ACME client in this method may be a network element or network function that has ACME client capabilities, for example, an NF that has ACME client capabilities. In this method, the NF generates a client certificate-key pair, generates a CSR based on the certificate-key pair and an ACME identifier, and sends the CSR to the ACME client, so that the ACME client requests a digital certificate for the NF.

[0127] Optionally, a secure channel may be pre-established between the NF and the ACME client to exchange information via the secure channel. The secure channel may be, for example, a transport layer security (TLS) channel, which is not limited in this application.

[0128] As shown in Figure 3, the process may include the following steps:

[0129] Step 301: The NF sends a CSR to the ACME client. The CSR is generated based on the ACME identifier and the NF's certificate key pair.

[0130] The certificate key pair of the NF includes a certificate public key and a certificate private key. The certificate key pair of the NF is generated or obtained by the NF.

[0131] The ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier. The specific implementation of the ACME server verifying that the ACME client has control over the ACME identifier can be referred to in the subsequent step 303.

[0132] In one possible implementation, before step 301, the NF may send the NF identifier to the ACME client. The ACME client determines the ACME identifier corresponding to (or associated with) the NF identifier based on the NF identifier, and sends the ACME identifier to the NF, so that the NF generates a CSR based on the ACME identifier.

[0133] Optionally, the ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the ACME client identifier. Optionally, the ACME client identifier may include, for example, the client's domain name and / or IP address, etc., which is not limited in this application.

[0134] In another possible implementation, the ACME identifier is the same as the NF identifier of the NF. That is, the NF may generate an ACME identifier that is the same as the NF identifier of the NF and generate a CSR based on the ACME identifier.

[0135] Optionally, the NF identifier may be: NF instance ID, NF domain name, NF IP address, NF fully qualified domain name (FQDN), etc., which is not limited in this application.

[0136] The CSR generation method can refer to the IETF protocol RFC2986, namely PKCS#10 (Public Key Cryptography Standard #10): Certification Request Syntax Specification. Generally, the CSR generation method is to digitally sign the certificate's subject name, certificate public key, and other optional attributes, such as the subject alias SubjectAltName (or AltSN), using the certificate private key. The method for the NF to generate a CSR may include: the NF generates or obtains the public key and private key corresponding to the certificate public key, uses the private key to sign, and the signed content includes the public key and may also include an ACME identifier and / or an NF identifier (which can be used as the subject name or subject alias, respectively, without limitation).

[0137] Step 302: After receiving the CSR from the NF, the ACME client sends the CSR to the ACME server.

[0138] In one possible implementation, before the ACME client sends the CSR to the ACME server, an order and challenge process is performed between the ACME client and the ACME server. After the ACME server successfully verifies the ACME client's challenge, the ACME client sends the CSR to the ACME server. The order and challenge process between the ACME client and the ACME server can refer to the ACME protocol, for example, see the relevant content in Figure 2 , and is not limited in this application. Successful verification of the ACME client's challenge by the ACME server indicates that the ACME client has control over the ACME identifier.

[0139] It should be noted that the embodiments of the present application do not limit the type of ACME challenge. For example, the ACME challenge can be a DNS challenge or HTTP challenge in the ACME protocol, or other types of challenges, such as Transport Layer Security and Application Layer Protocol Negotiation (TLS ALPN, where ALPN is the abbreviation of application-layer protocol negotiation, i.e., application layer protocol negotiation), or other types of challenges in the future.

[0140] In one possible implementation, the ACME client sends a finalize request message to the ACME server. The message includes the CSR and the public key AccPubKey of the ACME client's ACME client account key pair or an identifier of the public key. The message is signed using the account private key AccPriKey of the ACME client account key pair.

[0141] The ACME client generates an ACME client account key pair and sends the public key AccPubKey from the ACME client account key pair to the ACME server, so that the ACME server can use the public key AccPubKey to verify the signature from the ACME client. (Messages sent by the ACME client to the ACME server are signed using the private key AccPriKey from the ACME client account key pair.) The specific implementation process can refer to the account management phase of the ACME protocol shown in Figure 2, and this application does not limit it.

[0142] Step 303: After receiving the CSR, the ACME server verifies the CSR and issues a digital certificate to the NF based on the CSR if the verification is successful.

[0143] In one possible implementation, the ACME server first verifies the signature of the message from the ACME client using the public key AccPubKey in the ACME client's ACME client account key pair, and then verifies the CSR in the message after the verification is successful.

[0144] In one possible implementation, the method for ACME to verify the CSR may include: the ACME server verifying whether an ACME identifier in the CSR is identical to an ACME identifier in an order request message sent by the ACME client, and whether the ACME client account of the ACME client is authorized, etc. If the ACME identifier in the CSR is identical to the ACME identifier in the order request message sent by the ACME client, and the ACME client account of the ACME client is authorized, then the CSR verification is determined to be successful. Furthermore, if the ACME identifier in the CSR is identical to the ACME identifier in the order request message sent by the ACME client after challenge verification, then it can be understood that the ACME client has control over the ACME identifier.

[0145] Optionally, the ACME server can also update the order status based on the verification status and notify the ACME client of the order status. For example, if the ACME server verifies that the ACME client has completed the required authorization and has issued a digital certificate, the ACME server updates the order status to "valid" and notifies the ACME client of the URL of the digital certificate. For another example, if the ACME server verifies that the required authorization has not yet been completed, the ACME server updates the order status to "pending" and notifies the ACME client of the status.

[0146] The specific implementation process of this step can refer to the ACME protocol, for example, refer to the relevant content in Figure 2, and this application is not limited thereto.

[0147] In one possible implementation, the NF's digital certificate may include the following information:

[0148] - Certificate serial number SN (serial number);

[0149] -The name of the certificate subject (such as NF) (such as subject name, SubjectName);

[0150] -SubjectAltName;

[0151] - Subject public key information (including the certificate subject's public key, public key cryptographic algorithm identifier, related key parameters, etc.);

[0152] - Certificate validity period;

[0153] -Certificate issuer (e.g., CA);

[0154] -Signature (CA digitally signs the certificate using its private key), etc.

[0155] Optionally, the certificate subject information (eg, including the certificate subject name, or including the certificate subject alias) may be the same as the ACME identifier and / or the NF identifier (eg, the NF instance identifier and / or the NF domain name).

[0156] Optionally, the ACME identifier can be the same as the ACME client identifier (e.g., the client's domain name or IP address), or the same as the NF identifier (e.g., the NF instance identifier, the NF domain name, or the NF IP address). If the ACME identifier is the same as the NF instance identifier, then the NF instance identifier may appear twice or only once in the digital certificate. For example, the certificate subject name or subject alias is the same as the NF instance identifier, or the certificate subject name and subject alias are both the same as the NF instance identifier.

[0157] Step 304: The ACME server sends the download address of the digital certificate to the ACME client.

[0158] After the ACME server verifies the CSR successfully, it can send an Acknowledgement message to the ACME client. The Acknowledgement message includes the download address of the digital certificate, such as the URL of the digital certificate.

[0159] Step 305: The ACME client sends the download address of the digital certificate to the NF, or sends the digital certificate obtained according to the download address of the digital certificate to the NF.

[0160] In one possible implementation, the ACME client may send the download address of the digital certificate from the ACME server to the NF, so that the NF may send a request message to the corresponding server according to the download address of the digital certificate to request downloading of the digital certificate and obtain the digital certificate from the server.

[0161] In another possible implementation, the ACME client may obtain the digital certificate from the corresponding server according to the download address of the digital certificate from the ACME server, and send the digital certificate to the NF.

[0162] In another possible implementation, the ACME server may send the digital certificate issued for the NF to the ACME client, and the ACME client sends the digital certificate to the NF.

[0163] In the above embodiment, the NF can generate a CSR and send it to the ACME client, which then applies for a digital certificate through the ACME client. This is applicable to NF certificates in the 5G system SBA architecture. Furthermore, the above embodiment complies with the ACME protocol framework and requires minimal changes to the ACME protocol.

[0164] See Figure 4, which is a flowchart illustrating another digital certificate management method provided in an embodiment of the present application. The NF in this method may be an NF without ACME client capabilities or an NF without an integrated ACME client. The ACME client in this method may be a network element or network function with ACME client capabilities, for example, an NF with ACME client capabilities. In this method, the ACME client generates a client certificate-key pair, generates a CSR based on the certificate-key pair and the ACME identifier, and requests a digital certificate for the NF.

[0165] Optionally, a secure channel may be pre-established between the NF and the ACME client to exchange information via the secure channel. The secure channel may be, for example, a TLS channel, which is not limited in this application.

[0166] As shown in Figure 4, the process may include the following steps:

[0167] Step 401: The NF sends its NF identifier to the ACME client.

[0168] Optionally, the NF identifier may be: NF instance ID, NF domain name, NF IP address, NF FQDN, etc., which is not limited in this application.

[0169] Step 402: The ACME client determines the ACME identifier associated with the NF identifier. The ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier.

[0170] The ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier. The specific implementation of the ACME server verifying that the ACME client has control over the ACME identifier can be referred to in the subsequent step 405.

[0171] In a possible implementation, the ACME client determines, based on the NF identifier, an ACME identifier corresponding to (or associated with) the NF identifier.

[0172] Optionally, the ACME identifier is the same as the NF identifier of the NF, or the ACME identifier is the same as the client identifier of the ACME client.

[0173] Step 403: Generate a CSR based on the ACME identifier and the NF's certificate key pair generated or obtained by the ACME client.

[0174] The NF's certificate key pair includes a certificate public key and a certificate private key. The NF's certificate key pair is generated or obtained by the ACME client.

[0175] The CSR generation method can refer to IETF protocol RFC2986, which is not limited in this application.

[0176] Step 404: The ACME client sends the CSR to the ACME server.

[0177] For the specific implementation of this step, please refer to step 302 in Figure 3.

[0178] Step 405: After receiving the CSR, the ACME server verifies the CSR and issues a digital certificate to the NF based on the CSR if the verification is successful.

[0179] For the specific implementation of this step, please refer to step 303 in Figure 3.

[0180] In one possible implementation, the NF's digital certificate may include the following information:

[0181] - Certificate serial number SN (serial number);

[0182] -The name of the certificate subject (such as NF) (such as subject name, SubjectName);

[0183] -SubjectAltName;

[0184] - Subject public key information (including the certificate subject's public key, public key cryptographic algorithm identifier, related key parameters, etc.);

[0185] - Certificate validity period;

[0186] -Certificate issuer (e.g., CA);

[0187] -Signature (CA digitally signs the certificate using its private key), etc.

[0188] Optionally, the certificate subject information (eg, including the certificate subject name, or including the certificate subject alias) may be the same as the ACME identifier and / or the NF identifier (eg, the NF instance identifier and / or the NF domain name).

[0189] Optionally, the ACME identifier can be the same as the ACME client identifier (e.g., the client's domain name or client IP address), or the same as the NF identifier (e.g., the NF instance identifier, the NF domain name, or the NF IP address). If the ACME identifier is the same as the NF instance identifier, then the NF instance identifier may appear twice or only once in the digital certificate. For example, the certificate subject name or subject alias is the same as the NF instance identifier, or the certificate subject name and subject alias are both the same as the NF instance identifier.

[0190] Step 406: The ACME server sends the digital certificate download address to the ACME client.

[0191] For the specific implementation of this step, please refer to step 304 in Figure 3.

[0192] Step 407: The ACME client sends the download address of the digital certificate to the NF, or sends the digital certificate obtained according to the download address of the digital certificate to the NF.

[0193] For the specific implementation of this step, please refer to step 305 in Figure 3.

[0194] In the above embodiment, the ACME client can determine the ACME identifier based on the NF identifier of the NF, generate a CSR, and send the CSR to the ACME server. This allows the NF to apply for a digital certificate through the ACME client, which is applicable to NF certificates in the SBA architecture of 5G systems. Furthermore, the above embodiment complies with the ACME protocol framework and makes minor changes to the ACME protocol.

[0195] To improve security, based on the methods shown in FIG. 3 or FIG. 4 , in some embodiments of the present application, an NF identifier and certification information may be configured on the NF (or obtained by the NF). The NF may provide this certification information to the ACME client, allowing the ACME client to verify the certification information to verify the authenticity of the NF identifier of the NF or to verify that the NF has been configured with the NF identifier by the OAM. This certification information may also be referred to as initial trust information.

[0196] The certification information can be option 1, option 2, or option 3 below:

[0197] Option 1: The OAM or CA issues a NF certificate to the NF. This certificate includes the NF identifier and the NF's public key. This certificate can be used to prove that the NF's name and public key have been verified by the OAM or CA.

[0198] Option 2: OAM signature, that is, OAM signature on the NF identifier of the NF;

[0199] Option 3: Shared symmetric key, which is a symmetric key shared between NF and ACME client.

[0200] It should be understood that the embodiment of the present application does not limit the form of the certification information. For example, in a 5G system, the NF profile includes the NF instance ID and NF FQDN (or IP address). The NF profile can be configured with the above-mentioned initial trust to prove that the NF profile belongs to the NF.

[0201] In one possible implementation, the NF sends attestation information to the ACME client. The ACME client verifies the attestation information before sending the CSR from the NF to the ACME server. For example, the ACME client determines whether the NF identifier authenticated by the attestation information matches the NF identifier in the CSR from the NF. If so, the ACME client sends the CSR to the ACME server.

[0202] For the proof information in options 1, 2, and 3 above, the ACME client can verify the proof information using the following methods:

[0203] For Option 1: The ACME client uses the configured OAM public key to verify the NF certificate issued by the OAM, or the ACME client uses the configured CA root certificate to verify the NF certificate issued by the CA. If the verification succeeds, it is determined that the NF identifier and the corresponding NF public key included in the certificate have been verified by the OAM or CA. Next, the ACME client uses the verified NF public key to verify the message sent by the NF (the NF signed the message or part of the message using the corresponding private key). If the verification succeeds, it is determined that the NF identifier certified based on the certification information is authentic / valid.

[0204] For option 2: the ACME client verifies the OAM signature using the configured OAM public key; if the verification succeeds, the NF identifier certified based on the certification information is determined to be authentic / valid.

[0205] For option 3: the ACME client verifies the shared symmetric key; the ACME client receives the message authentication code sent by the NF using the shared symmetric key and the NF identifier, and compares it with the message authentication code generated by the ACME client using the shared symmetric key and the NF identifier using the same method. If they are the same, the NF identifier proved by the proof information is determined to be authentic / valid.

[0206] In one possible implementation, the NF may send the CSR and the certification information to the ACME client via a single message. Of course, the NF may also send the CSR to the ACME client via a single message and the certification information to the ACME client via another message, which is not a limitation of this application.

[0207] In one possible implementation, the ACME client may also send the NF's certification information to the ACME server. Before verifying the CSR, the ACME server first verifies the certification information to verify the authenticity of the NF identifier of the NF or to verify that the NF has been configured with the NF identifier by the OAM. For details on how the ACME server verifies the certification information, refer to the details on how the ACME client verifies the certification information. If the ACME server verifies the certification information successfully, it verifies the CSR.

[0208] Optionally, the ACME client may send the CSR and the certification information of the NF to the ACME server in one message. For example, the ACME client sends a finalize request message to the ACME server, which includes the CSR and certification information from the NF.

[0209] To improve security, in some embodiments of the present application, the NRF can issue (or configure) an NF token for the NF upon the NF's request. The NF token is used to authorize the NF to request a digital certificate using the ACME client. The NF can send its NF token to the ACME client. The ACME client will provide digital certificate management services for the NF only after validating the NF token, such as sending a CSR to the ACME server.

[0210] In a possible implementation, the method in which the NF requests the NRF to issue an NF token for it may be as shown in FIG5 .

[0211] The NF has been registered in the NRF, that is, the NF profile has been stored in the NRF. This application does not limit the NF registration method, and the method described in TS33.501 can also be referred to.

[0212] Optionally, in an embodiment of the present application, the configuration file of the NF includes first indication information. The first indication information may be used to indicate one or more of the following: that the NF allows the use of an ACME client to apply for and manage its certificates, or information about the ACME client authorized for use by the NF (e.g., the address or identifier of the ACME client), or that the NF is a stateless NF, or that the NF does not have the ability to integrate an ACME client, or that the NF does not have HTTP server capabilities. The first indication information may also be referred to as shared ACME client indication information.

[0213] Step 501: The NF sends an NF token request message to the NRF, which includes the NF identifier of the NF.

[0214] Optionally, the message may further include second indication information, where the second indication information indicates obtaining authorization to access the ACME client, where the authorization allows the NF to apply for or manage the NF's certificate through the client.

[0215] Step 502: The NRF verifies the legitimacy of the NF. After the verification is successful, the NRF generates a NF token.

[0216] The embodiments of this application do not limit the specific implementation of how the NRF verifies the legitimacy of the NF. One possible implementation is that the NF sets initial trust information that the NRF can verify, and the NRF can verify the initial trust information. For specific examples, please refer to 3GPP standard TS33.501.

[0217] Optionally, the claim or authorization scope of the NF token includes an NF identifier and / or third indication information. The third indication information indicates that the NF is allowed to access a certain ACME client or an NF of the ACME client type. That is, the NF can use the NF token as an authorization credential to access the ACME client or the NF of the ACME client type.

[0218] Optionally, the NF Token is digitally signed by the NRF.

[0219] Step 503: The NRF sends an NF token response message to the NF, which includes the NF token of the NF.

[0220] In one possible implementation, the ACME client is configured with the public key of the NRF, or the ACME client can obtain the public key of the NRF. The method for the ACME client to verify the NF token includes: the ACME client uses the public key to verify the authenticity of the NRF signature in the NF token. If the verification is successful, the ACME client confirms that the NF identifier in the NF token and the NF identifier included in the message 4 are authentic or valid.

[0221] In one possible implementation, the ACME client can also send the NF token of the NF to the ACME server. The ACME server can first verify the NF token before verifying the CSR, and then verify the CSR after successful verification. For details on how the ACME server verifies the NF token, see the ACME client's NF token verification method.

[0222] Based on the method shown in FIG. 3 or FIG. 4 , in a possible implementation, the ACME client is a dedicated client of the NF, that is, the ACME client only provides digital certificate management services for the NF.

[0223] Based on the method shown in FIG. 3 or FIG. 4 , in a possible implementation, the ACME client is a client shared by multiple NFs, that is, the ACME client can provide digital certificate management services for multiple NFs.

[0224] In a possible implementation, when multiple NFs share an ACME client, the multiple NFs may share an ACME client account, and the ACME client may apply for digital certificates for different NFs by using different ACME identifiers.

[0225] Exemplarily, when applying for a digital certificate for a NF, the ACME client obtains an ACME client account before sending a CSR to the ACME server. This ACME client account is shared by multiple NFs, including the NF itself. The ACME client uses the account key pair of this ACME client account to apply for digital certificates for these multiple NFs. That is, all messages exchanged between the ACME client and the ACME server for these multiple NFs are signed using the private key in this account key pair, and the messages include the public key in this account key pair or an identifier for this public key. Optionally, the ACME identifiers corresponding to different NFs are different.

[0226] In a possible implementation, when multiple NFs share an ACME client, different NFs in the multiple NFs use different ACME client accounts.

[0227] For example, when an ACME client applies for a digital certificate for a NF, before sending a CSR to the ACME server, the ACME client obtains the NF's ACME client account. This ACME client account is associated with the NF identifier of the NF, ensuring that different NFs use different ACME client accounts. The ACME client uses the account key pair of the ACME client account to apply for a digital certificate for the NF. That is, for this NF, all messages exchanged between the ACME client and the ACME server are signed using the private key in the account key pair, and all messages include the public key in the account key pair or the identifier of the public key.

[0228] Optionally, the method for the ACME client to obtain the NF's ACME client account may include one of the following methods:

[0229] Method 1: The ACME client determines the ACME client account corresponding to the NF identifier of the NF based on the NF identifier of the NF and the correspondence between the NF identifier and the ACME client account.

[0230] A specific implementation method for the ACME client to determine the ACME client account based on the NF identifier is to establish a mapping relationship (or correspondence relationship) between the NF identifier and the ACME client account, use the NF identifier to find the corresponding ACME client account, and then use the found ACME client account to apply for a digital certificate.

[0231] Method 2: The ACME client selects an ACME client account from the created ACME client accounts and establishes a correspondence between the ACME client account and the NF ID of the NF.

[0232] One specific implementation method for the ACME client to determine the ACME client account based on the NF identifier is to establish a mapping relationship (or correspondence relationship) between the NF identifier and the ACME client account, and then use the NF identifier to search for the corresponding ACME client account. If no corresponding ACME client account is found, an ACME client account is selected from the created ACME client accounts and a mapping relationship is established between the ACME client account and the NF identifier.

[0233] Method 3: The ACME client requests the ACME server to create an ACME client account, and the ACME client establishes a correspondence between the ACME client account and the NF identifier of the NF.

[0234] One specific implementation method for the ACME client to determine the ACME client account based on the NF identifier is to establish a mapping relationship (or correspondence) between the NF identifier and the ACME client account, and then search for the corresponding ACME client account using the NF identifier. If no corresponding ACME client account is found, the ACME client requests the ACME server to create a new ACME client account and establishes a mapping relationship between the new ACME client account and the NF identifier. The specific implementation method for the ACME client requesting the ACME server to create an ACME client account can be found in the ACME protocol, for example, see the relevant content in Figure 2.

[0235] The establishment of a mapping relationship between the ACME client account and the NF identifier also means the establishment of a mapping relationship between the NF identifier and the key pair of the ACME client account (including the client public key and private key).

[0236] In the ACME process, different ACME client accounts use different ACME client account key pairs. Therefore, different NFs use different ACME client accounts. This ensures that different NFs use different ACME client account key pairs for the ACME process, thereby achieving isolation between account keys.

[0237] In one possible implementation, when security isolation is required between all NFs, there is a one-to-one correspondence between NFs and ACME client accounts, that is, one NF corresponds to one ACME client account.

[0238] In another possible implementation, when some NFs require security isolation from other NFs while others do not, the NFs that require security isolation from other NFs have a one-to-one correspondence with ACME client accounts, i.e., each NF corresponds to one ACME client account. The remaining NFs can share one or more ACME client accounts, i.e., multiple NFs can correspond to one ACME client account. Alternatively, ACME can determine whether a NF requires a one-to-one account or a shared account with other NFs based on the indication information carried in the message sent by the NF to the ACME client (e.g., step 401). This indication information can also be included in a token issued by the NRF to the NF.

[0239] Several examples with application scenarios are given below based on the above embodiments.

[0240] Example 1: See Figure 6. The method shown in Figure 6 is a specific example of the method shown in Figure 3. The NF obtains or configures the NF identifier and certification information. A secure channel can also be pre-established between the NF and the ACME client.

[0241] It should be noted that, among the steps below, steps marked with A, B, and C can be implemented with reference to the ACME protocol. Other steps not marked with A, B, or C (e.g., steps 601 and 602) are understood to be non-ACME protocol steps. In other words, for the ACME protocol, these steps are out-of-band information transmission steps or are not ACME protocol operations. For example, step 601 below belongs to the 5G system (not the ACME protocol), and step 602 is an internal operation of the ACME client and is not part of the ACME protocol (it may be a 5G system operation).

[0242] As shown in Figure 6, the process may include the following steps:

[0243] Step 601: The NF sends a certificate request message to the ACME client, including the NF identifier.

[0244] Optionally, the certificate request message may also include certification information of the NF.

[0245] Steps A1-A3 (Account Management Process): For specific implementation methods, please refer to the ACME protocol.

[0246] It is understood that steps A1-A3 can also be performed before step 601, that is, there is no order requirement between these steps and step 601. In addition, if the ACME client has already established an ACME client account for the NF service, then steps A1-A3 are not necessarily performed and are optional steps.

[0247] Step 602: The ACME client determines the ACME identifier, which is used to complete the ACME challenge in the ACME process.

[0248] Optionally, the ACME client may determine the ACME identifier based on the NF identifier received in step 601. The ACME identifier and the NF identifier may be different. For example, the NF identifier may be an NF instance identifier, an NF FQDN, or an NF IP address, while the ACME identifier may be a client identifier of the client, such as a domain name or an IP address of the client.

[0249] The NF FQDN and the client's domain name are both domain names, but they can be different or have different ownership relationships. The NF FQDN is the domain name configured by the network for the NF, while the client's domain name is the domain name owned by the client. Similarly, the NF's IP address can be different from the client's IP address.

[0250] A specific implementation method for the ACME client to determine the ACME identifier based on the NF identifier is to establish a mapping relationship between the NF identifier and the ACME identifier, use the NF identifier to search for the corresponding ACME identifier, and then use the found ACME identifier to execute the ACME protocol (e.g., execute the order request and challenge process in step B). For example, in the following step B1, the ACME identifier is used as the identifier in the order request. If no corresponding ACME identifier is found, a new ACME identifier or an existing ACME identifier is used, and a mapping relationship is established between the ACME identifier and the NF identifier, and the ACME identifier is used as the ACME identifier in the order request in step B1.

[0251] Steps B1-B4 (order and challenge process): For specific implementation methods, please refer to the ACME protocol.

[0252] The ACME identifier in the order and challenge process is the ACME identifier determined by the ACME client in step 602. For example, the ACME client includes the ACME identifier determined in step 602 in the order request message sent to the ACME server in step B1.

[0253] Step 603: After the ACME client completes the challenge for the ACME identifier in step 602 as required by the ACME server, the ACME client sends a certificate response message to the NF, where the certificate response message includes the ACME identifier.

[0254] Optionally, the certificate response message may also include an NF identifier, or a mapping relationship between an ACME identifier and an NF identifier. The NF may perform subsequent steps based on the ACME identifier, such as generating a CSR request.

[0255] Optionally, step 603 may also be performed in advance, for example, before any step after the ACME identifier is determined after step 602, which is not limited in this application.

[0256] Step 604: The NF generates or obtains a certificate-key pair (the public key and private key corresponding to the digital certificate), and generates a CSR based on the certificate-key pair and the ACME identifier received in step 603.

[0257] Optionally, the CSR may also include an NF identifier.

[0258] For the specific implementation of generating CSR, please refer to IETF protocol RFC2986, namely PKCS#10 (Public Key Cryptography Standard #10): Certification Request Syntax Specification.

[0259] Optionally, the certificate key pair generated or obtained in step 604 may also be executed in advance, for example, before any step before step 604, which is not limited in this application.

[0260] Step 605: The NF sends a certificate request message to the ACME client, where the certificate request message includes the CSR generated in step 604.

[0261] Optionally, the certificate request message may further include an NF identifier and / or an ACME identifier.

[0262] Optionally, the message may also include certification information of the NF to prove that the NF actually owns or is configured with the NF identifier.

[0263] Steps C1-C4: The ACME protocol certificate issuance process. This process includes two implementation methods.

[0264] Implementation method 1: For details, please refer to the ACME protocol. With this implementation method, the ACME server can be unaware of NF information and NF certification information, thereby preventing the spread of NF information.

[0265] Implementation Method 2: Based on the ACME protocol, in step C1, the message sent by the ACME client includes the NF's certification information; in step C2, the ACME server further verifies the NF's certification information. The ACME server can compare the NF identifier, protected by the certification information signature, with the NF identifier in the CSR and the NF identifier received in step C1 (if the NF identifier was included in the message in step C1). Verification is passed only if they match, confirming that the NF possesses or has been configured by the OAM with the NF identifier. Steps C3 and C4 can be performed according to the ACME protocol.

[0266] Step 606: The ACME client sends a certificate response message to the NF. The certificate response message includes the digital certificate obtained by the ACME client in step C4, or includes a download address of the digital certificate.

[0267] When the ACME client receives the URL of the digital certificate from the ACME server, it can directly send the URL to the NF, which then downloads it. This implementation method can prevent the ACME client from downloading the NF's digital certificate, thereby increasing security.

[0268] It should be noted that the terms involved in FIG6 and the specific implementation of each step can refer to the above embodiment and will not be repeated here.

[0269] Example 1: See Figure 7. The method shown in Figure 7 is another specific example of the method shown in Figure 3. The NF obtains or configures the NF identifier and certification information. A secure channel can also be pre-established between the NF and the ACME client. The difference from the process shown in Figure 6 is that the ACME identifier used by the ACME protocol comes from the NF, allowing the NF to directly generate a CSR without interacting with the ACME client.

[0270] It should be noted that, in the following steps, steps marked with A, B, and C can be implemented with reference to the ACME protocol. Other steps not marked with A, B, or C (e.g., steps 701 and 702) can be understood as not being ACME protocol steps. In other words, for the ACME protocol, these steps are out-of-band information transmission steps or are not ACME protocol operations. For example, step 701 below is an internal operation of the ACME client and is not part of the ACME protocol (it may be part of the 5G system operation), while step 702 is a step of the 5G system (not the ACME protocol).

[0271] As shown in Figure 7, the process may include the following steps:

[0272] Step 701: NF generates or obtains a certificate key pair and generates a CSR based on the key pair and ACME identifier.

[0273] Optionally, the CSR includes an ACME identifier.

[0274] For the specific implementation of this step, please refer to step 604 in Figure 6.

[0275] Step 702: The NF sends a certificate request message to the ACME client, where the certificate request message includes the CSR and the ACME identifier.

[0276] The ACME client completes the ACME challenge with the ACME identifier sent by the NF, rather than performing an ACME challenge based on the ACME client's own identifier.

[0277] Optionally, the ACME identifier may be the same as the NF identifier, for example, the ACME identifier may be the same as the NF FQDN.

[0278] Optionally, the certificate request message may also include an NF identifier of the NF.

[0279] Optionally, the certificate request message may also include certification information of the NF.

[0280] Steps A1-A3 (Account Management Process): For specific implementation, please refer to the ACME protocol. For details, please refer to steps A1-A3 in Figure 6.

[0281] Steps B1-B4 (order and challenge process): For specific implementation methods, please refer to the ACME protocol.

[0282] The ACME identifier included in the order request message sent by the client to the ACME server in step B1 is the same as the ACME identifier sent by the NF in step 702. The ACME protocol and challenge are based on this ACME identifier, not the ACME client's own identifier (e.g., the client domain name).

[0283] Steps C1-C4: ACME protocol certificate issuance process. This process includes two implementation methods. For details, please refer to steps C1-C4 in Figure 6.

[0284] Step 703: The ACME client sends a certificate response message to the NF. The certificate response message includes the digital certificate obtained by the ACME client in step C4, or includes the download address of the digital certificate.

[0285] It should be noted that the terms involved in FIG. 7 and the specific implementation of each step can refer to the aforementioned embodiment and will not be repeated here.

[0286] Example 3: See Figure 8. The method shown in Figure 8 is a specific example of the method shown in Figure 4. The NF obtains or configures the NF identifier and certification information. A secure channel can also be pre-established between the NF and the ACME client. The difference from the process shown in Figure 6 is that the ACME client generates a certificate-key pair, creates a CSR, and sends the certificate-key pair to the NF. The ACME identifier used by the ACME protocol can come from the NF or be determined by the ACME client.

[0287] It should be noted that, among the steps below, steps marked with A, B, and C can be implemented with reference to the ACME protocol. Other steps not marked with A, B, or C (e.g., steps 801 and 802) are understood to be non-ACME protocol steps. In other words, for the ACME protocol, these steps are out-of-band information transmission steps or are not ACME protocol operations. For example, step 801 below belongs to the 5G system (not the ACME protocol), and step 802 is an internal operation of the ACME client and is not part of the ACME protocol (it may be a 5G system operation).

[0288] As shown in FIG8 , the process may include the following steps:

[0289] Step 801: The NF sends a certificate request message to the ACME client, including the NF identifier.

[0290] Optionally, the certificate request message may also include certification information of the NF.

[0291] Steps A1-A3 (Account Management Process): For specific implementation methods, please refer to the ACME protocol.

[0292] Step 802: The ACME client determines the ACME identifier.

[0293] A possible implementation manner may refer to step 602 in FIG. 6 .

[0294] Optionally, the ACME identifier may be the same as the client identifier (eg, the client's domain name or IP address), or the ACME identifier may be the same as the NF identifier.

[0295] Steps B1-B4 (order and challenge process): For specific implementation methods, please refer to the ACME protocol.

[0296] Steps C1-C4: ACME protocol certificate issuance process. This process includes two implementation methods. For details, please refer to steps C1-C4 in Figure 6.

[0297] In step C0, the ACME client generates a CSR based on the certificate key pair and ACME identifier generated by the ACME client. Optionally, the CSR may include the NF identifier. For details on how to generate the public and private key pairs and the CSR, see step 604 in Figure 6 or step 701 in Figure 7.

[0298] Step 803: The ACME client sends a certificate response message to the NF. The certificate response message includes the digital certificate obtained by the ACME client in step C4, or includes the download address of the digital certificate. The certificate response message also includes the certificate-key pair generated by the ACME client.

[0299] It should be noted that the terms involved in FIG8 and the specific implementation of each step can refer to the aforementioned embodiment and will not be repeated here.

[0300] Example 4: See Figure 9. The method shown in Figure 9 is a specific example of the method shown in Figures 3 or 6. The NF obtains or configures its NF identifier and certification information. A secure channel can also be pre-established between the NF and the ACME client. This process differs from the process shown in Figure 6 in that it uses different ACME client accounts for different NFs, achieving key isolation for multiple NFs within the same ACME client account.

[0301] It should be noted that, among the following steps, steps marked with A, B, and C can be implemented with reference to the ACME protocol. Other steps not marked with A, B, or C (e.g., steps 901 and 902) can be understood as not being ACME protocol steps. In other words, for the ACME protocol, these steps are out-of-band information transmission steps or are not ACME protocol operations. For example, step 901 below belongs to the 5G system (not the ACME protocol), and step 902 is an internal operation of the ACME client and is not part of the ACME protocol (it may be a 5G system operation).

[0302] As shown in FIG9 , the process may include the following steps:

[0303] Step 901: The NF sends a certificate request message to the ACME client, including the NF identifier.

[0304] Optionally, the certificate request message may also include certification information of the NF.

[0305] Step 902: The ACME client determines the ACME client account according to the NF identifier.

[0306] One specific implementation method for the ACME client to determine the ACME client account based on the NF identifier is to establish a mapping relationship between the NF identifier and the ACME client account, use the NF identifier to find the corresponding ACME client account, and then use the found ACME client account to perform the account management process. If the corresponding ACME client account cannot be found, a new ACME client account is used or an existing ACME client account is used and a mapping relationship is established between the ACME client account and the NF identifier.

[0307] It should be noted that in the ACME process, different ACME client accounts use different public and private key pairs. Therefore, different NFs use different CME client accounts, which can ensure that different NFs use different client account key pairs for ACME processes, thereby achieving isolation between client account keys.

[0308] It should also be noted that establishing a mapping relationship between an ACME client account and an NF identifier also means establishing a mapping relationship between the NF identifier and the public-private key pair of the ACME client account.

[0309] Steps A1-A3 (Account Management Process): For specific implementation methods, please refer to the ACME protocol.

[0310] During the process of determining the ACME client account corresponding to the NF identifier using the above method, if a new ACME client account needs to be created, step A1 of the account creation process is executed. If an existing ACME client account is selected, the ACME client confirms whether a mapping relationship already exists between the NF identifier and the ACME client account. If so, steps A1-A3 can be skipped and step B1 can be executed directly. If a mapping relationship between the NF identifier and the ACME client account has not yet been established, a mapping relationship between the ACME client account and the NF identifier is established.

[0311] In all subsequent steps, the ACME client executes the ACME protocol flow for the NF identifier using the keys of the ACME client account associated with the NF identifier. For example, when the ACME client sends a message to the ACME server, it signs the message using the private key of the ACME client account associated with the NF identifier and sends the public key or public key identifier of the client account to the ACME server.

[0312] Step 903: The ACME client determines the ACME identifier according to the NF identifier. The ACME identifier is used to complete the ACME challenge in the ACME process.

[0313] Steps B1-B4 (order and challenge process): For specific implementation methods, please refer to the ACME protocol.

[0314] Step 904: After the ACME client completes the challenge for the ACME identifier in step 602 as required by the ACME server, the ACME client sends a certificate response message to the NF, where the certificate response message includes the ACME identifier.

[0315] Step 905: The NF generates or obtains a certificate-key pair (the public key and private key corresponding to the digital certificate), and generates a CSR based on the certificate-key pair and the ACME identifier received in step 603.

[0316] Step 906: The NF sends a certificate request message to the ACME client. The certificate request message includes the CSR and may optionally include the NF identifier, the ACME identifier, or the NF's certification information.

[0317] Steps C1-C4: The ACME protocol certificate issuance process. This process includes two implementation methods.

[0318] Step 907: The ACME client sends a certificate response message to the NF. The certificate response message includes the digital certificate obtained by the ACME client in step C4, or includes the download address of the digital certificate.

[0319] For the above-mentioned step 903 and the process after step 903, please refer to the relevant content in Figure 6.

[0320] It should be noted that the terms involved in FIG9 and the specific implementation of each step can refer to the aforementioned embodiment and will not be repeated here.

[0321] The process shown in FIG9 adds a step to FIG6 in which the ACME client account is determined based on the NF identifier, thereby achieving key isolation for different NFs within the same ACME client account. It is understood that the process shown in FIG7 or FIG8 can also be supplemented with a step to determine the ACME client account based on the NF identifier to achieve key isolation for multiple NFs within the same ACME client account.

[0322] For example 5, see Figure 10. The method shown in Figure 10 is a specific example of the method shown in Figures 3 or 6. A secure channel can also be pre-established between the NF and the ACME client. Compared to the process shown in Figure 9, the NF in Figure 10 obtains authorization before using the ACME client account. This authorization can also be used by the ACME server to verify the authenticity or validity of the NF.

[0323] It should be noted that, among the steps below, steps marked with A, B, and C can be implemented with reference to the ACME protocol. Other steps not marked with A, B, or C (e.g., steps 1002 and 1003) are understood to be non-ACME protocol steps. In other words, for the ACME protocol, these steps are out-of-band information transmission steps or are not ACME protocol operations. For example, step 1002 below belongs to the 5G system (not the ACME protocol), and step 1003 is an internal operation of the ACME client and is not part of the ACME protocol (it may be a 5G system operation).

[0324] As shown in Figure 10, the process may include the following steps:

[0325] Step 1001: NF obtains NF token from NRF.

[0326] For the specific implementation of this step, please refer to the process shown in Figure 5.

[0327] Step 1002: The NF sends a certificate request message to the ACME client, including the NF identifier and the NF token.

[0328] Optionally, the certificate request message may also include certification information of the NF.

[0329] Step 1003: ACME client verifies NF token.

[0330] In one possible implementation, the ACME client preconfigures or obtains the NRF's public key and uses it to verify the authenticity of the NRF signature in the NF token. After verification, the ACME client confirms that the NF identifier in the NF token is identical to the NF identifier included in the certificate request message from the NF in step 1002. If they are identical, verification succeeds; otherwise, verification fails.

[0331] Step 1004: If the verification is successful, the ACME client determines the ACME client account according to the NF identifier.

[0332] For the specific implementation of this step, please refer to step 902 in Figure 9.

[0333] Steps A1-A3 (Account Management Process): For specific implementation methods, please refer to the ACME protocol.

[0334] Step 1005: The ACME client determines the ACME identifier according to the NF identifier. The ACME identifier is used to complete the ACME challenge in the ACME process.

[0335] For the specific implementation of this step, please refer to step 903 in Figure 9.

[0336] Steps B1-B4 (order and challenge process): For specific implementation methods, please refer to the ACME protocol.

[0337] Step 1006: After the ACME client completes the challenge for the ACME identifier in step 602 as required by the ACME server, the ACME client sends a certificate response message to the NF, where the certificate response message includes the ACME identifier.

[0338] For the specific implementation of this step, please refer to step 904 in Figure 9.

[0339] Step 1007: The NF generates or obtains a certificate-key pair (the public key and private key corresponding to the digital certificate), and generates a CSR based on the certificate-key pair and the ACME identifier received in step 603.

[0340] For the specific implementation of this step, please refer to step 905 in Figure 9.

[0341] Step 1008: The NF sends a certificate request message to the ACME client. The certificate request message includes the CSR and may optionally include the NF identifier, the ACME identifier, or the NF's certification information.

[0342] For the specific implementation of this step, please refer to step 906 in Figure 9.

[0343] Steps C1-C4: The ACME protocol certificate issuance process. This process includes two implementation methods.

[0344] Implementation method 1: For details, please refer to the ACME protocol. With this implementation method, the ACME server can be unaware of NF information and NF certification information, thereby preventing the spread of NF information.

[0345] Implementation Method 2: Based on the ACME protocol, in step C1, the message sent by the ACME client includes the NF token of the NF. In step C2, the ACME server also verifies the NF token of the NF. The implementation method for verifying the NF token by the ACME server can refer to the implementation method for verifying the NF token by the ACME client. Steps C3 and C4 can be performed according to the ACME protocol.

[0346] Step 1009: The ACME client sends a certificate response message to the NF. The certificate response message includes the digital certificate obtained by the ACME client in step C4, or includes a download address of the digital certificate.

[0347] For the specific implementation of this step, please refer to step 907 in Figure 9.

[0348] It should be noted that the terms involved in FIG9 and the specific implementation of each step can refer to the aforementioned embodiment and will not be repeated here.

[0349] The process shown in FIG10 adds an NF authorization step and a step for determining the ACME client account based on the NF identifier to FIG6 , thereby isolating the keys of different NFs in the same ACME client account and improving security. It is understood that the process shown in FIG7 or FIG8 can also be supplemented with an NF authorization step and a step for determining the ACME client account based on the NF identifier to isolate the keys of multiple NFs in the same ACME client account and improve security.

[0350] It is understood that in order to implement the functions in the above embodiments, the network devices and terminal devices include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily appreciate that, in combination with the units and method steps of each example described in the embodiments disclosed in this application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or in a manner driven by computer software depends on the specific application scenario and design constraints of the technical solution.

[0351] Figures 11 and 12 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 NF or ACME client or ACME server in the above-mentioned method embodiments, thereby also achieving the beneficial effects of the above-mentioned method embodiments. In the embodiments of the present application, the communication device can be the above-mentioned device or a module (such as a chip) in the above-mentioned device.

[0352] As shown in Figure 11, the communication device 1100 includes a processing unit 1110 and a transceiver unit 1120. The communication device 1100 is used to implement the functions of the NF or ACME client or ACME server in the above embodiments.

[0353] When the communication device 1100 is used to implement the functions of the ACME client in the method embodiment shown in FIG. 3 , the transceiver unit 1120 is used to receive a CSR from a NF, where the CSR is generated based on an ACME identifier and a certificate-key pair of the NF, where the certificate-key pair of the NF is generated or obtained by the NF, and the ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier. The processing unit 1110 is used to send the CSR to the ACME server via the transceiver unit 1120. The transceiver unit 1120 is further used to receive a download address of a digital certificate from the ACME server, where the digital certificate is issued by the ACME server for the NF based on the CSR. The processing unit 1110 is further used to send the download address of the digital certificate to the NF via the transceiver unit 1120, or to send the digital certificate obtained based on the download address of the digital certificate to the NF.

[0354] When the communication device 1100 is used to implement the NF function in the method embodiment shown in FIG. 3 , the processing unit 1110 sends a CSR to the ACME client via the transceiver unit 1120. The CSR is generated based on the ACME identifier and the NF's certificate-key pair, where the NF's certificate-key pair is generated or obtained by the NF. The ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier. The transceiver unit 1120 is configured to receive a digital certificate or a download address for the digital certificate from the ACME client. The digital certificate is issued by the ACME server based on the CSR.

[0355] When the communication device 1100 is used to implement the functions of the ACME client in the method embodiment described in FIG. 4 , the transceiver unit 1120 is configured to receive an NF identifier from a NF; the processing unit 1110 is configured to determine an ACME identifier associated with the NF identifier, where the ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier; the processing unit 1110 is configured to send a certificate signing request (CSR) to the ACME server via the transceiver unit 1120, where the CSR is generated based on the ACME identifier and a certificate-key pair of the NF, where the certificate-key pair of the NF is obtained or generated by the ACME client; the transceiver unit 1120 is further configured to receive a download address of a digital certificate from the ACME server, where the digital certificate is issued by the ACME server to the NF based on the CSR; and the processing unit 1110 is further configured to send the certificate-key pair of the NF and the download address of the digital certificate to the NF via the transceiver unit 1120, or send the certificate-key pair of the NF and a digital certificate obtained based on the download address of the digital certificate to the NF.

[0356] When the communication device 1100 is used to implement the NF function in the method embodiment shown in FIG. 4 : the processing unit 1110 sends the NF identifier to the ACME client via the transceiver unit 1120. The NF identifier is used by the ACME client to determine the ACME identifier associated with the NF identifier, and the ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier. The transceiver unit 1120 is used to receive the NF's certificate-key pair and the download address of the digital certificate from the ACME client, or receive the NF's certificate-key pair and the digital certificate obtained according to the download address of the digital certificate from the ACME client. The NF's certificate-key pair is generated or obtained by the ACME server. The NF's digital certificate is issued by the ACME server based on a certificate signing request (CSR). The CSR is generated by the ACME client based on the ACME identifier and the NF's certificate-key pair.

[0357] When the communication device 1100 is used to implement the function of the ACME server in the method embodiment shown in Figure 3 or Figure 4 above: the transceiver unit 1120 is used to receive a certificate issuance request CSR and first information from the ACME client, where the first information is the certification information of the NF or the NF token of the NF; the processing unit 1110 is used to send a download address of a digital certificate to the ACME client via the transceiver unit 1110 if the authenticity of the NF identifier is verified based on the first information, or if it is determined that the NF has been configured with the NF identifier by the OAM. The digital certificate is issued by the ACME server for the NF based on the CSR.

[0358] A more detailed description of the processing unit 1110 and the transceiver unit 1120 can be directly obtained by referring to the relevant description in the method embodiment shown in the above drawings, and is not repeated here.

[0359] As shown in Figure 12, communication device 1200 includes a processor 1210 and an interface circuit 1220. Processor 1210 and interface circuit 1220 are coupled to each other. It is understood that interface circuit 1220 may be a transceiver or an input / output interface. Optionally, communication device 1200 may further include a memory 1230 for storing instructions executed by processor 1210, input data required by processor 1210 to execute instructions, or data generated by processor 1210 after executing instructions.

[0360] When the communication device 1200 is used to implement the method shown in the above figures, the processor 1210 is used to implement the functions of the above processing unit 1110, and the interface circuit 1220 is used to implement the functions of the above transceiver unit 1120.

[0361] When the communication device is a chip implemented in the device, the chip implements the functions of the corresponding device in the method embodiment. The chip receives information from other modules in the device (such as a radio frequency module or antenna), where the information is sent to the device by other modules; or the chip sends information to other modules in the device (such as a radio frequency module or antenna).

[0362] When the above-mentioned communication device is a module applied to a mobile node, the module implements the functions of the mobile node in the above-mentioned method embodiment. The module receives information from other modules (such as a radio frequency module or antenna), and the information is sent by the terminal to the device; or the module sends information to other modules in the device (such as a radio frequency module or antenna), and the information is sent by the device to the terminal. The module here can be the baseband chip of the device, 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.

[0363] 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.

[0364] This 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. Taking a communication device including a processor and a memory as an example, as shown in FIG12 , a communication device 1200 includes a processor 1210 and a memory 1230. The processor 1210 and the memory 1230 are coupled together, and the memory 1230 stores instructions. When the instructions stored in the memory 1230 are executed by the processor 1210, the communication device 1200 performs the method performed by the terminal device or network device in the above-described embodiment.

[0365] It should be understood that the processor 1210 and the memory 1230 may also be integrated together, such as in one chip.

[0366] 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 a network device or a terminal. The processor and storage medium can also exist in a network device or a terminal as discrete components.

[0367] 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.

[0368] 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.

[0369] 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.

[0370] 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 digital certificate management method, characterized in that: include: An automated certificate management environment (ACME) client receives a certificate issuance request (CSR) from a network function (NF), wherein the CSR is generated based on an ACME identifier and a certificate key pair of the NF, wherein the certificate key pair of the NF is generated or obtained by the NF, and the ACME identifier is used by an ACME server to verify that the ACME client has control over the ACME identifier. The ACME client sends the CSR to the ACME server; The ACME client receives a download address of a digital certificate from the ACME server, where the digital certificate is issued by the ACME server to the NF based on the CSR; The ACME client sends the download address of the digital certificate to the NF, or sends the digital certificate obtained according to the download address of the digital certificate to the NF.

2. The method according to claim 1, wherein Before the ACME client receives the CSR from the NF, it also includes: The ACME client receives the NF identifier from the NF; The ACME client sends the ACME identifier to the NF, and the ACME identifier is associated with the NF identifier.

3. The method according to claim 2, wherein The ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

4. The method according to claim 1, wherein The ACME identifier is the same as the NF identifier of the NF.

5. The method according to any one of claims 2 to 4, characterized in that The NF identifier includes one or more of the following: an instance identifier of the NF, a domain name of the NF, or an Internet Protocol IP address of the NF.

6. The method according to any one of claims 1 to 5, wherein: Before the ACME client sends the CSR to the ACME server, the method further includes: The ACME client receives certification information from the NF, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the Operation, Maintenance and Management (OAM); The ACME client determines that the NF identifier certified based on the certification information matches the NF identifier in the CSR.

7. The method according to claim 6, wherein The ACME client sends the CSR to the ACME server, including: The ACME client sends the CSR and the certification information to the ACME server.

8. The method according to any one of claims 1 to 7, wherein: Also includes: The ACME client obtains an ACME client account of the NF, where the ACME client account is associated with an NF identifier of the NF. The account key pair of the ACME client account is used by the ACME client to apply for a digital certificate for the NF.

9. The method according to claim 8, wherein The ACME client sends the CSR to the ACME server, including: The ACME client sends a first message to the ACME server, where the first message includes the CSR and a public key in an account key pair of the ACME client account or an identifier of the public key, and the first message is signed using a private key in the account key pair.

10. The method according to any one of claims 8 to 9, characterized in that The ACME client obtains the ACME client account of the NF, including: The ACME client determines, based on the NF identifier of the NF and the correspondence between the NF identifier and the ACME client account, an ACME client account corresponding to the NF identifier of the NF; or The ACME client selects an ACME client account from the created ACME client accounts and establishes a correspondence between the ACME client account and the NF identifier of the NF; or, The ACME client requests the ACME server to create an ACME client account, and the ACME client establishes a correspondence between the ACME client account and the NF identifier of the NF.

11. The method according to any one of claims 1 to 7, wherein: Also includes: The ACME client obtains an ACME client account, where the ACME client account is shared by multiple NFs including the NF. The account key pair of the ACME client account is used by the ACME client to apply for digital certificates for the multiple NFs.

12. The method according to any one of claims 1 to 11, wherein: Before the ACME client sends the CSR to the ACME server, the method further includes: The ACME client receives an NF token from the NF, where the NF token is used to authorize the NF to use the ACME client to request a digital certificate; The ACME client verifies the NF token.

13. The method according to claim 12, wherein: Also includes: The ACME client sends the NF token of the NF to the ACME server.

14. The method according to any one of claims 12 to 13, wherein: The NF token is issued to the NF by the Network Repository Function (NRF) according to the configuration information of the NF; The configuration information of the NF includes first indication information, where the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information about the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have a Hypertext Transfer Protocol server capability.

15. A digital certificate management method, characterized in that: include: The network function NF sends a certificate signing request (CSR) to the automated certificate management environment (ACME) client. The CSR is generated based on an ACME identifier and a certificate key pair of the NF, where the certificate key pair of the NF is generated or obtained by the NF. The ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier. The NF receives the digital certificate or the download address of the digital certificate from the ACME client, where the digital certificate is issued by the ACME server according to the CSR.

16. The method according to claim 15, wherein Before the NF sends the CSR to the ACME client, the following steps are also performed: The NF sends an NF identifier of the NF to the ACME client; The NF receives the ACME identifier from the ACME client, and the ACME identifier is associated with the NF identifier.

17. The method according to claim 16, wherein The ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

18. The method according to claim 15, wherein The ACME identifier is the same as the NF identifier of the NF.

19. The method according to any one of claims 16 to 18, wherein: The NF identifier includes one or more of the following: an instance identifier of the NF, a domain name of the NF, or an Internet Protocol IP address of the NF.

20. The method according to any one of claims 15 to 19, wherein: Also includes: The NF sends the certification information of the NF to the ACME client, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the Operation, Maintenance and Management (OAM).

21. The method according to any one of claims 15 to 20, wherein: Also includes: The NF sends the NF token of the NF to the ACME client, where the NF token is used to authorize the NF to request a digital certificate using the ACME client.

22. The method according to claim 21, wherein The NF token is issued to the NF by the Network Repository Function (NRF) according to the configuration information of the NF; The configuration information of the NF includes first indication information, where the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information about the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have a Hypertext Transfer Protocol server capability.

23. A digital certificate management method, characterized in that: The method comprises: The automated certificate management environment ACME client receives the NF identifier from the network function NF; The ACME client determines an ACME identifier associated with the NF identifier, where the ACME identifier is used by the ACME server to verify that the ACME client has control over the ACME identifier; The ACME client sends a certificate signing request (CSR) to the ACME server, where the CSR is generated based on the ACME identifier and the certificate-key pair of the NF, where the certificate-key pair of the NF is obtained or generated by the ACME client; The ACME client receives a digital certificate download address from the ACME server, where the digital certificate is issued by the ACME server to the NF based on the CSR. The ACME client sends the certificate-key pair of the NF and the download address of the digital certificate to the NF, or sends the certificate-key pair of the NF and the digital certificate obtained according to the download address of the digital certificate to the NF.

24. The method according to claim 23, wherein The ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

25. The method according to any one of claims 23 to 24, wherein: Before the ACME client sends the CSR to the ACME server, the method further includes: The ACME client receives certification information from the NF, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the Operation, Maintenance and Management (OAM); The ACME client determines that the NF identifier certified based on the certification information matches the NF identifier in the CSR.

26. The method of claim 25, wherein: The ACME client sends the CSR to the ACME server, including: The ACME client sends the CSR and the certification information to the ACME server.

27. The method according to any one of claims 23 to 26, wherein: Also includes: The ACME client obtains an ACME client account of the NF, where the ACME client account is associated with an NF identifier of the NF. The account key pair of the ACME client account is used by the ACME client to apply for a digital certificate for the NF.

28. The method of claim 27, wherein: The ACME client obtains the ACME client account of the NF, including: The ACME client determines the ACME client account corresponding to the NF identifier of the NF according to the NF identifier of the NF and the correspondence between the NF identifier and the ACME client account; or, The ACME client selects an ACME client account from the created ACME client accounts and establishes a correspondence between the ACME client account and the NF identifier of the NF; Alternatively, the ACME client requests the ACME server to create an ACME client account, and the ACME client establishes a correspondence between the ACME client account and the NF identifier of the NF.

29. The method according to any one of claims 23 to 26, wherein: Also includes: The ACME client obtains an ACME client account, where the ACME client account is shared by multiple NFs including the NF. The account key pair of the ACME client account is used by the ACME client to apply for digital certificates for the multiple NFs.

30. The method according to any one of claims 23 to 29, wherein Before the ACME client sends the CSR to the ACME server, the method further includes: The ACME client receives an NF token from the NF, where the NF token is used to authorize the NF to use the ACME client to request a digital certificate; The ACME client verifies the NF token.

31. The method of claim 30, wherein: Also includes: The ACME sends the NF token of the NF to the ACME server.

32. The method according to any one of claims 30 to 31, wherein: The NF token is issued to the NF by the Network Repository Function (NRF) according to the configuration information of the NF; The configuration information of the NF includes first indication information, where the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information about the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have a Hypertext Transfer Protocol server capability.

33. A digital certificate management method, characterized in that: The method comprises: The network function NF sends an NF identifier to an automated certificate management environment ACME client, where the ACME client determines an ACME identifier associated with the NF identifier, and the ACME identifier is used by an ACME server to verify that the ACME client has control over the ACME identifier. The NF receives the NF's certificate-key pair and the download address of the digital certificate from the ACME client, or receives the NF's certificate-key pair and the digital certificate obtained according to the download address of the digital certificate from the ACME client, where the NF's certificate-key pair is generated or obtained by the ACME server, and the NF's digital certificate is issued by the ACME server based on a CSR, and the CSR is generated by the ACME client based on the ACME identifier and the NF's certificate-key pair.

34. The method of claim 33, wherein: The ACME identifier is the same as the NF identifier, or the ACME identifier is the same as the identifier of the ACME client.

35. The method according to any one of claims 33 to 34, wherein: Also includes: The NF sends the certification information of the NF to the ACME client, where the certification information is used to verify the authenticity of the NF identifier of the NF or to verify that the NF is configured with the NF identifier by the Operation, Maintenance and Management (OAM).

36. The method according to any one of claims 33 to 35, wherein: Also includes: The NF sends the NF token of the NF to the ACME client, where the NF token is used to authorize the NF to request a digital certificate using the ACME client.

37. The method of claim 36, wherein: The NF token is issued to the NF by the Network Repository Function (NRF) according to the configuration information of the NF; The configuration information of the NF includes first indication information, where the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information about the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have a Hypertext Transfer Protocol server capability.

38. A digital certificate management method, characterized in that: include: An automated certificate management environment (ACME) server receives a certificate issuance request (CSR) and first information from an ACME client, where the first information is certification information of a network function (NF) or an NF token of the NF. If the ACME server successfully verifies the authenticity of the NF identifier based on the first information, or determines that the NF has been configured with the NF identifier by the operation, maintenance and management (OAM), the ACME server sends a download address of a digital certificate to the ACME client, where the digital certificate is issued by the ACME server for the NF based on the CSR.

39. The method of claim 38, wherein The certification information of the NF includes one or more of the following: signature information of the NF on the NF identifier of the NF, signature information of the OAM on the NF identifier of the NF, or a hash verification code corresponding to the NF identifier of the NF.

40. The method according to any one of claims 38 to 39, wherein The NF token of the NF includes an identifier of the NF.

41. The method according to any one of claims 38 to 40, wherein: The NF token is issued to the NF by the Network Repository Function (NRF) according to the configuration information of the NF; The configuration information of the NF includes first indication information, where the first indication information indicates one or more of the following: the NF is allowed to use an ACME client, or information about the ACME client authorized to be used by the NF, or the NF is a stateless NF, or the NF does not have the capability of integrating an ACME client, or the NF does not have a Hypertext Transfer Protocol server capability.

42. 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 14, or a unit or module for executing the method according to any one of claims 15 to 22, or a unit or module for executing the method according to any one of claims 23 to 32, or a unit or module for executing the method according to any one of claims 33 to 37, or a unit or module for executing the method according to any one of claims 38 to 41.

43. A communication device, characterized in that include: One or more processors, wherein the one or more processors are configured to perform the method of any one of claims 1-14, or the method of any one of claims 15-22, or the method of any one of claims 23-32, or the method of any one of claims 33-37, or the method of any one of claims 38-41.

44. A readable storage medium, characterized in that The readable storage medium includes a program, which, when executed on a device, causes the device to execute the method described in any one of claims 1 to 14, or the method described in any one of claims 15 to 22, or the method described in any one of claims 23 to 32, or the method described in any one of claims 33 to 37, or the method described in any one of claims 38 to 41.

45. A chip system, characterized in that: include: The chip system includes at least one chip and a memory, and the at least one chip is used to read and execute the program stored in the memory to implement the method as described in any one of claims 1 to 14, or to implement the method as described in any one of claims 15 to 22, or to implement the method as described in any one of claims 23 to 32, or to implement the method as described in any one of claims 33 to 37, or to implement the method as described in any one of claims 38 to 41.

46. ​​A computer program product, characterized in that When the computer program product is run on a device, the device causes the device to perform the method according to any one of claims 1 to 14, or the method according to any one of claims 15 to 22, or the method according to any one of claims 23 to 32, or the method according to any one of claims 33 to 37, or the method according to any one of claims 38 to 41.

Citation Information

Patent Citations

  • Discovery method and device of network function service

    CN109391592A

  • Digital certificate updating method, terminal device, CA server and storage medium

    CN114172653A

  • Method for enabling traditional SSL application process to be compatible with ACME

    CN115277183A

  • Acme centralized management system and load balancing method thereof

    US20220029830A1