OCSP

A continuación se describen los conceptos generales del respondedor OCSP de EJBCA. Para obtener instrucciones sobre cómo configurarlo, consulte Administración del respondedor OCSP y Respondedores OCSP .

Introducción

Los clientes de PKI utilizan OCSP (Protocolo de Estado de Certificados en Línea) para verificar la validez de los certificados en tiempo real. Esto se realiza enviando una solicitud de estado de un certificado específico a un respondedor de OCSP. Este respondedor puede ser o no el mismo que la CA. El respondedor de OCSP envía al cliente una respuesta firmada con la información de estado solicitada. El cliente utiliza esta información de estado para determinar si el certificado es válido o está revocado. OCSP se define en dos RFC:

  • RFC 6960 : la especificación base de OCSP y cómo se envían los mensajes OCSP mediante HTTP POST

  • RFC 5019 : perfiles OCSP livianos, cómo se envían los mensajes mediante HTTP GET y encabezados de caché que permiten que las respuestas OCSP se almacenen en cachés web y CDN

El servlet OCSP recibe la solicitud OCSP a través de http(s) y envía una respuesta de estado firmada por la CA.

El servicio OCSP recibe solicitudes en http://localhost:8080/ejbca/publicweb/status/ocsp. Si se desea una URL corta sin la ruta http://hostname.tld/ para un respondedor OCSP, se puede reescribir la URL, por ejemplo, en un servidor web frontend (caché) o un balanceador de carga. Consulte la documentación de integración de EJBCA para ver algunos ejemplos.

Mientras el servicio OCSP no se haya desactivado, este puede procesar solicitudes de certificados firmados por una CA que se ejecute en EJBCA o una CA externa. Las combinaciones de teclas de OCSP están configuradas para procesar solicitudes de OCSP para las CA deseadas. Para que una CA sea válida como respondedor de OCSP, debe tener el uso de clave "Firma digital" en el perfil de certificado utilizado para crearla. Este uso de clave debe incluirse si la CA va a firmar respuestas de OCSP. Los perfiles de certificado predeterminados para las CA incluyen el uso de clave "Firma digital".

Para generar una solicitud OCSP usando OpenSSL (funciona con respondedores OCSP internos y externos):

openssl ocsp -issuer Test-CA.pem -CAfile Test-CA-chain.pem -cert CertificateToCheck.pem -req_text -url http: //localhost :8080 /ejbca/publicweb/status/ocsp

Para emitir solicitudes GET para pruebas, se puede utilizar la siguiente metodología (reemplácela con sus propios datos):

openssl ocsp -noverify -no_nonce -respout ocsp.resp -reqout ocsp.req -issuer ManagementCA.cacert.pem -cert ejbca-test2.primekey.se -url "http://ejbca-test2.primekey.se:8080/ejbca/publicweb/status/ocsp" -header "HOST" "ejbca-test2.primekey.se" -text
openssl enc - in ocsp.req -out ocsp.req.b64 -a
curl --verbose --url http: //ejbca-test2 .primekey.se:8080 /ejbca/publicweb/status/ocsp/MEkwRzBFMEMwQTAJBgUrDgMCGgUABBT1x9iHOmegR7sYp5Fzdo/u3FMBRgQUH1DTnzl9lscAe3WBTUPCWR +xwpQCCDlpiyU2q5Rb

Si Firefox debe solicitar y aceptar respuestas OCSP de una CA que no está en el almacén de confianza predeterminado, debe configurarse para confiar en esta CA:

  1. En Avanzado > Certificados > Ver certificados > Autoridades , importe y seleccione el certificado de CA y marque las opciones de Confianza adecuadas.

  2. Si se selecciona Consultar servidores de respuesta de OCSP para confirmar la validez actual de los certificados en Avanzado > Certificados , y los certificados incluyen una URL de servicio OCSP (extensión AIA), Firefox consultará al servidor OCSP cuando, por ejemplo, se haga doble clic en un certificado en el administrador de certificados.

Una URL adecuada para la validación es: http://hostname:8080/ejbca/publicweb/status/ocsp y doc/samples contiene un ejemplo sobre cómo verificar la revocación con OCSP usando las nuevas API a partir de JDK 1.5.

URI del localizador de servicios OCSP

El software, como los navegadores web, suele determinar qué URL de OCSP usar al validar un certificado específico consultando la extensión AIA (Acceso a la Información de la Autoridad) del certificado que se va a validar. La extensión AIA puede contener una URI de Localizador de Servicios de OCSP, que apunta al respondedor de OCSP que puede responder con autoridad si el certificado se revoca o no (consulte RFC 6960 para obtener más información). La URI de Localizador de Servicios de OCSP se puede configurar en los Perfiles de Certificado para los certificados emitidos por EJBCA.

Certificados de CA revocados

Cuando la primera entrada en la cadena de certificados de CA que coincide con una solicitud OCSP se revoca con uno de los códigos de motivo "keyCompromise", "cACompromise", "aACompromise" o "unspecified", el estado del certificado solicitado se devolverá como revocado con el motivo "cACompromise". Esto se ajusta a la RFC 6960, sección 2.7.

Esto significa que puede bloquear instantáneamente el uso de certificados de hoja revocando el emisor de estos certificados utilizando, por ejemplo, el código de motivo "cACompromise", incluso si el certificado de CA todavía se considera válido según una CRL en el cliente.

Esto también aplica si revoca un certificado de CA con firma cruzada por alguno de estos motivos o importa dicha actualización de estado de revocación de CA a sus VA. Aun así, se recomienda revocar los certificados individuales para garantizar que aparezcan en las CRL de respaldo.

Certificados vencidos

EJBCA mantiene el estado de los certificados caducados en la base de datos, por lo que el respondedor también responderá a las consultas sobre certificados caducados, a menos que los elimine de la base de datos. En la base de datos interna de EJBCA, el estado de los certificados caducados se establece en ARCHIVADO en la base de datos (tabla CertificateData) mediante el trabajo de creación de CRL. El estado ARCHIVADO no afecta la respuesta enviada por el respondedor de OCSP.

El algoritmo es:

  • Si el estado es CERT_REVOKED, el certificado está revocado y se recogen el motivo y la fecha.

  • Si el estado es CERT_ARCHIVED y el motivo es NOT REMOVEFROMCRL o NOT_REVOKED, se revoca el certificado y se seleccionan el motivo y la fecha.

  • Si el estado es CERT_ARCHIVED y el motivo es REMOVEFROMCRL o NOT_REVOKED, el certificado NO se revoca.

  • Si el estado no es CERT_REVOKED ni CERT_ARCHIVED, el certificado NO está revocado.

La extensión de corte de archivo se utiliza según lo definido en la sección 4.4.4 del RFC 6960. Para obtener más información, consulte Corte de archivo .

Validez de la respuesta

El campo nextUpdate se puede incluir en las respuestas de OCSP (RFC6960) y se calcula en función de la configuración de validez de la respuesta para la vinculación de claves de OCSP .

Un valor de 0 significa que siempre hay una respuesta más nueva disponible y el campo nextUpdate no está incluido en las respuestas de OCSP.

Si se calcula que la siguiente actualización será posterior a las 99991231235959Z, se establecerá en 99991231235959Z (última respuesta OCSP, según ETSI EN 319 411-2 y -1 ). Esto se puede forzar configurando la validez de la respuesta en, por ejemplo, 315328464000 segundos (9999 años).

Configuración de un respondedor OCSP en un VA remoto

Puede configurar respondedores OCSP separados en EJBCA para aislar la CA de Internet y poder responder a las solicitudes OCSP. Además, puede configurar firewalls para que solo se permita el tráfico saliente desde la CA y no el tráfico hacia ella.

También se recomiendan los respondedores OCSP separados cuando no se requiere una agrupación en clústeres de alto rendimiento para la CA, pero sí se necesita un alto rendimiento para los respondedores OCSP. Esta es una configuración común: si la CA solo emite certificados una vez al año para un millón de usuarios, esto no supone una gran presión para la CA, pero los respondedores OCSP pueden estar sometidos a una alta carga de trabajo de forma continua.

Para obtener información sobre cómo configurar respondedores OCSP independientes y separados, consulte Administración de respondedores OCSP .

Múltiples respondedores y certificados de CA

El respondedor OCSP puede tener varios certificados de respondedor, cada uno emitido por una CA y asignado mediante un OcspKeyBinding. Esto significa que el respondedor puede responder solicitudes dirigidas a varias CA. No hay límite en el número de CA que se pueden gestionar.

Selección de certificado de firma OCSP a partir de una solicitud

En la solicitud OCSP según se define en RFC 6960, están disponibles el hash del DN del sujeto de la CA emisora y la clave pública:

CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, – Hash of issuer's DN
issuerKeyHash OCTET STRING, – Hash de key public issuerKeyHash OCTET STRING, – Hash of issuer's
serialNumber CertificateSerialNumber }

EJBCA selecciona OcspKeyBinding basándose en el DN del sujeto y la clave pública del certificado de la CA que emitió un certificado de firma OCSP. El certificado de la CA emisora se determina a partir de la cadena de certificados OCSP, y su construcción se describe a continuación.

Consideraciones clave para la renovación de CA

EJBCA considera dos certificados de CA X.509 como la misma CA si comparten el mismo DN de sujeto y como versiones diferentes de la misma CA si la clave pública es distinta. Dado que tanto el sujeto como el par de claves se utilizan en la solicitud, se necesitarán dos OcspKeyBindings (uno emitido antes de la renovación de la clave y otro después) para poder atender las solicitudes OCSP donde los clientes utilizan el certificado de CA tanto para el par de claves antiguo como para el nuevo.

Actualmente, EJBCA solo permite emitir un certificado de firma OCSP de la última versión de la CA. Por lo tanto, antes de renovar la clave de la CA, deberá emitir certificados de firma OCSP que duren toda la vigencia del certificado de la CA.

Construcción de la cadena de certificados

EJBCA construye la cadena para cada certificado de firma OCSP buscando el certificado de CA más reciente con un DN de sujeto igual al DN de emisor del certificado de firma OCSP. A menos que el certificado de CA encontrado sea autofirmado, el procedimiento se repite hasta que se construye la cadena completa.

Si la cadena generada no puede verificar el certificado de firma OCSP (debido a la renovación de la clave del certificado de la CA), se utiliza un algoritmo diferente: EJBCA utiliza el valor interno de CertificateData.cAFingerprint para determinar el certificado exacto que emitió el certificado de firma OCSP. De forma similar al caso en que generamos la cadena utilizando el DN del emisor del certificado de firma OCSP, el proceso se repite hasta generar una cadena completa que conduzca a una CA autofirmada.

Cadena de certificados de respuesta de OCSP

Por razones de eficiencia, es posible configurar EJBCA para que omita la inclusión del certificado de firma o su cadena de certificados en la respuesta OCSP. Configurar la configuración correspondiente en el archivo $EJBCA_HOME/conf/ocsp.properties o en la vinculación de claves interna de la interfaz gráfica de usuario tiene el siguiente efecto:

  • Si ocsp.includesignercert=true y ocsp.includecertchain=true , el certificado de firma y su cadena, excepto el certificado de la CA raíz, se incluirán en la respuesta de OCSP. Si el certificado de firma es el certificado de la CA raíz, este se incluirá igualmente en la respuesta.

  • Si ocsp.includesignercert=true y ocsp.includecertchain=false , solo se incluirá el certificado de firma en la respuesta de OCSP, incluso si fuera un certificado de CA raíz.

  • Si ocsp.includesignercert=false , ni el certificado de firma ni la cadena de certificados se incluirán en la respuesta de OCSP, independientemente del valor de ocsp.includecertchain.

Auditoría y registro de transacciones

Los siguientes tipos de registros que puede generar el respondedor OCSP:

  • Registro de servicio OCSP

  • Registro de transacciones de OCSP

  • Registro de auditoría de OCSP

Registro de servicio OCSP

El registro del servicio OCSP utiliza Log4j para registrar el registro del servidor WildFly/JBoss. Este registro se encuentra en APPSRV_HOME/standalone/configuration/log/server.log de forma predeterminada y se puede configurar mediante la CLI de JBoss.

Registro de transacciones de OCSP

El registro de transacciones de OCSP permite registrar diversa información sobre las solicitudes de OCSP. El registro de transacciones resume cada solicitud/respuesta de OCSP, lo que permite cobrar a los clientes si se ejecuta un servicio OCSP comercial.

<p >Para obtener instrucciones sobre cómo configurar el registro de transacciones de OCSP, consulte Administración de respondedores de OCSP .

Registro de auditoría de OCSP

No confunda el registro de auditoría de OCSP con el registro estándar. Las operaciones de OCSP no se registran en una instalación de PKI estándar, pero se puede escribir en el disco un registro de auditoría específico para el respondedor de OCSP.

El registro de auditoría de OCSP registra solicitudes y respuestas completas. Esto puede ser útil cuando las solicitudes y respuestas están firmadas, ya que la información puede utilizarse para verificarlas posteriormente.

El registro de auditoría se configura de la misma manera que el registro de transacciones; consulte Administración de respondedores de OCSP para obtener más información.

Uso de la API de OCSP

Para aprender la API, puede estudiar el código fuente incluido. La API de cliente se utiliza en la clase org.ejbca.core.protocol.ocsp.OCSPUnidClient . La Caja de Herramientas de Cliente EJBCA , en la clase org.ejbca.ui.cli.Ocsp , puede ser un buen ejemplo para usar la API.

Índices de bases de datos

A medida que su base de datos OCSP crece con certificados revocados y activos, necesitará índices de base de datos para mantener un buen rendimiento. Consulte el archivo doc/sql-scripts/create-index-ejbca.sql (sección de datos de certificados) para conocer los índices necesarios para las operaciones de CA y OCSP.

OBTENER OCSP

La solicitud GET OCSP se define en RFC 6960 (y RFC2560) A.1 como:

'GET {url}/{codificación de URL de la codificación base-64 de la codificación DER de OCSPRequest}' .

Una solicitud codificada en base64 puede contener los caracteres reservados '+', '/' y '=', pero el respondedor los manejará correctamente tanto en su forma original como en su forma escapada %, ya que no está claro si entran en conflicto según se define en RFC 2396 2.2.

No todos los productos web gestionan correctamente el carácter "/" codificado (%2F). Es necesario iniciar JBoss/Tomcat añadiendo -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true a JAVA_OPT en JBOSS_HOME/bin/run.conf.

Respuestas con mayor validez y almacenamiento en caché

RFC 6960 (y RFC 2560) define thisUpdate, nextUpdate y producedAt. producedAt siempre se incluye en la respuesta y marca la hora de creación. thisUpdate y nextUpdate se habilitan configurando "ocsp.untilNextUpdate" en ocsp.properties o en OcspKeyBinding. thisUpdate marcará la hora en que se inserta una singleResponse en la respuesta principal y nextUpdate marcará "untilNextUpdate" segundos después de thisUpdate. Esto permite a los clientes compatibles con esta función reutilizar una respuesta válida y reducir la carga en el respondedor OCSP.

La RFC 5019 define cómo usar los encabezados de caché HTTP, según lo definido en la RFC 2616, para las solicitudes HTTP GET de OCSP. Mediante los encabezados "Última modificación", "Expiración", "Antigüedad máxima" y "Fecha", los componentes de red menos inteligentes, como las cachés HTTP, pueden almacenar en caché las respuestas. Esto permite la reutilización de las respuestas para reducir la carga del respondedor de OCSP y acortar los tiempos de respuesta al implementar la caché más cerca de los consumidores de OCSP. Los encabezados de caché HTTP se habilitan configurando "ocsp.maxAge" en ocsp.properties o en OcspKeyBinding.

Al usar encabezados HTTP de estilo RFC 5019, los usuarios de JBoss deben tener en cuenta que el encabezado de fecha se sobrescribe con un valor almacenado en caché. Dado que generar la cadena de fecha requiere un alto consumo de recursos computacionales para solicitudes GET pequeñas y regulares, se genera aproximadamente una vez por segundo. Por lo tanto, una respuesta puede tener, en ocasiones, un valor de "Última modificación" un segundo después de la fecha real.

Se puede utilizar un servidor HTTP Apache normal para almacenar en caché solicitudes, equilibrar la carga y descartar algunas solicitudes no deseadas:

< VirtualHost *:80>
# Use as much memory as possible for the cache (in 1 kB blocks)
# 1GB of memory at ~2kB/ocsp request would hold about 500000 different requests
CacheEnable mem /
MCacheSize 1048576
MCacheMaxObjectCount 1000000
MCacheMinObjectSize 1
MCacheMaxObjectSize 4096
# Using disk-cache will allow a much larger pool of cached entires and the operation system
# will cache those files, but you are responsible for cleaning up old cache-entries using
# the "htcacheclean" tool. A disk cache will also live through a server restart.
# The user running apache has to have read/write access to "/var/cache/ocsp".
#CacheEnable disk /
#CacheRoot /var/cache/ocsp
# Ignore requests for uncached responses.. this will protect the OCSP from
# DOS attacks using "Cache-Control: no-cache" or "Pragma: no-cache"
CacheIgnoreCacheControl On
ProxyRequests Off
< Location >
# Everybody is welcome here..
Allow from all
Order allow,deny
# ..or just those from networks that is supposed to use the service
#Deny from all
#Order deny,allow
#allow from 127.
#allow from 172.16.212.1
Balanceador ProxyPassReverse balancer://mycluster-kerb/
</ Location >
# Proxy requests to OCSP instances (only one machine currently configured)
< Proxy balancer://mycluster-kerb >
# proxy_ajp has to be enabled for ajp-proxying
BalancerMember ajp://127.0.0.1:8009/ejbca/publicweb/status/ocsp
# proxy_http has to be enabled for http-proxying
#BalancerMember http://ocsp2.domain.org:8080/ejbca/publicweb/status/ocsp
#BalancerMember http://ocsp3.domain.org:8080/ejbca/publicweb/status/ocsp
</ Proxy >
# We only want RFC 5019 compliant URLs to be forwarded to the OCSP, the rest
# should get a "404 Not found" or "414 Request-URI Too Large."
LimitRequestLine 257
RewriteEngine On
RewriteCond %{REQUEST_METHOD} get [NC]
RewriteRule ^/([a-zA-Z0-9+=/]+)$ balancer://mycluster-kerb/ $1 [P,L]
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/log/apache2/access.log combined
ErrorLog /var/log/apache2/error.log
</ VirtualHost >

Respuestas OCSP preproducidas

EMPRESA Esta es una característica de EJBCA Enterprise.

De forma predeterminada, EJBCA genera y firma respuestas OCSP para cada solicitud. Las respuestas OCSP preproducidas permiten que las respuestas se preproduzcan y persistan antes de ser solicitadas. Esto permite un mayor rendimiento en los respondedores OCSP, ya que la firma de respuestas suele convertirse en un cuello de botella durante picos de carga. Atender una solicitud con una respuesta preproducida implica, naturalmente, que la respuesta no se genera de forma inmediata. Esto significa que el estado del certificado solicitado puede haber cambiado después de generarse la respuesta. Los campos producedAt y thisUpdate de la respuesta siempre mostrarán cuándo se firmó la respuesta y en qué momento el respondedor supo que el estado era correcto. Además, el campo nextUpdate muestra la hora, o antes de la cual, estará disponible información más reciente sobre el estado del certificado.

Se entregará una respuesta OCSP persistente hasta que transcurra la fecha de nextUpdate o hasta que el respondedor genere una respuesta más reciente. Consulte Respuestas con mayor validez y almacenamiento en caché para obtener instrucciones de configuración de nextUpdate . No se conserva ninguna respuesta si nextUpdate no está configurado. Las respuestas se pueden mantener actualizadas configurando el servicio de prefirmación de respuestas OCSP o activando la función " Almacenar respuestas a petición", que las conservará cuando se soliciten.

Además de reducir la carga de los respondedores, las respuestas OCSP producidas previamente también se pueden utilizar para emitir respuestas OCSP finales antes de que expire una CA de conformidad con la norma EN 319 411-2 .

Para obtener más información sobre cómo configurar respuestas OCSP preproducidas, consulte Preproducción de respuestas OCSP .

Alta disponibilidad (HA) de OCSP

Una configuración típica al usar respondedores OCSP externos utiliza dos o más nodos de respuesta OCSP. Para garantizar que el fallo de un nodo no afecte a los demás, cada nodo de respuesta OCSP puede mantener su propia base de datos. Al usar su propia base de datos, se garantiza una alta disponibilidad, ya que los nodos son completamente independientes y se realiza el mantenimiento en un nodo, incluida la base de datos, sin afectar el tiempo de actividad del servicio OCSP en su conjunto. De igual forma, cada nodo de respuesta OCSP puede usar su propio HSM.

Los nodos de respuesta de OCSP también pueden usar una base de datos HA común y un clúster HA de HSM si eso se adapta mejor a su organización.

Cada nodo respondedor de OCSP puede producir registros de transacciones y auditoría, consulte Registro de auditoría y cuentas .

Ejemplos de uso

Adobe Reader

Un buen ejemplo del uso de OCSP es comprobar documentos PDF firmados digitalmente utilizando Adobe Reader.

Para verificar certificados en Adobe Reader, primero debe agregar el certificado de CA como de confianza en Adobe Reader. Puede hacerlo en el menú Documento > Identidades de confianza . Seleccione Certificados en el menú de lista y haga clic en Agregar contactos para buscar el certificado de CA que ha descargado en formato DER (por ejemplo, seleccionando Descargar a IE en las páginas públicas de EJBCA). El certificado de CA debe haberse guardado con un nombre que termine en .cer . Después de agregar el nuevo contacto, haga clic en Editar confianza y marque al menos Firmas, como raíz de confianza y Documentos certificados . Esto aplica tanto a respondedores OCSP internos como externos.

Los certificados con un localizador de servicio OCSP se verificarán con el respondedor OCSP. Puede configurar esto en el perfil de certificado utilizado para emitir certificados.

Si firma documentos PDF con respuestas OCSP integradas, estas respuestas deben incluir un campo nextUpdate y la marca de tiempo debe estar dentro del período thisUpdate y nextUpdate de la respuesta OCSP.

Extensiones de respuesta de OCSP

Las extensiones OCSP (excepto la extensión nonce ) se configuran en la sección que se muestra a continuación al editar una combinación de teclas OCSP.

imágenes/descargar/archivos adjuntos/143744129/ocsp_extension.png

Las extensiones OCSP que no requieren datos de la solicitud (como lo hace la extensión nonce ) se devolverán automáticamente si se especifican en la combinación de teclas, independientemente de que se hayan especificado o no en la solicitud del cliente.

Para obtener información sobre las extensiones de respuesta de OCSP, consulte las siguientes secciones: