Validación de certificados

Validación de políticas

Los certificados X509 pueden incluir campos opcionales de validación de políticas. Si hay un campo de validación de política, la validación de política se realiza para toda la cadena de certificados, incluidos el certificado de entidad final (EE) y los certificados de entidad de certificación (CA) intermedios. La validación de directivas no se aplica al certificado raíz. La validación de políticas garantiza que los certificados EE y CA intermedia tengan una política común. Si no existe una política común para la cadena de certificados que se está validando, se producirá un error en la validación del certificado.

Antes de la validación de la directiva, se debe crear una cadena de certificados que contenga el certificado raíz autofirmado, los certificados de CA intermedios y el certificado EE. La validación de la política comienza con el certificado de CA intermedio emitido por el certificado raíz autofirmado y continúa a través del certificado EE.

Los siguientes campos de certificado opcionales se utilizan para la validación de directivas:

• policy-oids

• requireExplicitPolicy

• skipCerts

Estos campos se describen en las secciones siguientes.

• OID de políticas configurados en firewalls de la serie SRX
• No hay OID de política configurados en firewalls de la serie SRX

No hay OID de política configurados en firewalls de la serie SRX

Si no se configura ningún OID de política en el firewall de la serie SRX, la validación de la política comienza cada vez que se encuentra el campo en la cadena de certificados.requireExplicitPolicy Un certificado puede contener uno o varios OID de directiva de certificado. Para que la validación de la política se realice correctamente, debe haber un OID de política común en la cadena de certificados.

Figura 1 muestra una cadena de certificados que consta de certificados para una CA raíz, tres CA intermedias y un EE. El certificado de CA para Int-CA-2 contiene el campo; por lo tanto, la validación de políticas comienza con Int-CA-2 y continúa hasta EE-1.requireExplicitPolicy 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 los OID de política P2 y P5. Dado que el OID P2 de la directiva es común a los certificados que se validan, la validación de la política se realiza correctamente.

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

El campo opcional de un certificado de CA intermedio indica el número de certificados, incluido el certificado de CA actual, que se van a excluir de la validación de directivas.skipCerts Si es 0, la validación de la directiva comienza desde el certificado actual.skipCerts Si es 1, el certificado actual se excluye de la validación de la directiva.skipCerts El valor del campo se comprueba en todos los certificados de CA intermedios.skipCerts Si se encuentra un valor inferior al número actual de certificados que se excluyen, se utiliza el valor inferior .skipCertsskipCerts

Figura 2 muestra una cadena de certificados que consta de una CA raíz, cuatro CA intermedias y un EE. El valor de Int-CA-1 es 12, que omite 12 certificados, incluido el certificado para Int-CA-1.skipCerts Sin embargo, el valor se comprueba en todos los certificados de CA intermedios de la cadena.skipCerts El valor en Int-CA-2 es 2, que es inferior a 12, por lo que ahora se omiten 2 certificados.skipCerts El valor de Int-CA-4 es 5, que es mayor que 2, por lo que se omite el valor de Int-CA-4 .skipCertsskipCerts

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

Cuando se configuran OID de directiva en el firewall de la serie SRX, los campos del certificado y se ignoran.requireExplicitPolicyskipCerts

Validación de longitud de ruta

La validación de certificados puede implicar una cadena de certificados que incluya una CA raíz, una o más CA intermedias opcionales y un certificado EE. El número de CA intermedias puede aumentar en función del 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. es un campo opcional en un certificado X509.path-length El valor de indica el número de certificados de CA intermedios no autofirmados permitidos para la validación de certificados.path-length El último certificado, que generalmente es el certificado EE, no se incluye en el límite de ruta. Si el certificado raíz contiene un valor de 0, no se permiten certificados de CA intermedios.path-length Si el valor es 1, puede haber 0 o 1 certificados de CA intermedios.path-length

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

Figura 3 muestra una cadena de certificados que consta de una CA raíz, cuatro CA intermedias y un EE. El valor de Root-CA es 10; por lo tanto, el límite de ruta de acceso inicial de los certificados de CA intermedios no autofirmados permitidos para la validación de certificados es 10.path-length En Int-CA-1, el límite de ruta es 10-1 o 9. El valor en 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 valor en Int-CA-2 es 5, que es mayor que el límite de ruta de acceso de 3, por lo que se omite.path-lengthpath-length En Int-CA-3, el límite de ruta es 3-1 o 2. El 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.path-length

Figura 3: Validación de longitud de ruta

Uso de claves

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

• Para los certificados EE, si el campo de uso de clave está presente pero el certificado no contiene ni marca, el certificado se rechaza.digitalSignaturenonrepudiation Si el campo de uso de clave no está presente, entonces el uso de clave no está marcado.

• En el caso de los certificados de CA, la clave se puede utilizar para la validación de certificados o firmas CRL. Dado que el demonio PKI es responsable tanto de la validación del certificado X509 como de las descargas de CRL, se debe comprobar el uso de claves antes de validar el certificado o la CRL.

  En la validación de firma de certificado, el indicador indica que se puede usar un certificado de CA para la validación de firma de certificado .keyCertSign Si no se establece este indicador, se finaliza la validación del certificado.

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

Validación del nombre distinguido del emisor y del sujeto

La validación de la firma se realiza para los certificados recibidos de un par, así como para el archivo CRL descargado de un servidor de CA. La validación de firma implica buscar el certificado de CA en una base de datos de CA en función del nombre distintivo (DN) del emisor en el certificado o la CRL que se está verificando.

Figura 4 muestra la búsqueda de certificados de CA según el DN del emisor. En el certificado EE, el DN del emisor es CA-1, que es el DN sujeto del certificado de CA intermedio en la cadena. En el certificado de CA intermedio, el DN del emisor es CA-Raíz, que es el DN sujeto del certificado de CA raíz autofirmado en la cadena. En la CRL, el DN del emisor es CA-Raíz, que es el DN sujeto del certificado Root-CA autofirmado.

Figura 4: Validación del DN del emisor y del sujeto

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

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

• Los valores de atributo codificados en los tipos PrintableString no distinguen entre mayúsculas y minúsculas. Estos valores de atributo se comparan después de eliminar los espacios en blanco iniciales y finales y convertir subcadenas internas de uno o más 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.