Summary

  • RFC 9811 requires an ordinary successful CMP-over-HTTP exchange to return 200 OK with a CMP response body. That outer success does not replace the inner PKIStatus, which can be accepted, modified, rejected or waiting.
  • A defensible certificate-automation receipt must preserve endpoint, HTTP, protected CMP message, transactionID, polling, confirmation, keystore and relying-system evidence as linked but separate states.

The dangerous line in a certificate automation log is often not red. It is green.

POST /... 200 OK looks conclusive. A request left one process, crossed an HTTP stack and received a response. A dashboard can count it. An orchestrator can advance. An auditor can find a timestamp. Yet none of those facts, alone, says that a certification authority accepted the request, that the requested certificate was issued without modification, that a waiting approval completed, that the client accepted the result, that the credential entered the intended keystore or that any relying service now trusts it.

RFC 9811 is valuable because it does not ask HTTP to answer those questions. Published on the IETF Standards Track in July 2025, it specifies how the Certificate Management Protocol, CMP, travels over HTTP. It replaces RFC 6712 and absorbs relevant transfer updates from RFC 9480. Its contract is exact: send a DER-encoded CMP PKIMessage in the content of an HTTP POST; label it application/pkixcmp; and, when that HTTP request succeeds in the ordinary request-response workflow, return the CMP response in the HTTP body with status 200 OK. Other successful 2xx codes must not be used for that purpose.

That sounds like a recipe for treating 200 as the verdict. It is the opposite. RFC 9811 fixes the outer envelope so that the inner protocol can remain authoritative.

The outer receipt and the inner verdict

HTTP and CMP answer different questions.

HTTP reports on a request to a target resource and carries a response. In the ordinary RFC 9811 flow, 200 says the HTTP request succeeded and the body is where the CMP response belongs. CMP then says what the public-key infrastructure operation means. RFC 9810, the current CMP specification, defines response statuses including accepted, grantedWithMods, rejection and waiting, as well as warning states for revocation and key update.

The possible combinations expose the error in a one-column success metric.

  • HTTP 200 plus CMP accepted can report that the requested operation was granted.
  • HTTP 200 plus grantedWithMods requires the requester to inspect what changed rather than pretending it received exactly what it asked for.
  • HTTP 200 plus rejection is a successful transfer of a negative PKI decision.
  • HTTP 200 plus waiting reports a live transaction whose decision is not finished.

All four can make the HTTP chart green. They do not authorize the same next action.

RFC 9811 makes the boundary still harder to ignore. When a client receives an HTTP response in the 2xx, 4xx or 5xx ranges, it must support handling response content that contains a CMP response PKIMessage. The outer error can carry an inner protocol message worth authenticating, correlating and recording. Code that returns immediately on status >= 400 may discard the most specific evidence the server supplied. Code that returns success immediately on status == 200 may never inspect the verdict at all.

The correct parser is therefore not a ladder with HTTP at the top. It is a chain. Validate enough of the HTTP response to recover the entity body. Confirm the expected media type and bounded size. Parse the DER structure. verify the relevant CMP protection and sender. Match transaction state. Then interpret the CMP body, status and failure information under the operation's rules. Each step can fail without retroactively changing what the earlier step proved.

Why 200 is deliberately narrow

RFC 9110 gives 200 OK the general meaning that a request succeeded; the representation depends on the method. RFC 9811 narrows that broad vocabulary for one binding. An ordinary successful CMP request-response uses exactly 200 because the meaningful response is a CMP message in the body. It reserves 201 and 202 for a different CMP-over-HTTP workflow: pushed announcements.

The precision is operationally useful. It prevents implementers from treating every 2xx as interchangeable and keeps a single outer success form for ordinary exchanges. But precision at one layer is not authority over the next. The word “successful” describes the HTTP operation. The CMP body can still report that the certificate operation was rejected or remains pending.

This is a recurring design discipline. A lower layer should provide a deterministic receipt for the function it actually performs. It should not borrow the vocabulary of the higher-layer business action and declare that action complete. HTTP can prove that a server returned the specified response form. It cannot decide whether an RA operator has approved a request or whether a certificate profile returned by a CA is acceptable to the end entity.

The missing response is an uncertainty state

RFC 9811 says that if receipt of an HTTP request is not confirmed by an HTTP response, the transferred CMP message must be assumed not to have been successfully delivered to its destination. That is a safe rule for the transfer protocol. It prevents a client from claiming delivery without a response.

It does not create omniscience.

A connection can fail after a server has read or processed a request but before the client receives the response. From the caller's observation point, delivery is unconfirmed. That does not necessarily prove absence of server-side state. A naive retry can therefore turn uncertainty into a duplicate operation. A naive refusal to retry can leave a required operation incomplete.

The only defensible response is transaction-aware reconciliation. Preserve the original transactionID, the exact request body hash, the target authority, the request type and the time boundary. Use the operation's CMP rules to continue or poll when they permit it. Escalate when the implementation cannot tell whether a side effect exists. Do not invent a fresh transaction identifier merely to make the dashboard move again.

This distinction matters especially in automated enrollment and renewal systems. A retry policy written for idempotent HTTP resource reads is not automatically safe for certificate issuance, revocation or key update. The transport failure class and the PKI operation's state machine must meet in an explicit rule.

Transaction identity across stateless carriage

HTTP's statelessness is not a reason to pretend that each request is a new certificate decision. RFC 9811 points to CMP's transactionID as the mechanism that associates an operation spanning more than one request-response pair. RFC 9810 supplies the detailed rules: once the identifier is established, subsequent requests and responses in the transaction use it; a client must not run more than one transaction with the same identifier against a given server; and a server must be able to associate the messages correctly.

The identifier is deliberately strong as a correlation value. RFC 9810 recommends 128 bits of pseudorandom data when a client starts a transaction. Servers may require uniqueness for the {client, transactionID} tuple or for the identifier alone, depending on how they distinguish clients. A collision that prevents correct association produces transactionIdInUse.

What the field does not do is equally important. It does not authenticate the client by itself. It does not prove authorization for a certificate profile. It does not guarantee that two semantically different requests with the same value are safe. It does not replace the CMP message-protection checks, nonces or request identifiers. And it is not automatically a business-level idempotency key for whatever system wrapped the CMP client.

A useful audit view keeps correlation and authority separate. transactionID answers “which protocol transaction does this message belong to?” Message protection and local policy answer “whose message is it, is it intact, and may this actor request this operation?” The certificate body and confirmation answer “what was offered and accepted?” The deployment record answers “where did it become active?”

Waiting and the polling clock

waiting is the clearest demonstration that transport success and operation completion are different states. RFC 9810 uses it when a request body has not yet been processed and more information is expected. The end entity sends pollReq; the CA or RA returns the final response if it is ready or a pollRep containing checkAfter; and the client waits at least that many seconds before polling again.

The delay is not merely network latency. RFC 9810 notes that it can reflect backend load, offline transfer between PKI management entities or required RA operator approval. A finished HTTP exchange can therefore sit in front of an unfinished human or institutional decision.

Automation should model that fact rather than translate it into an error or a success. waiting needs an owner, a next eligible poll time, an expiry or escalation rule and the original transaction context. Repeatedly polling faster than checkAfter is not resilience. It spends server capacity to deny the state the protocol disclosed. Treating waiting as final failure can trigger a second enrollment while the first still exists. Treating it as acceptance can deploy nothing while declaring compliance complete.

The polling clock is also evidence. A sudden increase in checkAfter, a growing population of waiting transactions or a change from immediate responses to operator approval can reveal capacity, workflow or policy shifts before users report expired certificates. The value should be observed as a distribution by authority, profile and operation—not merely as a count of successful HTTP calls.

A certificate response may not close the transaction

CMP does not always stop when a CA sends a certificate. RFC 9810 defines certConf, allowing the client to accept or reject returned certificates, and pkiconf, by which the CA acknowledges confirmation and closes the exchange. If a CA modifies requested certificate fields, the end entity must inspect the actual certificate rather than assuming that issuance equals consent.

That produces another sequence of separately accountable acts:

  1. The CA or RA returns a protected CMP response with status and, where appropriate, a certificate.
  2. The client verifies the response and compares the issued certificate with the requested identity, key, constraints, validity and intended use.
  3. The client sends the required confirmation or rejection.
  4. The authority returns protocol confirmation where the exchange requires it.
  5. A local process stores and activates the credential.
  6. The intended service presents or uses it.
  7. A relying system builds, validates and authorizes the result under its own policy.

No single receipt owns all seven acts. A certificate fingerprint can join them. It cannot make them identical.

This is where compliance systems often lose the plot. An issuance database says a certificate exists, so a ticket closes. The endpoint may still have the old key loaded. A load balancer may be presenting another certificate. A relying client may reject the chain, name, purpose or time validity. Conversely, a working service can hide that confirmation evidence was lost and that the CA still regards the transaction as unfinished. Running behavior and protocol closure both matter; neither should be fabricated from the other.

Announcement push uses a different receipt contract

RFC 9811 deliberately gives pushed CMP announcements another pattern. A CA may push a key-update, certificate, revocation or CRL announcement by acting as an HTTP client. The recipient does not return a CMP response. It returns an empty HTTP response whose status has processing meaning.

201 Created means the announced item was successfully stored or was already present. 202 Accepted means it was accepted for further processing. After 202, the sender may wait and try again until it gets confirmation that processing succeeded. The distinction mirrors the larger thesis: acceptance into a queue is not completed processing.

These codes must not be copied back into the ordinary certificate request-response flow. In one workflow, 200 carries the CMP verdict. In another, 201 or 202 is the defined receipt because there is no CMP response. A single library abstraction called “successful CMP HTTP” can erase exactly the differences operators need during an incident.

Unprotected acknowledgement also has limits. RFC 9811 warns that if responses to pushed announcements are not authenticated and protected, their claims about processing state may not be trusted; the PKI design must not depend on reliable receipt. A status code is evidence only within the protection and endpoint context that gives it provenance.

The authority behind /.well-known/cmp

To ease multivendor interworking, RFC 9811 requires CMP servers supporting HTTP or HTTPS transfer to support the /.well-known/cmp path prefix. Additional segments can identify an operation, a CA or a certificate profile. The live IANA Well-Known URIs registry lists cmp as a permanent IETF-controlled suffix, and the IANA CMP registry records registered path-segment structure.

The well-known path standardizes where to ask on an origin. It does not tell a client which hostname represents the intended authority. RFC 8615 is explicit that the well-known mechanism does not itself determine the hostname. It also warns that a well-known location is an origin-level control surface whose write authority and application scope require care.

An enrollment profile must therefore preserve how the authority portion was configured or discovered, which redirects occurred, what TLS peer was authenticated, which CMP sender appeared in the protected message and whether those identities agree with local policy. /.well-known/cmp is a compatibility convention, not a delegation certificate.

Redirects sharpen the point. RFC 9811 permits implementations to support 3xx but cautions against automatic following without security consideration. A maliciously stored 301 Moved Permanently destination could deny future contact with the correct server. Convenience at the HTTP layer can mutate the authority surface of the PKI client unless the client makes redirect policy visible and reversible.

Protection has layers too

CMP contains built-in integrity protection and authentication. HTTP can be carried over TLS to protect confidentiality and authenticate the transport peer. Those controls reinforce each other; they do not collapse.

RFC 9811 warns that HTTP information without effective protection should not be used to change CMP transaction state. It also recommends considering HTTPS or a VPN because even when CMP protects its messages, unencrypted metadata can reveal personal, technical or business-sensitive information. The result is not a contest over which layer is “secure.” It is a division of labor.

TLS can show which endpoint terminated the secure channel and protect bytes in transit. CMP protection can show that the protocol message is intact and attributable under its own credential model. transactionID can bind the message to an exchange. PKIStatus can state the operation's position. Certificate confirmation can record the requester's acceptance. Keystore and relying-service evidence can show what ran. Remove any one of those columns and another column is tempted to claim more than it knows.

Build a receipt that preserves the handoffs

A durable record for CMP-over-HTTP should be one joined event graph, not one success boolean. At minimum, preserve:

  • the intended CA or RA, configured authority, resolved URI, operation/profile path and redirect chain;
  • the TLS peer identity and connection result;
  • HTTP method, status, media type, request and response body hashes and timing;
  • CMP sender, recipient, message type, protection algorithm and verification result;
  • transactionID, sender/recipient nonces, request identifier and prior-message link;
  • PKIStatus, failure information, checkAfter and the next permitted action;
  • certificate fingerprint, key binding, requested-versus-issued differences and confirmation state;
  • keystore or hardware module version, activation result and rollback handle; and
  • an independent observation from each material relying service.

The record should also preserve uncertainty. “No HTTP response” is not silently rewritten as “not delivered.” “HTTP 200” is not silently rewritten as “issued.” “Issued” is not silently rewritten as “installed.” “Installed” is not silently rewritten as “trusted everywhere.” Each transition needs the evidence of the actor that owned it.

Running-Code Primacy supplies the closing test. RFC 9811 can define the interoperable transfer envelope. It cannot make an implementation parse an error body, respect a polling interval or load a new credential. Those truths arrive from running clients, CA/RA state, keystore inspection and relying transactions.

Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption explains why the binding should remain narrow. Shared rules define the bytes, method, media type, path convention and response handling necessary for interoperability. Local actors retain certificate policy, approval, deployment and rollback. The protocol coordinates their messages without pretending to become their single decision-maker.

Reality Layers explains the audit failure that follows when those distinctions are compressed. A transport receipt is true. A CMP verdict is true. A stored credential and a successful relying connection are true. They are not rival stories; they are states at different layers. The hostility begins when one convenient green light is asked to silence the others.

RFC 9811 does not weaken HTTP by limiting what 200 means. It makes the receipt trustworthy. The request succeeded. The response arrived. Now open it. The certificate decision is still inside.

Sources