Protocolos
A continuación se cubren varios protocolos compatibles con EJBCA.
Descripción general
Se puede acceder y gestionar EJBCA mediante métodos distintos a la interfaz de usuario y la CLI, tanto mediante protocolos remotos propios como protocolos establecidos. El objetivo principal de la mayoría de estos es permitir que aplicaciones de terceros interactúen con EJBCA como servidor.
Proxy
Con dos instancias de EJBCA configuradas mediante el protocolo EJBCA Peers , el par descendente actuará como proxy del ascendente. Por ejemplo, un mensaje CMP enviado a una RA se comprobará tanto en sentido ascendente con la CA como localmente en la RA (y la respuesta dependerá de dónde se configure el alias). Este proxy está deshabilitado por defecto y se puede activar en la página de Configuración de Protocolos Modulares .
Tipos de protocolo
Los protocolos se dividen en categorías a continuación, aunque algunas API son tan amplias que pertenecen a varias categorías.
Protocolos de inscripción de certificados
Estos protocolos suelen estar diseñados para operaciones sencillas de inscripción y renovación de certificados. Todas las acciones mencionadas aquí también pueden gestionarse en los Protocolos de Gestión de Certificados de .Protocols v7.5.0#, que se enumeran a continuación.
Protocolos de gestión de certificados
Estos protocolos son generalmente más avanzados y además de la inscripción también manejan operaciones como la revocación y la verificación del estado del certificado.
Protocolos de estado del certificado
Protocolo utilizado para verificar el estado de revocación de los certificados:
Protocolo utilizado para descargar certificados CA y CRL:
Autorización: Modo cliente vs. Modo RA
Algunos protocolos de inscripción estandarizados ofrecen configuración en modo Cliente vs. Modo RA. El modo Cliente o Modo RA está relacionado con la autorización de la inscripción, algo que no suele estar incluido en el estándar.
Los estándares de protocolo, como EST, CMP o SCEP, suelen definir un protocolo. Este define la apariencia de los mensajes, cómo se transportan (en algunos casos) y qué mecanismos de autenticación están disponibles. Tenga en cuenta que los estándares no suelen especificar cómo se autoriza una solicitud. Para ejemplificar lo que esto significa, considere una solicitud de certificado procedente de un dispositivo que afirma ser serialNumber=12345 . ¿Cómo autoriza la CA a que el remitente de esta solicitud tenga la autorización (derecho) para obtener un certificado para serialNumber=12345 ? Si un cliente pudiera obtener certificados para cualquier serialNumber que solicite, esto podría utilizarse para suplantar la identidad de otros dispositivos (o usuarios de servidores en otros escenarios).
La autorización debe diseñarse sobre el protocolo estándar, y es aquí donde EJBCA apunta al modo Cliente y RA.
Ejemplo de autorización en modo RA
En el modo RA, EJBCA asume que la entidad que envía una solicitud está autorizada a emitir cualquier certificado permitido por los perfiles y derechos de acceso de la RA.
Un ejemplo de caso de uso es el Administrador de Autoridades de Identidad (IdAM) de PrimeKey, una puerta de enlace para la inscripción de dispositivos en una fábrica, que está autorizado a emitir certificados para cualquier dispositivo producido y se conecta al sistema de ejecución de fabricación (EMS) que controla qué dispositivo se está produciendo en un momento determinado. En este caso, EJBCA no puede verificar que el dispositivo que se está produciendo tenga el número de serie solicitado por el IdAM, pero debe confiar en que este se haya instalado y configurado correctamente. Sin embargo, el IdAM solo puede emitir este tipo específico de certificados de dispositivo, con limitaciones de perfiles, CA y reglas de acceso en el propio IdAM. Para obtener más información, consulte la documentación del Administrador de Autoridades de Identidad (IdAM) .
Ejemplo de autorización en modo cliente
En modo Cliente, EJBCA asume que la entidad que solicita los certificados es una entidad final, que podría ser un agente malicioso. EJBCA no confía en esta entidad para obtener certificados emitidos para ningún número de serie, nombre de dominio, dirección de correo electrónico, etc., que ella misma declare. En cambio, en modo Cliente, otra entidad administradora, que realiza la verificación de identidad, debe prerregistrar los datos (añadir entidad final) en EJBCA. El cliente que realiza la solicitud solo puede obtener un certificado con los datos prerregistrados. La entidad solicitante aún debe autenticarse en EJBCA para demostrar que es la entidad final prerregistrada.
Un ejemplo es el registro inicial de eNodeBs (estaciones base en redes 4G/5G) como se especifica en el estándar 3GPP 33.310 . Aquí un Operador de Red Móvil (MNO) compra un conjunto de eNodeBs de un proveedor (por ejemplo Ericsson). El MNO conoce los números de serie de los eNodeBs comprados y puede pre-registrar estos números de serie. Cuando los eNodeBs se instalan en todo el país, se autentican utilizando un certificado de dispositivo inicial emitido por el proveedor a la CA del MNO y recuperan un nuevo certificado del MNO, con el número de serie pre-registrado que coincide con el número de serie del dispositivo. Si un actor malicioso comprara un eNodeB del mismo proveedor e intentara conectarse al MNO, el actor malicioso no puede autenticarse como ninguno de los dispositivos pre-registrados y, por lo tanto, no puede obtener un certificado del MNO. Para obtener más información sobre el estándar CMP 3GPP y la integración de EJBCA, consulte Uso de CMP con 3GPP .
En cualquier caso de uso de inscripción, es importante considerar la autorización en el diseño del sistema y tener en cuenta que esta autorización está fuera del estándar del protocolo. Si no se considera el nivel adecuado de autorización, el nivel de seguridad del sistema será muy bajo, incluso utilizando un protocolo técnicamente seguro.