Validar un certificado
Obtenga información sobre cómo validar los certificados de CA.
Validar certificado digital en el firewall de la serie SRX
Durante la negociación de IKE, la PKI en un firewall de la serie SRX valida los certificados X509 recibidos de los pares VPN. La validación del certificado realizada se especifica en RFC 5280, Perfil de lista de revocación de certificados (CRL) y certificado de infraestructura de clave pública X.509 de Internet. Las validaciones básicas de certificados y cadenas de certificados incluyen validación de firma y fecha, así como comprobaciones de revocación. En este tema se describen las validaciones de certificados digitales adicionales realizadas por la PKI.
- Validación de políticas
- Validación de longitud de ruta
- Uso de claves
- Validación del DN del emisor y del sujeto
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, incluido el certificado de entidad final (EE) y los certificados de 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 ninguna directiva común para la cadena de certificados que valida, se producirá un error en la validación del certificado.
Antes de la validación de la directiva, 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
OID de políticas configurados en firewalls de la serie SRX
En algunas situaciones, puede ser conveniente aceptar solo certificados con identificadores de objeto de política conocidos (OID) de pares (OID). Esta configuración opcional da como resultado una validación de certificado correcta solo si la cadena de certificados recibida del par contiene al menos un OID de directiva configurado en el firewall de la serie SRX.
En el firewall de la serie SRX, los OID de políticas se configuran en una política de IKE con la policy-oids instrucción configuration en el nivel de jerarquía [edit security ike policy policy-name certificate]. Puede configurar hasta cinco OID de directiva. Para validar correctamente el certificado de un par, la cadena de certificados del mismo nivel debe contener al menos uno de los OID de directiva configurados en el firewall de la serie SRX. Tenga en cuenta que el campo policy-oids de un certificado es opcional. Si configura OID de directiva en el firewall de la serie SRX, pero la cadena de certificados del par no contiene ningún OID de directiva, se producirá un error en la validación del certificado.
No hay OID de política configurados en firewalls de la serie SRX
Si no se configura ningún OID de directiva en el firewall de la serie SRX, la validación de la política comienza siempre que se encuentre el campo requireExplicitPolicy en la cadena de certificados. 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.
La 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 requireExplicitPolicy ; por lo tanto, la validación de políticas comienza con Int-CA-2 y continúa hasta 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 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.
requireExplicitPolicy
El campo opcional skipCerts 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. Si skipCerts es 0, la validación de la directiva comienza desde el certificado actual. Si skipCerts es 1, el certificado actual se excluye de la validación de la política. El valor del campo skipCerts se comprueba en todos los certificados de CA intermedios. Si se encuentra un valor skipCerts inferior al número actual de certificados que se excluyen, se utiliza el valor skipCerts inferior.
La figura 2 muestra una cadena de certificados que consta de una CA raíz, cuatro CA intermedias y un EE. El valor de skipCerts en Int-CA-1 es 12, que omite 12 certificados, incluido el certificado para Int-CA-1. Sin embargo, el valor skipCerts se comprueba en todos los certificados de CA intermedios de la cadena. El valor de skipCerts en Int-CA-2 es 2, que es inferior a 12, por lo que ahora se omiten 2 certificados. El valor skipCerts en Int-CA-4 es 5, que es mayor que 2, por lo que se omite el valor skipCerts de Int-CA-4.
skipCerts
Cuando se configuran OID de directiva en el firewall de la serie SRX, se omiten los campos de certificado requireExplicitPolicy y skipCerts .
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. path-length es un campo opcional en un certificado X509. El valor de longitud de ruta 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 ruta. Si el certificado raíz contiene un valor de longitud de ruta de acceso de 0, no se permiten certificados de CA intermedios. Si el valor de longitud de ruta es 1, puede haber 0 o 1 certificados de CA intermedios.
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 de longitud de ruta inferior al límite de ruta actual, se aplicará el nuevo límite. Por otro lado, si el valor de longitud de ruta es mayor que el límite de ruta actual, se omite.
La figura 3 muestra una cadena de certificados que consta de una CA raíz, cuatro CA intermedias y un EE. El valor de longitud de ruta en 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. En Int-CA-1, el límite de ruta es 10-1 o 9. El valor de longitud de ruta 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 de longitud de ruta en 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 valor de longitud de ruta en 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.
la 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.
En el caso de los certificados EE, si el campo de uso de claves está presente pero el certificado no contiene indicadores de firma digital o de no rechazo , se rechaza el certificado. 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, puede demandar a la clave para la validación de certificados o firmas de CRL. Dado que la PKI es responsable tanto de la validación del certificado X509 como de las descargas de CRL, debe comprobar el uso de la clave antes de validar el certificado o la CRL.
En la validación de firma de certificado, el indicador keyCertSign indica que se puede usar un certificado de CA para la validación de firma de certificado. Si no se establece este indicador, se finaliza la validación del certificado.
En las negociaciones de fase 1 de validación de firmas de CRL, los participantes comprueban la 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. Debe verificar los archivos CRL descargados antes de descargarlos en el dispositivo. Uno de los pasos de verificación es validar la firma CRL mediante un certificado de CA. La CRL descargada se firma con la clave privada del certificado de CA y debe comprobar con la clave privada 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 CRLSign para comprobar la CRL descargada. Si este indicador no está presente, se descarta la CRL.
Validación del DN del emisor y del sujeto
Debe validar la firma de los certificados recibidos de un par y del 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 según el DN del emisor en el certificado o la CRL que se está verificando.
La 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.
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 entre sí después de eliminar los espacios en blanco iniciales y finales y convertir subcadenas internas de uno o más espacios blancos consecutivos en un solo espacio.
Los valores de atributo codificados en tipos distintos de PrintableString distinguen entre mayúsculas y minúsculas.
Validar certificado digital en dispositivos de la serie MX
A partir de Junos OS versión 16.1R3, los dispositivos de la serie MX admiten la validación de certificados digitales. Durante la negociación IKE, la PKI en un dispositivo serie MX valida los certificados X509 recibidos de los pares VPN. La validación del certificado realizada se especifica en RFC 5280, Perfil de lista de revocación de certificados (CRL) y certificado de infraestructura de clave pública X.509 de Internet. Las validaciones básicas de certificados y cadenas de certificados incluyen validación de firma y fecha, así como comprobaciones de revocación. En este tema se describen las validaciones de certificados digitales adicionales realizadas por la PKI.
- Validación de políticas
- Validación de longitud de ruta
- Uso de claves
- Validación del nombre distinguido del emisor y del sujeto
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 directiva, debe realizar la validación de políticas para toda la cadena de certificados, incluidos el certificado EE y los certificados de 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 realizar la validación de directivas, debe crear una cadena de certificados que contenga el certificado raíz autofirmado, el certificado de CA intermedio 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 dispositivos de la serie MX
- No hay OID de política configurados en dispositivos de la serie MX
OID de políticas configurados en dispositivos de la serie MX
En algunas situaciones, puede ser conveniente aceptar solo certificados con identificadores de objeto de política conocidos (OID) de pares (OID). Esta configuración opcional permite que la validación de certificados se realice correctamente solo si la cadena de certificados recibida del par contiene al menos un OID de política configurado en el dispositivo de la serie MX.
En el dispositivo de la serie MX, debe configurar los OID de política en una política de IKE con la policy-oids instrucción de configuración en el nivel de jerarquía [edit security ike policy policy-name certificate]. Puede configurar hasta cinco OID de directiva. Para validar correctamente el certificado de un par, la cadena de certificados del mismo nivel debe contener al menos uno de los OID de política configurados en el dispositivo de la serie MX. Tenga en cuenta que el campo policy-oids de un certificado es opcional. Si configura OID de directiva en el dispositivo serie MX, pero la cadena de certificados del par no contiene ningún OID de directiva, se producirá un error en la validación del certificado.
No hay OID de política configurados en dispositivos de la serie MX
Si no se configura ningún OID de política en el dispositivo de la serie MX, la validación de la política comienza cada vez que se encuentra el campo requireExplicitPolicy en la cadena de certificados. 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.
La figura 5 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 requireExplicitPolicy ; por lo tanto, la validación de políticas comienza con Int-CA-2 y continúa hasta 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 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.
requireExplicitPolicy
El campo opcional skipCerts 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. Si skipCerts es 0, la validación de la directiva comienza desde el certificado actual. Si skipCerts es 1, el certificado actual se excluye de la validación de la política. El valor del campo skipCerts se comprueba en todos los certificados de CA intermedios. Si se encuentra un valor skipCerts inferior al número actual de certificados que se excluyen, se utiliza el valor skipCerts inferior.
La figura 6 muestra una cadena de certificados que consta de una CA raíz, cuatro CA intermedias y un EE. El valor de skipCerts en Int-CA-1 es 12, que omite 12 certificados, incluido el certificado para Int-CA-1. Sin embargo, el valor skipCerts se comprueba en todos los certificados de CA intermedios de la cadena. El valor de skipCerts en Int-CA-2 es 2, que es inferior a 12, por lo que ahora se omiten 2 certificados. El valor skipCerts en Int-CA-4 es 5, que es mayor que 2, por lo que se omite el valor skipCerts de Int-CA-4.
skipCerts
Cuando se configuran OID de directiva en el dispositivo de la serie MX, se omiten los campos de certificado requireExplicitPolicy y skipCerts .
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. path-length es un campo opcional en un certificado X509. El valor de longitud de ruta 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 ruta. Si el certificado raíz contiene un valor de longitud de ruta de acceso de 0, no se permiten certificados de CA intermedios. Si el valor de longitud de ruta es 1, puede haber 0 o 1 certificados de CA intermedios.
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 de longitud de ruta inferior al límite de ruta actual, se aplicará el nuevo límite. Por otro lado, si el valor de longitud de ruta es mayor que el límite de ruta actual, se omite.
En la figura 7 se muestra una cadena de certificados que consta de una CA raíz, cuatro CA intermedias y un EE. El valor de longitud de ruta en Root-CA es 10; por lo tanto, el límite de ruta inicial de los certificados de CA intermedios no autofirmados permitidos para la validación de certificados es 10. En Int-CA-1, el límite de ruta es 10-1 o 9. El valor de longitud de ruta 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 de longitud de ruta en 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 valor de longitud de ruta en 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.
la 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.
Certificados EE
En el caso de los certificados EE, si el campo de uso de claves está presente pero el certificado no contiene indicadores de firma digital o de no rechazo , se rechaza el certificado. Si el campo de uso de clave no está presente, entonces el uso de clave no está marcado.
Certificados de CA
La clave se puede utilizar para la validación de certificados o firmas CRL. Dado que la 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.
Validación de firma de certificado
La marca keyCertSign indica que se puede usar un certificado de CA para la validación de la firma del certificado. Si no se establece este indicador, se finaliza la validación del certificado.
Validación de la firma CRL
En las negociaciones de la fase 1, los participantes comprueban la 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 CRLSign para comprobar la CRL descargada. 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 DN del emisor en el certificado o la CRL que se está verificando.
La figura 8 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.
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 blancos consecutivos en un solo espacio.
Los valores de atributo codificados en tipos distintos de PrintableString distinguen entre mayúsculas y minúsculas.
Ejemplo: validación de certificados digitales mediante la configuración de OID de directiva
En algunas situaciones, puede ser conveniente aceptar solo certificados con identificadores de objeto de política conocidos (OID) de pares (OID). Esta configuración opcional permite que la validación de certificados se realice correctamente solo si la cadena de certificados recibida del par contiene al menos un OID de política configurado en el firewall de la serie SRX. En este ejemplo se muestra cómo configurar OID de políticas en la política de IKE en un firewall de la serie SRX.
Debe asegurarse de que al menos uno de los OID de política configurados en el firewall de la serie SRX esté incluido en el certificado o la cadena de certificados de un par. Tenga en cuenta que el campo policy-oids en el certificado de un par es opcional. Si configura OID de directiva en una política de IKE y la cadena de certificados del mismo nivel no contiene ningún OID de directiva, se producirá un error en la validación del certificado del mismo nivel.
Requisitos
Antes de empezar:
Asegúrese de que está utilizando Junos OS versión 12.3X48-D10 o posterior para firewalls serie SRX.
Configure un túnel VPN IPsec. Consulte Descripción general de la configuración de VPN IPsec. En este ejemplo no se muestra la configuración completa del túnel VPN de fase 1 y fase 2 de IKE.
Visión general
En este ejemplo se muestra una configuración de política de IKE en la que se especifican los OID de directiva 2.16.840.1.101.3.1.48.2 y 5.16.40.1.101.3.1.55.2. El ike_cert_pol de políticas de IKE hace referencia al ike_cert_prop de propuesta de ICR, que no se muestra. El certificado local en el firewall de la serie SRX es lc-igloo-root.
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
set security ike policy ike_cert_pol mode main set security ike policy ike_cert_pol proposals ike_cert_prop set security ike policy ike_cert_pol certificate local-certificate lc-igloo-root set security ike policy ike_cert_pol certificate policy-oids 2.16.840.1.101.3.1.48.2 set security ike policy ike_cert_pol certificate policy-oids 5.16.40.1.101.3.1.55.2
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por varios niveles en la jerarquía de configuración. Para obtener instrucciones sobre cómo hacerlo, consulte Usar el editor de CLI en modo de configuración en la Guía del usuario de CLI.
Para configurar OID de directiva para la validación de certificados:
Configure la política de IKE.
[edit security ike policy ike_cert_pol] user@host# set mode main user@host# set proposals ike_cert_prop user@host# set certificate local-certificate lc-igloo-root user@host# set certificate policy-oids 2.16.840.1.101.3.1.48.2 user@host# set certificate policy-oids 5.16.40.1.101.3.1.55.2
Resultados
Desde el modo de configuración, confirme la configuración introduciendo el show security ike policy ike_cert_pol comando. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
user@host# show security ike policy ike_cert_pol
mode main;
proposals ike_cert_prop;
certificate {
local-certificate lc-igloo-root;
policy-oids [ 2.16.840.1.101.3.1.48.2 5.16.40.1.101.3.1.55.2 ];
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
Comprobación del certificado de CA
Propósito
Muestra el certificado de CA configurado en el dispositivo.
Acción
Desde el modo operativo, ingrese el show security pki ca-certificate ca-profile ca-tmp comando.
user@host> show security pki ca-certificate ca-profile ca-tmp detail
Certificate identifier: ca-tmp
Certificate version: 3
Serial number: 00000047
Issuer:
Organization: U.S. Government,
Organizational unit: DoD, Organizational unit: Testing, Country: US,
Common name: Trust Anchor
Subject:
Organization: U.S. Government,
Organizational unit: Dod, Organizational unit: Testing, Country: US,
Common name: CA1-PP.01.03
Subject string:
C=US, O=U.S. Government, OU=Dod, OU=Testing, CN=CA1-PP.01.03
Validity:
Not before: 01- 1-1998 12:01 UTC
Not after: 01- 1-2048 12:01 UTC
?Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:cb:fd:78:0c:be:87:ac:cd:c0:33:66:a3:18
9e:fd:40:b7:9b:bc:dc:66:ff:08:45:f7:7e:fe:8e:d6:32:f8:5b:75
db:76:f0:4d:21:9a:6e:4f:04:21:4c:7e:08:a1:f9:3d:ac:8b:90:76
44:7b:c4:e9:9b:93:80:2a:64:83:6e:6a:cd:d8:d4:23:dd:ce:cb:3b
b5:ea:da:2b:40:8d:ad:a9:4d:97:58:cf:60:af:82:94:30:47:b7:7d
88:c3:76:c0:97:b4:6a:59:7e:f7:86:5d:d8:1f:af:fb:72:f1:b8:5c
2a:35:1e:a7:9e:14:51:d4:19:ae:c7:5c:65:ea:f5:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Certificate Policy:
Policy Identifier = 2.16.840.1.101.3.1.48.2
Use for key: CRL signing, Certificate signing
Fingerprint:
e0:b3:2f:2e:a1:c5:ee:ad:af:dd:96:85:f6:78:24:c5:89:ed:39:40 (sha1)
f3:47:6e:55:bc:9d:80:39:5a:40:70:8b:10:0e:93:c5 (md5)
Verificación de la validación del OID de directivas
Propósito
Si el certificado del par se valida correctamente, se establecen IKE y SA IPsec. Si se produce un error en la validación del certificado del par, no se establece ninguna SA de IKE.
Acción
Desde el modo operativo, escriba los show security ike security-associations comandos y show security ipsec security-associations .
user@host> show security ike security-associations node0: -------------------------------------------------------------------------- Index State Initiator cookie Responder cookie Mode Remote Address 821765168 UP 88875c981252c1d8 b744ac9c21bde57e IKEv2 192.0.2.2 1106977837 UP 1a09e32d1e6f20f1 e008278091060acb IKEv2 198.51.100.202
user@host> show security ipsec security-associations node0: -------------------------------------------------------------------------- Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <213909506 ESP:aes-cbc-192/sha256 8cb9e40a 1295/ unlim - root 500 192.0.2.2 >213909506 ESP:aes-cbc-192/sha256 8271d2b2 1295/ unlim - root 500 192.0.2.2 <218365954 ESP:aes-cbc-192/sha256 d0153bc0 1726/ unlim - root 1495 198.51.100.202 >218365954 ESP:aes-cbc-192/sha256 97611813 1726/ unlim - root 1495 198.51.100.202
Significado
El show security ike security-associations comando enumera todas las SA de fase 1 de IKE activas. Si no hay ninguna SA en la lista, hubo un problema con el establecimiento de la fase 1. En este caso, compruebe el mensaje PKID_CERT_POLICY_CHECK_FAIL en los registros del sistema. Este mensaje indica que la cadena de certificados del par no contiene un OID de directiva configurado en el firewall de la serie SRX. Compruebe los valores de policy-oids en la cadena de certificados del par con los valores configurados en el firewall de la serie SRX.
También puede ser que la cadena de certificados del par no contenga ningún campo policy-oids , que son campos opcionales. Si este es el caso, se producirá un error en la validación del certificado si hay algún OID de directiva configurado en el firewall de la serie SRX.
Ejemplo: mejora de la validación de certificados digitales mediante la configuración de OID de políticas en un dispositivo de la serie MX
En algunas situaciones, puede ser conveniente aceptar solo certificados con identificadores de objeto de política conocidos (OID) de pares (OID). Esta configuración opcional permite que la validación de certificados se realice correctamente solo si la cadena de certificados recibida del par contiene al menos un OID de política configurado en el dispositivo de la serie MX. En este ejemplo se muestra cómo configurar OID de políticas en la política IKE en un dispositivo serie MX.
Debe asegurarse de que al menos uno de los OID de política configurados en el dispositivo de la serie MX esté incluido en el certificado o la cadena de certificados de un par. Tenga en cuenta que el campo policy-oids en el certificado de un par es opcional. Si configura OID de directiva en una política de IKE y la cadena de certificados del mismo nivel no contiene ningún OID de directiva, se producirá un error en la validación del certificado del mismo nivel.
Requisitos
Antes de empezar:
Asegúrese de que está utilizando Junos OS versión 16.1 o posterior para dispositivos de la serie MX.
Configure un túnel VPN IPsec.
Visión general
En este ejemplo se muestra una configuración de política de IKE en la que se especifican los OID de directiva 2.16.840.1.101.3.1.48.2 y 5.16.40.1.101.3.1.55.2. El ike_cert_pol de políticas de IKE hace referencia al ike_cert_prop de propuesta de ICR, que no se muestra. El certificado local en el dispositivo de la serie MX es lc-igloo-root.
Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
set services ipsec-vpn ike policy ike_cert_pol mode main set services ipsec-vpn ike policy ike_cert_pol proposals ike_cert_prop set services ipsec-vpn ike policy ike_cert_pol certificate local-certificate lc-igloo-root set services ipsec-vpn ike policy ike_cert_pol certificate policy-oids 2.16.840.1.101.3.1.48.2 set services ipsec-vpn ike policy ike_cert_pol certificate policy-oids 5.16.40.1.101.3.1.55.2
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por 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 de la Guía del usuario de CLI.
Para configurar OID de directiva para la validación de certificados:
Configure la política de IKE:
[edit services ipsec-vpn ike policy ike_cert_pol] user@host# set mode main user@host# set proposals ike_cert_prop user@host# set certificate local-certificate lc-igloo-root user@host# set certificate policy-oids 2.16.840.1.101.3.1.48.2 user@host# set certificate policy-oids 5.16.40.1.101.3.1.55.2
Resultados
Desde el modo de configuración, confirme la configuración introduciendo el show services ipsec-vpn ike policy ike_cert_pol comando. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.
user@host# show services ipsec-vpn ike policy ike_cert_pol
mode main;
proposals ike_cert_prop;
certificate {
local-certificate lc-igloo-root;
policy-oids [ 2.16.840.1.101.3.1.48.2 5.16.40.1.101.3.1.55.2 ];
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
Comprobación del certificado de CA
Propósito
Muestra el certificado de CA configurado en el dispositivo.
Acción
Desde el modo operativo, ingrese el show security pki ca-certificate ca-profile ca-tmp comando.
user@host> show security pki ca-certificate ca-profile ca-tmp detail
Certificate identifier: ca-tmp
Certificate version: 3
Serial number: 00000047
Issuer:
Organization: U.S. Government,
Organizational unit: DoD, Organizational unit: Testing, Country: US,
Common name: Trust Anchor
Subject:
Organization: U.S. Government,
Organizational unit: Dod, Organizational unit: Testing, Country: US,
Common name: CA1-PP.01.03
Subject string:
C=US, O=U.S. Government, OU=Dod, OU=Testing, CN=CA1-PP.01.03
Validity:
Not before: 07- 3-2015 10:54 UTC
Not after: 07- 1-2020 10:54 UTC
?Public key algorithm: rsaEncryption(1024 bits)
30:81:89:02:81:81:00:cb:fd:78:0c:be:87:ac:cd:c0:33:66:a3:18
9e:fd:40:b7:9b:bc:dc:66:ff:08:45:f7:7e:fe:8e:d6:32:f8:5b:75
db:76:f0:4d:21:9a:6e:4f:04:21:4c:7e:08:a1:f9:3d:ac:8b:90:76
44:7b:c4:e9:9b:93:80:2a:64:83:6e:6a:cd:d8:d4:23:dd:ce:cb:3b
b5:ea:da:2b:40:8d:ad:a9:4d:97:58:cf:60:af:82:94:30:47:b7:7d
88:c3:76:c0:97:b4:6a:59:7e:f7:86:5d:d8:1f:af:fb:72:f1:b8:5c
2a:35:1e:a7:9e:14:51:d4:19:ae:c7:5c:65:ea:f5:02:03:01:00:01
Signature algorithm: sha1WithRSAEncryption
Certificate Policy:
Policy Identifier = 2.16.840.1.101.3.1.48.2
Use for key: CRL signing, Certificate signing
Fingerprint:
e0:b3:2f:2e:a1:c5:ee:ad:af:dd:96:85:f6:78:24:c5:89:ed:39:40 (sha1)
f3:47:6e:55:bc:9d:80:39:5a:40:70:8b:10:0e:93:c5 (md5)
Verificación de la validación del OID de directivas
Propósito
Si el certificado del par se valida correctamente, se establecen IKE y SA IPsec. Si se produce un error en la validación del certificado del par, no se establece ninguna SA de IKE.
Acción
En el modo operativo, escriba los show services ipsec-vpn ike security-associations comandos y show services ipsec-vpn ipsec security-associations .
user@host> show services ipsec-vpn ike security-associations node0: -------------------------------------------------------------------------- Index State Initiator cookie Responder cookie Mode Remote Address 821765168 UP 88875c981252c1d8 b744ac9c21bde57e IKEv2 192.0.2.1 1106977837 UP 1a09e32d1e6f20f1 e008278091060acb IKEv2 198.51.100.0
user@host> show services ipsec-vpn ipsec security-associations node0: -------------------------------------------------------------------------- Total active tunnels: 2 ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway <213909506 ESP:aes-cbc-192/sha256 8cb9e40a 1295/ unlim - root 500 192.0.2.1 >213909506 ESP:aes-cbc-192/sha256 8271d2b2 1295/ unlim - root 500 192.0.2.1 <218365954 ESP:aes-cbc-192/sha256 d0153bc0 1726/ unlim - root 1495 198.51.100.0 >218365954 ESP:aes-cbc-192/sha256 97611813 1726/ unlim - root 1495 198.51.100.0
Significado
El show services ipsec-vpn ike security-associations comando enumera todas las SA de fase 1 de IKE activas. Si no hay ninguna SA en la lista, hubo un problema con el establecimiento de la fase 1. En este caso, compruebe el mensaje PKID_CERT_POLICY_CHECK_FAIL en los registros del sistema. Este mensaje indica que la cadena de certificados del par no contiene un OID de directiva configurado en el dispositivo de la serie MX. Compruebe los valores de policy-oids en la cadena de certificados del par con los valores configurados en el dispositivo de la serie MX.
También puede ser que la cadena de certificados del par no contenga ningún campo policy-oids , que son campos opcionales. Si este es el caso, se producirá un error en la validación del certificado si hay algún OID de política configurado en el dispositivo de la serie MX.
Ejemplo: configuración de un dispositivo para la validación de cadena de certificados del mismo nivel
En este ejemplo se muestra cómo configurar un dispositivo para cadenas de certificados utilizadas para validar dispositivos del mismo nivel durante la negociación de IKE.
- Requisitos
- Visión general
- Configuración
- Verificación
- Error de IKE y SA IPsec para un certificado revocado
Requisitos
Antes de comenzar, obtenga la dirección de la CA y la información que necesita (como la contraseña de desafío) cuando envíe solicitudes de certificados locales.
Visión general
En este ejemplo se muestra cómo configurar un dispositivo local para cadenas de certificados, inscribir certificados de CA y locales, comprobar la validez de los certificados inscritos y comprobar el estado de revocación del dispositivo del mismo nivel.
Topología
En este ejemplo se muestran los comandos de configuración y operativos en el host-A, como se muestra en la figura 9. Se crea automáticamente un perfil de CA dinámico en el Host-A para permitir que el Host-A descargue la CRL de Sales-CA y compruebe el estado de revocación del certificado del Host-B.
cadena de certificados
La configuración de VPN IPsec para la negociación de fase 1 y fase 2 se muestra para el host-A en este ejemplo. El dispositivo del mismo nivel (host-B) debe estar configurado correctamente para que las opciones de fase 1 y fase 2 se negocien correctamente y se establezca SA.
Configuración
Para configurar un dispositivo para cadenas de certificados:
Configurar perfiles de CA
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
set security pki ca-profile Root-CA ca-identity CA-Root set security pki ca-profile Root-CA enrollment url http://10.157.88.230:8080/scep/Root/ set security pki ca-profile Root-CA revocation-check use-crl set security pki ca-profile Eng-CA ca-identity Eng-CA set security pki ca-profile Eng-CA enrollment url http://10.157.88.230:8080/scep/Eng/ set security pki ca-profile Eng-CA revocation-check use-crl set security pki ca-profile Dev-CA ca-identity Dev-CA set security pki ca-profile Dev-CA enrollment url http://10.157.88.230:8080/scep/Dev/ set security pki ca-profile Dev-CA revocation-check use-crl
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por 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 de la Guía del usuario de CLI.
Para configurar perfiles de CA:
Cree el perfil de CA para Root-CA.
[edit security pki] user@host# set ca-profile Root-CA ca-identity CA-Root user@host# set ca-profile Root-CA enrollment url http://10.157.88.230:8080/scep/Root/ user@host# set ca-profile Root-CA revocation-check use-crl
Cree el perfil de CA para Eng-CA.
[edit security pki] user@host# set ca-profile Eng-CA ca-identity Eng-CA user@host# set ca-profile Eng-CA enrollment url http://10.157.88.230:8080/scep/Eng/ user@host# set ca-profile Eng-CA revocation-check use-crl
Cree el perfil de CA para Dev-CA.
[edit security pki] user@host# set ca-profile Dev-CA ca-identity Dev-CA user@host# set ca-profile Dev-CA enrollment url http://10.157.88.230:8080/scep/Dev/ user@host# set ca-profile Dev-CA revocation-check use-crl
Resultados
Desde el modo de configuración, confirme su configuración introduciendo el show security pki comando. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@host# show security pki
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url "http:/;/10.157.88.230:8080/scep/Root/";
}
revocation-check {
use-crl;
}
}
ca-profile Eng-CA {
ca-identity Eng-CA;
enrollment {
url "http:/;/10.157.88.230:8080/scep/Eng/";
}
revocation-check {
use-crl;
}
}
ca-profile Dev-CA {
ca-identity Dev-CA;
enrollment {
url "http:/;/10.157.88.230:8080/scep/Dev/";
}
revocation-check {
use-crl;
}
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Inscribir certificados
Procedimiento paso a paso
Para inscribir certificados:
Inscriba los certificados de CA.
user@host> request security pki ca-certificate enroll ca-profile Root-CA
user@host> request security pki ca-certificate enroll ca-profile Eng-CA
user@host> request security pki ca-certificate enroll ca-profile Dev-CA
Escriba yes en las indicaciones para cargar el certificado de CA.
Compruebe que los certificados de CA estén inscritos en el dispositivo.
user@host> show security pki ca-certificate ca-profile Root-CA Certificate identifier: Root-CA Issued to: Root-CA, Issued by: C = us, O = juniper, CN = Root-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Eng-CA Certificate identifier: Eng-CA Issued to: Eng-CA, Issued by: C = us, O = juniper, CN = Root-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(2048 bits)user@host> show security pki ca-certificate ca-profile Dev-CA Certificate identifier: Dev-CA Issued to: Dev-CA, Issued by: C = us, O = juniper, CN = Eng-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(2048 bits)Compruebe la validez de los certificados de CA inscritos.
user@host> request security pki ca-certificate verify ca-profile Root-CA CA certificate Root-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Eng-CA CA certificate Eng-CA verified successfully
user@host> request security pki ca-certificate verify ca-profile Dev-CA CA certificate Dev-CA verified successfully
Inscribir el certificado local.
user@host> request security pki local-certificate enroll certificate-id Host-A ca-profile Dev-CA challenge-password juniper domain-name host-a.company.net email host-a@company.net subject DC=juniper,CN=Host-A, OU=DEV,O=PKI,L=Sunnyvale,ST=CA,C=US
Compruebe que el certificado local está inscrito en el dispositivo.
user@host> show security pki local-certificate Issued to: Host-A, Issued by: C = us, O = juniper, CN = Dev-CA Validity: Not before: 07- 3-2015 10:54 UTC Not after: 07- 1-2020 10:54 UTC Public key algorithm: rsaEncryption(1024 bits)Compruebe la validez del certificado local inscrito.
user@host> request security pki local-certificate verify certificate-id Host-A Local certificate Host-A verification success
Compruebe si hay perfiles de CA configurados en la descarga de CRL.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Root-CA Effective date: 09- 9-2015 13:08 Next update: 09-21-2015 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Eng-CA Effective date: 08-22-2015 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Dev-CA Effective date: 09-14-2015 21:15 Next update: 09-26-2012 11:02
Configurar las opciones de VPN IPsec
Configuración rápida de CLI
Para configurar rápidamente las opciones de VPN IPsec, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red, copie y pegue los comandos en la CLI en el nivel de jerarquía y, a continuación, ingrese commit desde el [edit] modo de configuración.
set services ipsec-vpn ike proposal ike_cert_prop_01 authentication-method rsa-signatures set services ipsec-vpn ike proposal ike_cert_prop_01 dh-group group5 set services ipsec-vpn ike proposal ike_cert_prop_01 authentication-algorithm sha1 set services ipsec-vpn ike proposal ike_cert_prop_01 encryption-algorithm aes-256-cbc set services ipsec-vpn ike policy ike_cert_pol_01 mode main set services ipsec-vpn ike policy ike_cert_pol_01 proposals ike_cert_prop_01 set services ipsec-vpn ike policy ike_cert_pol_01 certificate local-certificate Host-A set services ipsec-vpn ipsec proposal ipsec_prop_01 protocol esp set services ipsec-vpn ipsec proposal ipsec_prop_01 authentication-algorithm hmac-sha1-96 set services ipsec-vpn ipsec proposal ipsec_prop_01 encryption-algorithm 3des-cbc set services ipsec-vpn ipsec proposal ipsec_prop_01 lifetime-seconds 300 set services ipsec-vpn ipsec policy ipsec_pol_01 proposals ipsec_prop_01 set services ipsec-vpn ipsec vpn ipsec_cert_vpn_01 ike ipsec-policy ipsec_pol_01
Procedimiento paso a paso
En el ejemplo siguiente es necesario navegar por 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 de la Guía del usuario de CLI.
Para configurar las opciones de VPN IPsec:
Configure las opciones de la fase 1.
[edit services ipsec-vpn ike proposal ike_cert_prop_01] user@host# set authentication-method rsa-signatures user@host# set dh-group group5 user@host# set authentication-algorithm sha1 user@host# set encryption-algorithm aes-256-cbc [edit services ipsec-vpn ike policy ike_cert_pol_01] user@host# set mode main user@host# set proposals ike_cert_prop_01 user@host# set certificate local-certificate Host-A
Configure las opciones de la fase 2.
[edit services ipsec-vpn ipsec proposal ipsec_prop_01] user@host# set protocol esp user@host# set authentication-algorithm hmac-sha1-96 user@host# set encryption-algorithm 3des-cbc user@host# set lifetime-seconds 300 [edit services ipsec-vpn ipsec policy ipsec_pol_01] user@host# set proposals ipsec_prop_01 [edit services ipsec-vpn ipsec vpn ipsec_cert_vpn_01] user@host# set ike ipsec-policy ipsec_pol_01
Resultados
Desde el modo de configuración, escriba los show security ike comandos y show security ipsec para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de configuración en este ejemplo para corregirla.
[edit]
user@host# show services ipsec-vpn ike
proposal ike_cert_prop_01 {
authentication-method rsa-signatures;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike_cert_pol_01 {
mode main;
proposals ike_cert_prop_01;
certificate {
local-certificate Host-A;
}
}
[edit]
user@host# show services ipsec-vpn ipsec
proposal ipsec_prop_01 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 300;
}
policy ipsec_pol_01 {
proposals ipsec_prop_01;
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Si la validación del certificado se realiza correctamente durante la negociación de IKE entre dispositivos pares, se establecerán tanto IKE como SA de IPsec.
Verificación del estado de la fase 1 de IKE
Propósito
Verifique el estado de la fase 1 de IKE.
Acción
Ingrese el show services ipsec-vpn ike security-associations comando desde el modo operativo.
user@host> show services ipsec-vpn ike security-associations Remote Address State Initiator cookie Responder cookie Exchange type 192.0.2.0 Matured 63b3445edda507fb 2715ee5895ed244d Main
Comprobar el estado de fase 2 de IPsec
Propósito
Compruebe el estado de fase 2 de IPsec.
Acción
Ingrese el show services ipsec-vpn ipsec security-associations comando desde el modo operativo.
user@host> show services ipsec-vpn ipsec security-associations
Service set: ips_ss1, IKE Routing-instance: default
Rule: vpn_rule_ms_2_2_01, Term: term11, Tunnel index: 1
Local gateway: 10.0.1.2, Remote gateway: 172.16.0.0
IPSec inside interface: ms-2/2/0.1, Tunnel MTU: 1500
UDP encapsulate: Disabled, UDP Destination port: 0
Direction SPI AUX-SPI Mode Type Protocol
inbound 2151932129 0 tunnel dynamic ESP
outbound 4169263669 0 tunnel dynamic ESP
Error de IKE y SA IPsec para un certificado revocado
Comprobación de certificados revocados
Problema
Si se produce un error en la validación del certificado durante la negociación de IKE entre dispositivos del mismo nivel, asegúrese de que el certificado del mismo nivel no se haya revocado. Un perfil de CA dinámico permite que el dispositivo local descargue la CRL de la CA del mismo nivel y compruebe el estado de revocación del certificado del par. Para habilitar los perfiles de CA dinámicos, la opción debe configurarse en un perfil de revocation-check crl CA primario.
Solución
Para comprobar el estado de revocación del certificado de un par:
Identifique el perfil de CA dinámico que mostrará la CRL para el dispositivo par ingresando el comando desde el show security pki crl modo operativo.
user@host> show security pki crl CA profile: Root-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Root-CA Effective date: 09- 9-2012 13:08 Next update: 09-21-2012 02:55 CA profile: Eng-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Eng-CA Effective date: 08-22-2012 17:46 Next update: 10-24-2015 03:33 CA profile: Dev-CA CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Dev-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02 CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Sales-CA Effective date: 09-14-2012 21:15 Next update: 09-26-2012 11:02El perfil
dynamic-001de CA se crea automáticamente en el host A para que el host A pueda descargar la CRL de la CA del host B (Sales-CA) y comprobar el estado de revocación del certificado del par.Para mostrar la información de CRL para el perfil de CA dinámico, ingrese el show security pki crl ca-profile dynamic-001 detail comando desde el modo operativo.
Entrar
user@host> show security pki crl ca-profile dynamic-001 detail CA profile: dynamic-001 CRL version: V00000001 CRL issuer: C = us, O = juniper, CN = Sub11 Effective date: 09-19-2012 17:29 Next update: 09-20-2012 01:49 Revocation List: Serial number Revocation date 10647C84 09-19-2012 17:29 UTCEl certificado del host B (número de serie 10647084) ha sido revocado.
Configurar la captura de caducidad del certificado
Antes de empezar:
Comprender cómo funcionan los certificados en VPN. Lea Descripción de las cadenas de certificados.
En este tema se muestra cómo configurar la captura de expiración de certificados y cómo configurar el número de días antes de generar la captura.
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.