RA externa mediante sondeo de base de datos

EMPRESA Esta es una característica de EJBCA Enterprise.

Esta funcionalidad está obsoleta . En su lugar, recomendamos enviar solicitudes SCEP de forma síncrona a través de una RA mediante pares. Para obtener información sobre la RA externa basada en el conector de pares, consulte la Guía conceptual de RA EJBCA .

    Introducción

    En algunos casos, por razones de seguridad, es preferible denegar todo el tráfico entrante a la instalación de la CA y, en su lugar, permitir que EJBCA obtenga y procese periódicamente información de fuentes de datos externas de confianza. Para obtener una descripción general de la solución, consulte la ilustración a continuación.

    La API de autoridad de registro externo (RA) contiene las funciones más básicas como:

    • Generar certificado desde PKCS10

    • Generar PKCS12 para el usuario final

    • Recuperación de la clave del usuario (si se solicita mediante PKCS12)

    • Editar usuarios

    • Revocar certificados

    • Generar un certificado para un usuario existente usando un secreto compartido

    • Generar un almacén de claves para un usuario existente utilizando un secreto compartido

    A partir de EJBCA 6.3.1, la API de RA externa se incluye como parte de EJBCA Enterprise Edition y se puede habilitar en conf/externalra.properties .

    imágenes/descargar/archivos adjuntos/175047407/external-ra.png

    Trabajadores de servicios de RA externos

    Los Service Workers de RA externos se configuran en la interfaz gráfica de usuario (GUI) del administrador. Cada trabajador sondeará una fuente de datos en el servidor de aplicaciones. La fuente de datos debe apuntar a una base de datos fuera de la zona de seguridad de red de la CA. Esto significa que se utilizan conexiones de base de datos puras. Dependiendo de la base de datos y la configuración, estas conexiones pueden protegerse de diversas maneras, por ejemplo, mediante SSL.

    Un mensaje en la base de datos puede contener uno o más submensajes. Los mensajes de la base de datos se pueden firmar y cifrar. Actualmente, solo se admiten almacenes de claves PKCS#12 suaves para descifrar y firmar respuestas. Si un trabajador encuentra un nuevo mensaje de solicitud, cambia el estado del mensaje a "en proceso" y extrae todos los submensajes.

    Para cada submensaje, el trabajador hará lo siguiente:

    1. Descifre el submensaje con un almacén de claves (o rechácelo si se requiere cifrado).

    2. Verificar y validar la firma del submensaje (o rechazarlo si se requiere firma).

    3. Procesar la solicitud en el submensaje con los privilegios de administrador de los firmantes (o con privilegios completos si no hay ninguna firma presente).

    4. Firme el submensaje de respuesta (si el Service Worker requiere firmas).

    5. Cifrar el submensaje de respuesta (si el Service Worker requiere cifrado).

    Finalmente, se escriben todos los submensajes de respuesta como un solo mensaje con el estado procesado de vuelta a la fuente de datos. El cifrado de los submensajes se realiza mediante sobres CMS/PKCS#7.

    Habilitación de RA externa

    Para utilizar trabajadores de servicio de RA externos en EJBCA, haga lo siguiente:

    1. Habilite el servicio en EJBCA_HOME/conf/externalra.properties .

    2. Configure fuentes de datos en EJBCA_HOME/conf/externalra.properties.

    3. Si corresponde, instale los JAR del conector JDBC en el servidor de aplicaciones para las bases de datos utilizadas en EJBCA_HOME/conf/externalra.properties.

    4. Cree fuentes de datos que coincidan con la configuración en externalra.properties .

    5. Reconstruya e implemente EJBCA usando el comando ant clean deployear .

    Para crear una fuente de datos que no sea JTA para JBoss 7, se puede utilizar un comando en jboss-cli.sh, por ejemplo:

    data-source add --name=ramessage1ds --jta= false --driver-name= "org.mariadb.jdbc.Driver" --connection-url= "jdbc:mysql://127.0.0.1:3306/messages" --jndi-name= "java:/RAMessage1DS" --use-ccm= true --user-name= "ejbca" --password= "ejbca" --validate-on-match= true --background-validation= false --prepared-statements-cache-size= 50 --share-prepared-statements= true --min-pool-size= 5 --max-pool-size= 150 --pool-prefill= true --transaction-isolation=TRANSACTION_READ_COMMITTED --check-valid-connection-sql= "select 1;"

    O para PostgreSQL:

    data-source add --name=ramessage1ds --jta= false --driver-name= "org.postgresql.Driver" --connection-url= "jdbc:postgresql://127.0.0.1/messages" --jndi-name= "java:/RAMessage1DS" --use-ccm= true --user-name= "ejbca" --password= "ejbca" --validate-on-match= true --background-validation= false --prepared-statements-cache-size= 50 --share-prepared-statements= true --min-pool-size= 5 --max-pool-size= 150 --pool-prefill= true --transaction-isolation=TRANSACTION_READ_COMMITTED --check-valid-connection-sql= "select 1"

    imágenes/s/-2y7bau/8703/189cb2l/_/imagenes/iconos/emoticonos/advertencia.svg Tenga en cuenta que la selección 1 debe ser diferente para DB2 y Oracle.

    Se recomienda utilizar los siguientes índices en la base de datos de mensajes externos:

    create index message_idx1 on message (status);
    create index message_idx2 on message (messageId);

    Configuración

    En la interfaz gráfica de administración de EJBCA, vaya a Servicios y cree un nuevo trabajador personalizado que se ejecute a intervalos cortos. Cuanto más corto sea el intervalo, con mayor frecuencia el trabajador sondeará la fuente de datos en busca de nuevos mensajes.

    • Seleccionar trabajador: Trabajador personalizado

    • Ruta de clase de trabajador personalizada: org.ejbca.extra.caservice.ExtRACAServiceWorker

    • Propiedades de trabajador personalizadas: se muestran a continuación

    • Seleccionar intervalo: Intervalo periódico

    • Periodo: 10 segundos (o cualquier intervalo que desees, pero no menos de 5 segundos)

    • Seleccionar acción: Sin acción

    • Activo: Marcado

    Las propiedades de trabajador disponibles son:

    • externalra-caservice.persistenceunit: una referencia a la base de datos de RA configurada en externalra.properties (predeterminado: RAMessage1DS)

    • externalra-caservice.encryption.required: Solo acepta mensajes cifrados en la base de datos de RA (predeterminado: falso)

    • externalra-caservice.signature.required: Solo se aceptan mensajes firmados en la base de datos de RA (predeterminado: falso)

    • externalra-caservice.keystore.path: Ruta completa al almacén de claves PKCS#12 utilizado para descifrar y firmar mensajes. Este archivo debe estar disponible en todos los nodos EJBCA. Solo es necesario si se utiliza cifrado o firma. (Por razones históricas, el valor predeterminado es keystore/extrakeystore.p12).

    • externalra-caservice.keystore.pwd: Contraseña del almacén de claves definido por externalra-caservice.keystore.path. (Predeterminado: foo123)

    • externalra-caservice.raissuer: Nombre de la CA que emite los certificados de RA. Se utiliza para comprobar la validez de las firmas de RA. (Valor predeterminado: ManagementCA)

    • externalra-caservice.whitelist: Una lista separada por comas de nombres de clases de solicitud que este trabajador aceptará. Si está vacía o no está definida, se aceptan todo tipo de solicitudes.

    Tanto el almacén de claves del trabajador como el utilizado en el servidor de RA deben ser emitidos por 'externalra-caservice.raissuer'. El servidor de RA también necesita el certificado del almacén de claves del trabajador para cifrar los mensajes de solicitud. La firma requiere el uso de clave 'Firma digital' y el cifrado requiere el uso de clave 'Cifrado de clave'.

    Ejemplo:

    externalra-caservice.persistenceunit=RAMessage1DS
    externalra-caservice.encryption.required= false
    externalra-caservice.signature.required= false

    Clientes externos de la API de RA

    Los clientes de API de RA externa crean un mensaje a partir de varios submensajes, donde cada submensaje

    • Contiene una solicitud

    • Está firmado con el almacén de claves RA (opcional si no lo requiere el Service Worker)

    • Está encriptado con el certificado de almacén de claves del Service Worker (opcional si el Service Worker no lo requiere)

    El mensaje se escribe en la base de datos consultada por un Service Worker de RA externo. Tras un tiempo (dependiendo de la frecuencia de ejecución del Service Worker y de si la CA está en línea), el cliente puede obtener el mensaje de respuesta.

    El cliente también es responsable de sondear la base de datos en busca de respuestas del trabajador de servicio RA externo.

    Al ejecutar ant externalra-client se creará un cliente de ejemplo con todas las dependencias en EJBCA_HOME/dist/externalra-cli. Este sencillo JAR de cliente puede usarse directamente como biblioteca y es un buen punto de partida para el desarrollo de clientes. Consulte EJBCA_HOME/modules/externalra/src/org/ejbca/extra/ra/ExtRATestClient.java y EJBCA_HOME/modules/externalra/src-test/ para obtener más información sobre el uso de la API.

    Los nuevos submensajes requieren una nueva clase org.ejbca.extra.db.MyRequest y org.ejbca.extra.caservice.processor.MyRequestProcessor, donde "My" es el nombre que usted elija. El envío de mensajes a una clase de procesamiento se realiza mediante reflexión de Java para instanciar automáticamente el procesador correcto, por lo que es importante que los nombres de clase sean correctos.

    Para obtener información sobre los clientes de RA externos, consulte Uso del servidor SCEP RA .

    Para generar javadoc para la API de RA externa, puede:

    cd modules/externalra
    javadoc -classpath ../../lib/hibernate/ejb3-persistence.jar -d javadoc -sourcepath src -subpackages org.ejbca

    Seguridad

    Se recomienda encarecidamente usar al menos la firma de los mensajes enviados entre la RA y la CA. Si los mensajes están firmados, ¿se usará el certificado de la RA para la autorización interna? Esto permite rastrear qué RA aprobó la información certificada y controlar qué tipo de información puede aprobar la RA mediante la definición de perfiles de entidad final. Si no se usa la firma, el servicio se ejecuta como un "usuario interno" donde todo es posible (superadministrador).

    Si se utiliza la firma de mensajes, el certificado del servidor RA (utilizado para firmar el mensaje) debe ser administrador en EJBCA y tener al menos los siguientes derechos:

    • El rol de administrador de RA

    • Ver/Crear/Editar/Recuperación de clave/Derechos de revocación

    • Acceso a los perfiles de entidad final utilizados por la RA

    • Acceso a las CA utilizadas por la RA

    Para la firma y el cifrado, el cliente que utiliza la API en la RA debe ser compatible con estas opciones. La ScepRA no es compatible con la firma ni el cifrado.

    Para la firma se utiliza el algoritmo de resumen SHA-256 y para el cifrado se utiliza AES256.

    Uso del servidor SCEP RA

    El servidor SCEP RA es un cliente de API de RA externa creado a partir del paquete EJBCA.

    El servidor SCEP RA admite el modelo de sondeo de RA de SCEP. Un cliente SCEP puede enviar una solicitud al servidor SCEP RA y esperar, sondeando la RA en busca de actualizaciones. Cuando la CA procesa la solicitud, que obtiene la solicitud pkcs10 mediante la API de RA externa, el certificado se devuelve al servidor SCEP RA. Cuando el certificado llega al servidor SCEP RA, este envía la respuesta del certificado SCEP la próxima vez que el cliente SCEP lo sondee. Esta función es muy útil para aislar de forma segura a la CA de los clientes SCEP en toda la red.

    Configuración del servidor SCEP RA en el host RA externo

    El servidor SCEP RA es el módulo instalado en el servidor RA externo. Este módulo recibe solicitudes SCEP de clientes SCEP y utiliza la API de RA externa para que la CA las procese.

    1. Configurar una base de datos de mensajes en el servidor RA externo

    2. Configure conf/externalra.properties para implementar un nuevo DataSouce para la base de datos de mensajes y volver a implementar EJBCA

    3. Configurar un nuevo trabajador para esta nueva fuente de datos (como se describe en secciones anteriores)

    4. Emita un almacén de claves PKCS#12 para el servidor SCEP RA desde la CA SCEP y configúrelo en EJBCA_HOME/conf/scepra.properties. La CA SCEP es la emisora de todas las solicitudes SCEP.

    5. Cree un perfil de entidad final y un perfil de certificado para emitir solicitudes SCEP y configúrelo en EJBCA_HOME/conf/scepra.properties.

    6. Configure una asignación de CA en EJBCA_HOME/conf/scepra.properties.

    7. Configure la conexión a la base de datos en EJBCA_HOME/conf/scepra.properties

    8. Opcional: configure scep.ra.authPwd en EJBCA_HOME/conf/scepra.properties si desea autenticar mensajes SCEP según una contraseña en la solicitud.

    9. Asegúrese de que el conector JDBC de base de datos JAR correcto esté instalado en el servidor de aplicaciones para su base de datos.

    10. Ejecute 'ant externalra-scep-deploy' para implementar la fuente de datos y el servidor SCEP RA (o ejecute 'ant externalra-scep' e implemente el archivo war dist/scepraserver.war usted mismo).

    Acceso al servidor SCEP RA en el host RA externo

    Puede acceder al servidor SCEP RA en el host RA externo apuntando su cliente (enrutador VPN, etc.) a la URL http://scepraserver.hostname:8080/scepraserver/scep/pkiclient.exe.

    Al usar esta URL, se incluirá la cadena de certificados en las respuestas SCEP. Dependiendo de su cliente, puede usar la URL http://scepraserver.hostname:8080/scepraserver/scep/noca/pkiclient.exe. Al usar esta URL, solo se devolverá el certificado del cliente en la respuesta SCEP.

    Opciones de seguridad

    Al usar la RA externa, la CA confía en todos los mensajes que provienen de ella. Esto significa que, si un cliente SCEP envía una solicitud a la RA, la CA creará el usuario y emitirá un certificado en cuanto reciba el mensaje.

    Para realizar una configuración más segura, se recomienda una de las dos formas siguientes:

    • <p Cada solicitud SCEP puede contener una contraseña. Configure authPwd en conf/scepra.properties con un valor distinto de "ninguno". Esto requerirá que se envíe una contraseña correcta en la solicitud SCEP.

    • Configurar aprobaciones en las CA que emiten certificados SCEP.

    Las dos formas también se pueden combinar y utilizar ambas.

    Al activar las aprobaciones, una solicitud SCEP generará una solicitud de aprobación en la CA. Esta solicitud se utilizará para agregar o editar un usuario. Un administrador podrá verla y aprobarla o rechazarla desde el cliente SCEP. El cliente SCEP seguirá consultando a la RA hasta que se apruebe la solicitud (en cuyo caso se devolverá un certificado) o hasta que se rechace la solicitud (en cuyo caso se devolverá un mensaje de error).

    Si se rechaza una solicitud de aprobación, por ejemplo porque el administrador del enrutador escribió algo mal, tendrá que esperar 30 minutos antes de que se pueda realizar una nueva solicitud, porque la RA recordará el rechazo durante 30 minutos.

    Una solicitud de aprobación tendrá una validez de una hora. Transcurrida esa hora, se creará una nueva solicitud.

    El flujo de trabajo normal utilizando aprobaciones es el siguiente:

    1. Un administrador de enrutador crea una solicitud SCEP a la RA.

    2. El administrador del enrutador llama a un administrador de EJBCA y solicita la aprobación de la solicitud.

    3. El administrador de EJBCA aprueba la solicitud y el enrutador obtiene el certificado, o bien rechaza la solicitud y el enrutador recibe un mensaje de error.

    Proxy CMP que utiliza RA externa

    El proxy CMP puede utilizar un back-end de API RA externa.

    El proxy CMP, que utiliza el backend de RA externa, recibirá mensajes CMP de los clientes mediante HTTP, los almacenará en la base de datos de RA externa y esperará la respuesta de la CA en dicha base de datos. Al recibir la respuesta, se devolverá al cliente. El cliente esperará mientras se realiza el sondeo y procesamiento de RA externa, por lo que se recomiendan tiempos de sondeo cortos (aproximadamente 10 segundos).

    Configuración del proxy CMP en el host RA externo

    El proxy CMP es el módulo instalado en el servidor RA externo.

    1. Desempaquetar un servidor Apache Tomcat o un servidor JBoss.

    2. Configurar una base de datos de mensajes en el servidor RA externo.

    3. Configure la fuente de datos de la base de datos en el servidor de aplicaciones (consulte a continuación el ejemplo de Tomcat).

    4. Asegúrese de que el JAR del conector JDBC de la base de datos correcto esté instalado en el servidor de aplicaciones en el servidor RA externo. (es decir, copie mariadb-java-client-1.2.0.jar a apache-tomcat-7.0.67/lib/)

    5. Configure el backend y la fuente de datos de RA externos en EJBCA_HOME/modules/cmpProxy/resources/properties/cmpProxy.properties (si se usa el nombre de fuente de datos predeterminado, solo es necesario configurar cmp.backend.protocol).

    6. Configure el nivel de registro en módulos/cmpProxy/recursos/properties/log4j.xml.

    7. Ejecute 'ant cmpHttpProxy' para crear el proxy CMP (en dist/cmpHttpProxy) y copie el archivo war al directorio de implementación del servidor de aplicaciones.

    Si necesita recortar la configuración de la conexión de la base de datos en el host RA externo, esto se hace en módulos/cmpProxy/recursos/properties/persistence.xml.

    Para configurar una fuente de datos, utilizando un grupo de conexiones, en Tomcat debe editar conf/server.xml> y agregar el siguiente recurso a <GlobalNamingResources>:

    < Resource
    name = "jdbc/CMPRAMessageDS"
    auth = "Container"
    type = "javax.sql.DataSource"
    maxActive = "100"
    maxIdle = "30"
    maxWait = "10000"
    username = "ejbca"
    password = "ejbca"
    driverClassName = "org.mariadb.jdbc.Driver"
    url = "jdbc:mysql://database-host:3306/messages"
    />

    Necesita editar el nombre de usuario, la contraseña y la URL.

    También debe hacer que la fuente de datos esté disponible para la aplicación web editando conf/context.xml y agregando un enlace de recurso al final (justo antes de </Context>):

    < ResourceLink
    name = "jdbc/CMPRAMessageDS"
    global = "jdbc/CMPRAMessageDS"
    type = "javax.sql.DataSource" />

    Sondeo de mensajes de configuración desde EJBCA

    1. En el host de CA, configure conf/externalra.properties para habilitar el servicio de RA externa e implementar un nuevo DataSouce para la base de datos de mensajes, y vuelva a implementar EJBCA.

    2. Configure un nuevo trabajador para esta nueva fuente de datos (como se describe en secciones anteriores).

    3. Configure los alias de CMP, como lo haría utilizando la comunicación CMP directa.

    4. Asegúrese de que haya un JAR de conector JDBC de base de datos instalado en el servidor de aplicaciones local para la base de datos de mensajes RA externa.

    5. Configurar un nuevo trabajador para esta nueva fuente de datos.

      • Opcional: si se requiere firma y cifrado de mensajes, cree y configure almacenes de claves para esto.

      • Opcional: para una capa adicional de seguridad, utilice la lista de permitidos que se describe en la sección de configuración del servicio para permitir únicamente org.ejbca.extra.db.CMPRequest.

    Propiedades del servicio de muestra:

    • Seleccionar trabajador: Trabajador personalizado

    • Ruta de clase de trabajador personalizada: org.ejbca.extra.caservice.ExtRACAServiceWorker

    • Propiedades de trabajador personalizadas: (copiar a continuación)

    • Seleccionar intervalo: Intervalo periódico

    • Periodo: 5 segundos

    • Seleccionar acción: Sin acción

    • Activo: Marcado

    externalra-caservice.whitelist=org.ejbca.extra.db.CMPRequest
    externalra-caservice.keystore.path=/home/ejbca/externalra-caservice.p12
    externalra-caservice.keystore.pwd=foo123
    externalra-caservice.raissuer=ManagementCA
    externalra-caservice.signature.required= true
    externalra-caservice.encryption.required= false
    externalra-caservice.persistenceunit=RAMessage1DS

    Acceso al proxy CMP en el host RA externo

    Puede acceder al proxy CMP como se describe en las instrucciones del proxy CMP. No hay diferencia entre un cliente que usa el backend HTTP o el backend RA externo. Ejemplo de comando, usando cmpforopenssl (como en los ejemplos de CMP ), pero a través del proxy:

    ./cmpclient --server localhost --port 8080 --path cmpProxy- 6.4 . 0 /cmpalias --srvcert ManagementCA.cacert.pem --ir --user mykeyid --password password --newclcert clcert.der --newkey privkey.pem --subject "CN=user1,O=My Organization,C=SE"

    En comparación con una sesión directa a la CA:

    ./cmpclient --server localhost --port 8080 --path ejbca/publicweb/cmp/cmpalias --srvcert ManagementCA.cacert.pem --ir --user mykeyid --password password --newclcert clcert.der --newkey privkey.pem --subject "CN=user1,O=My Organization,C=SE"

    Opciones de seguridad

    Al usar la RA externa, la CA funciona igual que si un cliente se conectara directamente, lo que significa que puede usar el modo cliente o RA, etc. Para obtener más información, consulte CMP . Puede usar listas de permitidos y mensajes de RA externos firmados para limitar aún más las capacidades del host de RA externo.

    Para firmar y cifrar mensajes RA externos, utilice las siguientes opciones para configurar almacenes de claves en cmpProxy.properties:

    cmp.backend.keystorepath
    cmp.backend.keystorepwd
    cmp.backend.caservicecertpath
    cmp.backend.issuerchainpath

    Agrupación de RA externos

    Puede tener varios servidores de RA externos para proporcionar alta disponibilidad o un mayor rendimiento. Generalmente, existen dos maneras de agrupar RA externos:

    • Configuración de una base de datos compartida (HA) para los servidores RA externos.

    • Configuración de bases de datos independientes en cada servidor RA externo.

    imágenes/descargar/archivos adjuntos/175047407/external-ra-cluster.png

    Los service workers externos de RA en la CA funcionan en todo el clúster de la CA. Esto significa que, si tiene varios nodos de CA, un solo service worker se ejecutará en un nodo de forma predeterminada, pero si este falla, se ejecutará en los demás. Además, puede asignar service workers a nodos específicos, lo que permite configurar tres workers que siempre se ejecutan en sus respectivos nodos.