Validadores de campos de certificado
Los validadores de campos de certificado se ejecutan en campos específicos del CSR, como el campo SAN dnsName.
Validador de navegación segura de Google
El Validador de Navegación Segura de Google realiza una búsqueda de los dominios del certificado con la API de Búsqueda de Navegación Segura de Google v4 . Esta API incluye sitios web utilizados para la distribución de malware y phishing.
La API de navegación segura de Google solo debe utilizarse para fines no comerciales.
Antes de que el validador pueda realizar búsquedas en la API, debe crear una clave API mediante Google Developer Console; consulte https://console.developers.google.com/ .
Validador CAA
EMPRESA Esta es una característica de EJBCA Enterprise.
El validador de la Autorización de Autoridad de Certificación (CAA) se basa en la RFC 6844 , la fe de erratas 5065 y la Política de Certificados de Requisitos Base del CA/Browser Forum para la Emisión y Gestión de Certificados de Confianza Pública . Estos requisitos especifican que, para las CA que cumplen los requisitos y emiten certificados que contienen valores DNSName en la extensión subjectAltName, la CA debe realizar una comprobación de búsqueda en los DNS de todos los nombres especificados y comprobar que los registros de la CAA permiten la emisión para el emisor en cuestión.
El resultado de todas las búsquedas de CAA se escribe en los registros del servidor en el nivel INFO.
Un registro CAA típico tiene el siguiente formato:
example.com. 243 IN CAA 0 issue "ca.org"Este registro indica que el emisor "ca.org" puede emitir certificados (incluidos comodines) para todos los dominios y subdominios del dominio "example.com". En el caso de EJBCA, esto significa que, según la CAA, una entidad final que incluya el campo DNSNAME=example.com en la extensión subjectAltName (SAN) debe pasar una comprobación del validador de la CAA antes de que se le emita un certificado.
Fase de emisión
El Validador CAA solo se puede ejecutar durante la fase de datos.
Campos
EJBCA permite al administrador configurar lo siguiente al configurar un Validador CAA:
Nombre del campo | Descripción | ||||||||
Emisores | Este valor debe coincidir con el campo de valor del registro CAA del DNS; por lo tanto, "ca.org" en el ejemplo anterior. Si es necesario, puede especificar varios emisores separándolos con punto y coma. Por ejemplo, si especifica "ca1.org;ca2.org;ca3.org", el registro CAA coincidirá con ca1.org, ca2.org o ca3.org. | ||||||||
Resolución de DNS | Campo opcional para especificar una dirección IP como solucionador DNS (como 8.8.8.8 o 8.8.4.4). Si se deja en blanco, se utilizará el DNS público de Google. | ||||||||
Búsqueda de DNAME | Seleccione esta opción para buscar y seguir los registros DNAME encontrados durante el procesamiento de CAA. Para cumplir con la RFC 6844, se recomienda mantener esta opción habilitada. | ||||||||
Validar DNSSEC | Seleccione esta opción para validar DNSSEC. Si está habilitada y su DNS está firmado con DNSSEC y presenta un conjunto de registros erróneos (lo que sugiere un posible ataque MitM), la validación de CAA fallará. Se recomienda encarecidamente habilitar las comprobaciones de DNSSEC para garantizar la autenticidad de las respuestas DNS. | ||||||||
Ancla de confianza | Los anclajes de confianza se configuran para permitir la obtención de respuestas seguras desde la zona raíz del DNS mediante DNSSEC. De forma predeterminada, se utiliza el anclaje raíz de IANA. Este valor puede modificarse, pero debe permanecer inalterado a menos que el registro esté firmado por otro anclaje de confianza. | ||||||||
Error en la búsqueda | El comportamiento predeterminado es permitir la emisión si se detecta un error de búsqueda repetidamente y EJBCA puede determinar que el dominio no está firmado con DNSSEC. Para prohibir siempre la emisión cuando se detecta un error de búsqueda, habilite esta opción. Tener esta opción habilitada puede ser un requisito de cumplimiento si se comunica con su propio solucionador de DNS para búsquedas de CAA. | ||||||||
Ignorar dominios de nivel superior | Los registros CAA rara vez se asignan a nivel de TLD, y buscarlos puede llevar milisegundos. Con esta configuración, puede especificar una lista separada por nuevas líneas de dominios de nivel superior para los que no se realizarán búsquedas CAA. Por ejemplo: Las búsquedas de CAA se seguirán realizando en subdominios como de costumbre, por ejemplo , foo.com y foo.bar.se. | ||||||||
Ignorar nombres de dominio | Nombres de dominio que se excluirán de la validación de CAA. Se admiten comodines. Por ejemplo: | ||||||||
Ignorar etiquetas de propiedades críticas | Etiquetas críticas que se deben ignorar durante la búsqueda de CAA. Esto permite que la búsqueda de CAA continúe incluso si se encuentran etiquetas críticas desconocidas para EJBCA. Por ejemplo: correo electrónico de contacto ¡Úselo con precaución! Por defecto, las etiquetas críticas desconocidas resultan en la prohibición de emisión. Ignorar las etiquetas críticas no cumple con la norma RFC6844. | ||||||||
Utilice el correo electrónico de IODEF | Seleccione esta opción para habilitar el envío de correos electrónicos a cualquier enlace de correo registrado en el DNS como registros IODEF de CAA. Al hacerlo, se habilitarán las siguientes configuraciones adicionales:
|
Tenga en cuenta lo siguiente con respecto a la validación de CAA:
La validación de CAA se aprobará si el DNS carece por completo de registros CAA.
EJBCA utiliza IPv4 para realizar búsquedas de registros CAA.
EJBCA actualmente no valida parámetros en los registros CAA, pero estos se evaluarán correctamente. El manejo de parámetros está previsto en futuras versiones.
El validador CAA requiere que el puerto TCP y UDP 53 esté abierto en el firewall.
La implementación actual de iodef no admite el protocolo TLS para enviar informes de iodef mediante una conexión segura. Esto se añadirá a petición de los clientes o en futuras versiones.
Otra limitación es que la implementación no admite la devolución de llamada; solo se admiten respuestas inmediatas con el código 200 OK. Para más información, consulte RFC-6546 .
Los atributos del informe de incidentes generado son los mínimos requeridos. Los opcionales se ignoran por ahora, pero se pueden agregar si se solicita.
Actualmente, EJBCA no admite la propiedad de contacto CAA tal como se define en la sección 1.6.1 de los Requisitos de referencia.
Registro del validador de CAA
El validador CAA registra tanto los éxitos como los fallos. Dado que el éxito puede considerarse un evento de seguridad y debe mostrarse como prueba, se registra en el registro de auditoría de seguridad. Los fallos no son eventos de seguridad per se y se registran en el registro estándar del servidor a nivel de información.
Ejemplo de fallo:
15:49:07,017 INFO [org.cesecore.keys.validation.KeyValidatorSessionBean] (default task-24) VALIDATOR_VALIDATION_FAILED;FAILURE;VALIDATOR;CORE;msg=CAA Validator 'CAA Validator' failed issuance of certificates to issuer primekey.com, with messages: [Not allowed to issue certificate for dnsName *.allow.klaan.nu. Result type was: Issuance of wildcard certificates for this domain is prohibited. Parameters: {} Message: , Allowed to issue certificate for dnsName *.klaan.nu. Result type was: May issue, no CAA results for domain. Parameters: {} Message: , Not allowed to issue certificate for dnsName allow.klaan.nu. Result type was: Rejected due to issuer not having a CAA record at domain's DNS, or issuance being prohibited. Parameters: {} Message: ].Ejemplo de éxito:
15:50:58,930 INFO [org.cesecore.audit.impl.log4j.Log4jDevice] (default task-8) 2017-09-20 15:50:58+02:00;VALIDATOR_VALIDATION_SUCCESS;SUCCESS;VALIDATOR;CORE;ejbca;1865017768;;caaklaan1;msg=CAA Validator 'CAA Validator' has permitted issuance of certificates to issuer primekey.com, with messages: [Allowed to issue certificate for dnsName *.klaan.nu. Result type was: May issue, no CAA results for domain. Parameters: {} Message: , Allowed to issue certificate for dnsName a.allow.klaan.nu. Result type was: May issue. Parameters: {} Message: primekey.com , Allowed to issue certificate for dnsName b.allow.klaan.nu. Result type was: May issue. Parameters: {} Message: primekey.com].El resultado de la búsqueda DNS del registro de depuración disponible puede alcanzar grandes volúmenes y, por lo tanto, está deshabilitado de forma predeterminada. Para habilitar un registro de búsqueda DNS independiente, puede enviar el registro DEBUG de la clase CaaDnsLookup a un registro independiente, similar al registro de transacciones y auditoría de OCSP. Para obtener más información, consulte Registro .
Validador de lista de bloqueo de dominios
Los validadores de listas de bloqueo de dominios permiten verificar los atributos DNSNAME en el nombre alternativo del sujeto antes de su emisión.
El caso de uso previsto es requerir confirmación durante el proceso de aprobación para ciertos dominios de alto valor (siempre que las aprobaciones estén habilitadas), pero los validadores de listas de bloqueo de dominios también se pueden usar para bloquear sitios fraudulentos conocidos, por ejemplo.
Puede configurar varios validadores con diferentes ajustes. El siguiente ejemplo muestra un validador configurado para permitir la validación y advertir al administrador durante el proceso de aprobación.
Fase de emisión
El Validador de Listas de Bloqueo de Dominios puede ejecutarse durante la fase de datos o de aprobación. Si se configura para ejecutarse durante la fase de aprobación y la validación falla, se mostrará un mensaje de confirmación en la Web de RA para los administradores que aprueban.
Si el validador se ha configurado para ejecutarse durante la fase de aprobación y no existen requisitos de aprobación para la CA o el perfil de certificado, no tendrá ningún efecto.
Campos
Las siguientes listas son campos del Validador de lista de bloqueo de dominio disponibles:
Nombre del campo | Descripción | ||||||||||||||||||||||||||||||||||||||||||
Normalizaciones a aplicar | La normalización que se realizará con los dominios antes de compararlos con la lista de bloqueos. Actualmente solo hay una normalización disponible: Similares ASCII: Normaliza caracteres o secuencias de caracteres que parecen similares. Los caracteres IDN/Punicode de los dominios no se modifican. Se normalizan los siguientes caracteres y secuencias de caracteres:
| ||||||||||||||||||||||||||||||||||||||||||
Comprobaciones a realizar | Las comprobaciones controlan cómo se comparan los dominios con las entradas de la lista de bloqueos. Debe seleccionarse al menos uno. Dominio base: Todos los dominios base se compararán con la lista de bloqueos. Si se emite un certificado para "abexample.com", se compararán "abexample.com", "b.example.com", "example.com" y "com" con la lista de bloqueos. Componente de dominio: Se comprobarán todos los componentes del dominio individualmente. Por ejemplo, para "abexample.com", se buscarán en la lista de bloqueo "a", "b", "example" y "com". Coincidencia exacta: Se buscarán los dominios que coincidan exactamente. Tenga en cuenta que esta comprobación está incluida en "Dominio base". Para "abexample.com", solo se buscará "abexample.com" en la lista de bloqueo. | ||||||||||||||||||||||||||||||||||||||||||
Lista de bloqueos existentes | Muestra información sobre la lista de bloqueos actualmente activa y solo se muestra una vez que se ha cargado una lista de bloqueos. Número de entradas: Número de dominios en la lista de bloqueos. El número efectivo de dominios bloqueados puede ser mayor debido a la normalización y las comprobaciones realizadas. Fecha de subida: Hora en que se subió la lista de bloqueos. Se muestra en la zona horaria UTC. SHA-256: Hash del archivo completo, tal como se cargó (es decir, incluidos comentarios y espacios en blanco). | ||||||||||||||||||||||||||||||||||||||||||
Subir nueva lista de bloqueos | Haz clic en "Explorar" para subir una lista de bloqueos. Cualquier lista de bloqueos existente se reemplazará al subir una nueva. Para obtener información sobre la sintaxis, consulte Sintaxis del archivo de lista de bloqueo . Según su configuración, puede haber un límite de tamaño de archivo. Con un límite de 1 MB, podrá incluir alrededor de 50 000 dominios en su lista de bloqueo. Para evitar este límite, puede dividir la lista de bloqueo y usar varios validadores. |
Sintaxis del archivo de lista de bloqueos
Los archivos de texto de lista de bloqueo contienen un dominio de lista de bloqueo por línea:
Los dominios IDN deben estar codificados en Punycode
Las líneas vacías se ignoran
Se ignoran los espacios iniciales y finales
El texto después de un # se considera un comentario y se ignora.
Los comentarios pueden contener texto ASCII o UTF-8, pero el archivo puede no contener una marca de orden de bytes (BOM). En caso de duda, guarde el archivo en formato ASCII simple.
A continuación se muestra un ejemplo de un archivo de texto de lista de bloqueos:
# Sample block list file. Created 2019-03-01bank # If domain component blocking is enabled, then this will block "bank.com", "bank.example.com" but NOT "memorybank.com"example.com # With base domain blocking one can block a domain including subdomains.net # ...or entire TLDs (Top Level Domains)evil.example.edu # It is possible to block a specific subdomain onlyxn--rvare-jua.example.com # This is an IDN domain "rövare.example.com" Validador de lista de dominios permitidos
Los validadores de listas de dominios permitidos permiten verificar los atributos DNSNAME en el nombre alternativo del sujeto antes de la emisión.
El caso de uso previsto es simplificar el proceso de validación para algunos dominios seleccionados. El validador admite el uso de comodines (*) para facilitar la configuración.
Campos
La configuración del validador de listas de dominios permitidos contiene un campo que acepta un archivo de configuración con nombres de dominio permitidos. La sintaxis del archivo se describe a continuación. Haga clic en "Explorar" para cargar una lista de dominios permitidos. Cualquier lista existente se reemplazará al cargar una nueva.
La lista de dominios permitidos sigue reglas similares a las del Validador de lista de bloqueo:
Los dominios IDN deben estar codificados en Punycode con la excepción del carácter asterisco (*) para indicar comodines.
Las líneas vacías se ignoran.
Se ignoran los espacios iniciales y finales.
El texto después de un # se considera un comentario y se ignora.
Los comentarios pueden contener texto ASCII o UTF-8, pero el archivo puede no contener una marca de orden de bytes (BOM). En caso de duda, guarde el archivo en formato ASCII simple.
A continuación se muestra un ejemplo de un archivo de texto de lista de permitidos:
permit.compermit.example.com#good.example.compermit2.example.com # this is a commentpermit3.example.compermit4.example.com # commentpermit5.*.example.com # allows: 'permit5.abc.example.com' and 'permit5.*.example.com' but blocks: 'permit5.example.com' or 'permit5..example.com'*.permit6.*.example.com # allows: 'abc.permit6.xyz.example.com' or '*.permit6.xyz.example.com' or 'abc.permit6.*.example.com' but blocks: 'permit6.xyz.example.com' or 'abc.permit6.example.com'permit7.example.* # allows: 'permit7.example.io' or 'permit7.example.com' but blocks: 'permit7.example'