pbe

This type of protection of the response message can be used only when the request was authenticated using HMAC authentication module. The parameters used for the pbe protection are based on the parameters used in the received HMAC authentication.

signature

The CA used to handle the CMP request signs the CMP response message using the same protection algorithm specified in the CMP request. If a conflict occurs between the protection algorithm in the request and the CA's signature algorithm, the CA's key algorithm will be used in combination with a digest algorithm based on the protection algorithm in the CMP request. If a conflict occurs even on the digest algorithm level, a default digest algorithm will be used. For example, if the CMP request uses the protection algorithm ECDSA with SHA1 and the CA's signature algorithm is RSA with SHA256, the CMP response will be signed using RSA with SHA1.

The signature type of response protection can be used regardless of what authentication module was used to authenticate the CMP request.

CMP messages are signed using the CAs signature key. Verification of the signed CMP messages hence typically assumes that overly strict enforcement of Key Usage in CA certificate is not in place (similar to allow signing of OCSP responses under the CRLSign Key Usage).

CMP Response Additional CA Certificates

Additional CA certificates available in EJBCA can be added to the CMP response message (CertRepMessage.caPubs). Independent from the additional CA certificates configured, the signing CA certificate is returned at index 0 every time.

PKI Message Response Additional CA Certificates

Additional CA certificates available in EJBCA can be added to the CMP response wrapping PKI message (PKIMessage.extraCerts). Independent from the additional CA certificates configured, the response message signing CA certificate chain is included from index 0 every time.

User look-up

Initialization and certification requests uses the CRMF request message (RFC4211).

Users can be looked up from the request in different ways, as configured in the Admin GUI under CMP Configuration. By default the subject DN from the certTemplate in the request is used to look up the used in EJBCA. You can also configure EJBCA to use the CN or the UID from the subject DN as the username in EJBCA.

Vendor CA Authentication

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

If the end entity has a Vendor certificate with which it should identify itself for initial enrollment, as specified in 3GPP for example, it can also do that. In this case the CA issuing the end entity certificate is not the same as the Vendor CA. The vendor CA must be imported in EJBCA as an External CA (Admin GUI>Import CA certificate). This is described in detail in the integration guide for 3GPP available with EJBCA Enterprise.

KeyID

Instead of specifying an RA End Entity Profile, RA Certificate Profile, and/or RA CA Name explicitly when creating a CMP alias, you can choose the KeyID option. When this option is selected, the value of the senderKID field in the CMP request is used instead of the corresponding entry in the CMP alias (which is set to KeyID). The client sending the CMP request must ensure the correctness of the CMP request, for example. that the CA and Certificate Profile is authorized by the End Entity profile.

KeyID is useful when you want to issue different types of certificates using a single CMP alias. The EJBCA cmpclient tool allows you to set KeyID explicitly using the --keyid argument.

Multiprotection Support

In RA mode, it is also possible to send a CMP request with multiple signatures. EJBCA implements this feature following the specifications in RFC4210. In cases where an end entity sends a protected PKI message to an RA, the RA forwards that message to a CA, attaching its own signature for protection. This is accomplished by nesting the entire message sent by the end entity within a new PKI message.

Sample code for a signature protected NestedMessageContent message:

Sample Config

A sample configuration of EJBCA to allow an RA to request certificates for users. The RA uses password based mac (pbe) protection of CMP messages with password 'password'. Users will be created using UID from the request DN and with a prefix, so the resulting username will be: cmp<UsersUID>. End entity profiles names CMP_ENTITY and CMP_CERT is created in EJBCA allowing the request DN.

Using one authentication secret per CA

Edit each CAs that should be used for CMP certificate issuance and enter new CMP RA Authentication Secret. There should be no parameter specified for the HMAC authentication module, otherwise, this parameter will override the CA specific configuration.

In Client Mode

In client mode, the only end entity that is allowed to send a KeyUpdate request is the end entity that owns the certificate to be renewed. This end entity should be the one signing the request and attaching its "old" certificate (that has not been expired yet) to the CMP message. The CA will only look into the certificate in extraCert to find which certificate is to be updated.

In RA Mode

In RA mode, an administrator is allowed to send a KeyUpdate request on behalf of an end entity. The adminstrator should be the one signing the request and attaching his own certificate to the CMP message. Either only the subjectDN or both the subjectDN and the issuerDN of the certificate to be updated are specified in the CertificateTemplate field in the CMP message.

In order for this request to succeed, the administrator sending the update request has to be authorized to perform this operation. Also, EndEntityCertificate authentication module would have to be set among the configured authentication modules.

EJBCA cmpclient

ENTERPRISE EDITION This is an EJBCA Enterprise Edition (EE) feature.

EJBCA Enterprise includes a java command line client for CMP, used to request, renew and revoke certificates.

To build and run the cmpclient client, use the following:

An example workflow when you have one CMP alias in RA mode (raalias), using password based authentication of the RA, and another CMP alias (clientupdate) in client mode allowing updates using certificate authentication.

AET BlueX

CMP has been tested with BlueX from AET Europe. From EJBCA's point of view BlueX functions as an RA with the same configuration options as for jCert.

Aventra

CMP has been tested with Aventra card management system. Same configuration as above.

BouncyCastle

CMP has been tested with BouncyCastle CMP classes, available in BC 1.46 or later. Both client and RA mode should work.

Sample code for a HMAC protected (RA mode) certificate request (initial) message:

Sample code for a HMAC protected (RA mode) revocation request message:

Sample code for a signature protected (Client mode) message:

CMP for OpenSSL

CMP has been tested with cmpforopenssl. Cmpforopenssl is submitted for inclusion in OpenSSL and the code is available on GitHub on https://github.com/mpeylo/cmpossl. For documentation for the command, refer to https://github.com/mpeylo/cmpossl/blob/cmp/doc/man1/cmp.pod and for a Quick Start guide, tested with EJBCA, refer to https://github.com/mpeylo/cmpossl/wiki/Quick-Start.

The old client tool in cmpforopenssl was called cmpclient, while the new one is in the openssl command itself. Only the new one is documented here. It works with EJBCA CMP in both RA mode and client mode.

Cryptlib

CMP has been tested with CryptLib. An old test program for running CryptLib against EJBCA can be downloaded from download.primekey.com.

Huawei Pico 3GPP

The Huawei Pico cell is confirmed to successfully receive operator certificates using CMPv2.

In order to authenticate the Pico cell for initial enrollment the Huawei Vendor CA must be imported in EJBCA. Go to Certificate Authorities in the Admin GUI and import Huawei Equipment Root CA as External Certificate Authority by clicking Import CA Certificate.

RSA jCert

CMP has been tested using RSA jCert toolkit for initialization requests. To run this as an RA you should configure CMP with:

• CMP Operational Mode : RA Mode

• Allow RA Verify Proof-of-Possession : check

• CMP Response Protection : pbe

• CMP Authentication Module : HMAC

• CMP Authentication Parameters : your shared password

• and other configurations you want for your RA.

Enrolling Device with HMAC password

A typical PKI work-flow using CMP involves enrolling a device with a certificate and then having the device automatically renew the certificate when it is about to expire.

1. Generate a key pair

2. Initial enrollment of client certificate using a one-time enrollment code

3. Generate a new key pair

4. Renew with a new certificate for the new key pair, authenticated using the old key pair and certificate

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

This works with a default cmpalias (named cmp) configured with parameters:

1. Generate a key pair:

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

2. Initial enrollment:
   Before initial enrollment you add a new End Entity in EJBCA, in this example with user name cmptest and subject DN 'CN=cmptest', and enrollment code 'CMP-pwd'.

   $ ./openssl cmp -cmd ir \

   -server ejbca-server:8080 \

   -path ejbca/publicweb/cmp \

   -srvcert certs/3GPPCA.pem \

   -user cmptest \

   -pass CMP-pwd \

   -newkey certs/cl_key.pem \

   -certout certs/cl_cert.pem \

   -subject "/CN=cmptest"

3. Generate a new key pair:

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

4. Renew with a new certificate:

   $ ./openssl cmp -cmd kur \

   -server ejbca-server:8080 \

   -path ejbca/publicweb/cmp \

   -srvcert certs/3GPPCA.pem \

   -key certs/cl_key.pem \

   -cert certs/cl_cert.pem \

   -newkey certs/cl_new_key.pem \

   -certout certs/cl_new_cert.pem

Enrolling Device with Vendor Certificate

A PKI work-flow 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. The 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 thl 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 keystore 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 VendorCert.pem -key VendorKey.pem -certout ipsec_cert.pem -newkey ipsec_key.pem \

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

   -implicitconfirm

    

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

   -cert VendorCert.pem -key VendorKey.pem -certout tls_cert.pem -newkey tls_key.pem \

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

   -implicitconfirm

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 \

   -implicitconfirm

    

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

   -implicitconfir

Backends

The CMP Proxy can use different connection backends to the CA. The most usable are:

• Direct HTTP connection: The CMP proxy creates a new HTTP connection to the CA, and return the response to the client, through the client connection, after receiving the response from the CA.

• External RA connection: The CMP proxy creates an external RA msg in an external RA database, which the CA polls. When the CA stores a return message in the external RA database, this is picked up by the CMP proxy and returned to the client.

CMP Proxy Message Validation

The CMP proxy have options for verifying CMP message protection in the proxy, before passing the message to the CA. Password based MAC and Signature protection can be verifies. These validations can be activated in _cmpProxy.properties{_}. CMP message headers only allow one form of protection per message, so activating both modes will allow messages to use either form. Rejected messages will never pass the CMP Proxy, but will rejected in the same form as if they had been rejected from the CA.