Certificate Enrollment System and Method for Non-Virtual Machine Based Network Elements

Abstract

A system for performing fully automated registration of certificates in a mobile communication network includes a network element configured to request a certificate, at least one server configured to authenticate the network element and provide certification authority (CA) information to the network element, and a certificate manager configured to obtain a pre-configured policy for the requested certificate, obtain a certificate based on the pre-configured policy, and issue the certificate to the network element, wherein the network element is configured to: send a request to the at least one server to obtain information about the certificate manager, obtain from the at least one server information about the certificate manager, send a certificate signing request (CSR) to the certificate manager to request a certificate based on the obtained information about the certificate manager, and receive from the certificate manager the requested certificate generated by a CA server of the certificate manager.

Description

[Background technology]

[0001] The Radio Access Network (RAN) is a critical component in telecommunications systems because it connects end-user devices (or user equipment) to the rest of the network. The RAN includes a combination of various network elements (NEs) that connect end users to the core network. Traditionally, the hardware and / or software of a particular RAN is vendor-specific.

[0002] Open RAN (O-RAN) technology has emerged to enable multiple vendors to provide hardware and / or software for telecommunication systems. Because different vendors are involved, the types of hardware and / or software provided may also vary. That is, different types of NEs may be provided by different vendors, and depending on the specific service, the NEs may be virtualized in software (e.g., virtual machine (VM)-based) or physical hardware (e.g., non-VM-based). Therefore, traditional network architectures designed to support NEs provided by specific vendors are no longer appropriate. Furthermore, with the increasing number of parties involved in a network, ensuring network communications through traditional methods of authenticating and verifying vendor-specific NEs is no longer appropriate in a multi-vendor environment. Summary of the Invention [Problem to be solved by the invention]

[0003] In view of the above, it is necessary to provide a system that supports the deployment of multiple types of NEs. To this end, it is necessary to provide a system that can efficiently and securely authenticate NEs provided by different vendors, thereby providing secure connections between the NEs. [Means for solving the problem]

[0004] According to example embodiments, systems and methods are provided that enable non-virtual machine (VM) based network elements (NEs) in a radio access network (RAN) to perform certificate enrollment via a Certificate Authority (CA) server.

[0005] According to example embodiments, systems and methods are provided that enable fully automated enrollment of certificates for non-VM-based NEs within a RAN and that enable semi-automated enrollment of certificates for non-VM-based NEs within a RAN.

[0006] According to an example embodiment, a system and method are provided for securely authenticating an NE and securely providing information of a CA server to the NE.

[0007] According to an example embodiment, a system and method are provided that allows different types of NEs from one or more vendors to enroll certificates from one CA server.

[0008] According to example embodiments, systems and methods are provided that enable semi-automated registration of certificates as a fallback certificate registration method, for example, if the components for fully automated registration fail or if a particular NE does not support automated registration.

[0009] According to an exemplary embodiment, a system for performing fully automated certificate enrollment in a mobile communication network includes a network element configured to request a certificate; at least one server configured to authenticate the network element and provide Certificate Authority (CA) information to the network element; and a certificate manager configured to obtain a pre-configured policy for the requested certificate, obtain a certificate based on the pre-configured policy, and issue the certificate to the network element, wherein the network element is configured to: send a request to the at least one server to obtain information about the certificate manager; obtain from the at least one server information about the certificate manager; send a certificate signing request (CSR) to the certificate manager to request the certificate based on the obtained information about the certificate manager; and receive from the certificate manager the requested certificate generated by a CA server of the certificate manager.

[0010] The at least one server may include a Dynamic Host Configuration Protocol (DHCP) server and an authentication server, and the DHCP server may be configured to receive a request sent by the network element to obtain information about the certificate manager, the request including at least one security parameter; send the at least one security parameter to the authentication server to perform authentication of the network element; receive a result of the authentication from the authentication server; and send the information about the certificate manager to the network element based on a result of the authentication indicating successful authentication.

[0011] The at least one security parameter may include a device certificate pre-installed on both the network element and the authentication server, and the authentication server may be configured to perform authentication by verifying the device certificate included in the at least one security parameter using the device certificate pre-installed thereon.

[0012] The device certificate may be a vendor certificate issued by a CA of a vendor of the network element, and the authentication server may be configured to store multiple vendor certificates respectively issued by multiple CAs of vendors of network elements included in the mobile communication network.

[0013] The certificate manager may include a Registration Authority (RA) server and a CA server, where the RA server may be configured to receive a CSR sent by a network element, authenticate the network element, assign a predetermined profile identifier (ID) to the CSR, and send the CSR and the profile ID to a CA server, and the CA server may be configured to receive the CSR and the profile ID sent by the RA server, determine a pre-configured policy mapped to the profile ID, and generate a certificate according to the determined pre-configured policy.

[0014] The information about the certificate manager may include at least one of the fully qualified domain name (FQDN) and port of the CA server.

[0015] The system may further include a Certificate Lifecycle Management System (CLMS) configured to communicate with the CA server and perform semi-automated enrollment of certificates from the CA server.

[0016] The system may further include another network element configured to generate and input another CSR into the CLMS and download another certificate generated by the CA server via the CLMS, and the CLMS may be configured to provide a graphical user interface (GUI) through which a CA server is selected from among multiple CA servers and through which the other CSR is input, transmit the other CSR to the CA server, receive another certificate generated by the CA server based on the transmitted other CSR, and enable the other certificate to be downloaded by the other network element.

[0017] The CA server may be configured to receive another CSR sent by the CLMS, determine a profile ID corresponding to the other CSR, determine a pre-configured policy mapped to the profile ID, and generate another certificate based on the determined pre-configured policy.

[0018] If fully automated registration is not feasible for one or more network elements, semi-automated registration of certificates may be provided by the system as an alternative to fully automated registration.

[0019] According to an exemplary embodiment, a method for performing fully automated certificate enrollment in a mobile communications network includes: sending, by a network element, a request to at least one server to obtain information about a certificate manager; obtaining, by the network element, from the at least one server, information about the certificate manager based on the network element being authenticated by the at least one server; sending, by the network element, a certificate signing request (CSR) to the certificate manager to request a certificate based on the obtained information about the certificate manager; and receiving, by the network element, from the certificate manager, the requested certificate generated by the CA server based on a pre-configured policy obtained by the CA server of the certificate manager for the requested certificate.

[0020] The method may further include receiving, by a DHCP server of the at least one server, a request sent by the network element to obtain information about the certificate manager, the request including at least one security parameter; sending, by the DHCP server, the at least one security parameter to an authentication server to perform authentication of the network element; receiving, by the DHCP server, a result of the authentication from the authentication server; and sending, by the DHCP server, information about the certificate manager to the network element based on a result of the authentication indicating successful authentication.

[0021] The at least one security parameter may include a device certificate pre-installed on both the network element and the authentication server, and the method may further include performing authentication by the authentication server using the device certificate pre-installed therein to verify the device certificate included in the at least one security parameter.

[0022] The device certificate may be a vendor certificate issued by a CA of a vendor of the network element, and the authentication server may be configured to store multiple vendor certificates respectively issued by multiple CAs of vendors of network elements included in the mobile communication network.

[0023] The method may further include receiving a CSR sent by the network element by a registration authority (RA) server included in the certificate manager, authenticating the network element by the RA server, assigning a predetermined profile identifier (ID) to the CSR by the RA server, sending the CSR and the profile ID to a CA server by the RA server, determining by the CA server a pre-configured policy mapped to the profile ID based on the CA server sent by the RA server, and generating a certificate in accordance with the determined pre-configured policy by the CA server.

[0024] The information about the certificate manager may include at least one of a fully qualified domain name (FQDN) and a port of the CA server.

[0025] The method may further include communicating with the CA server via a certificate lifecycle management system (CLMS) to perform semi-automated certificate enrollment.

[0026] The method may further include providing, by the CLMS, a graphical user interface (GUI) through which a CA server is selected from among multiple CA servers and through which another CSR is input; generating, by another network element, the other CSR and inputting it into the CLMS; sending, by the CLMS, the other CSR to the CA server; receiving, by the CLMS, another certificate generated by the CA server based on the sent other CSR; and downloading, by the other network element, the other certificate from the CLMS.

[0027] The method may further include receiving, by the CA server, the other CSR sent by the CLMS; determining, by the CA server, a profile ID corresponding to the other CSR; determining, by the CA server, a pre-configured policy mapped to the profile ID; and generating, by the CA server, the other certificate based on the determined pre-configured policy.

[0028] According to an exemplary embodiment, a non-transitory computer-readable storage medium has stored thereon instructions executable by at least one processor of a network element, the instructions causing the at least one processor to perform a method for fully automated certificate enrollment in a mobile communications network, the method including: sending a request to at least one server to obtain information about a certificate manager; obtaining, from the at least one server, information about the certificate manager based on a network element authenticated by the at least one server; sending, to the certificate manager based on the obtained information about the certificate manager, a certificate signing request (CSR) to request a certificate; and receiving, from the certificate manager, the requested certificate generated by the CA server based on a pre-configured policy obtained by the CA server of the certificate manager for the requested certificate. [Brief explanation of the drawings]

[0029] The features, advantages, and significance of exemplary embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements.

[0030] [Figure 1] 1 is a block diagram of a system for performing fully automated certificate enrollment for non-virtual machine (VM)-based network elements of a mobile communications network, according to one or more embodiments. [Figure 2]FIG. 1 is a diagram of a system architecture including communication flows for performing fully automated certificate enrollment for non-VM-based network elements of a mobile communications network, according to one or more embodiments. [Figure 3] 1 is a flowchart of a method for performing fully automated certificate enrollment for non-VM-based network elements, according to one or more embodiments. [Figure 4] 1 is a flowchart of a method for providing CA server identification information to a non-VM NE according to one or more embodiments. [Figure 5] 1 is a flowchart of a method for generating a certificate, according to one or more embodiments. [Figure 6] FIG. 10 is a message flow diagram for obtaining CA server identification information, according to one or more embodiments. [Figure 7] 1 is a block diagram of a system for performing semi-automated certificate enrollment for non-virtual machine (VM)-based network elements of a mobile communications network, according to one or more embodiments. [Figure 8] FIG. 1 is a diagram of a system architecture including communication flows for performing semi-automated certificate enrollment for non-VM-based network elements of a mobile communications network, according to one or more embodiments. [Figure 9] 1 is a flowchart of a method for performing semi-automated certificate enrollment for non-VM-based network elements, according to one or more embodiments. [Figure 10] FIG. 1 is a diagram of components of one or more devices, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0031] The following detailed description of the exemplary embodiments refers to the accompanying drawings, in which the same reference numbers in various drawings may identify the same or similar elements.

[0032] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Additionally, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least in part) concurrently, and the order of one or more operations may be permuted.

[0033] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0034] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible implementations. Indeed, many of these features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set.

[0035] No element, act, or instruction used herein should be construed as critical or essential unless explicitly stated as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "a" or similar terms are used. Also, as used herein, terms such as "has," "have," "having," "include," and "including" are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified. Furthermore, phrases such as "at least one of [A] and [B]" and "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0036] Exemplary embodiments of the present disclosure provide zero trust automated mutual authentication of network elements (NEs) in a radio access network (RAN). In this regard, zero trust refers to the principle of "never trust, always verify," and mutual authentication refers to authenticating two entities to each other to set up a secure connection between them. For example, according to embodiments, whenever an NE (e.g., a radio unit (RU), a centralized unit (CU), a distribution unit (DU), etc.) attempts to establish a connection with another NE, both NEs enroll certificates from a certificate authority (CA) server and use the certificates to authenticate each other, thereby securing the connection.

[0037] An example embodiment of the present disclosure provides a fully automated method for enrolling a certificate for a non-virtual machine (VM)-based NE (e.g., a hardware-based physical NE), and a system for performing the same, the method including: using a Dynamic Host Configuration Protocol (DHCP) server and an authentication server to authenticate the NE and provide information of a Certificate Authority (CA) server (so that the NE can generate a Certificate Signing Request (CSR) and send the CSR to the CA server based on the provided information); using a Registration Authority (RA) server, such as an Enrollment over Secure Transport (EST) server, to assign a profile identifier (ID) to the CSR and forward the CSR along with the profile ID to the CA server (to ensure connectivity between the NE and the CA server); and using the CA server to map a policy corresponding to the CSR based on the profile ID and generate or obtain a certificate based on the determined policy. Because registration is fully automated in exemplary embodiments, users do not need to manually provide information (e.g., information about the CA server, policy information, CSR parameters, etc.) to register a certificate (e.g., when registering, re-registering, or renewing a certificate), thereby reducing the burden on network operators and the risk of information leakage (e.g., due to human error).

[0038] An exemplary embodiment of the present disclosure provides a semi-automated method for registering a certificate for a non-VM-based NE and a system for performing the same. The method includes using a certificate lifecycle management system (CLMS) to allow a user to input a CSR for the non-VM-based NE via a graphical user interface (GUI) and register the CSR with a CA server; and using the CA server to assign a policy ID and map a policy corresponding to the CSR based on the policy ID, generate a certificate based thereon, and send it to the CLMS. According to the exemplary embodiment, the user can then download the certificate to the non-VM-based NE via the CLMS. Furthermore, according to the exemplary embodiment, the user can use the GUI of the CLMS to select a CA server through which the certificate will be registered.

[0039] In addition to the fully automated method described above, one or more exemplary embodiments may provide a system and method for semi-automated certificate registration. As a result, the exemplary embodiments allow NEs that do not support automatic certificate registration to be deployed alongside NEs that do support automatic certificate registration, thereby allowing greater flexibility in configuring the network system (i.e., allowing the network system to support more types of NEs from the same or different vendors). Additionally, by including a CLMS and semi-automated method for registering certificates, the exemplary embodiments provide a fallback or backup certificate registration process in situations where automatic registration or automatic renewal cannot be performed (e.g., DHCP failure, authentication server failure, RA server failure, etc.). As a result, network stability is improved and the impact of system component failures is reduced.

[0040] Exemplary embodiments of the present disclosure provide a system and method for registering certificates for non-VM-based NEs that uses an authentication server separate from a DHCP server to authenticate NEs (e.g., verify security parameters of included NEs via DHCP requests). As a result, in one or more exemplary embodiments, the DHCP server does not need to store parameters for the authentication or validation process (e.g., vendor certificates, etc.), thereby reducing the load on the DHCP server. Furthermore, because the DHCP server does not need to store authentication or validation parameters, one DHCP server can provide CA information to multiple NEs from different vendors and / or different types (e.g., O-RUs, subscriber terminal units (STUs), radio interface units (RIUs), etc.). For example, in an O-RAN-based telecommunications system according to exemplary embodiments, NEs from multiple vendors may be included. To authenticate all NEs, a large amount of corresponding authentication information (e.g., vendor certificates, etc.) needs to be pre-installed. If such information were stored in the DHCP server, the load on the DHCP server would increase (i.e., more data storage and processing power would be used) as well as the cost. In one or more embodiments, offloading authentication to a separate authentication server improves the scalability of the system and reduces the load on the DHCP server.

[0041] According to an exemplary embodiment, a system and method are provided for assigning a profile ID to each CSR, mapping a corresponding policy to the profile ID, and generating a certificate based on the policy. Because the CA server generates the certificate based on the corresponding policy, the system can use one CA server to support operator (e.g., a telecommunications company or a mobile network operator) certificate enrollment for multiple types of NEs (different types of NEs have different policies). Using one CA server (or reducing the number of CA servers) reduces implementation costs and network construction time, and reduces overall network power consumption (considering the reduced number of CA servers).

[0042] 1 is a block diagram of a system for performing fully automated certificate enrollment for non-VM-based network elements of a mobile communications network, according to one or more embodiments. Referring to FIG. 1, the system includes a network element 100, a DHCP server 200, an authentication server 300, a registration authority (RA) server 400, and a certification authority (CA) server 500.

[0043] The network element (NE) 100 may be any network element included in a mobile communication (i.e., telecommunication) network (e.g., a fifth-generation (5G) mobile network, a long-term evolution (LTE) network, etc.). For example, the NE 100 may be an RU, an STU, an RIU, etc. Furthermore, the network may be an open RAN (O-RAN)-based network, and the NE 100 may be an O-RAN-based NE (e.g., an O-RU, etc.). To this end, the NE 100 may be any of a number of types and from any of a number of vendors. As described in further detail below, the NE 100 is configured to obtain information (e.g., an address, etc.) of a CA server 500 from the DHCP server 200, generate a certificate signing request (CSR), transmit the certificate signing request to the CA server 500 based on the obtained information, and receive a certificate generated by the CA server 500 based on the CSR. Using the certificate, the NE 100 can perform secure communication within the network, for example, with another non-VM-based NE or a VM-based NE (e.g., a CU, a DU, etc.).

[0044] The DHCP server 200 is configured to provide and assign an Internet Protocol (IP) address to the NE 100 and to provide information of the CA server 500 to the NE 100. Here, the DHCP server 200 provides the IP address and information of the CA server 500 based on the NE 100 being verified and / or authenticated by the authentication server 300. The information of the CA server 500 may include at least one of identification information of the CA server 500 (e.g., a fully qualified domain name (FQDN)), an address of the CA server (e.g., an IP address), and security parameters of the CA server 500 (e.g., a root certificate of the CA server 500).

[0045] The authentication server 300 is configured to authenticate the NE 100. Furthermore, the authentication server 300 includes a storage unit that stores security parameters for authenticating or verifying the NE 100. For example, vendor certificates (or third-party certificates) of multiple vendors of network elements in a mobile communication network are pre-installed in the authentication server 300. In this case, the authentication server 300 receives security parameters (e.g., the NE's vendor device certificate, signed parameters such as a serial number and / or a nonce, a vendor identifier, etc.) from the NE 100 and checks whether the received security parameters are correct using the pre-installed NE vendor certificate. Here, the security parameters may be sent by the NE 100 to the DHCP server 200 via a DHCP request (e.g., a DHCPv6 request message). In addition, according to one or more exemplary embodiments, one or more operator certificates (e.g., a root certificate from a root CA of a network operator) different from the certificate (e.g., an intermediate certificate) registered by the NE 100 may be pre-installed in the authentication server 300 in addition to (or instead of) the vendor certificates. In this case, the authentication server 300 can authenticate the NE100 using either an operator device certificate received from the NE100 (e.g., a root certificate pre-issued to the NE100 from the operator's root CA) or a vendor (or third-party) device certificate (e.g., a device certificate pre-installed or pre-issued to the NE100 from the NE vendor's CA).

[0046] The RA server 400 is configured to receive a CSR from the NE 100, authenticate or validate the NE 100, and forward the CSR to the CA server 500. For example, the RA server 400 may validate the NE 100 based on information included in or with the CSR (e.g., a vendor certificate, a third-party certificate, an operator root certificate, etc.) and information pre-installed in the RA server 400 (e.g., a vendor certificate, a third-party certificate, an operator root certificate, etc.). According to an exemplary embodiment, the RA server 400 may be an EST server that establishes a secure connection between the NE 100 and the CA server 500 based on the EST protocol (i.e., as defined in RFC 7030). For example, the NE 100 may send a vendor certificate (i.e., a certificate issued by the NE vendor's CA) to the EST server along with the CSR and / or in response to a Transport Layer Security (TLS) certificate request message, and the EST server verifies the vendor certificate and authorizes the CSR accordingly. It is understood that the EST server is merely an example, and one or more other embodiments are not limited thereto. For example, the RA server 400 in various other embodiments may implement different security protocols for certificate provisioning, including, but not limited to, Simple Certificate Enrollment Protocol (SCEP), Certificate Management Protocol (CMP), Certificate Management via Cryptographic Message Syntax (CMC), etc.

[0047] Further, according to an exemplary embodiment, RA server 400 (e.g., an EST server) is configured to assign or map a profile ID to a CSR and forward the CSR (i.e., a valid CSR) and (e.g., along with) the profile ID to CA server 500. RA server 400 may be pre-configured with a correspondence between multiple NEs in the network and multiple profile IDs. For example, RA server 400 may include or store a list of profile IDs or a mapping of profile IDs to at least one of NE device types (e.g., RU, CU, DU, etc.), pre-installed vendor certificates, vendor identification information, NE device identifiers (e.g., serial numbers), etc. As an example, RA server 400 may include a list of pre-installed vendor certificates, each with a corresponding profile ID. As another example, RA server 400 may include a list of devices (NEs) or device types to be registered with CA server 500, each with a corresponding pre-assigned profile ID. Here, the profile ID may be manually assigned by a user (e.g., a system administrator) when a new device is registered with the CA server 500 or installed in the network. Specifically, when a new device is registered with the CA server 500 to obtain a certificate, the user can assign a profile ID for the device and configure policies corresponding to the device / profile ID in the CA server 500 (e.g., define key usage, key validity period, etc.). The profile ID may be uniquely assigned to the NE 100 (e.g., NE serial number), or may be the same profile ID assigned to another NE (e.g., another NE with the same at least one of the following: type, purpose, vendor, etc.). In the latter case, a new policy does not need to be configured for the NE because it is already set for that profile ID.Additionally, in one or more embodiments, corresponding policies may be pre-configured and set in the CA server 500 for a range of Profile IDs (both assigned and unassigned), for example, a particular policy for a particular type of NE (such as an RU or an STU) may be pre-configured for a range of Profile IDs corresponding to that type of NE (e.g., 6000-6999 for an RU, 7000-7999 for an STU, etc.). In this case, when assigning a unique Profile ID to a device (e.g., a new RU being added to the network), the corresponding policy does not need to be configured at that time because it is already pre-configured and mapped to the range of Profile IDs that includes the newly assigned Profile ID.

[0048] The CA server 500 is configured to receive a CSR from the RA server 400, generate a certificate based on the CSR, and provide the certificate to the NE 100 (i.e., via the RA server 400). According to an exemplary embodiment, the CA server 500 is configured to receive a CSR and a profile ID from the RA server 400 (e.g., an EST server) and map a policy (i.e., a predetermined or predefined policy) corresponding to the CSR according to the profile ID. The CA server can store a list of profile IDs (i.e., pre-configured profile IDs), each corresponding to a specific NE (e.g., an NE serial number), a specific type of NE, a specific vendor, etc. For example, a first ID or a first set of IDs (e.g., “6xxx”) corresponds to a first type of NE (e.g., an RU), a second ID or a second set of IDs (e.g., “7xxx”) corresponds to a second type of NE (e.g., an STU), etc. The CA server 500 can also store multiple policies, each corresponding to a profile ID or a type of NE. The policy may be pre-configured by a user (e.g., an administrator) via a graphical user interface that includes various user input fields for defining the policy (e.g., validity period and validity period options, key usage, revocation parameters, etc.). The CA server 500 can then determine the policy that corresponds to the profile ID of the CSR and generate a certificate according to the determined policy. In this case, the generated certificate may include key usage, validity period, etc., such that the certificate only allows the NE 100 to perform the specified usage within the validity period.

[0049] As described above, a policy includes information for configuring or generating a certificate, such as at least one of a subject name format (C, O, CN fields), key usage (e.g., digital signature, key certificate signature, certificate revocation list signature, etc.), extended key usage, validity period, revocation information, etc. It is understood that a policy may be defined based on an NE type (e.g., a default or standard validity period for an RU device may be six months, and a default or standard validity period for a non-RU device may be three years), although one or more other embodiments are not limited thereto, and a policy may be defined according to a user's (e.g., an administrator's) desires, needs, etc. For example, a particular policy may be configured by a user with a relatively short validity period for an NE (i.e., a profile ID of the NE) that is under test or testing for certificate renewal.

[0050] 2 is a diagram of a system architecture including communication flows for performing fully automated certificate enrollment for non-VM-based network elements of a mobile communications network, according to one or more embodiments. Referring to FIG. 2, the system architecture includes a NE 100 and a central data center (CDC) 600. The CDC 700 may be a data center of an operator of a mobile communications network or a telecommunications company, and includes a DHCP server 200, an authentication server 300, and a certificate manager (CM) 700. It will be understood that this is merely an example, and that in other embodiments, at least some of the various devices may be distributed across multiple locations or data centers. The CM 700 includes an RA server 400 (e.g., an EST server) and a CA server 500 (e.g., a CA server of a mobile network operator). The NE100, DHCP server 200, authentication server 300, RA server 400, and CA server 500 may be the same as or substantially similar to those described above with reference to FIG. 1, and redundant descriptions thereof may not be repeated below.

[0051] Referring to FIG. 2, in [1], the NE 100 sends a request (e.g., a DHCP request) to the DHCP server 200. The NE 100 sends the request to obtain an IP address and CA information from the DHCP server 200. The request may include at least one of identification information related to the vendor of the NE 100, a serial number of the NE 100, an NE device certificate, a signed serial number, a signed nonce, etc. Here, the NE device certificate may be a vendor device certificate (or a vendor CA certificate) of the NE pre-installed in the NE 100, or may be an operator (e.g., a mobile network operator or a telecommunications company) device certificate (or an operator CA certificate) (e.g., a root CA certificate) that the NE 100 already has. Furthermore, the nonce may have been previously received by the NE 100 from the DHCP server 200.

[0052] In [2], the DHCP server 200 sends (or forwards) the security parameters of the NE 100 to the authentication server 300 for verification and authentication. The security parameters may include at least one of the received serial number of the NE 100, the received NE device certificate, the received signed serial number, the received signed nonce, the nonce itself, etc.

[0053] The authentication server 300 verifies and authenticates the received security parameters. For example, the authentication server 300 verifies that the NE device certificate, signed serial number, and signed nonce are correct using the corresponding pre-installed vendor or operator certificate, the received serial number, and the received nonce, respectively. In [3], the authentication server 300 sends the authentication and verification result (e.g., a success response or a failure response) to the DHCP server 200.

[0054] In [4], based on the authentication and verification result indicating successful authentication / verification, the DHCP server 200 generates and sends a message (e.g., a DHCP response message) to the NE 100, including the NE's IP address and CA server 500's information (e.g., FQDN / IP, port). The message may also include Domain Name System (DNS) information, an operator CA root certificate, etc. In one or more exemplary embodiments, a top-of-rack (TOR) switch or a transport network equipment (TNE) may be included in the communication path between the DHCP server 200 and the NE 100 and may forward messages therebetween.

[0055] In [5], the NE 100 transmits a CSR and a device certificate (e.g., a pre-installed vendor certificate) to the CM 700 based on the information received from the CA server 500. Here, the CSR generated by the NE 100 may include a public key (e.g., a public key generated by the NE 100 to be included in the requested certificate), a common name field (e.g., the device's hostname), and an organization name field (e.g., the name of the mobile network operator), and may be signed with a private key corresponding to the included public key. The CSR and the device certificate may be transmitted in an HTTP request message.

[0056] The CSR and device certificate are received by the RA server 400 (e.g., an EST server), which validates the NE 100. For example, the RA server 400 validates the NE 100 using the received device certificate and a corresponding pre-installed device certificate (e.g., a vendor certificate). The RA server 400 also assigns or maps a corresponding profile ID to the NE 100 / CSR, as described above, and sends (or forwards) the CSR together with the profile ID to the CA server 500 at [6].

[0057] As described above, the CA server 500 receives the CSR along with the profile ID from the RA server 400 and determines a policy (e.g., a pre-configured policy) for the CSR based on the profile ID. The CA server 500 generates a certificate based on the CSR and the determined policy. The certificate may be formatted according to a predefined standard such as X.509. At [7], the CA server 500 sends the certificate to the RA server 400, which then sends it to the NE 100 at [8]. The RA server 400 may send the certificate (e.g., a CA-signed device certificate) to the NE 100 in an HTTP response message.

[0058] 3 is a flowchart of a method for performing fully automated certificate enrollment for a non-VM-based network element, according to one or more embodiments. The method of FIG. 3 may be performed by the NE 100 described above with reference to FIG. 1 or FIG. 2. For example, the method may be performed by at least one processor executing instructions stored in a memory.

[0059] 3, in operation S301, the NE 100 sends a request (e.g., a DHCP request) to a first server (e.g., the DHCP server 200) to obtain CA server identification information. The request may include at least one of identification information related to the vendor of the NE 100, a serial number of the NE 100, an NE device certificate, a signed serial number, a signed nonce, etc. Here, the NE device certificate may be a vendor device certificate (or a vendor CA certificate) of the NE pre-installed in the NE 100, or an operator (e.g., a mobile network operator or a telecommunications company) device certificate (or an operator CA certificate) that the NE 100 already has. Furthermore, the nonce may have been previously received by the NE 100 from the first server.

[0060] In operation S302, the NE 100 obtains CA server identification information from a server (e.g., the DHCP server 200). For example, based on the non-VM NE being authenticated / verified by the server or the authorization server 300 communicatively connected to the server (e.g., the DHCP server 200), the NE 100 receives the CA server identification information (e.g., FQDN / IP, port) from the server according to the NE device certificate, signed serial number, signed nonce, etc. The NE 100 may also receive an IP address and additional information (e.g., DNS, etc.) from the server.

[0061] In operation S303, the NE 100 generates a CSR and sends it to the CA server 500. Here, the CSR may be generated before, after, or simultaneously with operation S301 in various embodiments. Further, in operation S303, the NE 100 may send the CSR along with at least one security parameter (e.g., a device certificate such as a vendor certificate) to be authenticated. For example, the NE 100 may send the CSR and the security parameters to the RA server 400 (e.g., an EST server), and the RA server 400 authenticates the NE 100 using the security parameter (and corresponding security parameters that it possesses) and then forwards the CSR to the CA server 500.

[0062] The CA server 500 generates a certificate based on the CSR, and in operation S304, the NE 100 receives the generated certificate.

[0063] 4 is a flowchart of a method for providing CA server identification information to a non-VM NE according to one or more embodiments. The method of FIG. 4 may be performed by DHCP server 200 described above with reference to FIG. 1 or FIG. 2, or may be performed in response to operation S301 of FIG. 3. For example, the method may be performed by at least one processor executing instructions stored in a memory.

[0064] 4, in operation S401, a server (e.g., DHCP server 200) receives a request to obtain CA information (e.g., CA server identification information) from NE 100. The request may also be for receiving an IP address. The request may include at least one of identification information regarding the vendor of NE 100, a serial number of NE 100, an NE device certificate, a signed serial number, a signed nonce, etc. The nonce may be previously sent by the server to NE 100 (e.g., in response to an initial message).

[0065] In operation S402, the server authenticates the NE 100 (e.g., determines whether the NE 100 is authentic). For example, the server (e.g., DHCP server 200) can send one or more security parameters (e.g., the received serial number, the received NE device certificate, the received signed serial number, the received signed nonce, and the nonce) to another server (e.g., authentication server 300), which verifies the one or more security parameters (e.g., using a corresponding pre-installed certificate) and returns a result of the verification (e.g., success or failure) to the server. Alternatively, the server may directly authenticate the NE 100 itself (i.e., may verify the one or more security parameters itself).

[0066] In operation S403, the server sends CA server identification information (e.g., FQDN / IP, port) based on the authentication / verification result to the NE 100. The server may also assign and send an IP address and additional information (e.g., DNS, etc.) to the NE 100 in operation S403.

[0067] Figure 5 is a flowchart of a method for generating a certificate according to one or more embodiments. The method of Figure 5 may be performed by CM 700 described above with reference to Figure 2, or may be performed in response to operation S303 of Figure 3. For example, the method may be performed by at least one processor executing instructions stored in memory.

[0068] 5, in operation S501, a first server (e.g., RA server 400) receives a CSR from the NE 100. The CSR may include a public key (e.g., a public key generated by the NE 100 to be included in the requested certificate), a common name field (e.g., a hostname of the device), and an organization name field (e.g., the name of a mobile network operator), and may be signed with a private key corresponding to the included public key. The first server may also receive a device certificate (e.g., a vendor certificate of the NE) from the NE 100 in operation S501.

[0069] In operation S502, the first server authenticates the NE 100. For example, the first server may authenticate the NE 100 according to a predefined protocol (e.g., EST protocol, SCEP, CMP, CMC protocol, etc.). For this purpose, a certificate corresponding to the device certificate received from the NE 100 may be pre-installed in the first server and may be used to verify the device certificate.

[0070] In operation S503, the first server maps or assigns a profile ID to the CSR 100. For example, the first server (e.g., RA server 400) may be pre-configured with a correspondence between a plurality of NEs in the network and a plurality of profile IDs. For example, the first server may include or store a list of profile IDs or a mapping of profile IDs to at least one of NE device types (e.g., RU, CU, DU, etc.), pre-installed vendor certificates, vendor identification information, NE device identifiers, etc. As an example, the first server may include a list of pre-installed vendor certificates, each with a corresponding profile ID. As another example, the first server may include a list of devices (NEs) or device types to be enrolled with the CA server 500, each with a corresponding pre-assigned profile ID.

[0071] In operation S504, the first server sends the CSR with the profile ID to the second server (ie, the CA server 500).

[0072] In operation S505, the second server determines or maps a policy corresponding to the CSR according to the profile ID, where the policy is pre-configured and set in the second server and includes information for configuring the certificate (e.g., at least one of subject name format (C, O, CN fields), key usage, extended key usage, validity period, etc.) For example, in operation S505, the second server can determine the device type of the NE 100 according to the profile ID and can determine a pre-configured policy based on the device type.

[0073] In operation S506, the second server generates a certificate based on the CSR and the determined policy. The certificate may be formatted according to a predefined standard such as X.509 and may have values ​​(e.g., validity period, key usage, etc.) based on the determined policy.

[0074] In operation S507, the second server (e.g., CA server 500) transmits the certificate to NE 100. For example, the second server may send the certificate to the first server (e.g., RA server 400), which then forwards the certificate to NE 100 (or to another device, e.g., a TOR switch or TNE, which then transmits the certificate to NE 100).

[0075] It will be appreciated that the methods of FIGS. 3-5 may be performed automatically, ie, without requiring manual input or human intervention during certificate enrollment (or re-enrollment, renewal, etc.).

[0076] Figure 6 is a message flow diagram for obtaining CA server identification information, according to one embodiment. The message flow diagram of Figure 6 includes messages sent between NE 100, DHCP server 200, and authentication server 300, such as those described above with reference to Figure 1. It is understood that one or more other embodiments are not limited to the message flow and system devices shown in Figure 6. For example, in one or more other embodiments, a TOR switch or other TNE may be included between at least two of the devices (e.g., between NE 100 and DHCP server 200).

[0077] 6 , in S601, the NE 100 sends a DHCP request message to the DHCP server 200. In response, in S602, the DHCP server 200 sends a nonce to the NE 100 in a DHCP advertise message. Here, the nonce may be generated (e.g., for one-time use) by the DHCP server 100, for example, in response to receiving the DHCP request message. In S603, the NE 100 generates a DHCP request message including vendor information, the NE serial number, the NE device certificate, a signed serial number, and the signed nonce, and sends it to the DHCP server 200. Here, the DHCP response message may include either the NE's vendor device certificate pre-installed in the NE 100 (sometimes referred to as an invalid operator device certificate), or an operator (e.g., a mobile network operator or telecommunications company) device certificate (or operator CA certificate) (sometimes referred to as a valid operator device certificate) that the NE 100 already has, for example, a root certificate from the operator's CA. In S604, the DHCP server 200 sends the security parameters (serial number, device certificate, signed serial number, signed nonce, and nonce) to the authentication server 300 in a verification request message. The authentication server 300 verifies the device certificate using a corresponding pre-installed vendor or operator CA certificate and verifies the signed serial number and signed nonce. Based on this verification, the authentication server 300 sends a verification response message indicating success or failure to the DHCP server 200 in S605. Based on the verification response message indicating success, the DHCP server 200 sends a DHCP response to the NE 100 in S606. The DHCP response received by the NE 100 includes the NE's IP address and the CA server's information (e.g., the CA server's FQDN, port, and / or IP). Furthermore, the DHCP response may include additional information such as at least one of the operator CA root certificate, DNS, and other details.

[0078] 7 is a block diagram of a system for performing semi-automated certificate enrollment for non-virtual machine (VM)-based network elements of a mobile communication network, according to one or more embodiments. Referring to FIG. 7, the system includes a network element (NE) 800, a user terminal 900, a certificate lifecycle management system (CLMS) 1000, and a certificate authority (CA) server 500.

[0079] The NE 800 may be any network element included in a mobile communication (i.e., telecommunication) network (e.g., a 5G mobile network, an LTE network, etc.). For example, the NE 800 may be an RU, an STU, an RIU, etc. Furthermore, the network may be an open RAN (O-RAN)-based network, and the NE 800 may be an O-RAN-based NE (e.g., an O-RU, etc.). For this purpose, the NE 800 may be any of a number of types and from any of a number of vendors. The NE 800 is configured to connect to the CLMS 1000, generate and upload a CSR to the CLMS 1000, and download and install a certificate (e.g., a mobile network or telecommunication company operator device certificate) (e.g., an address) of the CA server 500 obtained via the CLMS 1000. The CSR may be entered by a user (e.g., the owner of the NE 800, a system or network administrator, etc.) into a graphical user interface (GUI) provided by the CLMS for certificate enrollment. For example, a user may select a CA server (e.g., one of multiple intermediate CAs for signing or registering certificates for different types of NEs in the network) for registering a CSR via a GUI. The NE 800 may or may not support fully automated certificate enrollment, as described above with reference to FIGS. 1-6. In one or more embodiments, the NE 800 may be unable to obtain a certificate via the fully automated method described above with reference to FIGS. 1-6 (e.g., the NE 800 may not support fully automated certificate enrollment, a component of the system for performing fully automated certificate enrollment may fail, etc.). Alternatively or additionally, the system itself may not support fully automated certificate enrollment or may be specifically configured for semi-automated certificate enrollment according to an embodiment of the present disclosure.

[0080] The user terminal 900 is configured to connect to the CLMS 1000 and receive and display the CLMS 1000's graphical user interface. Additionally, the user terminal 900 includes an input device (e.g., at least one of a keyboard, a mouse, a touch screen, etc.) through which a user can provide input to the CLMS 1000's user interface. Specifically, the user terminal 900 may be configured to enable a user (e.g., an administrator) to approve or reject CSRs uploaded by the network element 800 and to manage one or more portions of the lifecycle of certificates deployed across a network (e.g., O-RAN). For example, a user may manually revoke certificates, modify certificate parameters or fields, view dashboards or information regarding deployed certificates, etc., via the CLMS 1000's graphical user interface displayed on the user terminal 900. The user terminal 900 may be any computing device (e.g., a personal computer, a laptop computer, a workstation, a mobile device, etc.).

[0081] The CLMS 1000 is a system (e.g., one or more servers or computing devices) for registering and managing the life cycle of CA certificates in a network. As described above, the CLMS 1000 provides a GUI for certificate registration through which the NE 800 can upload CSRs. For example, a user (e.g., an owner or administrator of the NE 800) can select a CA server for certificate registration via the GUI. In addition, the CLMS 1000 can provide a GUI on a user terminal that enables a user (e.g., an administrator) to approve or reject CSRs uploaded or entered into the CLMS 1000, view dashboards and information about certificates deployed throughout the network, and manage the life cycle of deployed certificates. In addition, the CLMS 1000 can check any CSR for compliance with specific policies, such as the approved encryption policies of a telecommunications company or mobile communications network operator, perform automatic certificate renewal, etc.

[0082] CLMS1000 is communicatively coupled or connected to CA server 500 via an application programming interface (API), such as a Representational State Transfer (REST or RESTful) API, and submits or transmits CSRs uploaded by NE800 to CA server 500. Additionally, CLMS1000 may be configured to receive notification from CA server 500 when a certificate is ready for download, notify a user (e.g., an owner or administrator of NE800) that the certificate is ready for download, receive the certificate from CA server 500, and enable the user to download the certificate to NE800.

[0083] The CA server 500 is configured to receive the CSR generated by the NE 800 from the CLMS 1000, determine a profile ID (e.g., based on the type or vendor of the NE 800) that has been pre-configured (e.g., by a user) for the CSR, determine a corresponding policy mapped to the profile ID as described above with reference to Figures 1 and 2, and generate a certificate according to the CSR and the policy. Furthermore, the CA server 500 is configured to send the certificate to the CLMS 1000 through which the user can download the certificate to the NE 800. In one or more embodiments, the CA server 500 may be further configured to send a notification to the CLMS to notify the user that the certificate is ready to be downloaded.

[0084] 8 is a diagram of a system architecture including communication flows for performing semi-automated certificate enrollment for non-VM-based network elements of a mobile communications network, according to one or more embodiments. The system shown in FIG. 8 includes, in addition to CLMS 1000, the components for supporting fully automated enrollment described above with reference to FIGS. 1-6. Thus, in this embodiment, the system supports both fully automated certificate enrollment and semi-automated certificate enrollment (e.g., as a backup or fallback enrollment for NEs 800 for which fully automated enrollment cannot be performed), although it will be understood that one or more other embodiments are not limited in this respect.

[0085] Referring to FIG. 8 , in [1], the NE 800 generates a CSR and uploads it to the CLMS 1000. For example, an authorized user (e.g., the owner of the NE 800, a system or network administrator, etc.) can select a CA server 500 from among multiple available CA servers (e.g., a CA server such as an intermediate CA server for registering a certificate based on an NE device type) via the GUI of the CLMS, and the NE 800 can generate a CSR and upload it to the CLMS 1000 for registration with the selected CA server. For example, a user (e.g., a system administrator, an administrative user, etc.) can use a user terminal to remotely log in to or access the NE 800 and generate and submit a CSR from the NE 800. Additionally or alternatively, an instruction may be triggered and executed (e.g., automatically executed) (e.g., by a user directly on the NE 800, by a user remotely, or by the occurrence of an event) to generate and submit a CSR to the CLMS 1000. For example, instructions or scripts installed on the NE800 can be automatically executed to generate and submit a CSR periodically or in response to an event (e.g., based on a renewal trigger point, such as X days until expiration, defined in the policy of an existing certificate registered by the NE800).

[0086] In [2], the CLMS 1000 provides the user terminal 900 with a GUI through which a user (e.g., an administrator) can approve or reject a CSR uploaded by the NE 800. In [3], the user terminal 900 submits approval (or rejection) of the CSR based on the user's input.

[0087] In [4], the CLMS 100 sends the approved CSR to the selected CA server 500 via an API (e.g., a REST API). The CA server 500 receives the CSR, determines a pre-configured profile ID for the CSR (or for the NE 800), and determines a corresponding pre-configured policy as described above. Based on the CSR and the determined policy, the CA server 500 generates a certificate for the NE 800. In [5], the CA server 500 sends the certificate to the CLMS 1000 via the API. In [6], the certificate is downloaded by the NE 800.

[0088] 9 is a flowchart of a method for performing semi-automated certificate enrollment for a non-VM-based network element according to one or more embodiments. The method of FIG. 9 may be performed by the system shown in FIG. 8 or FIG. 9.

[0089] 9, in operation S901, a CSR is generated and input into CLMS 1000. For example, the CSR may be input by a user (e.g., the owner of NE 800 or a system administrator) via a GUI of CLMS 1000. In addition, the user may select or input a particular CA server with which the CSR will be registered.

[0090] In operation S902, the CSR is transmitted from CLMS 1000 to CA server 500 via an API (e.g., a REST API). According to an example embodiment, CLMS 1000 can transmit the CSR to CA server 500 upon at least one of approval by a user (e.g., a system administrator) and a successful compliance check (e.g., verifying that the CSR complies with a predetermined policy of a network operator).

[0091] In operation S903, the CA server 500 determines a pre-configured or set profile ID corresponding to the CSR (or the NE 800). Here, the profile ID may be manually assigned by a user (e.g., a system administrator) when a new device is to be registered with the CA server 500. Specifically, when a new device is registered with the CA server 500 to obtain a certificate, the user can assign a profile ID for the device and configure policies corresponding to the device / profile ID in the CA server 500 (e.g., define key usage validity period, key validity period, etc.). Thus, the CA server can store a list of profile IDs (i.e., pre-configured profile IDs), each corresponding to a specific NE (e.g., serial number), a specific type of NE, a vendor of the NE, etc. For example, a first ID or a first set of IDs (e.g., “6xxx”) corresponds to a first type of NE (e.g., RU), a second ID or a second set of IDs (e.g., “7xxx”) corresponds to a second type of NE (e.g., STU), etc.

[0092] In operation S904, the CA server 500 determines a pre-configured policy according to the profile ID. The policy includes information for configuring or generating a certificate, such as at least one of a subject name format (C, O, CN fields), key usage, extended key usage, validity period, etc. The policy may be defined based on the NE type (e.g., the default or standard validity period for an RU device may be six months, and the default or standard validity period for a non-RU device may be three years), but it is understood that one or more other embodiments are not limited thereto. The CA server 500 can determine the policy corresponding to the profile ID of the CSR, for example, by determining the device type of the NE 100 according to the profile ID and the pre-configured policy based on the device type.

[0093] In operation S905, the CA server 500 generates a certificate according to the determined policy, where the generated certificate may include key usage, validity period, etc., such that the certificate only allows the NE 800 to perform the specified usage within the validity period.

[0094] In operation S906, the certificate is sent via the CLMS to the NE 800. For example, the CA server 500 can send a notification to the CLMS to notify the user that the certificate is ready to be downloaded, and the user can then use the CLMS to download the certificate and install it on the NE 800.

[0095] While the above example embodiments are described with reference to certificate enrollment, it is understood that one, some, or all of the above embodiments may also be applicable to certificate re-enrollment or renewal, which may, in one or more embodiments, be triggered based on the current system date and time exceeding a threshold, for example, determined according to the following formula: Certificate issuance data + renewal threshold * Certificate validity period

[0096] For example, using the above formula, if the certificate validity period is 100 days and the renewal threshold is 60%, then certificate renewal is triggered when the current system date reaches or exceeds 60 days from the certificate issuance date. It is understood that one or more of the certificate validity period and renewal threshold are configurable by a user (e.g., a system administrator) and may vary per certificate, per NE, per NE device type, etc. Furthermore, in one or more embodiments, an alarm or notification (e.g., "Operator certificate will expire in X days") may be generated by the device (e.g., the corresponding NE where the certificate is registered, another NE connected to the NE, a CLMS, etc.) and renewed daily (or periodically) until the alarm is cleared (e.g., upon successful certificate renewal).

[0097] FIG. 10 is a diagram of components of one or more devices, according to one embodiment.

[0098] The device 1100 may correspond to any of the devices described above (eg, network element 100 or 800, DHCP server 200, authentication server 300, RA server 400, CA server 500, user terminal 900, CLMS 1000, etc.).

[0099] 10, device 1100 may include a bus 1110, a processor 1120, a memory 1130, a storage component 1140, and a communication interface 1150. It will be understood that one or more of the components may be omitted and / or one or more additional components may be included.

[0100] Bus 1110 includes components that enable communication between components of device 1100. Processor 1120 is implemented in hardware, firmware, or a combination of hardware and software. Processor 1120 may be a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or another type of processing component. Processor 1120 includes one or more processors that can be programmed to perform functions.

[0101] Memory 1130 may include random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by processor 1120.

[0102] Storage component 1140 stores information and / or software related to the operation and use of device 1100. For example, storage component 1140 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

[0103] Communication interface 1150 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 900 to communicate with other devices via a wired connection, a wireless connection, or a combination of wired and wireless connections, etc. Communication interface 1150 may enable device 1100 to receive information from another device and / or provide information to another device. For example, communication interface 1150 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0104] Device 1100 may perform one or more processes described herein. Device 1100 may perform operations based on processor 1120 executing software instructions stored by a non-transitory computer-readable medium, such as memory 1130 and / or storage component 1140. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space across multiple physical storage devices.

[0105] The software instructions may be loaded into memory 1130 and / or storage component 1140 from another computer-readable medium or from another device via communications interface 1150. When executed, the software instructions stored in memory 1130 and / or storage component 1140 may cause processor 1120 to perform one or more processes described herein.

[0106] Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement one or more processes described herein. Thus, the embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0107] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations.

[0108] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail. Furthermore, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include computer-readable non-transitory storage medium(s) having computer-readable program instructions for causing a processor to perform operations.

[0109] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or raised structures with instructions recorded in grooves, and any suitable combination of the above. As used herein, a computer-readable storage medium should not itself be interpreted as a transitory signal, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted through a wire.

[0110] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0111] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects or operations.

[0112] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to manufacture a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0113] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0114] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks than those shown in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0115] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods is not intended to limit the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A system for performing fully automated enrollment of certificates in a mobile communications network, the system comprising: a network element configured to request a certificate; at least one server configured to authenticate the network elements and provide Certificate Authority (CA) information to the network elements; a certificate manager configured to obtain a pre-configured policy for the requested certificate, obtain the certificate based on the pre-configured policy, and issue the certificate to the network element; Equipped with The network element sending a request to the at least one server to obtain information about the certificate manager; obtaining the information regarding the certificate manager from the at least one server; sending a certificate signing request (CSR) to the certificate manager to request the certificate based on the obtained information about the certificate manager; receiving from the certificate manager the requested certificate generated by a CA server of the certificate manager; configured to: system.

2. the at least one server includes a Dynamic Host Configuration Protocol (DHCP) server and an authentication server; The DHCP server receiving the request sent by the network element to obtain information about the certificate manager, the request including at least one security parameter; sending said at least one security parameter to said authentication server for performing authentication of said network element; receiving a result of the authentication from the authentication server; sending, to the network element, the information regarding the certificate manager based on the result of the authentication indicating successful authentication; configured to: The system of claim 1 .

3. the at least one security parameter includes a device certificate pre-installed on both the network element and the authentication server; the authentication server is configured to perform the authentication by verifying the device certificate included in the at least one security parameter using the device certificate pre-installed thereon. The system of claim 2 .

4. 4. The system of claim 3, wherein the device certificate is a vendor certificate issued by a CA of a vendor of the network element, and the authentication server is configured to store a plurality of vendor certificates issued by a plurality of CAs of vendors of network elements included in the mobile communication network, respectively.

5. the certificate manager includes a registration authority (RA) server and the CA server; The RA server: receiving the CSR sent by the network element and authenticating the network element; assigning a predetermined profile identifier (ID) to the CSR; sending the CSR and the profile ID to the CA server; configured to: The CA server: receiving the CSR and the profile ID sent by the RA server; determining a pre-configured policy mapped to the profile ID; generating the certificate according to the determined pre-configured policy; configured to: The system of claim 1 .

6. The system of claim 5 , wherein the information about the certificate manager includes at least one of a fully qualified domain name (FQDN) and a port of the CA server.

7. The system of claim 1 , further comprising a certificate lifecycle management system (CLMS) configured to communicate with the CA server and perform semi-automated enrollment of certificates from the CA server.

8. another network element configured to generate and input another CSR into the CLMS and to download, via the CLMS, another certificate generated by the CA server; Furthermore, The CLMS, providing a graphical user interface (GUI) through which the CA server is selected from among a plurality of CA servers and through which the other CSR is entered; sending the other CSR to the CA server; receiving the other certificate generated by the CA server based on the transmitted other CSR; enabling the other certificate to be downloaded by the other network element; configured to: The system of claim 7.

9. The CA server: receiving the other CSR sent by the CLMS; determining a profile ID corresponding to the other CSR; and determining a pre-configured policy mapped to the profile ID; generating the other certificate based on the determined pre-configured policy; and The system of claim 8 configured to:

10. 10. The system of claim 1, wherein semi-automated registration of certificates is provided by the system as an alternative to the fully automated registration if the fully automated registration is not feasible for one or more network elements.

11. 1. A method for performing fully automated registration of certificates in a mobile communications network, the method comprising: sending, by the network element, a request to at least one server to obtain information about the certificate manager; obtaining, by the network element, from the at least one server, the information regarding the certificate manager based on the network element being authenticated by the at least one server; sending, by the network element, a certificate signing request (CSR) to the certificate manager to request the certificate based on the obtained information regarding the certificate manager; receiving, by the network element, from the certificate manager, the requested certificate generated by the CA server based on a pre-configured policy obtained by the CA server of the certificate manager for the requested certificate; A method comprising:

12. receiving, by a DHCP server of the at least one server, the request sent by the network element to obtain information about the certificate manager, the request including at least one security parameter; sending, by the DHCP server, the at least one security parameter to an authentication server for performing authentication of the network element; receiving, by the DHCP server, a result of the authentication from the authentication server; sending, by the DHCP server, to the network element, the information regarding the certificate manager based on the result of the authentication indicating successful authentication; The method of claim 11 further comprising:

13. the at least one security parameter includes a device certificate pre-installed on both the network element and the authentication server; the method further comprising performing the authentication by the authentication server using the device certificate pre-installed therein to verify the device certificate included in the at least one security parameter. The method of claim 12.

14. 14. The method of claim 13, wherein the device certificate is a vendor certificate issued by a CA of a vendor of the network element, and the authentication server is configured to store a plurality of vendor certificates issued by a plurality of CAs of vendors of network elements included in the mobile communication network, respectively.

15. receiving, by a registration authority (RA) server included in the certificate manager, the CSR sent by the network element, and authenticating, by the RA server, the network element; assigning, by the RA server, a predetermined profile identifier (ID) to the CSR; sending, by the RA server, the CSR and the profile ID to the CA server; determining, by the CA server, a pre-configured policy mapped to the profile ID based on the CA server sent by the RA server; generating, by the CA server, the certificate according to the determined pre-configured policy; The method of claim 11 further comprising:

16. 16. The method of claim 15, wherein the information about the certificate manager includes at least one of a fully qualified domain name (FQDN) and a port of the CA server.

17. 12. The method of claim 11, further comprising communicating with the CA server via a Certificate Lifecycle Management System (CLMS) for performing semi-automated certificate enrollment.

18. providing a graphical user interface (GUI) through which the CA server is selected from among a plurality of CA servers by the CLMS and through which other CSRs are entered; generating and inputting said another CSR into said CLMS by another network element; transmitting, by the CLMS, the other CSR to the CA server; receiving, by the CLMS, another certificate generated by the CA server based on the transmitted another CSR; downloading, by the other network element, the other certificate from the CLMS; 20. The method of claim 17, further comprising:

19. receiving, by the CA server, the other CSR sent by the CLMS; determining, by the CA server, a profile ID corresponding to the other CSR; determining, by the CA server, a pre-configured policy mapped to the profile ID; generating, by the CA server, the other certificate based on the determined pre-configured policy; 20. The method of claim 18, further comprising:

20. 1. A non-transitory computer-readable storage medium having stored thereon instructions executable by at least one processor of a network element, the instructions causing the at least one processor to perform a method for fully automated enrollment of certificates in a mobile communications network, the method comprising: sending a request to at least one server to obtain information about the certificate manager; obtaining, from the at least one server, the information regarding the certificate manager based on the network elements being authenticated by the at least one server; sending a certificate signing request (CSR) to the certificate manager to request the certificate based on the obtained information about the certificate manager; receiving from the certificate manager the requested certificate generated by the CA server based on a pre-configured policy obtained by the CA server of the certificate manager for the requested certificate; 1. A non-transitory computer-readable recording medium, comprising:

Images