Introducción

EJBCA puede configurarse para actuar como Autoridad de Certificación (CA) , Autoridad de Validación (VA) y Autoridad de Registro (RA) , o cualquier combinación de las tres, distribuidas en varias máquinas. Esto requiere conexiones entre las instancias:

1. La CA debe estar conectada a la VA para poder publicar certificados , a diferencia de la VA , que debe estar conectada a la CA para actualizar automáticamente los certificados de firma.

2. La RA debe estar conectada a la CA para poder transmitir solicitudes de certificado.

Por otro lado, los modelos de seguridad de dominio común tienen los siguientes requisitos:

1. Todas las conexiones deben realizarse mediante TLS mutuamente autenticado.

2. La CA debe estar detrás de un firewall que permita solo conexiones salientes debido a que los VA y RA generalmente residen en dominios de menor seguridad para poder ser accesibles para los clientes.

Si bien el primer requisito es fácil de resolver, el segundo plantea algunos problemas con las conexiones modeladas anteriormente.

Sistemas pares EJBCA

EJBCA resuelve el segundo requisito descrito anteriormente mediante un protocolo propietario denominado Peers Systems, basado en TLS con autenticación mutua. Se basa en los siguientes principios:

• Todas las conexiones TLS se inician en la instancia que actúa como CA. Si bien este es un concepto bastante simple para la publicación CA → VA , ya que solo implica tráfico saliente, presenta algunos problemas para las solicitudes de certificado de la RA y la firma de las solicitudes de renovación de certificado de la VA, ya que estas se inician en el nodo descendente.

• Las conexiones TLS son autenticadas por una CA conocida por ambos nodos, generalmente la CA de administración . En el nodo ascendente, esta conexión se representa mediante una vinculación de clave de autenticación.

• En lugar de crear y desconectar conexiones, la CA establece grupos de conexiones en el VA o la RA , que se utilizan tanto para el tráfico saliente como para que el nodo descendente inicie solicitudes. Esto permite, por ejemplo, que una RA transmita solicitudes de certificado sincrónicamente a la CA, sin comprometer la seguridad del dominio.

• Las operaciones de gestión interna no están expuestas a través de la API , lo que significa que incluso con la adquisición hostil completa de un VA o RA, no se pueden generar claves de CA, modificar perfiles ni cambiar configuraciones.

• Cada nodo EJBCA es internamente independiente de su rol o posición en la jerarquía. Esto significa que una instancia de EJBCA no se limita a un solo rol, sino que puede ser cualquier combinación de los tres, o incluso actuar como CA para sí misma y VA para otra instancia de EJBCA.

• Cada conexión de pares tiene su propio rol y reglas de autorización , lo que significa que el conjunto de operaciones, ya de por sí limitado, en la API puede reducirse aún más a un número limitado de CA o perfiles. Esto limita el daño de una adquisición hostil de un nodo de RA y permite la multitenencia (donde varias organizaciones comparten la misma CA sin conocerse entre sí) y la división organizacional.
  

Esto se establece estableciendo un TLS de confianza mutua entre los nodos ascendentes y descendentes, y lo que se requiere para lograr esto es configurar un enlace de clave de autenticación en el nodo ascendente, cuyas claves están firmadas por una CA de confianza para ambas partes (que en casi todos los casos sería la CA de administración ).