The following includes information about the Certificate Management Protocol (CMP) and how it works with EJBCA. For guides, configurations and workflows using CMP, see the CMP Operations Guide.

CMP and 3GPP/4G/LTE Configuration Guide
CMP Alias Configuration
Configuration
CMP over HTTP
CMP over TCP
CMP Message Authentication
CMP Response Messages
Client Mode for CMP
RA Mode for CMP
Key Update Request (kur)
Proof of Possession
Server Generated Keys
Certificate Validity
Certificate Key Usage
Interoperability / Tested Libraries and Devices
CMP Error Messages
CMP Proxy
CMP Proxy Error Messages

The Certificate Management Protocol (CMP) is an Internet protocol used for obtaining X.509 digital certificates in a public key infrastructure (PKI). It is described in RFC4210 and is one of two protocols to use the Certificate Request Message Format (CRMF), described in RFC4211.

EJBCA supports the following messages of the complex CMP protocol (RFC4210):

Initialization request (ir)
Certification request (cr)
Certification confirm (certConf)
Revocation request (rr)
NestedMessageContent (nested)
Key Update Request (kur)

Certificate requests use the CRMF (RFC4211).

EJBCA can work in the following modes with CMP:

Client mode: Default. 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.
RA mode: 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.

In RA mode, EJBCA supports several CAs and profiles based on the use of configuration alias specified in the URL used (see CMP over HTTP).

The EJBCA implementation of Certificate Confirm (certConf) does not strictly adhere to RFC4210. The RFC4210 sections 5.3.18, 5.2.8, and 4.2.2.2 specify certConf and that a certificate must be revoked if not accepted. EJBCA will not revoke certificates that are not accepted. In fact, certConf is mostly ignored, but a PKI Confirm message (RFC4210 section 5.3.17) is sent back to the client. The CA will never revoke a certificate based on a certConf message, or the lack thereof. Generally, CMP use cases would benefit from using the implicitConfirm method specified in section 5.1.1.1 of RFC4210.

Using CMP with EJBCA supports high transaction volumes with multiple concurrent transactions, enabling for high speed (hundreds of requests/second). However, if your CMP alias is configured for static/re-use of End Entities, making parallel requests to issue certificates for the same End Entity is not supported and will result in one of the transactions failing with database transaction error, indicating that the concurrent transactions tried to modify the same End Entity at the same time. This may be improved and implemented in a future version of EJBCA, but as of EJBCA 7.3.0, it is not a supported mode of operation.

CMP and 3GPP/4G/LTE Configuration Guide

To read more about using CMP with 3GPP in EJBCA, see Using CMP with 3GPP.

CMP Alias Configuration

CMP Operational Mode: Client mode
CMP Authentication Module: EndEntityCertificate
Extract Username Component: CN
Use Vendor Certificate Mode: Use and add CANevRoot as Vendor CA

Configuration

Configuring CMP is done in the CA UI, under CMP Configuration. To be able to edit the CMP configuration, you require edit_systemconfiguration access.

CMP over HTTP

By default, EJBCA supports CMP over the http transport protocol. The URL for the CMP servlet is: http://127.0.0.1:8080/ejbca/publicweb/cmp/ALIAS.

ALIAS is a configuration alias specifying the set of CMP configurations to be used when handling a request sent through this specific URL. ALIAS can be any alphanumeric string and you can specify as many aliases as you need in the Admin GUI.

Example: http://127.0.0.1:8080/ejbca/publicweb/cmp/cmpalias

Any CMP request sent through this URL will use the CMP configurations associated with the alias cmpalias.

CMP over TCP

You can enable a CMP TCP service by changing the option cmp.tcp.enabled in the conf/cmptcp.properties file. Ensure to copy the conf/cmptcp.properties.sample to conf/cmptcp.properties first. When re-deploying EJBCA, a TCP listener is started on the default port for CMP over TCP. You must run the application server as root to use the default port, since it is a low port (<1024). Refer to the documentation in conf/cmp.properties for information about configuration options for TCP. We recommend using a non standard port > 1024.

CMP requests sent over TCP will be using CMP configurations associated with the configuration alias tcp. Note that a CMP configuration alias with the name tcp does not exist per default. It has to be created (and/or altered) using the CA UI before any CMP request arrives through TCP.

EJBCA will cease to support CMP over TCP, and it is strongly recommended to use CMP over HTTP instead.

CMP Message Authentication

EJBCA supports four modules for message authentication, configured in the CA UI under CMP Configuration.

The supported modules are either password extractors or PKIMessage verifiers:

Module	Description
Password extractors (client mode only)
RegTokenPwd	Extracts the password from the CMP request through the means of a regToken control (id-regCtrl-regToken) in the CRMF message. The regToken is a UTF8String containing the user password as registered in EJBCA. This module requires no parameters.
DnPartPwd	Extracts the password from the subjectDN of the user the request concerns. As a parameter, the DN part that contains the password should be specified. For example, if the subjectDN is "CN=name,C=se,UID=PASSWORD", the parameters should be set to "UID".
PKIMessage verifiers
HMAC	This module uses a shared secret to authenticate the CMP message: In RA mode, the shared secret is set as a parameter to this module. If no parameter is specified, EJBCA uses the shared secret specified in the CA under CMP RA Authentication Secret. In client mode, the pre-registered end entity will be looked up in the database, and if there was a clear text password there, this password will be used to authenticate the message. If there is no clear text password associated with that end entity, the authentication will fail.
EndEntityCertificate	When the EndEntityCertificate module is used, the request sender should attach his certificate in the extraCert field in the PKIMessage and then sign the message with his private key. In client mode, a user may only send a CMP request regarding his/her own certificate. EJBCA will then check if the certificate in extraCert does exist in its database and verifies that it belongs to the sender before verifying the signature. No parameters should be specified for this module in client mode. In RA mode, as a parameter, this module expects the name of the CA that has issued the certificate in the extraCert field. If a parameter is specified, EJBCA checks if the certificate in extraCert does exist in the database, that it was issued by the right CA (the CA specified as a parameter), and that it belongs to a registered administrator in EJBCA with the right authorizations to perform the operations required in the request. If no parameter is specified, none of the mentioned checks will be performed. However, EJBCA will expect the CMP request to have been previously authenticated by other ways, for example, by sending the request inside a signed NestedMessageContent.

You can specify more than one module in the CA UI CMP Configuration page by separating the modules with a semicolon ";". If specifying multiple modules, the first module is used for authentication testing. If the first module fails, the second module is used for authentication testing, and so on until a successful authentication is done or all alternatives fail.

CMP Response Messages

When a CMP request is successful, EJBCA returns a protected CMP response message. The protection type of the response message can also be configured in the CA UI under CMP Configuration. EJBCA supports the following types of response message protection: pbe and signature.

If a CMP request fails, EJBCA returns an unprotected, unencrypted CMP error message.

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

The CA certificates returned with the CMP response message can be configured in the CMP configuration. For a list of CMP error codes, see CMP Error Messages.

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.

Client Mode for CMP

Client mode is used when the CMP client will act as an End Entity to EJBCA. This means that the End Entity must be pre-registered in EJBCA and that the client request is authenticated with this pre-registered end entity before a certificate is issued. This is the same authentication model as for regular enrollment, i.e. browser enrollment, using a username/password combination.

The users DN is deducted from the request according to rules configured.
The username in EJBCA must be pre-registered.
The password for the user in EJBCA must be passed in the request (one-time password).
If the Certificate Profile allows it, keyUsage, validity and extensions are also taken from the CertTemplate in the request message.
Signature POPO is used.

After the user has been authenticated in EJBCA, a certificate is generated as usual and sent back to the client.

To use client mode, no particular configuration is needed, since this is the default mode.

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 CA UI 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 This is an EJBCA Enterprise 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 (CA UI → Import CA certificate). This is described in detail in the integration guide for 3GPP available with EJBCA Enterprise.

RA Mode for CMP

RA mode is used when the CMP client will act as an RA to EJBCA. When the RA sends a certificate request to EJBCA, no user needs to be pre-registered in EJBCA. When EJBCA receives the request, the message will be authenticated. After it has been authenticated, a user is created, and a certificate is issued.

The users DN is taken from the CertTemplate in the request message send from the RA (i.e. the DN requested by the RA).
The username in EJBCA is generated according to the options configured.
The password for the user in EJBCA is random.
If the Certificate Profile allows it, keyUsage, validity and extensions are also taken from the CertTemplate in the request message.
raVerify POPO is used.
Messages are authenticated using one of the configured authentication modules.

After the user has been created in EJBCA, a certificate is generated as usual and sent back to the RA, who will distribute it to the end-user.

If the same username is constructed (for example UID) as an already existing user, the existing user will be modified with new values for profile etc, and a new certificate will be issued for that user.

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.

Note that KeyID is only visible when the number of available options is at least two.

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. For a sample of what such a message might look like, se the CMP Operations Guide.

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.

CMP Operational Mode : RA Mode
Allow RA Verify Proof-of-Possession : check
CMP Response Protection : pbe
CMP Authentication Module : HMAC
CMP Authentication Parameters : password
RA Name Generation Scheme : DN
RA Name Generation Parameters : UID
RA Name Generation Prefix : cmp
RA End Entity Profile : CMP_ENTITY
RA Certificate Profile : CMP_CERT
RA CA Name : ManagementCA

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.

Key Update Request (kur)

Also known as the Certificate Update request. When a key pair is due to expire, the relevant end entity may request a key update. The CMP request is signed, and the sender attaches their certificate in the extraCert field in the CMP message.

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

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

Proof of Possession

Proof of Possession (POP) is another part where CMP has numerous of options. The following POPs in the CRMF are supported by EJBCA:

raVerify: If Allow RA Verify Proof-of-Possession is selected, EJBCA will support the raVerify POP and in that case not do any verification of POP. By default false, because the standard does not recommend this option.
signature: here the PublicKey is in the CertTemplate and the signature is calculated over the CertReqMsg.certReq (the standard procedure when the CertTemplate contains the subject and publicKey values).
signature with POPOSigningKeyInput: here the PublicKey and subject DN is in POPOSigningKeyInput, possibly just copied from the CertTemplate. The signature is calculated over the POPOSigningKeyInput (if the values are also in the CertTemplate they must be identical).

Currently these are the POPOs supported by EJBCA, so if you do not use raVerify or signature your request will fail because POPO is not verified.

Server Generated Keys

CMP allows clients to request server generated keys, using one of the following in the CRMF certificate request:

Leaving out the (optional) request public key in the CRMF request.
Adding a subjectPublicKeyInfo containing an AlgorithmIdentifier followed by a zero-length BIT STRING for the subjectPublicKey (RFC4210 Appendix D.4).

These options enable a large number of choices and taking into consideration that the server wants to restrict what type of keys the clients can request and certify, there are a number of rather strict rules and business logic used by EJBCA. The following list highlights these choices.

Note that the following only applies if server generated keys are enabled in the CMP alias configuration. Use of server generated keys are by default disabled, and the default behavior is thus that all request for server generated keys are denied.

If the request does not contain a request public key, key generation options are taken from the certificate profile that will be used to issue the certificate:
- The certificate profile must contain only one allowed key algorithm and one allowed key specification, for example RSA 1024 or ECDSA secp256r1.
- If there is not a single distinct choice, the request will be denied, and an error returned to the client.
If the certificate profile contains a subjectPublicKeyInfo with the RSA algorithmId (rsaEncryption = 1.2.840.113549.1.1.1) the certificate profile must contain a single choice of key sizes allowed.
- If there is not a single distinct choice, the request will be denied
If the certificate profile contains a subjectPublicKeyInfo with the ECDSA algorithmId (id_ecPublicKey = 1.2.840.10045.2.1), the subjectPublicKeyInfo must contain parameters where two choices are allowed:
- implicitlyCA: The certificate profile must contain a single choice of curves allowed, otherwise the request will be denied.
- namedCurve: With the OID of a supported named curve, which is among the allowed curves in the certificate profile.

These rules allow the CA administrator to control what server generated keys the CA will generate and return to the client, and can be summarized as:

A distinct choice of a single key algorithm and key size/curve, defined in the certificate profile.
A choice of a single RSA key size and a set of EC curves, defined in the certificate profile and selected by the client in the request.

Currently, RSA and EC keys are supported.

In order to support server generated, the client must include a id_regCtrl_protocolEncrKey in the request, containing a public key that the server will use to encrypt the private key returned in the response.

Server generated keys are returned in the CertifiedKeyPair.privateKey field in the response, as defined in the RFC4210 sections 5.3.4 and D.4. The EncryptedValue will contain the private key, encrypted using AES256 with a random symmetric key, in turn wrapped using the public key in id_regCtrl_protocolEncrKey (RFC4211 Appendix B have more details on the EncryptedValue).

Code example in Java for requesting server generated keys can be found in the test method CrmfRequestTest.test12ServerGeneratedKeys().

Certificate Validity

Generally, the validity period of issued certificates is controlled by the certificate profile. If you enable Allow validity override in the certificate profile, and the CMP initialization- or certification request contains a validity time in the CRMF request template, this validity period will be used.

Certificate Key Usage

Generally, the key usage extension of issued certificates are controlled by the certificate profile. If you enable Allow Key Usage Override in the certificate profile, and the CMP initialization- or certification request contains a key usage in the CRMF request template, this key usage will be used.

Interoperability / Tested Libraries and Devices

EJBCA's cmpclient

ENTERPRISE This is an EJBCA Enterprise 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:

$ ant cmpclient
$ cd dist/cmpclient
$ java -jar cmpclient.jar
$ java -jar cmpclient.jar crmf --help

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.

$ java -jar cmpclient.jar crmf --dn "CN=tomas" --url http://192.168.122.230:8080/cmpProxy/raalias --authparam password --reqnewkeyspec RSA2048
$ openssl pkcs12 -export -inkey dest/tomas-key.pem -in /dest/tomas.pem -certfile ManagementCA.cacert.pem -name tomas -out dest/tomas.p12
$ java -jar cmpclient.jar update --dn "CN=tomas" --url http://192.168.122.230:8080/cmpProxy/clientupdate --keystore dest/tomas.p12 --keystorepwd foo123 --extraCertsFriendlyName tomas --includepopo --reqnewkeyspec RSA2048
$ openssl x509 -in dest/tomas.pem -text
$ java -jar cmpclient.jar revoke --issuer "CN=ManagementCA,O=EJBCA Sample,C=SE" --serno 17b9a7b8ce44b3fa --url http://192.168.122.230:8080/cmpProxy/raalias --authparam password

You can use a https URL with the cmpclient, but you may need to provide a truststore to Java in order for the client to verify the server certificate. The truststore contains the Root CA certificate of the server certificate chain.

java -Djavax.net.ssl.trustStore=truststore.jks -jar cmpclient.jar crmf --dn "CN=tomas" --url https://ejbca.example.com:8442/ejbca/publicweb/cmp/cmpra --authparam password --reqnewkeyspec RSA2048

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. For sample implementations of client messages using BouncyCastle, see the CMP Operations Guide.

CMP for OpenSSL

OpenSSL includes CMP from version 3.0, i.e. cmpforopenssl below is merged into OpenSSL main and is available in OpenSSL Git (or a release when available on your platform).

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.

See the CMP Operations Guide for more information about commands for cmpforopenssl.

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.

CMP Alias Settings

CMP Operational Mode - Client
CMP Authentication Module - EndEntityCertificate only
Extract Username Component - CN
Vendor Certificate Mode - Use
List Of Vendor CAs - Huawei Equipment Root CA
CMP Response Protection - Signature
CMP Response Additional CA certificates - Leave blank
PKI Message Response Additional CA certificates - Leave blank
Certificate Confirmation Default CA - Use whatever CA is configure in the End Entity
Automatic Key Update - Checked
Certificate renewal with same keys - Checked
Allow Server Generated Keys - Unchecked
Nested Message Trusted Certificates Path - Leave blank

End Entity Profile Settings

Batch Generation - Use
Subject DN Attributes, CN - Required
Default and Available Certificate Profiles - Set to your CMP Certificate profile
Default and Available CAs - Set to the Issuing CA that you have set in CMP Certificate Confirmation Default CA
Default Token - User Generated

Certificate Profile Settings

Available CAs - Set to the Issuing CA that you have set in CMP Certificate Confirmation Default CA

Apache configuration

Certain Pico devices do not allow for a URL to a CMP host. If this is the case, we recommend running apache in front of the EJBCA JBoss/WildFly application server. You can add in this configuration to an Apache to have it redirect to the EJBCA CMP URL.

Listen 8080
<VirtualHost *:8080>
    DocumentRoot /var/www/html/
    # Disallow any HTTP method that is not HEAD, GET or POST
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} !^(HEAD|GET|POST)$ [NC]
    RewriteRule .* - [F,L]
    #Since we are adding an additional port we can redirect all traffic to the CMP alias
    ProxyPass "/"      "ajp://localhost/ejbca/publicweb/cmp/3gpp" keepalive=On ping=500ms retry=1 timeout=300
    ProxyPassReverse "/" "ajp://localhost/ejbca/publicweb/cmp/3gpp"
</VirtualHost>

RSA jCert

CMP has been tested using RSA jCert toolkit for initialization requests. To run this as an RA, configure CMP according to the following:

CMP Operational Mode: RA Mode
Allow RA Verify Proof-of-Possession: enabled
CMP Response Protection: pbe
CMP Authentication Module: HMAC
CMP Authentication Parameters: your shared password
and other configurations you want for your RA.

CMP Error Messages

If issues occur during CMP processing, different CMP error messages or HTTP error codes are returned depending on issue type and when it is encountered.

The following lists examples of CMP error codes:

Error Description	Error Type	Error Code
The received request did not contain a DER object.	HTTP	400 Bad Request
The DER object contained in request could not be parsed to a CMP message.	Unsigned CMP	BAD_REQUEST (2)
Signature verification on a nested message failed.	Unsigned CMP	BAD_REQUEST (2)
Received CMP message was of an unknown type	Unsigned CMP	BAD_REQUEST (2)
Submitting a request with a URL that does not match an existing CMP alias	HTTP	404 Not Found
Submitting a CMP RA message with a signing certificate which was revoked or expired.	Unsigned CMP	BAD_REQUEST (2)
Submitting a CMP RA message that could not be authenticated.	Unsigned CMP	BAD_MESSAGE_CHECK (1)
Trying to revoke a certificate that was already revoked	Signed CMP	CERT_REVOKED (10)
Trying to revoke a certificate whose revocation is is waiting for approval	Unsigned CMP	BAD_REQUEST (2)
Trying to revoke a certificate from a nonexistant CA.	Unsigned CMP	BAD_REQUEST (2)
Trying to revoke a non existing certificate	Signed CMP	BAD_CERTIFICATE_ID (4)
Trying to revoke a certificate, but serial number or issuer were missing from request.	Signed CMP	BAD_CERTIFICATE_ID (4)
Revocation reason could not be parsed from CMP message	Unsigned CMP	INCORRECT_DATA (7)
Trying to issue or request a certificate from a non existing CA	Unsigned CMP	WRONG_AUTHORITY (6)
Submitting a CMP request with bad POP	Unsigned CMP	BAD_POP (9)
Submitting a CMP client mode enrollment request with invalid certificate extensions specified.	Unsigned CMP	BAD_REQUEST (2)
Submitting a CMP client mode enrollment request with invalid enrollment code.	Unsigned CMP	NOT_AUTHORIZED (23)
Attempting a key update request without the end entity authentication module configured.	Unsigned CMP	BAD_REQUEST (2)
A key update request without could not be authenticated/verified.	Unsigned CMP	BAD_REQUEST (2)
A key update request was submitted without a subject DN	Unsigned CMP	BAD_REQUEST (2)
A key update request for an end entity which wasn't found in the database.	Unsigned CMP	BAD_MESSAGE_CHECK (1)
A key update request was submitted using the same keypair.	Unsigned CMP	BAD_MESSAGE_CHECK (1)
Any other failures that may have occurred during key renewal.	Unsigned CMP	BAD_MESSAGE_CHECK (1)
Submitting a CMP client mode enrollment request with wrong user/enrollment code	Unsigned CMP	NOT_AUTHORIZED (23)
A request for server generated keys when this is not enabled in CMP alias	Unsigned CMP	BAD_REQUEST (2)
A request for server generated keys when the certificate profile does not exist	Unsigned CMP	BAD_REQUEST (2)
A request for server generated keys when the key algorithm, key size (RSA) or curve (ECDSA) is not allowed	Unsigned CMP	BAD_REQUEST (2)
A request for server generated keys with invalid or unsupported key parameters	Unsigned CMP	BAD_REQUEST (2)
Other internal errors	Unsigned CMP	Various

CMP Proxy

ENTERPRISE This is an EJBCA Enterprise feature.

In some installations it may be desirable to terminate the client connection in a DMZ before connecting further to the CA. In this case the client never has a direct network connection to the CA machine. In such a scenario you can use the CMP proxy module. Clients use the CMP proxy, as it would otherwise use EJBCA. The proxy in turn connects to EJBCA gets the answer and forwards it back to the client.

The proxy is a stand alone module that runs on another machine than the CA itself.

See EJBCA_HOME/modules/cmpProxy/resources/README for information how to build and use the proxy.

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.

Password based MAC

Password based MAC verification can be activated by setting the following value to true in cmpProxy.properties:

mp.backend.hmacPasswordValidationRequired=true

In addition to this, KeyId/password pairs need to be defined, where they KeyID is the name of the CA and the password is the CMP RA Authentication Secret for that CA.

cmp.backend.hmacPassword.keylist=[ca1:foo][ca2:bar]

Signature

This form can be activated by setting the following value:

cmp.backend.signatureRequired=true

In addition to this, the following value needs to be defined:

cmp.backend.issuerchainpath

This value can either be set to a single PEM file or to a directory containing multiple PEM files, representing one or more valid issuers of signing certificates.

CMP Proxy Error Messages

The CMP Proxy will return error messages, partly as a result of problems inherent to the proxy in itself, and partly due to evaluating CMP requests directly on the proxy before passing them on. The messages listed here are those returned by the proxy independently of the CA, as listed in the CMP Error Messages section.

Error Description	Error Type	Error Code
The received request did not contain a DER object.	Unsigned CMP	BAD_REQUEST (2)
Submitting a request with a URL that does not match an existing CMP alias	HTTP	404 Not Found
Sending a response over TCP failed.	HTTP	500 Internal Server Error
Signature/HMAC protection was required in configuration, but no protection was present.	Unsigned CMP	BAD_REQUEST (2)
HMAC/Signature verification failed.	Unsigned CMP	BAD_REQUEST (2)
Message signature was required, but no signing certificate was supplied.	Unsigned CMP	BAD_REQUEST (2)
Message signature was required, but revocation check could not be performed.	Unsigned CMP	SYSTEM_UNAVAILABLE (24)
Message signature was required, if a cache failure occurred during revocation check.	Unsigned CMP	SYSTEM_UNAVAILABLE (24)
Message signature was required, but no certificate chains defined on proxy	Unsigned CMP	SYSTEM_UNAVAILABLE (24)
Message signature was required, but signer certificate was revoked.	Unsigned CMP	BAD_REQUEST (2)