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:
|CMP Operational Mode||Client Mode|
|CMP Authentication Mode||EndEntityCertificate|
|Vendor Certificate Mode||Use and specify the name of the Vendor CA|
|Allow Automatic Key Update||Allow|
|Allow Certificate Renewal with Same Keys||Allow|
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:
|CMP Operational Mode||RA Mode|
|CMP Authentication Mode||EndEntityCertificate, and specify the issuer of the certificate in the extraCerts|
|RA Name Generation Scheme||DN and specify the DN part to be usee as the username|
|Allow Automatic Key Update||Allow|
|RA End Entity Profile||The name of the End Entity Profile to be used when adding Entities representing the substations|
|RA Certificate Profile||ProfileDefault or the name of the Certificate Profile to be used when creating certificates for the substations|
|RA CA Name||ProfileDefault or the name of the CA to be used when creating End Entities and certificates for the substations|
|Allow Automatic Key Update||Allow|
|Allow Certificate Renewal with Same Keys||Allow|
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.
- 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.
- The Vendor Root CA is trusted for initial enrollment, for devices pre-registered in EJBCA with parts of the DN (usually device serial number).
- 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.
- Generate two new key pairs on the device
- Initial enrollment of an IPSEC Certificate for the new key on the device uses certificate authentication with the Vendor Certificate on the device.
- Initial enrollment of a TLS Certificate for the new key on the device uses certificate authentication with the Vendor Certificate on the device.
- Generate two new key pairs on the device
- Renew the IPSEC certificate for the new key pair, authenticated using the old key pair and certificate
- 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
Generate key pairs:
$ ./openssl genrsa -out certs/ipsec_key.pem 2048 $ ./openssl genrsa -out certs/tls_key.pem 2048BASH
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_confirmBASH
Generate new key pairs:
$ ./openssl genrsa -out certs/ipsec_new_key.pem 2048 $ ./openssl genrsa -out certs/tls_new_key.pem 2048BASH
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_confirmBASH
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 188.8.131.52 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).
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
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
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
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 184.108.40.206.
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'
-sansswitch, but unless
overrideoptions 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.
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.
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
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 220.127.116.11 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.
- 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.
- 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.
- Ericsson use a four level hierarchy, and send all of them in the extraCerts field. This works (from EJBCA 18.104.22.168) 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.
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)
- Huawei Femtocell BTS3202H, 3202E (CMP)
- Juniper SRX (SCEP)
- NEC eNB.
- Nokia Networks ENB (CMP)
- Nokia Networks Flexi Zone micro (CMP)
- Casa security gateway and Airspan gNodeB/CBSD units(4G & 5G)