Respondedores del OCSP
Una CA puede delegar la firma de respuestas OCSP a un par de claves separado; esto se configura en la página Respondedores OCSP en la interfaz de usuario.
Especificación del certificado
Un respondedor OCSP utiliza un par de claves locales (definido en un token criptográfico ), que a su vez debe estar firmado por la CA a la que responde el respondedor OCSP. Además, el perfil de certificado de este certificado debe definir lo siguiente:
El certificado debe tener Uso de clave: Firma digital .
El certificado debe tener Uso de clave extendido: OCSPSigner .
El certificado normalmente tiene habilitada la extensión OCSP No Check .
La lista de certificados confiables se utilizará para validar la firma de la solicitud OCSP (si se requiere una firma).
Además, se puede usar una asignación de teclas para firmar respuestas de certificados emitidos por otras CA. Se pueden agregar a una lista mediante la interfaz gráfica de usuario (GUI) o la interfaz de línea de comandos (CLI) de EJBCA. Se puede asignar una CA a un máximo de una asignación de teclas.
Propiedades globales de OCSP
A continuación se cubren las propiedades globales de OCSP.
El respondedor predeterminado
El respondedor predeterminado es la CA válida o la combinación de teclas OCSP establecida para firmar respuestas a solicitudes que provienen de emisores desconocidos.
Para todos los emisores desconocidos, el respondedor predeterminado responderá con la respuesta "DESCONOCIDO". Para las CA externas sin atajos de teclado OCSP dedicados, el respondedor predeterminado realizará búsquedas OCSP estándar. Tenga en cuenta que esto puede causar un comportamiento inesperado si existe un atajo de teclado inactivo (debido a la revocación o vencimiento del certificado del respondedor), y que este atajo de teclado tiene un comportamiento diferente al del respondedor predeterminado con respecto a los certificados desconocidos.
Si no se define ningún respondedor predeterminado, se define incorrectamente o el respondedor elegido no tiene un certificado, el respondedor responderá "No autorizado" (según RFC2560) con una carga útil nula.
Habilitación de la extensión NONCE en las respuestas OCSP de las CA
La extensión OCSP NONCE (según se define en RFC6960 4.4.1 ) permite mitigar los ataques de repetición mediante la inclusión de un nonce enviado con la solicitud OCSP como parte de la respuesta firmada. La extensión NONCE puede habilitarse individualmente para los respondedores OCSP o configurarse globalmente para las CA que actúan como sus propios respondedores.
Tipo de ID de respondedor para CA
Según lo definido en RFC6960 4.2.1 , el tipo de ID del respondedor puede configurarse como hash de clave o nombre. Para los respondedores OCSP individuales, esto se configura por respondedor, pero para las CA que actúan como su propio respondedor, esto se elige globalmente.
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 necesita 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".
Propiedades del respondedor OCSP
En esta sección se describen las propiedades establecidas para cada respondedor.
Propiedades generales
Propiedad | Descripción |
Identificación | Número de identificación único. |
Nombre | Un nombre único y legible para humanos. |
Token criptográfico | El token criptográfico donde hacemos referencia a un par de claves. |
Alias del par de claves | Una referencia al par de claves utilizado actualmente en el token criptográfico especificado. |
Algoritmo de firma | El algoritmo de firma del usuario durante la firma, por ejemplo, la firma de una respuesta OCSP. |
Alias del siguiente par de claves | Una referencia al próximo par de claves a utilizar en el token criptográfico especificado al renovar. |
Firmantes de la solicitud
Cada respondedor OCSP puede configurarse para que requiera la firma de las solicitudes. Si se habilita (configurando "La solicitud debe firmarse con un certificado de confianza" más abajo), el respondedor OCSP aceptará solicitudes firmadas con un par de claves certificado por cualquier CA conocida.
Esto se puede restringir aún más a CA individuales o a certificados individuales emitidos por esas CA.
Tenga en cuenta que la solicitud debe estar firmada con un certificado confiable y debe estar marcada para que esta configuración tenga efecto.
Delegación de respuesta de OCSP
Si bien no es un caso de uso común, un respondedor OCSP también se puede configurar para responder solicitudes de certificados emitidos por otras CA.
Al seleccionar CA de la lista y hacer clic en Agregar , el respondedor responderá a las solicitudes OCSP dirigidas a esas CA.
Propiedades específicas de OCSP
Propiedad | Descripción |
No existir es bueno | Si es verdadero, un certificado que no existe en la base de datos, pero que es emitido por una CA conocida por la VA, se considerará no revocado. El valor predeterminado (cuando tanto este valor como el de "Non existing is revocado" son falsos) lo considera "desconocido". Dado que la base de datos de respondedores de OCSP normalmente contiene todos los certificados emitidos, esto proporciona valores razonables (de acuerdo con RFC6960) para los certificados "ok", "revocados" y "desconocidos". Establecer este valor en verdadero es útil si desea que una base de datos de respondedores de OCSP externos solo contenga los certificados revocados, y no todos los certificados. En este caso, el respondedor responderá "ok" a las solicitudes de certificados que no existen en la base de datos. |
Lo no existente se revoca | Si es verdadero un certificado que no existe en la base de datos, pero es emitido por una CA conocida por la VA, se tratará como revocado; el motivo de la revocación será "Retención del certificado" y la fecha de revocación será el 1 de enero de 1970. El valor predeterminado (cuando este valor y el valor de "No existente es válido" son falsos) es tratarlo como "desconocido". |
No existente no está autorizado | Si se establece como verdadero un certificado que no existe en la base de datos, pero que es emitido por una CA conocida por el VA, este responderá con un mensaje "No autorizado" sin firmar para indicar que no puede procesar la solicitud. La ventaja de esta configuración es que no requiere que el VA realice una firma, lo que mitiga el riesgo de ataques de denegación de servicio (DoS) al saturarlo con solicitudes OCSP para números de serie desconocidos. |
Encabezado HTTP Max-Age (segundos) | Una sugerencia para los proxies de caché al usar HTTP GET sobre el tiempo que deben conservar una respuesta. Debe establecerse en un valor menor o igual a la validez de la respuesta. Un valor de 0 significa que no se almacena en caché. |
La solicitud debe estar firmada con un certificado de confianza. | Cuando sea verdadero, las firmas de la solicitud se comprobarán con la lista de certificados confiables o anclajes de confianza. |
Validez de la respuesta (segundos) | Cuánto tiempo es válida y se puede utilizar la respuesta OCSP. Un valor de 0 significa que siempre hay una respuesta más reciente disponible. |
ID de respuesta | Define el tipo de ResponderID incluido en la respuesta. ResponderID puede ser un nombre (DN del sujeto 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). |
Incluir certificado de firma en la respuesta | Cuando sea verdadero, el certificado de firma se incluirá en la respuesta. |
Incluir cadena de certificados en la respuesta | Cuando es verdadero, toda la cadena de certificados, excepto el certificado de CA raíz, se incluirá en la respuesta (tenga en cuenta que esto solo es aplicable si "Incluir certificado de firma en la respuesta" es verdadero). |
Habilitar nonce en respuesta | Si es verdadero, si la solicitud OCSP contiene un nonce, la respuesta también lo contendrá. Si es falso, nunca habrá un nonce en la respuesta, incluso si se incluye uno en la solicitud. |
Omitir el código de motivo si no se especifica el motivo de la revocación (cumplimiento de CABF) | Habilitado de forma predeterminada. Los requisitos básicos del foro CA/B 1.7.1 y posteriores exigen que se omita el código de motivo cuando es "Unspecified" . Deshabilite esta propiedad para ignorar este requisito. |
Extensiones
Las extensiones OCSP se eligen individualmente por cada respondedor como se indica a continuación.
Las extensiones que no requieren ninguna entrada de solicitud (como CertHash) siempre se devuelven si están habilitadas, ya sea que se especifiquen en la solicitud o no.
mientras tanto
Nonce es la única extensión estándar definida y no se configura aquí, sino en las propiedades generales mencionadas anteriormente. El nonce permite al cliente verificar que una respuesta realmente responde a solicitudes específicas y no a una respuesta reproducida. Se recomienda que, si las solicitudes OCSP contienen la extensión nonce, la respuesta OCSP también la contenga. EJBCA incluye el nonce de las solicitudes del cliente en la respuesta del servidor si estas contienen un nonce. La extensión nonce OCSP se puede deshabilitar tanto por cada atajo de teclado OCSP como globalmente para todas las CA que actúen como sus propios respondedores OCSP. Deshabilitar los nonces globalmente no afectará si los atajos de teclado OCSP usan la extensión nonce en sus respuestas.
Extensión de mapeo Fnr-Unid
Para obtener información sobre la funcionalidad de Unid, consulte Unid FNR .
Extensión OCSP de CertHash
Para obtener información sobre la funcionalidad de CertHash, consulte CertificateHash .
Extensión de corte de archivo
La extensión de corte de archivo se define en la sección 4.4.4 del RFC 6960 y se utiliza para "contribuir a una prueba de que una firma digital era (o no) confiable en la fecha en que se produjo, incluso si el certificado necesario para validar la firma ha expirado hace mucho tiempo".
<p >La marca de tiempo en la extensión de corte de archivo se puede derivar del momento en que se produjo la respuesta de OCSP (como se describe en RFC6960) o de la fecha notBefore en el certificado CA del emisor (como lo exige ETSI EN 319 411-2, CSS-6.3.10-08).La extensión de corte de archivo se configuraba previamente en el archivo de propiedades EJBCA ocsp.properties mediante la propiedad ocsp.expiredcert.retentionperiod . A partir de EJBCA 7.3, la extensión de corte de archivo se configura en la interfaz de usuario mediante una asignación de teclas OCSP.
La extensión de corte de archivo solo está presente en las respuestas OCSP cuando se configura una asignación de teclas OCSP para la CA. Para obtener más información e instrucciones de configuración, consulte Corte de archivo .
Auditoría y registro de transacciones de OCSP
El respondedor OCSP normalmente no registra nada por razones de rendimiento. Sin embargo, es posible habilitar el registro según sus necesidades configurando el registro de auditoría y el registro de transacciones de OCSP.
Al habilitar esta función se habilita el registro de auditoría y/o transacciones para todas las combinaciones de teclas de OCSP.
El registro de auditoría se registrará en el nivel DEBUG desde la clase org.cesecore.certificates.ocsp.logging.AuditLogger .
El registro de transacciones se registrará en el nivel DEBUG desde la clase org.cesecore.certificates.ocsp.logging.TransactionLogger .
Ejemplo de mensajes de registro
Los mensajes de registro se escriben en el nivel DEBUG, tanto para el registro de transacciones como para el de auditoría de OCSP. Los mensajes de registro de transacciones de OCSP se registran mediante org.cesecore.certificates.ocsp.logging.TransactionLogger , mientras que los mensajes de registro de auditoría de OCSP se registran mediante org.cesecore.certificates.ocsp.logging.AuditLogger .
Los mensajes de registro se verán como los siguientes, utilizando la configuración predeterminada en standalone.xml :
- 10 05 - 2021 16 : 57 : 58 DEBUG [org.cesecore.certificates.ocsp.logging.AuditLogger] ( task- default , 1 ) < 093 ) <log message goes here>- 10 05 - 2021 17 : 40 : 42 DEBUG [org.cesecore.certificates.ocsp.logging.TransactionLogger] ( task- default , 1 ) < 323 ) <log message goes here>Usando la configuración predeterminada para el registro de transacciones en la interfaz de usuario.
${SESSION_ID};${LOG_ID};${STATUS};${REQ_NAME}"${CLIENT_IP}";"${SIGN_ISSUER_NAME_DN}";"${SIGN_SUBJECT_NAME}";${SIGN_SERIAL_NO};"${LOG_TIME}";${REPLY_TIME};${NUM_CERT_ID};0;0;0;0;0;0;0;"${ISSUER_NAME_DN}";${ISSUER_NAME_HASH};${ISSUER_KEY};${DIGEST_ALGOR};${SERIAL_NOHEX};${CERT_STATUS};${CERT_PROFILE_ID};${FORWARDED_FOR}Se registra una entrada de registro como la siguiente.
08:14:36,789 DEBUG [org.cesecore.certificates.ocsp.logging.TransactionLogger] (default task-2) 7f4c11397f000101489d61ffc1cf1ccc;5;0;0"127.0.0.1";"0";"0";0;"2021-05-31 06:14:36.782+0000";7;1;0;0;0;0;0;0;0;"CN=Management CA,O=PK-DM,C=AE";27cbed5e54a990ccd30f644e3715c75b1decfdee;bb689f7058d62ab4b8c13866fac3cf8fc1986ada;1.3.14.3.2.26;21d26108348624ad3df3ef1171c3ca84a5c337fe;1;0;Usando la configuración predeterminada para el registro de auditoría en la interfaz de usuario.
SESSION_ID:${SESSION_ID};LOG ID:${LOG_ID};"${LOG_TIME}";TIME TO PROCESS:${REPLY_TIME};\nOCSP REQUEST:\n"${OCSPREQUEST}";\nOCSP RESPONSE:\n"${OCSPRESPONSE}";\nSTATUS:${STATUS}Se registra una entrada de registro como la siguiente (codificación hexadecimal completa de la solicitud y respuesta cortada para facilitar la lectura).
08:19:48,014 DEBUG [org.cesecore.certificates.ocsp.logging.AuditLogger] (default task-2) SESSION_ID:7f4c11397f000101489d61ffc1cf1ccc;LOG ID:5;"2021-05-31 06:14:36.782+0000";TIME TO PROCESS:5;\nOCSP REQUEST:\n"307a30...e068b5";\nOCSP RESPONSE:\n"308205...2cd2f1";\nSTATUS:0 Variables
Los mensajes de registro escritos en el registro de transacciones de OCSP y en el registro de auditoría de OCSP se pueden personalizar mediante variables.
Los valores válidos para el registro de auditoría son:
Valor del registro de auditoría | Descripción |
${ID_DE_REGISTRO} | Un número entero que comienza en 1 y se incrementa con cada solicitud recibida. |
${ID_DE_SESIÓN} | Una cadena aleatoria de 32 bytes de longitud generada cuando se inicia el respondedor OCSP. |
${OCSPREQUEST} | La solicitud OCSP byte[] (codificada en hexadecimal) que vino con la solicitud HTTP. |
${OCSPRESPONSE} | La respuesta OCSP byte[] (codificada en hexadecimal) que se incluyó en la respuesta HTTP. |
Las variables válidas para el registro de transacciones son:
Variable | Explicación |
${ID_DE_REGISTRO} | Un número entero que comienza en 1 y se incrementa con cada solicitud recibida. |
${ID_DE_SESIÓN} | Una cadena aleatoria de 32 bytes de longitud generada cuando se inicia el respondedor OCSP. |
La dirección IP del cliente que realiza la solicitud. | |
${ESTADO} | Estado de la solicitud OCSP. Los valores posibles son:
|
${TIEMPO_DE_PROCESO} | Registra el tiempo total que tarda en procesarse una solicitud, excluyendo el tiempo que lleva leerla. |
${NOMBRE_DE_REQUISITOS} | Nombre distinguido del sujeto normalizado de Bouncy Castle del cliente que realiza la solicitud. |
${REQ_NAME_RAW} | Nombre distinguido del sujeto no normalizado del cliente que realiza la solicitud. |
${NOMBRE_DEL_EMISOR_DE_SIGNO_DN} | El nombre distinguido del emisor normalizado de Bouncy Castle del certificado utilizado para firmar la solicitud. |
${NOMBRE_SUJETO_DE_SIGNO} | Nombre distinguido del sujeto normalizado de Bouncy Castle del certificado utilizado para firmar la solicitud. |
${NÚMERO DE SERIE DE SEÑAL} | El número de serie del certificado utilizado para firmar la solicitud. |
${NUM_CERT_ID} | La cantidad de certificados cuyo estado de revocación se desea comprobar. |
${NOMBRE_DEL_EMISOR_DN} | El nombre distinguido del emisor normalizado de Bouncy Castle del certificado solicitado. |
${NOMBRE_DEL_EMISOR_DN_RAW} | El nombre distinguido del emisor no normalizado del certificado solicitado. |
${HASH DEL NOMBRE DEL EMISOR} | El hash del nombre distinguido del sujeto del emisor. |
${CLAVE_EMISOR} | La clave pública del emisor del certificado solicitado. |
${ALGOR_DIGESTIÓN} | El algoritmo hash utilizado para generar hash de la clave del emisor y del nombre del emisor. |
${SERIAL_NOHEX} | El número de serie del certificado solicitado. |
${ESTADO_CERTIFICADO} | El estado de revocación del certificado solicitado, según se define en RFC 6960. Por ejemplo:
|
${ID_DE_PERFIL_DE_CERTIFICADO} | El número de identificación del perfil de certificado utilizado para emitir el certificado solicitado. |
${REENVIADO PARA} | El valor del encabezado HTTP X-Forwarded-For. |
${MOTIVO DE REVISIÓN} | El motivo de revocación del certificado solicitado, según se especifica en la sección 5.3.1 de la RFC 5280, o -1 si no se revocó. Se establece en 6 (certificateHold) cuando se desconoce el certificado, incluso si el estado devuelto es correcto. |
Tenga en cuenta que ${LOG_ID} es el mismo en el registro de auditoría de OCSP y en el registro de transacciones de OCSP para cualquier solicitud. Esto significa que pueden compararse. Puede recuperar información del registro de transacciones y verificar su validez mediante el registro de auditoría.
Configuración de archivos de salida para el registro de OCSP
Para JBoss y WildFly, puede configurar el registro en JBOSS_HOME/standalone/configuration/standalone.xml para guardar los registros de transacciones y auditoría en archivos separados. Un ejemplo es:
< name -rotating-file-handler periodic = "OCSPTRANSACTION" autoflush = "true" >< formatter >< pattern -formatter pattern = "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n" /></ formatter >< file relative-to = "jboss.server.log.dir" path = "transactions.log" />< suffix value = ".yyyy-MM-dd" />< append value = "true" /></ -rotating-file-handler> periodic >< name -rotating-file-handler periodic = "OCSPAUDIT" autoflush = "true" >< formatter >< pattern -formatter pattern = "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n" /></ formatter >< file relative-to = "jboss.server.log.dir" path = "audit.log" />< suffix value = ".yyyy-MM-dd" />< append value = "true" /></ -rotating-file-handler> periodic >< logger category = "org.cesecore.certificates.ocsp.logging.TransactionLogger" use-parent-handlers = "false" >< level name = "DEBUG" />< handlers >< handler name = "OCSPTRANSACTION" /></ handlers ></ logger >< logger category = "org.cesecore.certificates.ocsp.logging.AuditLogger" use-parent-handlers = "false" >< level name = "DEBUG" />< handlers >< handler name = "OCSPAUDIT" /></ handlers ></ logger >