Resumen

  • En el intercambio ordinario de CMP sobre HTTP, RFC 9811 exige 200 OK y un cuerpo con la respuesta CMP. Ese éxito exterior no decide si la operación fue aceptada, concedida con cambios, rechazada o puesta en espera.
  • El recibo defendible conserva por separado el destino, HTTP, la protección del PKIMessage, el transactionID, el estado, el sondeo, la confirmación, el almacén de claves y la aceptación por los sistemas que dependen del certificado.

El error de automatización más cómodo cabe en una línea: 200 OK, operación completada.

La primera mitad puede ser cierta. La segunda no procede de HTTP. La RFC 9811, norma del IETF publicada en julio de 2025, define un transporte muy concreto para el Certificate Management Protocol. Un PKIMessage codificado en DER viaja en el cuerpo de un POST con Content-Type: application/pkixcmp. Si la petición HTTP ordinaria tiene éxito, la respuesta CMP ocupa el cuerpo de una respuesta 200; ningún otro 2xx sirve para ese intercambio.

El código 200 hace útil la envoltura. No absorbe la autoridad de lo que contiene.

Dos resultados en una sola respuesta

La RFC 9810 enumera los estados de CMP. Entre ellos están accepted, grantedWithMods, rejection y waiting. Por tanto, una respuesta HTTP 200 puede transportar una concesión exacta, una concesión que exige examinar cambios, una negativa o un proceso que todavía no ha terminado.

Una tasa de éxito HTTP no distingue ninguna de esas acciones. Tampoco conviene invertir el error y descartar el cuerpo al ver un 4xx o 5xx. RFC 9811 exige que el cliente pueda manejar un PKIMessage de respuesta presente en cuerpos asociados a códigos 2xx, 4xx y 5xx. La capa exterior puede informar de un problema y, al mismo tiempo, entregar una explicación CMP protegida y vinculada a la transacción.

El orden correcto es acumulativo: recibir la respuesta HTTP, validar límites y tipo de medio, decodificar DER, verificar la protección CMP y el remitente, asociar la transacción, interpretar el tipo de cuerpo, el estado y la causa. Cada prueba autoriza el siguiente análisis, no el resultado final de toda la cadena.

Sin respuesta no significa sin efecto

RFC 9811 indica que, si una respuesta HTTP no confirma la recepción, debe suponerse que el mensaje CMP no fue entregado con éxito. Esa formulación protege al protocolo de transporte contra una afirmación sin recibo. No demuestra que el servidor jamás leyera el mensaje.

La conexión puede romperse después de que la autoridad haya creado estado y antes de que el cliente vea la respuesta. Para el cliente, la entrega queda sin confirmar. Repetir con una identidad nueva puede duplicar una solicitud; no repetir puede dejar una renovación incompleta.

Por eso la política de reintento debe guardar el transactionID, la huella exacta del mensaje, la autoridad, la clase de operación y el límite temporal. Cuando CMP ofrezca sondeo o continuación, se usa ese mecanismo. Cuando la implementación no permita resolver la ambigüedad, el estado debe llamarse incierto y escalarse. Borrar la incertidumbre con un nuevo identificador solo la desplaza al servidor.

Estado CMP sobre un transporte sin estado

Algunas operaciones PKI ocupan varios pares de petición y respuesta. El transactionID mantiene su afiliación aunque cada trayecto HTTP sea independiente. RFC 9810 exige que los mensajes posteriores utilicen el valor establecido y que un cliente no mantenga dos transacciones activas con el mismo identificador frente al mismo servidor.

La recomendación de usar 128 bits pseudoaleatorios reduce colisiones. El servidor puede exigir unicidad por {cliente, transactionID} o por el identificador solo, según su capacidad para reconocer al cliente. Si no puede asociar correctamente un valor ya usado, devuelve transactionIdInUse.

Correlación no es autenticación. El identificador no prueba quién solicita, qué perfil puede pedir, si el mensaje está íntegro ni si una repetición es segura para el sistema de negocio. Esas decisiones pertenecen a la protección CMP, los nonces, los identificadores de solicitud y la política local. Un expediente debe unirlos sin llamar identidad a un número de seguimiento.

La espera tiene reloj propio

waiting significa que el cuerpo solicitado aún no ha sido procesado. El cliente envía pollReq; la CA o RA contesta con el resultado final si está listo o con pollRep y checkAfter. Antes de sondear otra vez debe transcurrir, como mínimo, ese intervalo.

Las causas pueden estar lejos de la red: carga del backend, traslado fuera de línea entre entidades PKI o aprobación de un operador de RA. HTTP terminó, pero el actor que decide todavía no.

La automatización necesita conservar el propietario de la espera, la hora del siguiente sondeo, la edad total, el margen hasta la expiración y la regla de escalado. Sondear con más frecuencia no acelera una aprobación humana y puede consumir la capacidad que falta. Convertir waiting en rechazo genera solicitudes paralelas; convertirlo en aceptación declara una renovación que aún no existe.

El certificado recibido todavía puede ser rechazado

CMP contempla una fase posterior a la emisión. Con certConf, el cliente acepta o rechaza los certificados devueltos; con pkiconf, la autoridad confirma y puede cerrar el intercambio. Si la CA ha cambiado campos solicitados, el cliente debe inspeccionar el certificado real. grantedWithMods no es un atajo hacia la instalación.

El historial completo separa respuesta protegida, estado, huella del certificado, comparación con la solicitud, confirmación, cierre del protocolo, escritura en el almacén, activación del servicio y validación por la parte que confía. La misma huella relaciona esos registros, pero no demuestra que todos hayan ocurrido.

Esto evita cerrar un control porque «la CA emitió». El balanceador quizá siga presentando el certificado anterior. El proceso puede haber cargado otra clave. Un cliente relevante puede rechazar la cadena, el nombre, el propósito o el tiempo. También puede funcionar el servicio mientras se ha perdido la confirmación del protocolo. La operación necesita evidencia de ambas realidades.

Las notificaciones usan 201 y 202 por otra razón

RFC 9811 reserva otro patrón para anuncios impulsados por una CA: actualización de clave, certificado, revocación o CRL. El servidor CMP actúa como cliente HTTP y el receptor no devuelve un mensaje CMP. Responde con contenido vacío.

201 Created significa que la información se almacenó o ya estaba presente. 202 Accepted significa que solo fue admitida para procesamiento posterior. El emisor puede esperar y volver a enviar hasta obtener confirmación de procesamiento. Ese contrato no debe mezclarse con el flujo ordinario donde 200 lleva el resultado CMP.

La protección vuelve a importar. Si el acuse de una notificación no está autenticado, su afirmación sobre el procesamiento no es fiable y el diseño no debe depender de una entrega garantizada. El significado del código requiere procedencia.

/.well-known/cmp ubica una ruta, no nombra al soberano

Para interoperar entre productos, los servidores CMP sobre HTTP o HTTPS deben admitir el prefijo /.well-known/cmp. Segmentos posteriores pueden distinguir operaciones, autoridades o perfiles. El registro IANA muestra cmp como sufijo permanente bajo control del IETF.

La ruta es común, pero el host no aparece por arte de magia. RFC 8615 no define cómo descubrir el nombre de host y advierte que un recurso «well-known» representa una superficie de control del origen. Por eso hay que registrar de dónde salió la autoridad configurada, qué resolución y redirección se produjo, qué par TLS respondió, qué remitente CMP firmó el mensaje y qué política permite relacionarlos.

RFC 9811 permite soportar redirecciones, pero pide cautela antes de seguirlas automáticamente. Un 301 persistido por un atacante puede producir una denegación permanente al separar al cliente de la autoridad correcta. La comodidad HTTP no debe reescribir en silencio el ancla de una infraestructura de claves.

La evidencia conserva cada entrega de autoridad

Un registro útil contiene: CA o RA prevista; URI final y cadena de redirecciones; identidad TLS; método, código, tipo y huellas de los cuerpos HTTP; remitente y destinatario CMP, tipo de mensaje y veredicto de protección; transactionID, nonces e identificador de solicitud; estado, fallo y checkAfter; huella y diferencias del certificado; certConf y pkiconf; versión del almacén; activación; retirada del material anterior; y pruebas desde los servicios dependientes.

También conserva las negativas: sin respuesta, entrega sin confirmar; con 200, respuesta recibida; con emisión, objeto creado; con instalación, estado local cambiado; con una conexión correcta, un observador aceptó. Ninguna frase debe suplantar a la siguiente.

Running-Code Primacy sitúa la prueba final en los procesos y servicios que ejecutan el protocolo. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption explica por qué la interfaz común debe fijar solo método, bytes, identificación, correlación y seguridad compartida, dejando la política y el despliegue en manos locales. Reality Layers obliga a resistir el símbolo único de éxito.

RFC 9811 no convierte 200 en una señal débil. Lo convierte en una señal honesta. La petición HTTP terminó bien. La decisión sobre el certificado sigue en el mensaje que llegó.

Fuentes