Jellyfish

What is CMP  

Certificate enrolment over Certificate Management Protocol (CMP) is a standardised protocol for managing X.509 certificates. CMP is widely used for automating certificate lifecycle operations such as enrolment, renewal, and revocation.  

The standard began with CMPv1 (RFC 2510, 1999), then CMPv2 (RFC 4210, 2005) and later CMP Updates (RFC9480, 2023) to the proposed standard of CMPv3 (RFC 9810, 2025), which would replace RFC 2510, RFC 4210 and RFC 9480. CMPv2 is widely used within the industry today. CMPv3, defined in RFC 9810, is an updated version of the CMP standard. It standardises the use of newer, more secure cryptographic algorithms and supports the issuance of certificates using post-quantum algorithms such as ML-DSA. It is broadly backwards compatible with CMPv2. 

Key Components of CMP 

PKI Entities: 

  • End Entity (EE): A client device or application requesting the certificate. 
  • Certification Authority (CA): The server issuing certificates. 
  • Registration Authority (RA): An intermediary that authenticates certificate requests before forwarding them to the CA. 

Message Formats: 

  • CMP messages are exchanged in PKIMessage format, consisting of: 
  • Header: Contains metadata (sender, recipient, transaction ID). 
  • Body: The specific request or response (e.g., certificate request, confirmation). 
  • Protection: Ensures message integrity and authenticity (HMAC, digital signatures) 

Security Mechanisms: 

CMP uses certificate-based signatures or password-based MAC authentication to protect the messages. 

Other Features 

Key Update Request (KUR): Allows renewing certificates without generating a new key pair. 

Revocation Request: Used to request revocation of an existing certificate. 

Polling (IP/CP): Supports asynchronous communication for long-running operations by allowing clients to poll for status updates. 

General Messages (GenM): Used for querying the CMP server for information such as the latest CRL, or the CA Certificate chain. 

CMP Transport 

CMP messages can be exchanged over various transports: 

  • HTTP/HTTPS 
  • TCP 
  • Email 
  • File-based mechanisms 

HTTP(s) is generally the preferred mechanism, and CMP over HTTP is standardised in RFC 6712, and later updated by RFC 9811. 

Benefits of CMP 

  • Automation: CMP facilitates automated certificate management workflows, making it ideal for large-scale PKI deployments. 
  • Flexibility: Support for various message types and transports ensures adaptability to different use cases. 
  • Interoperability: Being a standardized protocol, it allows integration between products from different vendors. 

CMP is particularly useful in environments requiring high scalability, such as IoT, mobile networks, or enterprise PKI systems. 

Limitations of CMP 

While CMP is a robust and widely used protocol for certificate lifecycle management, it has certain limitations and challenges. Below are the key limitations of CMP: 

Complexity 

  • Implementation Difficulty: CMP is a comprehensive and complex protocol. Implementing a CMP client or server can be challenging due to the extensive features and message formats. 
  • Configuration Challenges: The need for precise configurations, such as authentication mechanisms (HMAC, signature-based), transport protocols, and profile-specific parameters, can make it difficult to set up and troubleshoot. 

Lack of Broad Adoption 

  • Interoperability Issues: While CMP is standardized, not all CA systems or PKI environments natively support it. This limits its adoption in environments where proprietary protocols or APIs are preferred. 
  • Vendor-Specific Extensions: Some CA implementations introduce proprietary extensions or modifications to CMP, potentially causing compatibility issues between different systems 

Security Concerns 

  • Shared Secrets: HMAC-based authentication relies on shared secrets, which can be challenging to manage securely at scale. 
  • Transport Layer Security (TLS): While CMP can be used over HTTP or TCP, ensuring proper encryption and authentication via TLS is critical but not always enforced by default. 

Limited Support for Modern Standards 

  • CMPv2 was initially defined in RFC 4210, which predates some newer cryptographic and PKI standards.  
  • CMPv3 amends this shortcoming with support for several more modern algorithms, including but not limited to: 
  • PBMAC1, rather than PasswordBasedMAC 
  • Deprecation of SHA-1 
  • Support for post-quantum algorithms such as ML-DSA 
  • Although it has been updated in later RFCs, it may still lack support for certain modern requirements, such as advanced validation mechanisms like Online Certificate Status Protocol (OCSP) stapling. 

 Resource-Intensive 

  • Server Load: CMP servers need to handle various message types and keep track of asynchronous transactions for each request, which can increase resource requirements on CA/RA systems. 
  • Network Overhead: The protocol involves multiple message exchanges, especially in asynchronous workflows, potentially adding latency and bandwidth usage. 

Limited Client Tools 

  • Fewer out-of-the-box tools and libraries are available for working with CMP compared to other protocols (e.g., ACME for automated TLS/SSL certificate management). This can make development and integration harder for organizations without expertise in CMP. 

Scalability 

  • In environments with large-scale deployments (e.g., IoT), CMP’s reliance on message protection (HMAC or signature-based) and complex workflows can make scaling more challenging compared to simpler protocols like EST (Enrolment over Secure Transport). 

Lack of End-User Accessibility 

  • CMP is designed for system-to-system communication, making it less suitable for manual use by end users. This limits its use cases to backend automation. 

Limited Awareness and Expertise 

  • CMP requires PKI and cryptographic expertise to implement and manage effectively. Organizations without sufficient knowledge may struggle with the protocol. 

Despite these limitations, CMP remains a powerful protocol, especially for environments requiring detailed control over certificate management and strong security mechanisms. 

Alternatives to CMP 

In environments where these limitations pose challenges, organizations might consider alternatives like: 

  • ACME (Automatic Certificate Management Environment): A simpler protocol for automating TLS certificate issuance and renewal. 
  • EST (Enrolment over Secure Transport): A lighter protocol for certificate enrolment with HTTPS-based transport. 
  • SCEP (Simple Certificate Enrolment Protocol): An older protocol that is easier to implement but less secure. 

Endpoints in CMP 

CMP defines a single endpoint to handle all CMPv2 operations: 

  • /cmp: This endpoint processes all message types (e.g., IR, CR, KUR, RR, etc.), and the operation type is determined by the content of the request. 
CMP Workflow

Certificate Enrolment Workflow in CMP 

The CMP enrolment process involves the following steps: 

  1. Initial Enrolment Request (IR, CR, KUR, P10CR): 
    1. The end entity (EE) generates a Certificate Signing Request (CSR) using a Cryptographic Message Syntax (CRMF) structure, or PKCS#10 for a legacy P10CR request. 
    2. The CSR includes: 
      1. Subject Distinguished Name (DN) 
      2. Public key 
      3. Requested certificate extensions (e.g., key usage) 
    4. The CSR is encapsulated in a PKIMessage, which is protected (HMAC or digital signature) to ensure authenticity. 
  3. Submission to the RA or CA: 
    1. The PKIMessage containing the request is sent to the Registration Authority (RA) or directly to the CA. 
    2. The RA may perform additional checks, such as verifying the requestor's identity or credentials. 
  5. CA Processing: 
    1. The CA validates the PKIMessage: 
      1. Verifies the authenticity and integrity of the message. 
      2. Checks the compliance of the CSR against its policies. 
    3. If valid, the CA issues a certificate based on the CSR. 
  7. Certificate Response: 
    1. The CA Returns the issued certificate to the EE. 
    2. The issued certificate is again encapsulated in a PKIMessage, with protection. 
  9. Confirmation (optional): 
    1. The end entity validates the response and sends a confirmation (CertConf) message to acknowledge receipt of the certificate. 
    2. The server responds with its own confirmation (PKIConf) to finalise the transaction. 

Use Cases 

  • IoT Devices: 
    • Automates certificate enrolment and renewal in IoT ecosystems. 
  • Servers and Services: 
    • Simplifies certificate management for web servers or microservices. 
  • Secure Network Infrastructure: 
    • Automates certificate provisioning for VPN gateways, firewalls, or routers. 

Tools and Software Supporting CMP 

  • Cogito Jellyfish: Supports CMPv2/3 for automated certificate lifecycle management 
  • OpenSSL: Can be used to interact with CMPv2/3 servers for testing and operations. 
  • EJBCA: Supports CMPv2 for automated certificate lifecycle management.