Operaciones de sistemas de pares
EMPRESA Esta es una característica de EJBCA Enterprise.
A continuación se proporciona información sobre cómo administrar conectores de pares mediante la descripción general de sistemas de pares ( Funciones del sistema → Sistemas de pares ).
Para obtener más información conceptual sobre los sistemas pares, consulte Descripción general de los sistemas pares .
Descripción general
En la descripción general de sistemas de pares puede:
Modificar configuraciones globales como habilitar o deshabilitar conexiones entrantes.
Vea una lista de sistemas pares EJBCA conocidos y configurados a los que esta instancia puede conectarse (conectores pares) y su estado de conexión actual.
URL de conexión, es decir, https://remotehost:8443/ejbca/peer/v1
Estado del grupo de conexiones, conexiones en uso/listas/máximas/en cola
Estado de sincronización, si se inicia la conexión entre pares
Información del certificado TLS de cliente y servidor
Rol utilizado para la conexión entrante, si está habilitado
Ver una lista de sistemas que se han conectado a esta instancia recientemente ( Conexiones entrantes ).
Además, hay enlaces disponibles a las configuraciones de autenticación relevantes para conexiones salientes (AuthenticationKeyBinding) y conexiones entrantes (rol de administrador).
Conexiones salientes
Las conexiones salientes están permitidas de forma predeterminada y los administradores autorizados a /peer/modify pueden deshabilitarlas de forma recursiva.
Un conector de pares es una representación de una instancia EJBCA remota y puede ser referenciado por otros componentes como publicadores y servicios. Cada conector de pares mantiene un conjunto de conexiones salientes reutilizables (HTTP Keep-Alive) y solo se crean nuevas conexiones cuando es necesario.
Para autenticarse con un par, debe configurar un enlace de clave de autenticación . El enlace de clave de autenticación (AuthenticationKeyBinding) es la identidad de la instancia EJBCA y consta de un certificado SSL X509 de cliente y un par de claves en uno de los tokens criptográficos de la instancia. Asegúrese de que el enlace de clave de autenticación (AuthenticationKeyBinding) esté configurado para confiar en el certificado SSL del servidor del par; de lo contrario, la conexión fallará. La configuración de AuthenticationKeyBinding solo se lee cuando se inicia el grupo de conexiones de un conector de par y, si se actualiza el certificado de cliente, esto no surtirá efecto hasta que se restablezca el grupo de conexiones.
Para cada conector de pares configurado, puede ver el nombre legible, el punto final de la conexión y el estado actual de la conexión. Puede hacer ping a cualquiera de los pares para comprobar la conectividad; el resultado es el tiempo de ida y vuelta desde y hacia la aplicación a través de la conexión segura (lo que proporciona una visión más precisa del tiempo de ida y vuelta real que un ping de red con el protocolo ICMP).
Solo la primera conexión a un par que utilice el mismo certificado de cliente se someterá a una verificación de autenticación completa, y las solicitudes posteriores compartirán la misma credencial. Esto significa que una solicitud de ping inicial a un sistema par será significativamente más lenta que la siguiente.
Configuración de una conexión entre pares saliente
Para obtener más información sobre cómo agregar una conexión de pares saliente, consulte:
→ Cómo configurar una conexión entre pares salientes
La configuración de una conexión saliente entre pares presupone que ya se ha configurado una clave de autenticación para esta conexión. Para obtener instrucciones, consulte Configuración de un autenticador remoto .
Editar, clonar o eliminar un conector de pares
En la vista general de Sistemas de Pares , haga clic en Editar para un Conector de Pares existente. En la vista del Conector de Pares , puede modificar y guardar el nombre, la URL o el estado. En la vista Editar , también puede clonar o eliminar el objeto actual.
Conexiones entrantes
Las conexiones entrantes no están permitidas de forma predeterminada y pueden ser habilitadas por administradores autorizados a /peer/modify de forma recursiva.
En la lista de conexiones entrantes, puede ver los sistemas que se han conectado correctamente a la instancia EJBCA con un certificado de cliente en el que confía la configuración SSL del servidor de aplicaciones. Si el certificado de cliente presentado por el sistema que se conecta ya forma parte de un rol de administrador, se muestra el nombre de este rol.
Autorización de conexiones entrantes
De forma predeterminada, EJBCA requiere que haya un certificado TLS de administrador en la base de datos. Si está configurando una VA o RA externa, probablemente desee poder conectar un par de la CA a la VA/RA sin tener que importar el certificado de cliente TLS de la CA (desde una vinculación de clave de autenticación) a la VA/RA. Esto se realiza configurando web.reqcertindb=false en conf/web.properties. Consulte Administración de respondedores de OCSP .
Si no existe un rol de administrador para el certificado de cliente del sistema de conexión, haga clic en "Crear nuevo rol" para configurar un nuevo rol de administrador para el certificado de cliente entrante y un conjunto de reglas de acceso relevantes. También puede agregar el certificado de cliente entrante a un rol de administrador existente.
Si existe un rol de administrador para el certificado de cliente del sistema de conexión, haga clic en Modificar rol para cambiar el conjunto relevante de reglas de acceso para el rol de administrador.
Esto proporciona una vista simplificada de la gestión normal de autenticación y autorización de EJBCA, y el rol de administrador creado se puede editar como cualquier otro rol de administrador.
Operaciones de gestión para un sistema de pares EJBCA
Una vez que se ha autorizado una instancia EJBCA para conectarse y administrar otra instancia EJBCA, las operaciones en el par se pueden realizar a través de la GUI de administración de la instancia autorizada.
El administrador que inicia estas operaciones debe estar autorizado a las reglas de acceso /peer/view /peer/manage y, además, a cualquier CA relevante.
Publicación mediante conectores de pares
La descripción general de editores se utiliza para propagar información de certificados o CRL a un sistema de pares. La implementación de PeerPublisher permite enviar esta información a un conector de pares configurado.
El sistema de conexión debe estar autorizado a las reglas de acceso /peerincoming /peerpublish/writecert /peerpublish/writecrl /ca/[CAName] para poder enviar datos de certificado y CRL.
Sincronización de certificados con una VA
En una configuración donde una instancia de CA EJBCA (o un clúster) utiliza respondedores externos de VA/OCSP EJBCA, la información de revocación debe propagarse de la CA al VA. La información sobre los certificados recién emitidos y las actualizaciones de revocación se envía normalmente mediante un publicador (de pares), pero la primera vez que se conecta un nuevo VA, se le debe enviar el estado actual de todos los certificados emitidos previamente.
En la descripción general de los conectores de pares:
Haga clic en Administrar para el conector de pares que representa al VA y seleccione la pestaña Sincronización de datos de certificado .
Configure el subconjunto de información relevante para sincronizar.
Haga clic en Iniciar para iniciar la sincronización como una tarea en segundo plano.
El progreso se puede seguir en esta vista o en la descripción general de sistemas pares.
El subconjunto de información de revocación que se envía afecta la forma en que se realizan las consultas a la base de datos. Dependiendo de la base de datos, podría ser más rápido sincronizar solo todos los datos o solo un subconjunto a la vez.
El sistema de conexión debe estar autorizado a las reglas de acceso /peerincoming /peerpublish/readcert /peerpublish/writecert /ca/\[CAName\] para poder verificar los datos de sincronización e insertar entradas de certificado faltantes u obsoletas.
Solucionar problemas de sincronización
Una vez completada la sincronización, se le propone descargar un informe con todos los elementos que no se pudieron sincronizar. El siguiente ejemplo muestra cómo se vería el archivo si la CA no estuviera autorizada a escribir en la base de datos del VA.
implementation: org.ejbca.peerconnector.PeerSyncReport creationDate: 2019-08-28 13:52 failureCount: 1 failures: - fingerprint: da28b65061b753f0059ac85c4917332d27f14f0d subjectDn: CN=OCSPTest,O=AnaTom,C=SE issuerDn: CN=TEST errorType: org.cesecore.authorization.AuthorizationDeniedException errorMessage: Not authorized to publish certificates for CN=TEST. Renovación de las asignaciones de teclas internas remotas
En una configuración donde una instancia de CA EJBCA (o un clúster) utiliza respondedores de VA/OCSP EJBCA externos, una CA delega la firma de las respuestas de OCSP a un certificado de firma de OCSP (configurado como OcspKeyBinding) en el VA. El certificado de firma de OCSP debería ser de corta duración y, para facilitar su renovación, está disponible como una operación de administración remota en la CA.
En la descripción general de los conectores de pares:
Haga clic en Administrar para el conector de pares que representa al VA y seleccione la pestaña Vinculaciones de teclas remotas .
Haga clic en "Renovar" para generar un nuevo certificado. Opcionalmente, también puede generar un nuevo par de claves para el siguiente certificado de firma OCSP.
La renovación de enlaces de teclas internos remotos se puede automatizar mediante un actualizador de enlaces de teclas internos remotos.
El sistema de conexión debe estar autorizado a las reglas de acceso /peerincoming /internalkeybinding/view/[Enlace de clave interno]/internalkeybinding/modify/[Nombre del enlace de clave interno] y /cryptotoken/view/[Nombre del token criptográfico] para poder renovar un certificado de enlace de clave interno. Además, se requiere /cryptotoken/keys/generate/[Nombre del token criptográfico] si se debe permitir la renovación de claves.
Al renovar el certificado de firma, desactive la publicación en los perfiles de certificado OCSP para evitar superposiciones durante la renovación.
Atender solicitudes de autoridad de registro a través de conexiones entre pares
La autoridad de registro EJBCA (RA) se puede ejecutar de forma local o remota mediante conexiones de pares de larga duración desde CA a RA.
La CA se conectará a la RA y escuchará las solicitudes, capturará la primera pendiente o esperará una, y la devolverá a la CA. Una vez que la CA termine de procesar la solicitud, se reconectará a la misma RA, entregará el resultado y esperará una nueva solicitud.
Configuración del conector de pares para obtener solicitudes de la RA
Al configurar un conector de par saliente en la CA, preste atención a las opciones de "Solicitudes entrantes".
Procesar solicitudes entrantes: habilitar esta opción hará que la CA establezca conexiones de larga duración con la RA y obtenga solicitudes.
Solicitudes paralelas mínimas: número mínimo de conexiones largas que esperarán las solicitudes en la RA cuando esta esté inactiva.
Solicitudes paralelas máximas: número máximo de conexiones de larga duración que procesarán solicitudes de la RA cuando esta se utilice por completo.
La CA regulará automáticamente el número de conexiones largas a cada RA según su utilización. Si desea respuestas rápidas a ráfagas de solicitudes tras un largo periodo de inactividad, debe aumentar el mínimo. Si desea limitar la carga que una RA puede infligir a una CA cuando está completamente utilizada, debe reducir el máximo.
Autorizar qué tipos de solicitudes de la RA atender
Una vez que la CA pueda conectarse a la RA, existe una opción en la lista de conectores de pares salientes para autorizar solicitudes. La RA se autentica ante la CA con su certificado TLS del servidor y, al usar "Autorizar solicitudes", podrá crear un nuevo rol (acción adecuada para la primera RA) o asignar este certificado a un rol de administrador existente (acción adecuada para las demás RA).
Una vez que el certificado TLS del servidor pertenece a un rol, se muestra una vista simplificada de las reglas de acceso relevantes para el procesamiento de solicitudes de la RA. Dado que las solicitudes de la RA a través de las conexiones entre pares de larga duración se autorizan con un subconjunto común de reglas de acceso de un administrador autenticado ante la RA y la propia RA, esto limitará el acceso máximo que cualquier administrador puede tener al realizar solicitudes a través de la RA. Considérelo una autorización contextual.
Autorizar a la CA a obtener solicitudes de la RA
De forma similar a la autorización en "Autorización de conexiones entrantes" , debe otorgar a la CA derechos en la RA para recuperar las solicitudes pendientes. Modifique el rol correspondiente y asegúrese de que la opción "Aceptar conexiones de larga duración (RA externa)" esté seleccionada.
Consideraciones sobre el equilibrio de carga
<p La configuración del conector de pares se almacena en la base de datos compartida por todos los nodos del clúster de CA. Cada nodo donde se pueda usar la vinculación de clave de autenticación (por ejemplo, el token criptográfico con la clave privada activa) intentará establecer conexiones con el punto final de RA.Un nodo CA aleatorio conectado a la RA recogerá una nueva solicitud para garantizar una distribución uniforme de la carga. Cuando todos los nodos CA tienen el mismo número de conexiones largas abiertas, aumenta la probabilidad de que los nodos CA con más conexiones largas inactivas recojan la siguiente solicitud.
Cuando un nodo de CA utiliza todas las conexiones actuales a una RA, se crearán más conexiones hasta alcanzar el número máximo de conexiones de larga duración. Si la implementación tiene un ancho de banda de red asimétrico entre los nodos de CA y una RA, los nodos de alta latencia mantendrán más conexiones abiertas para lograr el mismo rendimiento que los nodos de baja latencia, a costa de mayores tiempos de respuesta.
Contenido relacionado
Página: Sistemas de pares