Gestión de respondedores de OCSP
A continuación se cubren todos los aspectos de la gestión de un respondedor OCSP, ya sea ubicado localmente en la misma máquina que la CA o de forma remota en un VA.
Habilitar encabezados de caché de OCSP para respuestas no autorizadas
Comprobación del estado del respondedor OCSP mediante la caja de herramientas del cliente EJBCA
Para obtener una descripción detallada de cómo EJBCA gestiona OCSP, consulte la Descripción general de OCSP . Para obtener más información sobre los respondedores de OCSP, consulte la Descripción general de los respondedores de OCSP.
Creación y configuración del respondedor OCSP
Uso de la interfaz de usuario en un asistente virtual remoto
El respondedor OCSP tiene la misma interfaz de usuario que la CA, por lo que puede administrar todos sus tokens criptográficos y enlaces de claves mediante la interfaz de usuario de la CA (o la CLI, consulte a continuación).
En un respondedor OCSP, normalmente solo se utilizan algunas funciones de la interfaz de CA, aunque todas están disponibles. Las funciones importantes para un respondedor OCSP son:
Tokens criptográficos
Atajos de teclado internos
Requisitos previos para el acceso a la interfaz de usuario de CA:
Almacenes de claves TLS disponibles como p12/tomcat.jks y p12/truststore.jks (copias de la CA EJBCA), que se implementarán con deploy-keystore y web-configure (puede requerir la configuración de la contraseña del almacén de claves en conf/web.properties).
Un certificado de CA de administración importado (el certificado de la CA que emite certificados de administrador).
Administradores configurados con reglas de acceso.
Si solo desea configurar un superadministrador, la regla de acceso inicial se configura automáticamente durante el inicio (consulte las tablas de base de datos AdminGroupData y AccessRulesData). Puede ejecutar los siguientes comandos para importar un certificado de CA de administración y agregar un superadministrador que tenga un certificado con "CN=SuperAdmin" emitido por esta CA (esto creará un registro en la tabla de base de datos AdminEntityData).
bin /ejbca .sh ca importcacert ManagementCA /home/user/adminca1 .pembin /ejbca .sh roles addmember "Super Administrator Role" ManagementCA WITH_COMMONNAME TYPE_EQUALCASE SuperAdmin Si no desea importar el certificado de administrador en EJBCA, puede configurar web.reqcertindb= false en conf/web.properties .
De lo contrario, el certificado de administrador debe estar presente en la base de datos (se puede importar mediante la CLI).
Configuración de las claves de respuesta de OCSP
Si trabaja en un VA remoto, asegúrese de importar la CA que se supone que será el respondedor OCSP desde la CA EJBCA.
Las claves utilizadas para firmar la respuesta OCSP se referencian mediante tokens criptográficos (que pueden ser de software o basados en HSM/PKCS#11). Debe haber una clave para cada CA, y se debe emitir un certificado de firma OCSP desde cada CA a la que responde el respondedor.
El perfil del certificado podría ser el mismo para todos los certificados de firma OCSP emitidos.
Para emitir un certificado de firmante OCSP desde EJBCA, defina un nuevo perfil de certificado y clone el perfil de certificado integrado "OCSPSIGNER". Este perfil de certificado es similar a un perfil normal, con los siguientes usos de clave:
- Key Usage: Digital Signature- Extended Key Usage: OCSPSignerConfigure el perfil de certificado recién creado para usar el publicador OCSP definido anteriormente. También debe crear un nuevo perfil de entidad final para usar el nuevo perfil de certificado. A continuación, debe crear un usuario para cada CA que use este perfil de certificado. Utilice el tipo de token " Generado por el usuario" .
Los certificados de los respondedores de OCSP y los certificados de la CA deben publicarse desde la CA al respondedor de OCSP. Para la CA, esto se hace configurando el publicador de CRL como el publicador de OCSP.
Cómo rellenar la base de datos OCSP en un VA remoto
Por diseño, un VA independiente está diseñado para ser con estado, ya que no se puede presumir una conexión con la CA, ni se puede confiar en que dicha conexión sea constante. Por ello, la base de datos del VA se alimenta con información del certificado, lo que le permite funcionar independientemente de la CA. Esto se puede lograr de varias maneras. Si bien recomendamos encarecidamente usar el EJBCA Peer Publisher como la opción más segura y sencilla, ofrecemos opciones para alimentar el VA desde una CRL generada por una CA no EJBCA, o bien para generar su propio editor personalizado y escribir directamente en la base de datos EJBCA.
Uso de un editor en la CA
Actualmente ofrecemos dos publicadores: EJBCA Peer Publisher , que publica certificados de forma sincrónica mediante TLS, y Legacy VA Publisher , que utiliza la publicación directa de bases de datos.
Uso del editor de pares EJBCA
EMPRESA Esta es una característica de EJBCA Enterprise.
Siga los pasos para configurar un nuevo firmante OCSP utilizando un sistema de pares EJBCA:
Estas instrucciones presuponen que ya existe un sistema par que conecta las máquinas de la CA y del VA, que la conexión ya se ha probado y que existe una identidad remota que representa a la CA entre las "Conexiones entrantes" en los sistemas par del VA. Para obtener información sobre la configuración de sistemas par, consulte Sistemas par .
Vaya a la interfaz de usuario de CA del VA → Crypto Tokens y cree un nuevo Crypto Token (a menos que desee reutilizar uno existente).
Vaya a la interfaz de usuario de CA del VA → Tokens criptográficos → Su token criptográfico creado y genere un nuevo par de claves.
Vaya a la interfaz de usuario de CA de VA → Respondedores OCSP y cree un nuevo Respondedor OCSP que haga referencia al token criptográfico y al par de claves.
Vaya a la interfaz de usuario de CA del VA → Sistemas pares → Haga clic en Modificar rol para el conector par que representa a la CA y configure reglas de acceso para el respondedor OCSP recién creado ("solo lectura" o "Renovar certificado").
Vaya a la interfaz de usuario Ra de la CA → Inscribirse → Realizar nueva solicitud , cree una entidad final (use la opción "Posponer" para "Generación de par de claves") para emitir el certificado de firma OCSP (use un perfil de certificado de firmante OCSP).
Vaya a la interfaz de usuario de CA de la CA → Sistemas pares → Haga clic en Administrar para el conector par que representa al VA → Vinculaciones de teclas remotas, complete las credenciales para la entidad final de firma de OCSP en el respondedor de OCSP recién creado y haga clic en Emitir certificado de firma .
Vaya a la interfaz de usuario de CA de VA > Respondedores OCSP y verifique que la vinculación de clave OCSP tenga un certificado y se haya activado.
Uso del Legacy VA Publisher
EMPRESA Esta es una característica de EJBCA Enterprise.
Siga los pasos para configurar un nuevo firmante de OCSP utilizando un publicador de VA:
Vaya a la interfaz de usuario de CA del VA → Crypto Tokens y cree un nuevo Crypto Token (a menos que desee reutilizar uno existente).
Vaya a la interfaz de usuario de CA del VA → Tokens criptográficos → Su token criptográfico creado y genere un nuevo par de claves.
Vaya a la interfaz de usuario de CA de VA → Respondedores OCSP y cree un nuevo Respondedor OCSP que haga referencia al token criptográfico y al par de claves.
Vaya a la interfaz de CA del VA → Asignaciones de teclas internas y cree una solicitud de firma de certificado para su nuevo respondedor OCSP. Guarde este archivo.
Vaya a la Web de RA de CA → Inscribirse → Usar nombre de usuario → Usar las credenciales para emitir un certificado de firma OCSP y cargue la CSR.
...(CA publica un nuevo certificado de firma OCSP en la instancia VA)...
Vaya a la interfaz de CA del VA → Asignaciones de claves internas y haga clic en Actualizar para su nuevo respondedor OCSP. Esto encontrará el certificado publicado al comparar el par de claves con el certificado.
Vaya a la interfaz de usuario de CA del VA → Vinculaciones de teclas internas y haga clic en Habilitar para que su nuevo respondedor OCSP comience a procesar respuestas OCSP con él.
Uso del servicio de descarga de CRL
Para configurar un servicio que descargue y complete automáticamente los campos mencionados desde una CRL, haga lo siguiente:
Seleccione CA UI → Autoridades de certificación → Importar certificado de CA para la CA para la que desea entregar respuestas de OCSP.
Seleccione CA UI → Autoridades de certificación → Editar CA para la CA importada → Configurar un CDP externo donde la CA pone a disposición sus CRL (debe comenzar con "http://").
Seleccione CA UI → Servicios y agregue un nuevo servicio "CRLDownloadService".
Seleccione CA UI → Servicios y edite "CRLDownloadService":
Seleccionar Trabajador: Descargador de CRL.
CA a verificar : seleccione la CA importada (o seleccione CUALQUIERA para procesar todas las CA X509 externas con un CDP externo configurado).
Ignorar nextUpdate y descargar siempre la CRL : seleccione esta opción para forzar la descarga de la CRL cada vez que se ejecute el servicio en lugar de solo descargar la CRL cuando la última CRL conocida indica que habrá una nueva disponible.
Tamaño máximo permitido para descargar (bytes): El Servicio se negará a procesar CRL que sean más grandes que este límite.
Periodo: Con qué frecuencia el Servicio debe comprobar si es necesario descargar una nueva CRL.
Activo: Seleccione para activar el servicio.
La próxima vez que se ejecute el servicio, se generarán entradas de registro que indicarán si la descarga y el procesamiento de la CRL se realizaron correctamente. Tras la primera ejecución del servicio, debería poder descargar la CRL desde las páginas web de RA del VA.
A continuación, configure un Responder OCSP como se describe para el caso donde se utiliza la publicación directa de la base de datos. La única diferencia es que el VA no tiene forma de saber si un certificado se ha emitido alguna vez, por lo que es lógico responder con el estado OCSP "bueno" para los certificados desconocidos.
Si la CRL descargada del CDP externo contiene la extensión CRL más reciente, el servicio intentará descargar y procesar cualquier URL que utilice "http" como protocolo.
Uso de una implementación personalizada
Al ejecutar el respondedor OCSP que responde a las consultas de las CA en una instalación EJBCA, rellene la base de datos mediante el Publicador OCSP externo . Para obtener más información, consulte Creación y configuración del respondedor OCSP .
Al usar un software de CA distinto de EJBCA, puede rellenar la base de datos con los datos de ese sistema. Solo necesita insertar datos en la tabla CertificateData del respondedor OCSP externo.
Los valores utilizados por el respondedor OCSP son:
Campo | Descripción |
DN del emisor | Debe tener el formato "EJBCA normalizado", como lo devuelve org.cesecore.util.CertTools.getIssuerDN(cert) . |
número de serie | Es BigInteger.toString(). |
estado | Proviene de CertificateDataBean.CERT_REVOKED, etc. |
Fecha de revocación |
Fecha (en milisegundos desde la época) en que se revocó el certificado. O 0 por defecto si no se revocó. |
Motivo de revocación | Motivo de la revocación. Si se trata de RevokedCertInfo.NOT_REVOKED, etc. |
ID de perfil del certificado | Se utiliza si configura cosas como ocsp.999.untilNextUpdate en ocsp.properties . |
fecha de vencimiento | Fecha (en milisegundos desde la época) en que vence el certificado. |
Los certificados de CA y los certificados de firmante OCSP también deben estar en la base de datos. Para estos certificados, también deben incluirse los campos de huella digital, subjectDN y base64Cert.
Configuración del respondedor predeterminado
El respondedor predeterminado es el CA o el respondedor OCSP válido configurado para firmar respuestas a solicitudes que provienen de emisores desconocidos.
Configuración del respondedor predeterminado desde la GUI
Puede elegir el respondedor predeterminado en el menú de lista de la página "Respondedor de OCSP" de la interfaz gráfica de usuario. Este menú mostrará todas las CA y respondedores válidos. También podrá elegir "ninguno" y conservar un valor antiguo, pero no coincidente, importado mediante la migración desde configuraciones anteriores a la versión 6.2.4.
Configuración del respondedor predeterminado desde la CLI
El respondedor predeterminado también se puede elegir desde la CLI con el siguiente comando.
> bin/ejbca.sh ocsp setdefaultresponder < DNPara ver una lista de respondedores válidos, ejecute el comando con la opción --help . Esto también mostrará el respondedor seleccionado.
Configuración del tipo de ID de respondedor para las CA
Las CA locales responderán automáticamente a las respuestas OCSP, a menos que se les haya configurado un respondedor OCSP. Esta configuración define el tipo de ID de respondedor general para las CA que actúan como sus propios respondedores. Al igual que para un respondedor OCSP, el tipo de ID de respondedor puede ser un nombre (SubjectDN del certificado de firma utilizado para la respuesta) o un hash de clave (resumen SHA-1 de la clave pública del certificado de firma utilizado para la respuesta).
Habilitar la actualización de la caché de firma de OCSP
Controla si la actualización de la caché de firmas OCSP está habilitada. De forma predeterminada, la actualización de la caché está deshabilitada ( la opción "Habilitar actualización de la caché de firmas OCSP " está desactivada).
Antes de EJBCA 7.4.1, la actualización de caché estaba habilitada de forma predeterminada y siempre se buscaban entradas faltantes de CA desconocidas en la caché. Tenga en cuenta que esto solo se aplica cuando se crean nuevas CA o se renuevan las existentes. Si se requiere el comportamiento anterior, se debe seleccionar la opción Habilitar actualización de caché de firmas OCSP para habilitarla.
Habilitar encabezados de caché de OCSP para respuestas no autorizadas
De forma predeterminada, las respuestas con el estado "No autorizado" no incluyen encabezados de caché. Al habilitar esta opción, las respuestas no autorizadas contendrán un encabezado "no-cache".
Comprobación del estado del respondedor OCSP mediante la caja de herramientas del cliente EJBCA
La verificación de un respondedor en ejecución se puede realizar mediante la Caja de herramientas del cliente EJBCA .
Para enumerar todos los comandos OCSP disponibles, ejecute lo siguiente:
$TOOLBOX_HOME/ejbcaClientToolBox.sh OCSP Uso de HTTP GET y RFC5019
Para las solicitudes HTTP GET según RFC5019, podemos configurar encabezados HTTP en la respuesta para permitir que los servidores proxy de caché almacenen las respuestas en caché. De forma predeterminada, estas propiedades no permiten el almacenamiento en caché, que es el comportamiento predeterminado.
Para habilitar el almacenamiento en caché en servidores proxy HTTP, puede ajustar algunas propiedades en conf/ocsp.properties o en el Respondedor OCSP.
ocsp.untilNextUpdate: Número de segundos que una respuesta será válida. Esto establece el campo nextUpdate en la respuesta de OCSP.
ocsp.maxAge: Tiempo en segundos que se almacenará en caché una respuesta. Debe ser menor que untilNextUpdate. Esto añade encabezados de caché RFC5019 .
También puede especificar diferentes valores de nextUpdate según los perfiles de certificado que emitieron el certificado. Esto solo funciona si ha publicado la información del certificado con EJBCA 3.9.0 o posterior, donde se rellena la columna "certifiedProfileId" de la tabla "CertificateData". Puede encontrar el "certifiedProfileId" en la interfaz de usuario de la CA.
ocsp.<certificateProfileId>.untilNextUpdate: Número de segundos que una respuesta será válida para los certificados emitidos con el perfil de certificado especificado.
ocsp.<certificateProfileId>.maxAge: Tiempo durante el cual se almacenará en caché una respuesta para los certificados emitidos con el perfil de certificado especificado. Debe ser menor que untilNextUpdate.
Si no se especifica un certificadoProfileId específico, se utilizan los valores predeterminados de ocsp.maxAge y ocsp.untilNextUpdate. Las propiedades de un respondedor de OCSP anularán los valores predeterminados, pero nunca la configuración específica de certificateProfileId.
Sin embargo, en caso de que se desconozca el estado del certificado, EJBCA intenta evitar el almacenamiento en caché de una respuesta GET de OCSP configurando el encabezado HTTP "Cache-Control" en "no-cache, must-revalidate" (no configurable).
Pruebas de estrés de OCSP
Puede realizar pruebas de estrés a sus CA y respondedores OCSP utilizando la Caja de herramientas del cliente EJBCA .
Para realizar una prueba de estrés, emita una gran cantidad de certificados desde la CA utilizando la prueba de estrés del servicio web y, luego, realice una prueba de estrés del respondedor OCSP con una selección aleatoria de todos los certificados emitidos.
$TOOLBOX_HOME/ejbcaClientToolBox.sh EjbcaWsRaCli stress ...$TOOLBOX_HOME/ejbcaClientToolBox.sh OCSP stress ... Monitoreo de bases de datos OCSP
La CLI de base de datos EJBCA contiene una herramienta independiente para supervisar bases de datos OCSP. Esta herramienta se basa en Java SE JPA y se puede configurar en:
dist/ejbca-db-cli/META-INF/persistence.xml.Log4J se utiliza para generar informes y se puede configurar en:
dist/ejbca-db-cli/log4j.xml.Una vez creado, ejecute el comando con:
./run.sh ocspmonLa herramienta utiliza ID de perfil de certificado, que son representaciones internas de diferentes perfiles de certificado en EJBCA. Al ejecutarse, la herramienta muestra todos los ID existentes en cada OCSP. Estos ID también se muestran en la interfaz de usuario de la CA para cada perfil de certificado.
Se detectan las siguientes inconsistencias:
Falta información sobre los certificados en la base de datos OCSP. (ERROR)
Información adicional sobre los certificados en la base de datos OCSP. (ERROR)
Información sobre certificados en la base de datos OCSP que han sido alterados. (ERROR)
Si hay perfiles de certificado adicionales en uso en el OCSP además de los que se están verificando. (ADVERTENCIA)
Cada inconsistencia detectada también se informará en un mensaje de ERROR final resumido y, si hay demasiados errores, este mensaje final se truncará.
En lugar de recorrer cada fila de CertificateData en una base de datos, se recomienda utilizar índices como el siguiente ejemplo tanto para la base de datos de CA como para cada respondedor de OCSP:
create index certificatedata_idx7 on CertificateData(certificateProfileId); Activación del token de firma (solo actualizaciones)
Si actualiza desde una versión anterior de EJBCA 5.0.x, se requiere la contraseña de activación para migrar los almacenes de claves de firma de OCSP. Al activar, se le solicitará una contraseña, que se usará para todas las contraseñas de token no configuradas.
Para activar:
$TOOLBOX_HOME/ejbcaClientToolBox.sh OCSPActivateDespués de migrar los almacenes de claves y los certificados a Crypto Tokens y OCSP Responders, debe utilizar la CLI de EJB para activar sus Crypto Tokens.
Ejemplo: Configurar un respondedor
Para obtener instrucciones sobre cómo configurar un respondedor mediante la interfaz de línea de comandos, consulte Configurar un respondedor mediante la CLI.