3GPP CMP Operations

This page describes how to configure CMP for 3GPP and common operations and testing.

This page describes configuration and operations for using EJBCA with 3GPP. For more information on the 3GPP CMP standard and EJBCA's integration with it, see the 3GPP Overview page.

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 used 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.

In this example we show how to issue both IPSec certificates and TLS certificates. Depending on your use case you may only need one of these, and not both.

This works with two cmpaliases configured with parameters:

CMP Alias: aliasIPSEC
CMP Operational Mode: Client
CMP Authentication Module : EndEntityCertificate
Extract Username Component : CN
RA Name Generation Postfix : _IPSEC
Vendor Certificate Mode: Use
List Of Vendor CAs: Add Vendor Root CA (imported as External CA in EJBCA)

CMP Alias: aliasTLS
CMP Operational Mode: Client
CMP Authentication Module : EndEntityCertificate
Extract Username Component : CN
RA Name Generation Postfix : _TLS
Vendor Certificate Mode: Use
List Of Vendor CAs: Add Vendor Root CA (imported as External CA in EJBCA

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:

   BASH

   $ ./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'.

   BASH

   $ 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:

   BASH

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

4. Renew with new certificates:

   BASH

   $ 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

Three level Vendor PKI Hierarchy

Vendor CA hierarchies can be either two or three levels (or even four), i.e. either Root CA→DeviceID or Root CA→Sub CA→DeviceID. 3GPP 33.310 section 9.5.4.2 says that in a three level hierarchy the base station certificate and the intermediate certificate shall be included in the extraCerts field of the CMP request.

The following displays an example cmpforopenssl command to test Vendor CA authentication with a three level Vendor CA PKI:

./cmpclient --server 127.0.0.1 --port 8080 --path ejbca/publicweb/cmp/vendor --srvcert 3GPPCA.cacert.pem --ir --subject "C=SE,O=Test,CN=Network Element 32" --clcert nevcert.pem --newclcert nev-op-crt.der --newkey nev-op-key.pem --key nevkey.pem --extracert casubnevcert.pem

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).

Prerequisites

To complete the 3GPP PKI configuration and eNodeB enrollment, the following prerequisites must be fulfilled:

An Operator CA created in EJBCA

The Operator CA hierarchy can be either one or two levels deep (or deeper) and can use any algorithm matching the eNodeB capabilities. In the following example, an Operator Root CA is created that issues end entity certificates directly, using a prime256r1 EC Key and SHA256WithECDSA.

A certificate Profile and End Entity Profile created in EJBCA for Issuing the eNodeB (End Entity) Certificates

The certificate profile is configured to issue end entity certificates suitable for TLS client connections, this means that the Key Usage is suitable for the key type (different for RSA and EC) and Extended Key Usage clientAuthentication. Other fields should be specified as required by your certificate policy.

The end entity profile is configured to allow eNodeBs to enroll with:

• CN: For example 210305854210K8002536.vendor.com.
• OU: For example Wireless Network Product Line.
• O: For example Vendor.
• C: For example SE.
• DnsNames : For example 210305854210K8002536.vendor.com.

And should have the configured 3GPP CA and certificate profile selected as available CAs.

Do not select other CAs and profiles here as that affects possible needed access rules, see Using an External RA over Peers.

The Vendor Root CA Certificate from the eNodeB Vendor Imported in EJBCA

The following provides a sample three-level Vendor CA hierarchy with the Root CA. The following example uses ECDSA to make the certificate shorter to copy-paste, but RSA works just as well.

Note that Vendors are not restricted to having only one Vendor Root CA, but can have different Vendor CA hierarchies for different products lines, for example eNodeB vs SecGW.

Here is the VendorRootCAEC384.cacert.pem certificate for our example.

-----BEGIN CERTIFICATE-----
MIIB5zCCAY2gAwIBAgIIfIFBpHsapFAwCgYIKoZIzj0EAwMwRzELMAkGA1UEBhMC
U0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBS
b290IENBIEVDMzg0MB4XDTIwMTAxOTA2MjExMloXDTQwMTAxNDA2MjExMlowRzEL
MAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMM
FFZlbmRvciBSb290IENBIEVDMzg0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE
Pg1gVL60dcs+pI0xqdt+ZxFsi0z0PM/++tXy3CTN1MIL+UL7hjIbHZoKHDydDjvX
Jh2wNEvR1uby3XIwg0+zVaNjMGEwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAW
gBSK0LnIltrD+4XTciuLinXtYpk/yzAdBgNVHQ4EFgQUitC5yJbaw/uF03Iri4p1
7WKZP8swDgYDVR0PAQH/BAQDAgGGMAoGCCqGSM49BAMDA0gAMEUCIQDsFbCpZbxA
tPYrCaNm+8viymtxgW59rrUqbi4GweEqBQIgMvS0OeKVASGAeBIUoI3GBgszzVgj
M6MzBjOO586jzSs=
-----END CERTIFICATE-----

cat > VendorRootCAEC384.cacert.pem

In some cases, an intermediate (Sub CA) from the Vendor certificate must also be imported, see Variations.

CMP Alias

A CMP alias must be added according to the following:

• Name: 5GeNodeB (freely choosable label, but is part of the URL used by eNodeBs)
• CMP Client Mode
• CMP Authentication Module: EndEntityCertificate
• Extract Username Component: CN
• Vendor Certificate Mode: true
• Adding the Vendor Root CA as vendor CA
• Default CA: 5GCA
• Automatic Key Update: true

Pre-registering eNodeB

The eNodeB to be authorized for enrollment must be added to EJBCA in order to authorize this specific eNodeB to receive an Operator certificate to be able to communicate on the Operators network. The end entity can be added using the CLI, RA Web UI or using the WS or REST API.

The CN typically matches the serial number of the device to be enrolled. Often a DNSName is also added, in case the eNodeB should act as server-side in TLS communication. The password passed on the command line is not needed for the enrollment and can be set to a random value, or if password is not required in the end entity profile, can be set to 'null'.

bin/ejbca.sh ra addendentity --username 1234.primekey.com --dn "CN=1234.primekey.com,O=PrimeKey Mobile Operator,C=SE" --altname "DNSName=1234.primekey.com" --caname 5GCA --eeprofile=3GPP --certprofile=3GPP --type 1 --token USERGENERATED --password ZUhgGPuu-doesnt-matter-randomize

eNodeB Operation

To enroll to an Operator certificate, the eNodeB must send the Vendor certificates, eNodeB, and Sub CA, in the extraCerts field of the CMP request, the eNodeB certificate must be first in the chain according to 3GPP 33.310 section 9.5.4.2.

The following provides the eNodeBVendorKey.pem (device vendor private key), eNodeBVendorCert.pem (device vendor certificate), and VendorSubCAEC384.cacert.pem (vendor Sub CA certificate). 

In the eNodeB terminal, create the needed certificate files:

cat > eNodeBVendorKey.pem
-----BEGIN PRIVATE KEY-----
MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgUmy7YVUMGuemV637
Vcq91ZNL9WAnF56fC1dThaGy5T6gCgYIKoZIzj0DAQehRANCAASyrEYCkTX4ApjD
R9E36V63cUgkZwD4raKpGMZ6jO2RnfPjtcalGK1sDdlF+GSh9XpLul9GibPiDLIX
Ten4Un2I
-----END PRIVATE KEY-----

cat > eNodeBVendorCert.pem
-----BEGIN CERTIFICATE-----
MIIB2DCCAX2gAwIBAgIIVZHqvoM7h7wwCgYIKoZIzj0EAwMwRTELMAkGA1UEBhMC
U0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxGzAZBgNVBAMMElZlbmRvciBT
dWJDQSBFQzM4NDAeFw0yMDEwMTkwNjIyNTlaFw00MDEwMTQwNjIxMTJaMDwxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhQcmltZUtleTEaMBgGA1UEAwwRMTIzNC5wcmlt
ZWtleS5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASyrEYCkTX4ApjDR9E3
6V63cUgkZwD4raKpGMZ6jO2RnfPjtcalGK1sDdlF+GSh9XpLul9GibPiDLIXTen4
Un2Io2AwXjAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFOAbHblwsKqYhl4u5DX9
hBpNKAAWMB0GA1UdDgQWBBRln9C8ctMywHZ+Azk4IsZnu0HmXzAOBgNVHQ8BAf8E
BAMCB4AwCgYIKoZIzj0EAwMDSQAwRgIhAImjJNNR2LkSWBBmThF3SrhErXtFB5t6
T9AZPqRXnuGQAiEAt9RUxTqGc0d4olxtsMU7O/yJ/L2OayUruRjOOZZHLcc=
-----END CERTIFICATE-----

cat > VendorSubCAEC384.cacert.pem
-----BEGIN CERTIFICATE-----
MIIB5jCCAYugAwIBAgIIc8lyzz9D+tQwCgYIKoZIzj0EAwMwRzELMAkGA1UEBhMC
U0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxHTAbBgNVBAMMFFZlbmRvciBS
b290IENBIEVDMzg0MB4XDTIwMTAxOTA2MjE0MVoXDTQwMTAxNDA2MjExMlowRTEL
MAkGA1UEBhMCU0UxGTAXBgNVBAoMEFByaW1lS2V5IEZhY3RvcnkxGzAZBgNVBAMM
ElZlbmRvciBTdWJDQSBFQzM4NDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABP4c
764FiC2EPqHqkHmRn7OdQoinqWe73yKfBSdTxppnQntMW1oq4kkO1A9qxWgiBN4f
nvx/oByN38Pe1Sl0w1yjYzBhMA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAU
itC5yJbaw/uF03Iri4p17WKZP8swHQYDVR0OBBYEFOAbHblwsKqYhl4u5DX9hBpN
KAAWMA4GA1UdDwEB/wQEAwIBhjAKBggqhkjOPQQDAwNJADBGAiEAhWK79GK75Y++
uVLcF6TK2+FWvF0bN820Fwsdmzqsk1ACIQCkwGxvCmZ5RBclq3aWS37wnfucxqeU
6efhzZTOTcKwGA==
-----END CERTIFICATE-----

cat eNodeBVendorCert.pem VendorSubCAEC384.cacert.pem > VendorExtraCerts.pem

For initial enrollment, the eNodeB needs the CA certificate of the Operator CA, 3GPP CA. Using OpenSSL for simulation, you need it beforehand, but controlling the code on the eNodeB it can in thoery grab it from the caCerts field of the CMP response. Consult your eNodeB documentation for more information.

cat > Operator5GCA.cacert.pem
-----BEGIN CERTIFICATE-----
MIIB1TCCAXugAwIBAgIUdVQacClwDaymDHvc4Jur3EgSZ7QwCgYIKoZIzj0EAwIw
ODELMAkGA1UEBhMCU0UxGjAYBgNVBAoMEVByaW1lS2V5IE9wZXJhdG9yMQ0wCwYD
VQQDDAQ1R0NBMB4XDTIwMTAxOTA3NDk0NVoXDTMwMTAxNzA3NDk0NVowODELMAkG
A1UEBhMCU0UxGjAYBgNVBAoMEVByaW1lS2V5IE9wZXJhdG9yMQ0wCwYDVQQDDAQ1
R0NBMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEIv0auwTmMXCfj3nCsVJAIRCU
iC55jCLaKwoRu9Pa2S1ugeh66LbAV80A5WGiq+NkzJdr8c9lE/Hyz2W/KldoCKNj
MGEwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBQC57BXQLTWiCCPlaDY5QBA
1dpC7jAdBgNVHQ4EFgQUAuewV0C01oggj5Wg2OUAQNXaQu4wDgYDVR0PAQH/BAQD
AgGGMAoGCCqGSM49BAMCA0gAMEUCIC7J67/LLFW65QD5W1WP/SLD2ZhUVUTV2++k
31gbEYvwAiEA95pLBSW9gRD2zHVve6WCGO0JNq+AGWdHqUynR9SMVtE=
-----END CERTIFICATE-----

The eNodeB generates a new key pair to issue in the CMP initial request.

openssl ecparam -name prime256v1 -genkey -noout -out eNodeBOperatorKey.pem

Make the request to the CA (with hostname ejbca.example.com) and receive the issued Operator certificate back:

openssl cmp -cmd ir -server ejbca.example.com:8080 -path ejbca/publicweb/cmp/5GeNodeB \
-cert eNodeBVendorCert.pem -key eNodeBVendorKey.pem -certout eNodeBOperatorCert.pem -newkey eNodeBOperatorKey.pem \
-subject "/CN=1234.primekey.com/O=PrimeKey Mobile Operator/C=SE" sans "DNS=1234.primekey.com" -extracerts VendorExtraCerts.pem -srvcert Operator5GCA.cacert.pem -trusted Operator5GCA.cacert.pem \
-implicit_confirm

A command line output similar to the following is shown when the (simulated) eNodeB stores the Operator certificate.

user@host:~/cmp$ openssl cmp -cmd ir -server ejbca.example.com:8080 -path ejbca/publicweb/cmp/5GeNodeB -cert eNodeBVendorCert.pem -key eNodeBVendorKey.pem -certout eNodeBOperatorCert.pem -newkey eNodeBOperatorKey.pem -subject "/CN=1234.primekey.com/O=PrimeKey Mobile Operator/C=SE" -extracerts VendorExtraCerts.pem -svrcert Operator5GCA.cacert.pem -srvcert Operator5GCA.cacert.pem -trusted Operator5GCA.cacert.pem -implicit_confirm
setup_client_ctx:apps/cmp.c:1980:CMP info: will contact http://ejbca.example.com:8080/ejbca/publicweb/cmp/5GeNodeB
CMP info: sending IR
CMP info: received IP
save_free_certs:apps/cmp.c:2029:CMP info: received 1 enrolled certificate(s), saving to file 'eNodeBOperatorCert.pem'

You may specify different altNames, using the -sans switch, but unless override options are specified in the certificate profile, these are ignored and only the values registered in the end entity in EJBCA are used. For security reasons, values sent from the client are by default not trusted.

Renewal

When renewing the eNodeB Operator certificate the eNodeB generates a new key pair and issues a CMP renewal request, signed with the old Operator certificate. Here the old Operator certificate and Operator Sub CA certificate are used as extraCerts (see 3GPP section TODO). Since we are signed directly by the Operator Root CA, we only need to include the old TLS certificate in extraCerts, the Root CA is already trusted by the server.

openssl ecparam -name prime256v1 -genkey -noout -out eNodeBOperatorKey-new.pem

Renewing the certificate, the (simulated) eNodeB sends a CMP KeyUpdate request, signed with the revious operator key and certificate.

openssl cmp -cmd kur -server ejbca.example.com:8080 -path ejbca/publicweb/cmp/5GeNodeB \
-cert eNodeBOperatorCert.pem -key eNodeBOperatorKey.pem -certout eNodeBOperatorCert-new.pem -newkey eNodeBOperatorKey-new.pem \
-extracerts eNodeBOperatorCert.pem -trusted Operator5GCA.cacert.pem \
-implicit_confirm

This should result in similar output to this on the command line, when the (simulated) eNodeB stores the Operator certificate.

user@host:~/cmp$ openssl cmp -cmd kur -server ejbca.example.com:8080 -path ejbca/publicweb/cmp/5GeNodeB -cert eNodeBOperatorCert.pem -key eNodeBOperatorKey.pem -certout eNodeBOperatorCert-new.pem -newkey eNodeBOperatorKey-new.pem -extracerts eNodeBOperatorCert.pem -trusted Operator5GCA.cacert.pem -implicit_confirm
setup_client_ctx:apps/cmp.c:1980:CMP info: will contact http://ejbca.example.com:8080/ejbca/publicweb/cmp/5GeNodeB
CMP info: sending KUR
CMP info: received KUP
save_free_certs:apps/cmp.c:2029:CMP info: received 1 enrolled certificate(s), saving to file 'eNodeBOperatorCert-new.pem'

Neither CMP (RFC4210) nor 3GPP 33.310 mandate any specific times when key update can occur. Hence an eNodeB may send a Key Update Request (kur) at any time, as long as it is authenticated using the old certificate/key.

Implicit Confirm

The above examples use of the flag Implicit_confirm, which lets the client (eNodeB) get the Operator certificate without sending a CMP Confirm message back to the CA. Regardless of the eNodeB uses implicit_confirm or not, EJCBA will answer properly. It is then important that the -srvcert parameter to the openssl command is provided, as it will otherwise target the CertConf message to the wrong CA.

Using an External RA over Peers

When using an External RA in front of EJBCA, using Peer Connectors from the CA, the RAs Peer Connection certificate limits the capabilities of the RA using access roles and rules. To complete enrollment of eNodeB certificates over a Peer Connection, the Peer Connectors Role must include access rules for:

• Operator Issuing CAs
• Issuing End Entity Profiles
• Vendor CAs as added as External CAs in EJBCA

If you have any missing access rules you will get log entries like the following in the CA log:

2020-10-15 13:05:55,593 INFO
[org.cesecore.authorization.AuthorizationSessionBean] (EJB default -
34) Authorization failed for 10.11.96.4 [via] CN=primepki-peer1,C=SE of type AlwaysAllowLocalAuthenticationToken for resource
/ca/1471073378

As of EJBCA 7.4.3, an external CA cannot be added using the simple access rule configuration in Peer Systems > Authorized Request but must be added to the role in Advanced Mode access rules. There is a danger when using the simple Authorized Request button to remove the advanced access rules, so this button cannot be used until External CAs can be added in this simplified configuration mode.

Variations Discovered

Vendor CA Hierarchies in extraCerts

Vendor CA hierarchies can be either two or three levels, i.e. either Root CA→DeviceID or Root CA→Sub CA→DeviceID. 3GPP 33.310 section 9.5.4.2 says that in a three-level hierarchy the base station certificate and the intermediate certificate shall be included in the extraCerts field of the CMP request. Albeit this is stated in the standard, some variations occur.

1. Fortinet SecGW only includes the end entity certificate in the extraCerts field of the request. This means that the Vendor Sub CA must be added as Vendor CA in the CMP alias in order to verify the end entity certificate chain.
   This means that both the Vendor Root CA and Vendor Sub CA must be imported in EJBCA as External CAs, and only the Sub CA added as Vendor CA in the CMP alias.
2. Huawei eNodeBs also includes the Root CA certificate, as well as the end entity and Sub CA certificates, in the extraCerts field of the request. The Root CA certificate is redundant but works well when configuring the Root CA as Vendor CA in the CMP alias (as the Root CA certificate can be verified by the Root CA certificate).
   This means that only the Vendor Root CA must be imported in EJBCA as External CAs, and only the Vendor Root CA added as Vendor CA in the CMP alias.
3. Ericsson use a four level hierarchy, and send all of them in the extraCerts field. This works (from EJBCA 7.4.3.2) for the same reason as above.
   This means that only the Vendor Root CA must be imported in EJBCA as External CAs, and only the Vendor Root CA added as Vendor CA in the CMP alias. in EJBCA
   If you have an Operator CA with a Root and a Sub CA, in the BBU (Base Band Unit) you configure the SubCA subject DN as enrollmentAuthorityName (CMP recipient and issuer of the end entity certificate) and the Root CA fingerprint (SHA-1) as enrollmentCaFingerprint (trust anchor).
   The configuration of enrollmentAuthorityName in the BBU has to be very exact matching how the internal PKI client displays the DN, which is known to have some spaces, i.e. "CN = ranCA,OU = RAN,O = PrimeKey,C = SE". If this exact format is not correct you will get an error from the BBU with "No valid ra certificate found".

Common Name of issued Operator certificates

The CN of the eNodeB Vendor certificate may for example be 210305854210K8002536.vendor.com, but the desired CN of the Operator issue eNodeB certificate is only 210305854210K8002536. This is possible to achieve by pre-registering the end entity with CN 210305854210K8002536, but setting the username of the end entity to 210305854210K8002536.vendor.com. When an enrollment request comes in, the end entity is looked up based on the full subjecDN of the request (which matches the Operators desired name) and hence the username is found regardless if it matches this CN or not, but when verifying the Vendor certificate the username is mapped from the CN in the vendor certificate and hence the username matches the CN of the Vendor certificate.

Other fields than the CN can be used to match a Vendor certificate to an end entity username, but using CN is the most common and used in this example.

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 micro (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.