Certificate Management Protocol

The initial version of CMP is described in RFC 2510, the respective CRMF version in RFC 2511. Both were published in March 1999.

CMP version 2 was described in RFC 4210, published in September 2005. HTTP transfer for CMP messages was first described by RFC 6712, published in September 2012.

In November 2023, CMP Updates, CMP Algorithms, and CoAP transfer for CMP, have been published as well as the Lightweight CMP Profile focusing on industrial use.

In July 2025, RFC 9810 was released, which combines the RFCs 4210 and 9480 into a self-contained document and adds further features, in particular support for KEM keys. At the same time, an update of the specification for HTTP(S) transfer of CMP messages was published in RFC 9811.

In a Public-Key Infrastructure (PKI), so-called end entities (EEs) act as CMP client, requesting one or more certificates for themselves from a certificate authority (CA), which issues the legal certificates and acts as a CMP server. None or any number of registration authorities (RA), can be used to mediate between the EEs and CAs, having both a downstream CMP server interface and an upstream CMP client interface. Using a "cross-certification request" a CA can get a certificate signed by another CA.

• Self-contained messages with protection being independent of message transfer – as opposed to related protocols EST and SCEP, this supports built-in end-to-end proof of origin also over several hops.
• Proof of possession (POP) is usually done by a self-signature of the requested certificate contents, but CMP supports also other methods. This is crucial in particular for requesting certificates for KEM-only keys.
• CMP supports the very important aspect of proof of origin (i.e., proof of identity of the requester) in two variants: MAC-based with a shared secret (used initially) and signature-based (using pre-existing certificates).
• Key pair generation is usually done by the client side, but can also be requested from the server side.
• In case an end entity has lost its private key and it is stored by the CA, it might be recovered by requesting a "key pair recovery".
• Full certificate life-cycle support: an end entity can utilize CMP to obtain certificates from a CA, request updates for them, and also get them revoked.
• There are various further types of requests possible, for instance to retrieve CA certificates and to obtain PKI parameters and preferences of the server side.

CMP messages are usually transferred over HTTP(S), but any reliable means of transportation can be used.

• Encapsulated in HTTP messages,^[1] optionally using TLS (HTTPS) for additional protection.
• Encapsulated in CoAP messages, optionally using DTLS for additional protection.^[2]
• TCP or any other reliable, connection-oriented transport protocol.
• As a file, e.g., over FTP or SCP.
• By email, using the MIME encoding standard.

The Content-Type used is application/pkixcmp. Initially, application/pkixcmp-poll, application/x-pkixcmp or application/x-pkixcmp-poll were used.

• OpenSSL since version 3.0 includes extensive CMP support in C.
  The so-called generic CMP client provides a high-level API for it, adhering to the Lightweight CMP Profile defined in RFC 9483.
• Bouncy Castle offers CMP support in Java and C#.^[3]
• RSA BSAFE Cert-J provides CMP support in C and Java.
• cryptlib provides CMP support in C.
• The CA software products EJBCA^[3][4], Insta Certifier, Entrust Certificate Authority, Nexus Certificate Manager, DigiCert Device Trust Manager, and IBM z/OS PKI Services, implement subsets of CMPv2.

• Simple Certificate Enrollment Protocol (SCEP)
• Certificate Management over CMS (CMC)
• Enrollment over Secure Transport (EST)
• Automated Certificate Management Environment (ACME)