Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validación de certificados

Descripción de la validación de certificados digitales

Durante la negociación ICR, el demonio de PKI de un dispositivo serie SRX valida los certificados X509 recibidos de los interlocutores VPN. La validación de certificado realizada se especifica en RFC 5280, certificado de infraestructura de clave pública X.509de Internet y perfil de lista de revocación de certificados (CRL). Las validaciones de certificados básicos y de cadenas de certificados son la validación de la firma y la fecha, así como las comprobaciones de revocación. Este tema describe las validaciones adicionales de certificados digitales realizadas por el demonio de PKI.

Validación de políticas

Los certificados X509 pueden incluir campos opcionales de validación de políticas. Si existe un campo de validación de Directiva, la validación de la Directiva se realiza para toda la cadena de certificados, incluidos los certificados de la entidad final (EE) y los de la entidad de certificación intermedia (CA). La validación de políticas no es aplicable al certificado raíz. La validación de políticas garantiza que los certificados de la CA de EE e intermedias tengan una directiva común. Si no existe ninguna directiva común para la cadena de certificados que se valida, se produce un error en la validación de certificados.

Antes de validar la Directiva, debe generarse una cadena de certificados que contenga el certificado raíz autofirmado, los certificados de entidad emisora intermedia y el certificado EE. La validación de políticas se inicia con el certificado de la entidad emisora intermedia emitido por el certificado raíz firmado automáticamente y continúa a través del certificado EE.

Para la validación de directivas se utilizan los siguientes campos opcionales de certificado:

  • policy-oids

  • requireExplicitPolicy

  • skipCerts

Estos campos se describen en las secciones siguientes.

OID de directiva configurados en dispositivos serie SRX

En algunas situaciones, puede ser conveniente aceptar únicamente los certificados con identificadores de objetos de directiva conocidos (OID) de los elementos del mismo nivel. Esta configuración opcional solo permite que la validación de certificados se realice correctamente si la cadena de certificados recibida del interlocutor contiene al menos un OID de la Directiva que está configurado en el dispositivo de serie SRX.

En el dispositivo de serie SRX, los OID de Directiva se configuran en policy-oids una directiva ICR con laedit security ike policy policy-name certificateinstrucción de configuración en el nivel de jerarquía []. Puede configurar hasta cinco OID de directiva. Para que el certificado de un par se valide correctamente, la cadena de certificados del par debe contener al menos una de las ID de política configuradas en el dispositivo de la serie SRX. Tenga en cuenta policy-oids que el campo de un certificado es opcional. Si configura las ID de políticas en el dispositivo de la serie SRX, pero la cadena de certificados del par no contiene ninguna IA de política, se produce un error en la validación del certificado.

OID de Directiva no configurado en dispositivos serie SRX

Si no se configura ningún OID de directiva en el dispositivo serie SRX, la validación de requireExplicitPolicy la Directiva se iniciará siempre que el campo se encuentre en la cadena de certificados. Un certificado puede contener uno o varios OID de directiva de certificados. Para que se realice correctamente la validación de directivas, debe haber un OID de la Directiva común en la cadena de certificados.

Figura 1muestra una cadena de certificados formada por certificados para una entidad emisora raíz, tres CA intermedias y EE. El certificado de la entidad emisora de int-CA requireExplicitPolicy -2 contiene el campo; por lo tanto, la validación de políticas comienza con int-CA-2 y se realiza a través de EE-1. El certificado para int-CA-2 contiene los OID de directiva P1, P2 y P3. El certificado para int-CA-3 contiene los OID de directiva P2, P3 y P4. El certificado para EE-1 contiene el OID de directiva P2 y P5. Dado que el OID de la Directiva P2 es común a los certificados que se validan, la validación de la Directiva se realiza correctamente.

Figura 1: Validación de políticas con el campo requireExplicitPolicyValidación de políticas con el campo requireExplicitPolicy

El campo skipCerts opcional de un certificado de entidad emisora intermedia indica el número de certificados, incluido el certificado de entidad emisora actual, que se van a excluir de la validación de directivas. Si skipCerts es 0, la validación de la Directiva comienza a partir del certificado actual. Si skipCerts es 1, el certificado actual se excluye de la validación de directivas. El valor del skipCerts campo se comprueba en todos los certificados de entidades emisoras intermedias. Si se skipCerts encuentra un valor menor que el número actual de certificados que se excluyen, se utiliza skipCerts el valor menor.

Figura 2muestra una cadena de certificados formada por una entidad emisora raíz, cuatro entidades emisoras intermedias y EE. El skipCerts valor de int-CA-1 es 12, lo que omite 12 certificados, incluido el certificado de int-CA-1. Sin embargo, skipCerts el valor se comprueba en todos los certificados de entidades emisoras intermedias de la cadena. El skipCerts valor de int-CA-2 es 2, que es inferior a 12, por lo que ahora se omiten 2 certificados. El skipCerts valor de int-CA-4 es 5, que es mayor que 2, por lo que se omite el valor skipCerts int-CA-4.

Figura 2: Validación de políticas con el campo skipCertsValidación de políticas con el campo skipCerts

Cuando se configuran los OID de directiva en el dispositivo de requireExplicitPolicy serie SRX skipCerts , los campos del certificado se pasan por alto.

Validación de longitud de ruta

La validación de certificados puede implicar una cadena de certificados que incluye una entidad de certificación raíz, una o varias CA intermedias opcionales y un certificado EE. El número de entidades emisoras de certificación intermedias puede aumentar según el escenario de implementación. La validación de longitud de ruta proporciona un mecanismo para limitar el número de certificados intermedios implicados en la validación de certificados. path-length es un campo opcional en un certificado X509. El valor de path-length indica el número de certificados de CA intermedios no autofirmados permitidos para la validación de certificados. El último certificado, que generalmente es el certificado EE, no se incluye en el límite de la ruta de acceso. Si el certificado raíz contiene el path-length valor 0, no se permiten certificados de entidades emisoras intermedias. Si el path-length valor es 1, puede haber 0 ó 1 certificados de CA intermedios.

path-lengthpuede estar presente en varios certificados de CA de la cadena de certificados. La validación de longitud de ruta de acceso siempre comienza con el certificado raíz autofirmado. El límite de ruta de acceso se reduce en 1 en cada certificado intermedio de la cadena. Si un certificado intermedio contiene un path-length valor menor que el límite de ruta actual, se aplicará el nuevo límite. Por otro lado, si el path-length valor es mayor que el límite de ruta actual, se omite.

Figura 3muestra una cadena de certificados compuesta por una entidad emisora raíz, cuatro entidades emisoras intermedias y EE. El path-length valor en root-CA es 10, por lo que el límite de ruta de acceso inicial de los certificados de CA intermedios no firmados automáticamente para la validación de certificados es 10. En int-CA-1, el límite de ruta es 10-1 o 9. El path-length valor de int-CA-1 es 4, que es menor que el límite de ruta de 9, por lo que el nuevo límite de ruta se convierte en 4. En int-CA-2, el límite de ruta es 4-1 o 3. El path-length valor de int-CA-2 es 5, que es mayor que el límite de ruta de acceso de 3, por lo que se omite. En int-CA-3, el límite de ruta es 3-1 o 2. El path-length valor de int-CA-3 es 20, que es mayor que el límite de ruta de acceso de 2, por lo que también se omite.

Figura 3: Validación de longitud de rutaValidación de longitud de ruta

Uso de la clave

El campo uso de la clave de un certificado EE o CA define el propósito de la clave contenida en el certificado.

  • En el caso de los certificados EE, si está presente el campo de uso de la digitalSignature clave nonrepudiation pero el certificado no contiene ni indicadores, el certificado se rechazará. Si el campo uso de la clave no está presente, no se comprueba el uso de la clave.

  • Para AC certificados, la clave se puede usar para la validación de certificados o firmas CRL. Dado que el demonio de PKI es responsable tanto de las descargas de validación de certificados X509 como de las listas CRL, debe comprobarse el uso de claves antes de validar el certificado o la CRL.

    En la validación de firmas de certificado, el indicador indica que se puede usar AC certificado de certificación keyCertSign para la validación de firma de certificado. Si esta marca no se establece, se anula la validación del certificado.

    En las negociaciones de fase 1 de validación de firmas de CRL, los participantes comprueban la lista de revocación de certificados (CRL) para ver si los certificados recibidos durante un intercambio de ICR siguen siendo válidos. La CRL se descarga periódicamente para los perfiles de CA configurados con CRL como la comprobación de revocación de certificados. Los archivos de CRL descargados deben comprobarse antes de descargarlos en el dispositivo. Uno de los pasos de comprobación consiste en validar la firma de la CRL con un certificado de CA. La CRL descargada está firmado con la clave privada del certificado de AC y debe comprobarse con la clave pública del certificado de AC almacenada en el dispositivo. El campo uso de claves del certificado de la entidad emisora debe contener el CRLSign indicador para comprobar la CRL descargada. Si este indicador no está presente, la CRL se descarta.

Validación de emisor y nombre distintivo de asunto

La validación de firmas se realiza para los certificados recibidos de un interlocutor, así como para el archivo CRL descargado de un servidor de CA. La validación de firmas implica buscar el certificado de AC en una base de datos de AC basada en el nombre distinguido (DN) del emitidor en el certificado o en la CRL verificada.

Figura 4muestra la búsqueda de certificados de entidad emisora basada en el DN del emisor. En el certificado EE, el nombre completo del emisor es CA-1, que es el DN del firmante del certificado de la CA intermedia en la cadena. En el certificado de entidad emisora intermedia, el DN de emisor es CA-root, que es el DN del firmante del certificado de entidad emisora raíz de firma automática en la cadena. En la CRL, el DN de emisor es CA-root, que es el DN del firmante del certificado de entidad emisora raíz de firma automática.

Figura 4: Validación de DN de asunto y emisorValidación de DN de asunto y emisor

La búsqueda de los DN de emisor o de sujeto debe seguir estas reglas para los valores de atributo:

  • Se supone que los valores de atributo codificados en diferentes tipos ASN. 1 (por ejemplo, PrintableString y BMPString) representan cadenas diferentes.

  • Los valores de atributo codificados en tipos PrintableString no distinguen mayúsculas de minúsculas. Estos valores de atributo se comparan después de quitar los espacios en blanco iniciales y finales y convertir las subcadenas internas de uno o varios espacios en blanco consecutivos en un único espacio.

  • Los valores de atributo codificados en tipos distintos de PrintableString distinguen entre mayúsculas y minúsculas.

Ejemplo Validación de un certificado digital mediante la configuración de OID de directiva en un dispositivo serie SRX

En algunas situaciones, puede ser conveniente aceptar únicamente los certificados con identificadores de objetos de directiva conocidos (OID) de los elementos del mismo nivel. Esta configuración opcional solo permite que la validación de certificados se realice correctamente si la cadena de certificados recibida del interlocutor contiene al menos un OID de la Directiva que está configurado en el dispositivo de serie SRX. En este ejemplo se muestra cómo configurar OID de directiva en la Directiva de ICR en un dispositivo serie SRX.

Debe asegurarse de que al menos una de las ID de política configuradas en el dispositivo de la serie SRX se incluya en un certificado o cadena de certificado de un par. Tenga en cuenta policy-oids que el campo del certificado de un par es opcional. Si configura los CADE de políticas en una política de ICR y la cadena de certificados del par no contiene ninguna IA de política, se produce un error en la validación del certificado para el par.

Aplicables

Antes de empezar:

Descripción general

Este ejemplo muestra una configuración de directiva ICR en la que se especifican los OID 2.16.840.1.101.3.1.48.2 y 5.16.40.1.101.3.1.55.2 de la Directiva. La Directiva de ICR ike_cert_pol hace referencia a la ike_cert_prop propuesta de ICR, que no se muestra. El certificado local en el serie SRX dispositivo es LC-Igloo-root.

Automática

Modalidades

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los [edit] comandos en la CLI en el nivel de jerarquía y, a continuación, entrar commit desde el modo de configuración.

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte uso del editor de CLI en el modo de configuración en la guía del usuario de CLI.

Para configurar OID de directiva para la validación de certificados:

  1. Configure la Directiva de ICR:

Resultados

Desde el modo de configuración, escriba el show security ike policy ike_cert_pol comando para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Comproba

Confirme que la configuración funciona correctamente.

Comprobar el certificado de la entidad emisora

Purpose

Muestra el certificado de CA configurado en el dispositivo.

Intervención

En modo operativo, escriba el show security pki ca-certificate ca-profile ca-tmp comando.

Comprobación de validación de OID de Directiva

Purpose

Si el certificado del par se valida correctamente, ICR y asociaciones de seguridad IPsec se establecen. Si se produce un error en la validación del certificado del par, no ICR asociación de seguridad.

Intervención

En modo operativo, escriba los show security ike security-associations comandos show security ipsec security-associations y.

Efectos

El show security ike security-associations comando enumera todas las SA activas de ICR Phase 1. Si no se enumera ninguna SA, hubo un problema con el establecimiento de la fase 1. En este caso, compruebe el mensaje de PKID_CERT_POLICY_CHECK_FAIL en los registros del sistema. Este mensaje indica que la cadena de certificados del par no contiene una OID de política configurada en el dispositivo de la serie SRX. Compruebe los valores de la cadena de certificados del par policy-oids con los valores configurados en el dispositivo de la serie SRX.

También podría ser que la cadena de certificados del par no contiene ningún policy-oids campo, que son campos opcionales. Si éste es el caso, se produce un error en la validación de certificados si se han configurado OID de directiva en el dispositivo serie SRX.