CMP
A continuación se incluye información sobre el Protocolo de administración de certificados (CMP) y cómo funciona con EJBCA.
Para obtener guías, configuraciones y flujos de trabajo utilizando CMP, consulte la Guía de operaciones de CMP .
Introducción
El Protocolo de Gestión de Certificados (CMP) es un protocolo de Internet utilizado para obtener certificados digitales X.509 en una infraestructura de clave pública (PKI). Se describe en el RFC 4210 y es uno de los dos protocolos que utilizan el Formato de Mensaje de Solicitud de Certificado (CRMF), descrito en el RFC 4211 .
EJBCA admite los siguientes mensajes del complejo protocolo CMP, tal como se define en RFC4210 (y los mensajes de respuesta como cp y kup se construyen y se envían a los clientes):
Solicitud de inicialización (ir)
Solicitud de certificación (cr)
Solicitud de certificación Legacy PKCS #10 (p10cr)
Confirmación de certificación (certConf)
Solicitud de revocación (rr)
Contenido de mensaje anidado (anidado)
Solicitud de actualización de clave (kur)
Se espera que las solicitudes de certificados utilicen el formato de mensaje de solicitud de certificado definido en RFC4211 (y para el tipo de mensaje p10cr, el formato debe ser el definido en RFC 2986 ).
EJBCA no admite CMPv1 como se define en RFC2510
Alias y multitenencia
Al igual que con sus otros protocolos de inscripción, EJBCA proporciona multitenencia (la capacidad de que varios actores disjuntos utilicen la misma CA sin estar conscientes unos de otros) a través de un sistema de alias .
Un alias proporciona un punto final independiente para la inscripción añadiendo el nombre del alias a la URL del punto final, p. ej. , http://127.0.0.1:8080/ejbca/publicweb/cmp/cmpalias . Cada alias también proporciona una configuración independiente para cada punto final, lo que permite que cada alias utilice sus propios perfiles de certificado, configuración de PoPo, etc.
Modos operativos de cliente y RA
EJBCA puede funcionar en los siguientes modos con CMP:
Modo cliente | El modo cliente asume que la entidad final ya se ha creado y que el cliente que realiza la inscripción simplemente envía un par de claves para su firma. Al recibir la solicitud, EJBCA la verifica (véase Autenticación de mensajes CMP ) y emite un certificado a un usuario previamente registrado en EJBCA. Si la entidad final solicitada no existe, la solicitud fallará. |
Modo RA | El modo RA, en cambio, asume que el cliente CMP es una entidad de confianza y, por lo tanto, le permite inscribir entidades finales en la misma acción que envía las claves para su firma. En el modo RA, EJBCA admite varias CA y perfiles según el uso del alias de configuración especificado en la URL utilizada (consulte CMP sobre HTTP ). |
La implementación de EJBCA de Certificate Confirm (certConf) solo se adhiere estrictamente a RFC4210 si el certificado no se publica en un repositorio externo. RFC4210 sección 4.2.2.2, con detalles en las secciones 5.3.18 y 5.2.8, especifica certConf y que un certificado debe ser revocado si no es aceptado por el cliente a través de un certConf si se ha publicado o puesto a disposición de otra manera . EJBCA no revocará los certificados que no sean aceptados. De hecho, certConf se ignora principalmente, pero se envía un mensaje de confirmación de PKI (RFC4210 sección 5.3.17) de vuelta al cliente. La CA nunca revocará un certificado basándose en un mensaje certConf, o la falta de este. Generalmente, los casos de uso de CMP se beneficiarían del uso del método ImplicitConfirm especificado en la sección 5.1.1.1 de RFC4210.
El uso de CMP con EJBCA permite un alto volumen de transacciones con múltiples transacciones concurrentes, lo que permite una alta velocidad (cientos de solicitudes por segundo). Sin embargo, si su alias de CMP está configurado para la reutilización estática de entidades finales, no se admiten solicitudes paralelas para emitir certificados para la misma entidad final, lo que provocará que una de las transacciones falle con un error de transacción de base de datos, lo que indica que las transacciones concurrentes intentaron modificar la misma entidad final simultáneamente. Esto podría mejorarse e implementarse en una versión futura de EJBCA, pero a partir de EJBCA 7.3.0, no es un modo de operación compatible.
Autenticación de mensajes CMP
EJBCA admite cuatro módulos para la autenticación de mensajes, configurados en la interfaz de usuario de CA en Configuración de CMP .
Los módulos compatibles son extractores de contraseñas o verificadores de PKIMessage:
Módulo | Descripción |
Extractores de contraseñas (solo modo cliente) | |
Contraseña de token de registro | Extrae la contraseña de la solicitud CMP mediante un control regToken (id-regCtrl-regToken) en el mensaje CRMF. El regToken es una cadena UTF-8 que contiene la contraseña del usuario registrada en EJBCA. Este módulo no requiere parámetros. Este tipo de autenticación no es compatible con solicitudes p10cr heredadas. |
Contraseña de la parte de Dn | Extrae la contraseña del subjectDN del usuario al que se refiere la solicitud. Como parámetro, se debe especificar la parte del DN que contiene la contraseña. Por ejemplo, si el subjectDN es "CN=nombre,C=se,UID=CONTRASEÑA", el parámetro debe establecerse en "UID". |
Verificadores de mensajes PKI | |
HMAC | Este módulo utiliza un secreto compartido para autenticar el mensaje CMP:
|
Certificado de entidad final | Cuando se utiliza el módulo EndEntityCertificate, el remitente de la solicitud debe adjuntar su certificado en el campo extraCert en PKIMessage y luego firmar el mensaje con su clave privada.
|
Puede especificar más de un módulo en la página Configuración de CA UI CMP seleccionando varios módulos en Módulo de autenticación de CMP . Si especifica varios módulos, el primero se utiliza para las pruebas de autenticación. Si el primero falla, el segundo se utiliza para las pruebas de autenticación, y así sucesivamente hasta que la autenticación se complete correctamente o todas las alternativas fallen.
Mensajes de respuesta del CMP
Cuando una solicitud CMP se realiza correctamente, EJBCA devuelve un mensaje de respuesta CMP protegido. El tipo de protección del mensaje de respuesta también se puede configurar en la interfaz de CA, en "Configuración de CMP" . EJBCA admite los siguientes tipos de protección de mensajes de respuesta: pbe y signature .
Si falla una solicitud CMP, EJBCA devuelve un mensaje de error CMP sin protección ni cifrado.
Nota: pbe solo está disponible en modo RA.
pbe
Este tipo de protección del mensaje de respuesta solo se puede utilizar cuando la solicitud se autenticó mediante el módulo de autenticación HMAC. Los parámetros utilizados para la protección pbe se basan en los parámetros utilizados en la autenticación HMAC recibida.
Si el tipo de protección de la solicitud entrante es PBMAC1, la respuesta también estará protegida con PBMAC1 y lo mismo ocurre con el tipo de protección passwordBasedMac predeterminado.
firma
La CA que gestiona la solicitud CMP firma el mensaje de respuesta CMP con el mismo algoritmo de protección especificado en la solicitud CMP. Si se produce un conflicto entre el algoritmo de protección de la solicitud y el algoritmo de firma de la CA, se utilizará el algoritmo de clave de la CA junto con un algoritmo de resumen basado en el algoritmo de protección de la solicitud CMP. Si se produce un conflicto incluso en el algoritmo de resumen, se utilizará un algoritmo de resumen predeterminado. Por ejemplo, si la solicitud CMP utiliza el algoritmo de protección ECDSA con SHA1 y el algoritmo de firma de la CA es RSA con SHA256, la respuesta CMP se firmará con RSA con SHA1.
El tipo de firma de protección de respuesta se puede utilizar independientemente del módulo de autenticación que se utilizó para autenticar la solicitud CMP.
Los mensajes CMP se firman con la clave de firma de la CA. Por lo tanto, la verificación de los mensajes CMP firmados suele presuponer que no existe una aplicación demasiado estricta del uso de la clave en el certificado de la CA (similar a permitir la firma de respuestas OCSP con el uso de la clave CRLSign).
Los certificados de CA devueltos con el mensaje de respuesta de CMP se pueden configurar en la configuración de CMP. Para obtener una lista de códigos de error de CMP, consulte Mensajes de error de CMP .
Certificados de CA adicionales de respuesta de CMP
Se pueden agregar certificados de CA adicionales disponibles en EJBCA al mensaje de respuesta de CMP (CertRepMessage.caPubs). Independientemente de los certificados de CA adicionales configurados, el certificado de CA firmante se devuelve siempre con el índice 0.Certificados de CA adicionales de respuesta de mensaje PKI
Se pueden agregar certificados de CA adicionales disponibles en EJBCA al mensaje PKI que envuelve la respuesta de CMP (PKIMessage.extraCerts). Independientemente de los certificados de CA adicionales configurados, la cadena de certificados de CA que firma el mensaje de respuesta se incluye siempre desde el índice 0.
Modo cliente para CMP
El modo cliente se utiliza cuando el cliente CMP actúa como entidad final para EJBCA. Esto significa que la entidad final debe estar prerregistrada en EJBCA y que la solicitud del cliente se autentica con esta entidad final prerregistrada antes de emitir un certificado. Este es el mismo modelo de autenticación que para el registro normal (es decir, el registro del navegador) mediante una combinación de nombre de usuario y contraseña.
El DN del usuario se deduce de la solicitud según las reglas configuradas.
El nombre de usuario en EJBCA debe estar registrado previamente.
La contraseña del usuario en EJBCA debe pasarse en la solicitud (contraseña de un solo uso).
Si el perfil del certificado lo permite, keyUsage, validez y extensiones también se toman de CertTemplate en el mensaje de solicitud (en el caso de solicitudes p10cr, la validez se decide mediante la validez de la CA emisora).
Se utiliza la firma POPO.
Una vez que el usuario ha sido autenticado en EJBCA, se genera un certificado como de costumbre y se envía al cliente.
Para utilizar el modo cliente no se necesita ninguna configuración particular, ya que éste es el modo predeterminado.
Búsqueda de usuarios
Las solicitudes de inicialización y certificación utilizan el mensaje de solicitud CRMF (RFC4211) o el formato de solicitud de certificación p10cr heredado.
Se pueden buscar usuarios desde la solicitud de diferentes maneras, según lo configurado en la interfaz de usuario de la CA, en la sección "Configuración de CMP" . De forma predeterminada, el DN del sujeto de la plantilla de certificado de la solicitud se utiliza para buscar en EJBCA (esto no aplica para el tipo de mensaje de solicitud de certificado p10cr). También puede configurar EJBCA para usar el CN o el UID del DN del sujeto como nombre de usuario.
Autenticación de CA del proveedor
EMPRESA Esta es una característica de EJBCA Enterprise.
Si la entidad final tiene un certificado de proveedor con el que debe identificarse para la inscripción inicial, como se especifica en 3GPP, por ejemplo, también puede hacerlo. En este caso, la CA que emite el certificado de entidad final no es la misma que la CA del proveedor. La CA del proveedor debe importarse en EJBCA como CA externa ( IU de CA → Importar certificado de CA ). Esto se describe en detalle en la guía de integración para 3GPP disponible con EJBCA Enterprise.
Modo RA para CMP
El modo RA se utiliza cuando el cliente CMP actúa como RA para EJBCA. Cuando la RA envía una solicitud de certificado a EJBCA, no es necesario que el usuario se registre previamente en EJBCA. Cuando EJBCA recibe la solicitud, el mensaje se autentica. Tras la autenticación, se crea un usuario y se emite un certificado.
El DN del usuario se toma del CertTemplate en el mensaje de solicitud enviado desde la RA (es decir, el DN solicitado por la RA) (en el caso de una solicitud p10cr, se obtiene de CSR).
El nombre de usuario en EJBCA se genera de acuerdo con las opciones configuradas.
La contraseña del usuario en EJBCA es aleatoria.
Si el perfil del certificado lo permite, keyUsage, validez y extensiones también se toman de CertTemplate en el mensaje de solicitud (no aplicable para el tipo p10cr).
Se utiliza raVerify POPO (no aplicable para el tipo p10cr).
Los mensajes se autentican mediante uno de los módulos de autenticación configurados.
Una vez creado el usuario en EJBCA, se genera un certificado como de costumbre y se envía a la RA, quien lo distribuirá al usuario final.
Si se construye el mismo nombre de usuario (por ejemplo UID) que un usuario ya existente, el usuario existente se modificará con nuevos valores para el perfil, etc., y se emitirá un nuevo certificado para ese usuario.
Identificación de clave
En lugar de especificar explícitamente un perfil de entidad final de RA, un perfil de certificado de RA o un nombre de CA de RA al crear un alias de CMP, puede elegir la opción KeyID . Al seleccionar esta opción, se utiliza el valor del campo senderKID de la solicitud de CMP en lugar de la entrada correspondiente en el alias de CMP (que se establece en KeyID). El cliente que envía la solicitud de CMP debe garantizar su exactitud; por ejemplo, que la CA y el perfil de certificado estén autorizados por el perfil de entidad final.
Tenga en cuenta que KeyID solo es visible cuando el número de opciones disponibles es al menos dos.
KeyID es útil cuando se desea emitir diferentes tipos de certificados con un único alias CMP. La herramienta cmpclient de EJBCA permite configurar KeyID explícitamente mediante el argumento --keyid .
Soporte de multiprotección
En modo RA, también es posible enviar una solicitud CMP con múltiples firmas. EJBCA implementa esta función según las especificaciones de RFC 4210. Cuando una entidad final envía un mensaje PKI protegido a una RA, esta lo reenvía a una CA, adjuntando su propia firma para su protección. Esto se logra anidando todo el mensaje enviado por la entidad final dentro de un nuevo mensaje PKI. Para ver un ejemplo de cómo se vería un mensaje de este tipo, consulte la Guía de Operaciones de CMP .
Configuración de muestra
Ejemplo de configuración de EJBCA para permitir que una RA solicite certificados para los usuarios. La RA utiliza protección MAC basada en contraseña (PBE) para los mensajes CMP . Los usuarios se crearán utilizando el UID del DN de la solicitud y un prefijo, por lo que el nombre de usuario resultante será: cmp<UsersUID>. Los perfiles de entidad final CMP_ENTITY y CMP_CERT se crean en EJBCA, lo que permite el DN de la solicitud.
CMP Operational Mode : RA ModeAllow RA Verify Proof-of-Possession : checkCMP Response Protection : pbeCMP Authentication Module : HMACCMP Authentication Parameters : passwordRA Name Generation Scheme : DNRA Name Generation Parameters : UIDRA Name Generation Prefix : cmpRA End Entity Profile : CMP_ENTITYRA Certificate Profile : CMP_CERTRA CA Name : ManagementCA Uso de un secreto de autenticación por CA
Edite cada CA que deba utilizarse para la emisión de certificados CMP e introduzca el nuevo secreto de autenticación de RA de CMP. No se debe especificar ningún parámetro para el módulo de autenticación HMAC; de lo contrario, este parámetro anulará la configuración específica de la CA.
Solicitud de actualización de clave (kur)
También conocida como solicitud de actualización de certificado. Cuando un par de claves está a punto de caducar, la entidad final correspondiente puede solicitar una actualización de clave. La solicitud CMP se firma y el remitente adjunta su certificado en el campo extraCert del mensaje CMP.
En modo cliente
En modo cliente, la única entidad final autorizada a enviar una solicitud KeyUpdate es la entidad final propietaria del certificado que se va a renovar. Esta entidad final debe ser quien firme la solicitud y adjunte su certificado "antiguo" (que aún no haya caducado) al mensaje CMP. La CA solo consultará el certificado en extraCert para encontrar el que se va a actualizar.
En modo RA
En el modo RA, un administrador puede enviar una solicitud de KeyUpdate en nombre de una entidad final. El administrador debe ser quien firme la solicitud y adjunte su propio certificado al mensaje CMP. En el campo "CertificateTemplate" del mensaje CMP, se especifican solo el subjectDN (aplica en el caso del tipo p10cr) o ambos, el subjectDN y el issuerDN del certificado que se va a actualizar.
Para que esta solicitud se realice correctamente, el administrador que la envía debe estar autorizado para realizarla. Además, el módulo de autenticación EndEntityCertificate debe estar configurado entre los módulos de autenticación.
Ni CMP (RFC4210) ni 3GPP 33.310 establecen horarios específicos para la actualización de claves. Por lo tanto, un cliente puede enviar una solicitud de actualización de clave (kur) en cualquier momento, siempre que esté autenticado con el certificado o la clave antiguos.
Prueba de posesión
La Prueba de Posesión (PoPo) es el acto de demostrar que usted controla la clave privada de la clave pública que intenta certificar. EJBCA admite varios métodos PoPo a través de CMP:
Método | Descripción |
raVerificar | Delega la verificación de PoPo a una RA ubicada antes de EJBCA, lo que provocará que EJBCA no realice ninguna verificación de PoPo. No recomendado por los estándares. |
firma | PublicKey está en CertTemplate y la firma se calcula sobre CertReqMsg.certReq (el procedimiento estándar cuando CertTemplate contiene los valores de sujeto y publicKey). |
firma con POPOSigningKeyInput | La clave pública y el DN del sujeto se encuentran en POPOSigningKeyInput, posiblemente copiados de CertTemplate. La firma se calcula sobre POPOSigningKeyInput (si los valores también están en CertTemplate, deben ser idénticos). |
Los métodos PoPo mencionados anteriormente solo son aplicables al tipo de mensaje de solicitud de certificado CRMF. En el caso del tipo de mensaje p10cr, la prueba de propiedad es la verificación de la firma. Crear una solicitud PKCS10 implica básicamente especificar la identidad con la que se desea asociar el certificado final y firmar la estructura que contiene dicha información. La idea es que, si la clave pública adjunta puede verificar la firma cuando la autoridad de certificación (CA) revise la solicitud posteriormente, la estructura debe haberse firmado con la clave privada correspondiente.
Claves generadas por el servidor
CMP permite a los clientes solicitar claves generadas por el servidor, utilizando una de las siguientes opciones en la solicitud de certificado CRMF:
Omitir la clave pública de solicitud (opcional) en la solicitud CRMF.
Agregar un subjectPublicKeyInfo que contiene un AlgorithmIdentifier seguido de una CADENA DE BITS de longitud cero para subjectPublicKey (RFC4210 Apéndice D.4).
Estas opciones permiten una gran variedad de opciones y, dado que el servidor desea restringir el tipo de claves que los clientes pueden solicitar y certificar, EJBCA utiliza una serie de reglas y lógica de negocio bastante estrictas. La siguiente lista destaca estas opciones.
Tenga en cuenta que lo siguiente solo aplica si las claves generadas por el servidor están habilitadas en la configuración del alias de CMP. El uso de claves generadas por el servidor está deshabilitado por defecto, por lo que se deniega toda solicitud de claves generadas por el servidor.
Si la solicitud no contiene una clave pública de solicitud, las opciones de generación de clave se toman del perfil de certificado que se utilizará para emitir el certificado:
El perfil del certificado debe contener solo un algoritmo de clave permitido y una especificación de clave permitida, por ejemplo RSA 1024 o ECDSA secp256r1 .
Si no hay una única opción distinta, se rechazará la solicitud y se devolverá un error al cliente.
Si el perfil del certificado contiene un subjectPublicKeyInfo con el algoritmo RSA Id (rsaEncryption = 1.2.840.113549.1.1.1), el perfil del certificado debe contener una única opción de tamaños de clave permitidos.
Si no hay una única opción distinta, la solicitud será denegada.
Si el perfil del certificado contiene un subjectPublicKeyInfo con el algoritmo ECDSA Id (id_ecPublicKey = 1.2.840.10045.2.1), el subjectPublicKeyInfo debe contener parámetros donde se permitan dos opciones:
implícitamenteCA: El perfil del certificado debe contener una única opción de curvas permitidas, de lo contrario se rechazará la solicitud.
namedCurve: con el OID de una curva con nombre compatible, que se encuentra entre las curvas permitidas en el perfil del certificado.
Estas reglas permiten al administrador de CA controlar qué claves generadas por el servidor generará la CA y devolverá al cliente, y se pueden resumir de la siguiente manera:
Una elección distinta de un algoritmo de clave única y un tamaño/curva de clave, definidos en el perfil del certificado.
Una elección de un único tamaño de clave RSA y un conjunto de curvas EC, definidos en el perfil del certificado y seleccionados por el cliente en la solicitud.
Actualmente, se admiten claves RSA y EC.
Para dar soporte al servidor generado, el cliente debe incluir un id_regCtrl_protocolEncrKey en la solicitud, que contenga una clave pública que el servidor utilizará para cifrar la clave privada devuelta en la respuesta.
Las claves generadas por el servidor se devuelven en el campo CertifiedKeyPair.privateKey de la respuesta, como se define en las secciones 5.3.4 y D.4 de la RFC 4210. El valor cifrado (EncryptedValue) contendrá la clave privada, cifrada mediante AES256 con una clave simétrica aleatoria, que a su vez se encapsula con la clave pública en id_regCtrl_protocolEncrKey (el Apéndice B de la RFC 4211 contiene más detalles sobre el valor cifrado).
Se puede encontrar un ejemplo de código en Java para solicitar claves generadas por el servidor en el método de prueba CrmfRequestTest.test12ServerGeneratedKeys().
Las claves generadas por el servidor no son aplicables en el caso del tipo de solicitud p10cr, ya que siempre debe haber una clave pública presente en la solicitud correspondiente que llega a la CA.
Validez del certificado
Generalmente, el período de validez de los certificados emitidos se controla mediante el perfil del certificado. Si se activa la opción "Permitir anulación de validez" en el perfil del certificado y la solicitud de inicialización o certificación de CMP contiene un tiempo de validez en la plantilla de solicitud de CRMF, se utilizará este período de validez.
En el caso del tipo de solicitud p10cr, la validez está impuesta por la validez definida en la CA que maneja la solicitud.
Uso de la clave del certificado
Generalmente, la extensión del uso de claves de los certificados emitidos se controla mediante el perfil del certificado. Si habilita la opción "Permitir anulación del uso de claves" en el perfil del certificado, y la solicitud de inicialización o certificación de CMP contiene un uso de claves en la plantilla de solicitud de CRMF, se utilizará dicho uso.
Interoperabilidad con 3GPP/4G/LTE
Para leer más sobre el uso de CMP con 3GPP en EJBCA, consulte Uso de CMP con 3GPP .
Interoperabilidad / Bibliotecas y dispositivos probados
Para leer más sobre la interoperabilidad de EJBCA con varios clientes, dispositivos y bibliotecas, consulte Interoperabilidad CMP .
Mensajes de error de CMP
Si se producen problemas durante el procesamiento de CMP, se devuelven diferentes mensajes de error de CMP o códigos de error HTTP según el tipo de problema y el momento en que se produce. Para obtener una lista completa de todos los códigos de error de CMP, consulte Mensajes de error de CMP .
Proxy CMP
EMPRESA Esta es una característica de EJBCA Enterprise.
En algunas instalaciones, puede ser conveniente finalizar la conexión del cliente en una DMZ antes de continuar con la CA. En este caso, el cliente nunca tiene una conexión de red directa con el equipo de la CA. En tal caso, puede usar el módulo Proxy CMP .
Contenido relacionado
Página: Mensajes de error de CMP
Página: Uso de CMP con 3GPP
Página: Interoperabilidad CMP