Configuring EJBCA for Direct CA - Base Station Communication

To configure EJBCA for Direct CA - Base Station Communication, click CMP Configuration under System Functions and configure a CMP Alias with the following configuration:

The CMP Operational Mode Client mode works like any other enrollment in EJBCA. When a request comes in, EJBCA verifies the request (see CMP Message Authentication ) and issues a certificate to a user that has been previously registered in EJBCA. For more information on CMP operational modes, see CMP.

The following displays the settings on the Edit CMP Alias page:

Note that EJBCA always authenticates an update request using only the EndEntityCertificate module, no matter how many authentication modules are configured. However, in order for the update request to authenticate successfully, EndEntityCertificate module has to be set as one of the used authentication modules.

Configuring EJBCA for CA - Base Station Communication Through an RA

The 3GPP CMP standard specifies a usable profile for direct CA-to-device communication. Although this is the primary use case for the 3GPP specification, solutions are often found in a use case where a trusted central point, a registration authority, or a security gateway needs to issue certificates to end entities under its control. For such use cases, you can use CMP in RA mode, a profile of CMP not described in the 3GPP standard.

To configure EJBCA for Direct CA - Base Station Communication through an RA, click CMP Configuration under System Functions and configure a CMP Alias with the following configuration:

The CMP Operational Mode RA Mode is u sed when the CMP client acts as an RA to EJBCA (the RA sends a certificate request to EJBCA). No user is pre-registered in EJBCA, but when authenticated RA CMP messages arrive, a user is created in EJBCA and a certificate is issued. For more information on CMP operational modes, see CMP.

The following displays the settings on the Edit CMP Alias page:

Enrolling Device with Vendor Certificate

A PKI workflow as specified in the 3GPP standard uses CMP to enroll a device, authenticating the initial request using a Vendor certificate added to the device at manufacturing. After initial enrollment, the device can automatically renew the certificate when it is about to expire.

1. There is a Vendor Root CA and a Vendor Sub CA that issues a Vendor Certificate to the device, with which is comes pre-provisioned from the factory.

2. The Vendor Root CA is trusted for initial enrollment, for devices pre-registered in EJBCA with parts of the DN (usually device serial number).

3. We want to generate two certificates for the device, one for IPSEC and one for TLS, and thus the Vendor Certificate is used for multiple authentications to different end entities.

4. Generate two new key pairs on the device

5. Initial enrollment of an IPSEC Certificate for the new key on the device uses certificate authentication with the Vendor Certificate on the device.

6. Initial enrollment of a TLS Certificate for the new key on the device uses certificate authentication with the Vendor Certificate on the device.

7. Generate two new key pairs on the device

8. Renew the IPSEC certificate for the new key pair, authenticated using the old key pair and certificate

9. Renew the TLS certificate for the new key pair, authenticated using the old key pair and certificate

The above steps can be simulated in reality using the cmpforopenssl client, but also using the EJBCA cmpclient.

This works with two cmpaliases configured with parameters:

The Vendor Certificate is issued (suggested as a key store with the private key) from Vendor Sub CA the with subjectDN: CN=1234.primekey.com,O=PrimeKey,C=SE

1. Generate key pairs:

   $ ./openssl genrsa -out certs/ipsec_key.pem 2048

   $ ./openssl genrsa -out certs/tls_key.pem 2048

2. Initial enrollment:
   Before initial enrollment you add two new End Entities in EJBCA, in this example with user name 1234.primekey.com_IPSEC and 1234.primekey.com_TLS with subject DN 'CN=ipsec1234' resp. 'CN=hostname1234'.

   $ openssl cmp -cmd ir -server localhost:8080 -path ejbca/publicweb/cmp/aliasIPSEC \

   -cert VendorDeviceCert.pem -key VendorDeviceKey.pem -certout operator_ipsec_cert.pem -newkey ipsec_key.pem \

   -subject "/CN=ipsec1234" -extracerts VendorExtraCerts.pem -trusted IPSECROOTRSA.cacert.pem \

   -implicit_confirm

    

   $ openssl cmp -cmd ir -server localhost:8080 -path ejbca/publicweb/cmp/aliasTLS \

   -cert VendorDeviceCert.pem -key VendorDeviceKey.pem -certout operator_tls_cert.pem -newkey tls_key.pem \

   -subject "/CN=hostname1234" -extracerts VendorExtraCerts.pem -trusted TLSROOTRSA.cacert.pem \

   -implicit_confirm

3. Generate new key pairs:

   $ ./openssl genrsa -out certs/ipsec_new_key.pem 2048

   $ ./openssl genrsa -out certs/tls_new_key.pem 2048

4. Renew with new certificates:

   $ openssl cmp -cmd kur -server localhost:8080 -path ejbca/publicweb/cmp/aliasIPSEC \

   -cert ipsec_cert.pem -key ipsec_key.pem -certout ipsec_new_cert.pem -newkey ipsec_new_key.pem \

   -subject "/CN=ipsec1234" -extracerts IPSECCAcerts.pem -trusted IPSECROOTRSA.cacert.pem \

   -implicit_confirm

    

   $ openssl cmp -cmd kur -server localhost:8080 -path ejbca/publicweb/cmp/aliasTLS \

   -cert tls_cert.pem -key tls_key.pem -certout tls_new_cert.pem -newkey tls_new_key.pem \

   -subject "/CN=hostname1234" -extracerts TLSCAcerts.pem -trusted TLSROOTRSA.cacert.pem \

   -implicit_confirm

eNodeB Enrollment Example

To assist in configuring eNodeB enrollment in accordance with 3GPP 33.310, the following provides a full working example of an EJBCA configuration as well as simulated eNodeB enrollment messages using OpenSSL v3 (OpenSSL v3 includes the CMP client).

Vendor List

New devices are coming to the market at all times, and are continuously tested with EJBCA by operators. For illustration of the array of vendors and devices that have been tested the following list is a small subset of devices using in networks by mid 2020 (the list is not continuously updated but a snapshot):

• Airspan AirHarmony 1000 ENB (CMP)

• Airvana/Commscope OneCell (CMP)

• Alcatel Lucent 9412 (CMP)

• Cisco 7600 Series Routers with SAMI (CMP)

• Ericsson RBS6000 (SCEP)

• Ericsson RBS6201 (CMP)

• Ericsson Baseband 6630/6648 BBU (CMP)

• Fortinet Fortigate Next Generation Firewall (SCEP, CMP)

• Huawei ENB (CMP) (for example version SRAN 17.1 & 18.1 verified 2022)
  

• Huawei Femtocell BTS3202H, 3202E (CMP)

• Juniper SRX (SCEP)

• NEC eNB.

• Nokia Networks ENB (CMP) (for example version SRAN 21A verified 2022)
  

• Nokia Networks Flexi Zone mi cro (CMP)

• Casa security gateway and Airspan gNodeB/CBSD units(4G & 5G)
  

Related Topics

For questions and answers regarding usage according to 3GPP 33.310, see 3GPP CMP Questions and Answers.