Uso de CT en certificados

Configure los registros y habilite CT en los perfiles de certificado como se describe en la sección Agregar registros CT .

Se recomienda agregar un Servicio de Revocación de Precertificados para revocar cualquier certificado emitido de forma incompleta, es decir, precertificados para los que no se generó el certificado final. Si no existe dicho servicio, aparecerá un botón para agregarlo en la pestaña Registros de Transparencia de Certificados de la Configuración del Sistema.

Uso de CT en las respuestas de OCSP

EJBCA admite CT en respuestas OCSP, tanto en respondedores OCSP activos como en la preproducción de respuestas. De forma predeterminada, EJBCA almacena en caché hasta aproximadamente 100 000 extensiones de respuesta CT. Las extensiones de respuesta almacenadas en caché sobrantes que no se hayan solicitado durante 10 segundos se eliminan aleatoriamente de la caché. Los parámetros se pueden ajustar en el archivo conf/cesecore.properties .

Para utilizar CT OCSP también debe habilitar la extensión correspondiente en OcspKeyBinding del OCSP Responder:

1. Seleccione CA UI → Vinculaciones de teclas internas → OcspKeyBindings y elija la vinculación de teclas que desea editar.

2. En Extensiones OCSP , seleccione Transparencia de certificado SCT .

3. Haga clic en Agregar y luego en Guardar.

Para obtener más información sobre cómo configurar registros CT y perfiles de certificado, consulte Agregar registros CT .

Uso de CT para la extensión TLS

En este modo, el titular del certificado solicita las SCT de los registros y las incluye en una extensión TLS. La CA no tiene que hacer nada, pero es posible reducir el tiempo necesario para obtener los registros de auditoría completos (combinados) publicando los certificados en los registros tan pronto como se emiten. Para obtener detalles de configuración, consulte Publicar en registros CT de forma asíncrona tras la emisión .

Publicar en registros CT de forma asincrónica después de la emisión

EJBCA puede publicar certificados de forma asíncrona en uno o más registros CT mediante un publicador personalizado. Esta función está diseñada principalmente para usarse con CT en modo TLS u OCSP.

Para habilitar la publicación en registros sin incluir los SCT en los certificados emitidos, haga lo siguiente:

1. Vaya a Funciones de CA > Editores y agregue un nuevo editor con la siguiente configuración:

   Campo	Valor
   Tipo de editor	Editor personalizado.
   Ruta de clases	org.ejbca.code.model.ca.publisher.CTCustomPublisher Dependiendo de la configuración del sistema, esto puede aparecer solo como "CTCustomPublisher".
   Propiedades	Déjalo en blanco.
   Sin publicación directa, solo uso de cola	Sí.
   Mantener los elementos publicados correctamente en la base de datos	No.
   Usar cola para CRL	No.
   Usar cola para certificados	Sí.

2. Haga clic en Guardar. Tenga en cuenta que el editor debe estar habilitado en los perfiles de certificado antes de que la publicación se active.

3. A continuación, especifique lo siguiente en Funciones del sistema > Servicios para crear un servicio para el editor:

   Campo	Descripción
   Obrero	Trabajador de proceso de cola de publicación.
   Editores a verificar	El editor creado previamente.
   Período	El valor predeterminado es 5 minutos y puede cambiarse a varias horas.
   Activo	Sí.

Servicio de revocación de precertificados

Al usar CT en certificados, se recomienda agregar un Servicio de Revocación de Precertificado . Si solo se usa CT en respuestas OCSP o extensiones TLS, no se necesita dicho servicio.

Adición de registros CT

Los servidores de registro CT se configuran en Configuración del sistema . Tenga en cuenta que no estarán activos hasta que se habiliten según el perfil de certificado.

Los siguientes parámetros deben configurarse en un registro:

El servidor de registros debe aceptar los certificados emitidos por sus CA. Para realizar pruebas locales, puede instalar su propia instancia del servidor de registros de ejemplo del proyecto de código abierto CT y agregar su CA raíz a la lista de CA de confianza. Para un sistema de producción (o para probar uno), debe contactar al operador de registros para que agregue su CA raíz.

Para mayor redundancia, se recomienda agregar más registros a cada etiqueta que el mínimo requerido. De esta forma, la emisión del certificado no fallará si un solo registro falla. También es recomendable especificar un tiempo de espera corto o habilitar la opción ct.fastfail.enabled en conf/cesecore.properties para que un registro fallido no ralentice todas las solicitudes.

En cuanto al rendimiento, EJBCA se conectará a todos los registros que tengan una de las etiquetas seleccionadas en el perfil del certificado, en el orden en que se agregaron y en paralelo. Continuará obteniendo SCT hasta alcanzar el número máximo de SCT . EJBCA fallará la emisión si no puede obtener al menos el número de SCT especificado en el parámetro "Número mínimo de SCT" del perfil del certificado. Si el número de SCT recuperados supera el valor máximo, se excluirán los registros que estén en último lugar.

Para cambiar el orden en que se contactan los registros, reorganícelos en la página Configuración del sistema .

Etiquetas

Puede ser necesario publicar en ciertos registros y en una cantidad determinada de ellos antes de emitir un certificado. Por ejemplo, Google Chrome exige que todos los certificados EV emitidos después del 1 de enero de 2015 se publiquen en al menos un registro CT operado por Google, en al menos un registro no operado por Google y en una cantidad determinada de registros en total, cuyo número total depende de la vigencia del certificado.

Para tener cierto control sobre los registros que se escriben durante una operación de emisión, estos se clasifican en Etiquetas . Al agregar etiquetas a los perfiles de certificado, se debe escribir al menos un registro de cada etiqueta. Los SCT restantes requeridos se utilizarán de los registros con respuesta más rápida, y cualquier SCT devuelto después de la emisión se descartará, siguiendo un enfoque aleatorio, con el fin de cumplir con los requisitos de Chrome y, al mismo tiempo, proporcionar la emisión en el menor tiempo posible.

Los parámetros Número mínimo de SCT y Número máximo de SCT se pueden configurar para cada perfil de certificado, ya sea manualmente o por validez del certificado, según la política CT. Un ejemplo de configuración que cumple con la política CT de Chrome podría incluir lo siguiente:

• Una etiqueta de registros de Google que contiene un conjunto de registros operados por Google y una etiqueta Sin etiqueta que contiene un conjunto de registros no operados por Google.

• Un perfil de certificado con:

  • Las etiquetas Registros de Google y Sin etiquetar seleccionadas.

  • El parámetro Número mínimo de SCT se establece en Por validez para permitir que EJBCA seleccione un mínimo de forma dinámica según la Política CT de Chrome.

  • El parámetro Número máximo de SCT se establece en Por validez para incluir solo la cantidad de SCT requerida según la Política CT de Chrome en el certificado.

Restablecimiento de conexión

Este síntoma se diagnostica utilizando entradas de registro con "Restablecimiento de conexión" al enviar un certificado a los registros de CT como se muestra a continuación:

Para solucionar este problema, verifique lo siguiente:

1. Algunos servidores de registro requieren TLS v1.2, que no es compatible con algunas versiones anteriores de Java. Java 8 usa TLS v1.2 por defecto. Si el envío de CT falló debido a un error de TLS, verá algo similar a esto en el registro:

   Caused by: java.net.SocketException: Connection reset

   at java.net.SocketInputStream.read(SocketInputStream.java: 196 ) [rt.jar: 1.7 .0_85]

   at java.net.SocketInputStream.read(SocketInputStream.java: 122 ) [rt.jar: 1.7 .0_85]

   at sun.security.ssl.InputRecord.readFully(InputRecord.java: 442 ) [jsse.jar: 1.7 .0_85]

   at sun.security.ssl.InputRecord.read(InputRecord.java: 480 ) [jsse.jar: 1.7 .0_85]

   at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java: 946 ) [jsse.jar: 1.7 .0_85]

   at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java: 1344 ) [jsse.jar: 1.7 .0_85]

   at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java: 1371 ) [jsse.jar: 1.7 .0_85]

   at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java: 1355 ) [jsse.jar: 1.7 .0_85]

   Esto significa que el protocolo de enlace TLS falló y el servidor de registro CT cerró la conexión.

2. Asegúrese de que su firewall esté configurado correctamente, por ejemplo, permita que EJBCA envíe tráfico HTTPS a los registros CT que está utilizando.

   Para probar la comunicación entre EJBCA y el servidor de registro CT, emita el siguiente comando en la máquina EJBCA:

   > curl 'https://<log server>/ct/v1/add-pre-chain'

   {

   "error_message" : "Unable to parse request." ,

   "success" : false

   }

   "No se puede analizar la solicitud" significa que el servidor de registro CT recibió su solicitud correctamente y la comunicación entre EJBCA y el servidor de registro CT debería funcionar correctamente.

HTTP 400 Solicitud incorrecta

Este síntoma se diagnostica mediante entradas de registro con "HTTP 400 Bad Request" al enviar un certificado a los registros de CT, como se muestra a continuación:

Para solucionar este problema, verifique lo siguiente:

1. Asegúrese de que el operador del registro CT agregue su certificado de CA raíz al almacén de confianza del registro CT.

   Para comprobar qué raíces acepta un registro CT, envíe una solicitud GET a https://<servidor de registro>/ct/v1/get-roots, como se explica en la RFC 6962, sección 4.7 "Recuperación de certificados raíz aceptados". Para más información, consulte la RFC 6962 .

2. No todos los registros aceptan todos los certificados. En particular, algunos registros CT, como los registros Argon de Google y los registros Nimbus de Cloudflare, solo aceptan certificados con un año específico para la salida. Al agregar estos registros, siempre debe habilitar la opción de registros CT fragmentados, como se explica en Registros CT basados en la fecha de vencimiento . Si no está seguro de qué certificados acepta un registro en particular, comuníquese con el operador del registro CT.

3. Inspeccione los registros y busque el mensaje de error JSON devuelto por el servidor de registros CT. Este mensaje se registra en el nivel INFO a partir de EJBCA 6.14 y se parece al siguiente ejemplo:

   2018 - 06 - 01 13 : 37 : 00 INFO [org.cesecore.certificates.certificatetransparency.HttpPostTimeoutInvoker] (pool- 000 30 -thread- , 3 ) Error content from CT log was: {

   "error_message" : "Foo." ,

   "success" : false

   }

   La entrada del registro solo se escribirá en el registro si recibe una respuesta HTTP del registro CT con un código de estado HTTP x, 200 ≤ x ≤ 299. Es decir, si el envío de CT falló debido a un error de TLS, este mensaje no se escribirá en el registro.
   
   

4. Los servidores de registro CT incorporan una limitación de velocidad. Algunas limitaciones son globales y pueden afectarle incluso si su tasa de envío es baja. Los problemas de CT causados por esta limitación pueden ser difíciles de solucionar, ya que los errores aparecen esporádicamente y aparentemente al azar. Si el mensaje de error del servidor de registro contiene algo como "solicitud inválida" o "límite de velocidad", es posible que esté sufriendo una limitación de velocidad. Para garantizar que EJBCA pueda emitir el certificado incluso si algunos registros CT no pueden atender su solicitud, debe agregar servidores de registro adicionales a su configuración de registros CT.

Precertificados persistentes y OCSP

EJBCA genera un precertificado ( RFC 6962 ) que se envía a los registros CT configurados antes de la emisión del certificado final. Si ( y solo si ) se recibe un número suficiente de SCT como respuesta, se emite el certificado final. En caso de no generar el certificado final debido a respuestas SCT insuficientes, falta de contacto con suficientes registros CT o cualquier error interno después de generar un precertificado, la transacción se revertirá, pero el precertificado se conservará en la base de datos (a partir de EJBCA 7.3.1) y se publicará para los publicadores configurados.

Aunque el precertificado en sí mismo es inútil tras una emisión fallida, según la RFC 6962, emitirlo es una intención vinculante. Por lo tanto, se conserva en la base de datos (con estado "bueno") para que OCSP responda de acuerdo con la política de Mozilla y las expectativas del Foro CA/B. La revocación de precertificados se gestiona de la misma manera que la de los certificados reales en EJBCA y se registrará en la CRL.