PKI Protocols

MTG CLM supports multiple PKI protocols, to meet diverse certificate deployment scenarios. This page provides a comprehensive overview of protocol capabilities, use cases and prerequisites to help you select and configure the appropriate protocol for your infrastructure.

Protocol Overview

MTG CLM supports five protocols, each optimized for different device types, automation requirements and operational workflows:

Protocol Primary Purpose

ACME

Automated certificate issuance and renewal for web servers, cloud-native environments and clients using RFC 8555 compatible tooling.

EST

Simplified enrollment for IoT, mobile and embedded devices using RFC 7030 with basic authentication and policy-based certificate management.

SCEP

Legacy and enterprise device support (Juniper, Cisco, Windows, mobile platforms) using RFC 8894 with certificate-based or password-based authorization.

CMP

Enterprise key management with advanced operations including initialization, key updates and revocation using RFC 4210 and RFC 4211.

OCSP

Certificate revocation status verification via OCSP responder functionality (validation service, not enrollment).

Capability Comparison Matrix

Feature ACME EST SCEP CMP OCSP

RFC Standard

RFC 8555

RFC 7030

RFC 8894

RFC 4210/4211

RFC 6960

Certificate Renewal

Yes (automated)

Yes (simplereenroll)

Yes (RenewalReq)

Yes (Key Update Request)

N/A (validation only)

Revocation Support

No

No

No

Yes (Revocation Request)

N/A (responder only)

Key Generation

Client-side (PKCS#10)

Client-side (PKCS#10)

Client-side (PKCS#10)

Server-side or client-side

N/A (validation only)

Authentication Methods

Account creation + HTTP challenge verification

Basic authentication (end entity credentials)

Certificate-based or password-based (challenge password)

Shared Secret (HMAC) or Signature-based

N/A (no authentication)

Device Support Examples

Linux, Windows, macOS, containers, Kubernetes

IoT, mobile, embedded systems

Juniper, Cisco, legacy enterprise devices, Windows

Enterprise systems requiring advanced key management

All PKI clients supporting OCSP validation

Default Policy Support

Yes (with API client)

Yes (with API client)

Yes (with API client)

Yes (with API client)

Configured per CA

Multi-Policy Endpoints

Yes (/v2/<policy_id>/directory)

Yes (/.well-known/est/<policy_id>/*)

Yes (/<policy_id>/scep or /scep/<policy_id>)

Yes (/<policy_id>/cmp or /cmp/<policy_id>)

N/A

Use Case Mapping

ACME (RFC 8555)

Best For:

  • Automated web server certificate management

  • Cloud-native and Kubernetes environments (via cert-manager)

  • Continuous Integration/Continuous Deployment (CI/CD) pipelines

  • Clients requiring RFC 8555 compliance

EST (RFC 7030)

Best For:

  • IoT device enrollment at scale

  • Mobile and embedded systems with limited computational resources

  • Initial device onboarding with simplified credentials (end entity UUID + password)

  • Environments requiring basic authentication over TLS

SCEP (RFC 8894)

Best For:

  • Juniper, Cisco and legacy enterprise device management

  • Microsoft Windows device enrollment scenarios

  • Mobile platform certificate installation

  • Environments requiring existing SCEP infrastructure

CMP (RFC 4210 / RFC 4211)

Best For:

  • Enterprise environments requiring advanced key management operations

  • Scenarios involving initialization, key updates and key recovery

  • Systems where revocation management is critical

  • Long-lived certificate lifecycle operations

OCSP (RFC 6960)

Best For:

  • Real-time certificate revocation status queries

  • Clients needing revocation information before transaction completion

  • High-frequency revocation status checks in PKI environments

  • Architectures where CRL latency is unacceptable

Common Prerequisites Across All Protocols

Prerequisite Details

API Client

Create an API client in MTG CLM. Acquire client secret and provider ID for protocol server configuration.
See: API Clients

Default Policy

Associate API client with a default policy. Protocol server uses this policy if client does not specify alternative.
Alternatively, specify policy ID in protocol request.
See: Policies

End Entity (Password-Based Auth)

For protocols using password-based authorization (EST, SCEP password mode, CMP Shared Secret), create an end entity and configure end entity password.
See: End Entities, End Entity Passwords

Realm Context

All protocols operate within realm context defined by API client’s default policy or explicit policy specification.
Multi-realm deployments require separate API clients per realm or careful policy management.
See: Realms

Certificate Provider Compatibility

Verify selected certificate provider supports required operations. Most protocols support all standard providers; specific restrictions depend on provider and policy configuration.

Protocol Selection Decision Framework

Choose ACME if you need:

  • Fully automated certificate lifecycle with minimal manual intervention.

  • Integration with Kubernetes, containers, or modern DevOps tooling.

  • Challenge-based validation as part of security model.

Choose EST if you need:

  • Lightweight protocol for IoT, mobile, or embedded device enrollment.

  • Simplified credential management (end entity UUID + password).

  • Broad device support with minimal computational overhead.

Choose SCEP if you need:

  • Support for legacy or vendor-specific devices (Juniper, Cisco, etc.).

  • Existing SCEP infrastructure and tooling compatibility.

  • Windows device enrollment or Mobile management integration.

Choose CMP if you need:

  • Advanced key management operations (key updates, key recovery, revocation).

  • Fine-grained control over certificate lifecycle operations.

  • Enterprise-grade protection mechanisms (signature-based or shared secret).

Choose OCSP if you need:

  • Real-time revocation status validation capability.

  • High-frequency status checks from distributed clients.

  • Integration point for PKI clients querying certificate validity.

API Client and Policy Configuration

All protocol servers require:

  1. API Client: Create via MTG CLM.

  2. Default Policy (recommended): Associate with API client to streamline client configuration.

  3. Credentials: Provide protocol server with API client credentials (secret, provider ID).

If API client lacks default policy, clients must explicitly specify policy ID in protocol requests using policy-specific endpoints.

Policy-specific endpoints allow flexible deployment where different clients authenticate to different policies, enabling scenarios like:

  • Separate policies for development, staging, production environments.

  • Per-team or per-business-unit certificate issuance rules.

  • Testing policy configurations before production deployment.

Detailed Protocol Documentation

For comprehensive configuration, troubleshooting and advanced use cases, please refer to protocol-specific pages: