Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Revocación de certificados

Los certificados digitales tienen una fecha de vencimiento, sin embargo, antes de la expiración, es posible que un certificado deje de ser válido debido a muchas razones. Puede administrar las revocaciones y validaciones de certificados localmente y haciendo referencia a una lista de revocación de certificados de autoridad de certificación (CA).

Descripción del protocolo de estado de certificado en línea y las listas de revocación de certificados

OCSP se utiliza para comprobar el estado de revocación de los certificados X509. OCSP proporciona estado de revocación en certificados en tiempo real y es útil en situaciones sensibles al tiempo, como transacciones bancarias y operaciones de acciones.

El estado de revocación de un certificado se comprueba mediante el envío de una solicitud a un servidor OCSP que reside fuera de un dispositivo de la serie SRX. Según la respuesta del servidor, se permite o se niega la conexión VPN. Las respuestas OCSP no se almacenan en memoria caché en dispositivos de la serie SRX.

El servidor OCSP puede ser la autoridad de certificación (CA) que emite un certificado o un respondedor autorizado designado. La ubicación del servidor OCSP se puede configurar manualmente o extraer del certificado que se está verificando. Las solicitudes se envían primero a ubicaciones de servidor OCSP configuradas manualmente en perfiles de CA con la ocsp url instrucción en el nivel de jerarquía [edit security pki ca-profile profile-name revocation-check]; se pueden configurar hasta dos ubicaciones para cada perfil de CA. Si no se puede acceder al primer servidor OCSP configurado, la solicitud se envía al segundo servidor OCSP. Si el segundo servidor OCSP no es accesible, la solicitud se envía a la ubicación en el campo de extensión AuthorityInfoAccess del certificado. La use-ocsp opción también debe configurarse, ya que la lista de revocación de certificados (CRL) es el método de comprobación predeterminado.

Los dispositivos de la serie SRX solo aceptan respuestas OCSP firmadas de la CA o del respondedor autorizado. La respuesta recibida se valida mediante certificados de confianza. La respuesta se valida de la siguiente manera:

  1. El certificado de CA inscrito para el perfil de CA configurado se usa para validar la respuesta.

  2. La respuesta OCSP puede contener un certificado para validar la respuesta OCSP. El certificado recibido debe estar firmado por un certificado de CA inscrito en el dispositivo de la serie SRX. Después de que el certificado recibido sea validado por el certificado de CA, se usa para validar la respuesta OCSP.

La respuesta del servidor OCSP puede estar firmada por diferentes CA. Se admiten los siguientes escenarios:

  • El servidor de CA que emite el certificado de entidad final para un dispositivo también firma la respuesta de estado de revocación OCSP. El dispositivo de la serie SRX verifica la firma de respuesta OCSP mediante el certificado de CA inscrito en el dispositivo de la serie SRX. Después de validar la respuesta OCSP, se comprueba el estado de revocación del certificado.

  • Un respondedor autorizado firma la respuesta de estado de revocación OCSP. El certificado para el respondedor autorizado y el certificado de entidad final que se está verificando debe ser emitido por la misma CA. El respondedor autorizado se verifica primero mediante el certificado de CA inscrito en el dispositivo de la serie SRX. La respuesta OCSP se valida mediante el certificado de CA del respondedor. A continuación, el dispositivo de la serie SRX utiliza la respuesta OCSP para comprobar el estado de revocación del certificado de entidad final.

  • Hay diferentes firmantes de CA para el certificado de entidad final que se está verificando y la respuesta OCSP. La respuesta OCSP está firmada por una CA en la cadena de certificados para el certificado de entidad final que se está verificando. (Todos los pares que participen en una negociación de ICR deben tener al menos una CA de confianza común en sus respectivas cadenas de certificados.) La CA del respondedor OCSP se verifica mediante una CA en la cadena de certificados. Después de validar el certificado de CA del respondedor, la respuesta OCSP se valida mediante el certificado de CA del respondedor.

Para evitar ataques de reproducción, se puede enviar una carga de nonce en una solicitud OCSP. Las cargas de Nonce se envían de forma predeterminada, a menos que estén deshabilitadas explícitamente. Si está habilitado, el dispositivo de la serie SRX espera que la respuesta OCSP contenga una carga de nonce, de lo contrario, se producirá un error en la comprobación de revocación. Si los respondedores OCSP no son capaces de responder con una carga de nonce, la carga de nonce debe deshabilitarse en el dispositivo de la serie SRX.

En el curso normal de los negocios, los certificados se revocan por diversas razones. Es posible que desee revocar un certificado si sospecha que se ha visto comprometido, por ejemplo, o cuando un titular de certificado abandona la empresa.

Puede administrar revocaciones y validaciones de certificados de dos maneras:

  • Localmente: esta es una solución limitada.

  • Al hacer referencia a una lista de revocación de certificados (CRL) de autoridad de certificación (CA): puede acceder automáticamente a la CRL en línea a intervalos que especifique o en el intervalo predeterminado establecido por la CA.

En las negociaciones de fase 1, el dispositivo de la serie SRX verifica el certificado EE recibido del par durante un intercambio IKE y utiliza la CRL para asegurarse de que su CA no revoque el certificado EE.

Si no se carga una CRL en el dispositivo y el emisor del certificado par es una CA de confianza:

  1. Junos OS recupera la CRL mediante las ubicaciones LDAP o HTTP CRL configuradas (es decir, los puntos de distribución CRL (CDP)), si se definen en el perfil de CA.
  2. Si los puntos de distribución CRL no están configurados en el perfil de CA, el dispositivo utiliza la extensión CDP en un certificado emitido por la CA (si está presente). El certificado emitido por la CA puede ser un certificado inscrito por el administrador o recibido durante la negociación de fase 1.

Si una CA raíz no emite el certificado EE, los certificados de cada CA intermedia pasan por la misma comprobación y revocación. La CRL de la CA raíz se utiliza para comprobar si se revoca el certificado emitido por la CA raíz. Si el CDP no está configurado en el perfil de CA raíz, el dispositivo utiliza la extensión CDP en el certificado emitido por la CA (si está presente).

La extensión del punto de distribución CRL (.cdp) en un certificado X509 se puede agregar a una URL HTTP o a una URL LDAP.

Si el certificado no contiene una extensión de punto de distribución de certificado y no puede recuperar automáticamente la CRL mediante el protocolo ligero de acceso a directorios (LDAP) o el protocolo de transferencia de hipertexto (HTTP), puede recuperar una CRL manualmente y cargarla en el dispositivo.

Los certificados locales se validan con la lista de revocación de certificados (CRL) incluso cuando la comprobación de CRL está deshabilitada. Esto se puede detener deshabilitando la comprobación de CRL mediante la configuración de infraestructura de clave pública (PKI). Cuando la comprobación de CRL está deshabilitada, la PKI no validará el certificado local con CRL.

Comparación del protocolo de estado de certificado en línea y la lista de revocación de certificados

El protocolo de estado de certificado en línea (OCSP) y la lista de revocación de certificados (CRL) se pueden usar para comprobar el estado de revocación de un certificado. Cada método tiene ventajas y desventajas.

  • OCSP proporciona estado de certificado en tiempo real, mientras que CRL utiliza datos almacenados en caché. Para aplicaciones sensibles al tiempo, OCSP es el enfoque preferido.

  • La comprobación de CRL es más rápida porque la búsqueda del estado del certificado se realiza en la información almacenada en caché en el dispositivo VPN. OCSP requiere tiempo para obtener el estado de revocación de un servidor externo.

  • CRL requiere memoria adicional para almacenar la lista de revocación recibida de un servidor CRL. OCSP no requiere memoria adicional para guardar el estado de revocación de certificados.

  • OCSP requiere que el servidor OCSP esté disponible en todo momento. CRL puede usar datos almacenados en memoria caché para comprobar el estado de revocación de certificados cuando el servidor no es accesible.

En los dispositivos serie MX y SRX, CRL es el método predeterminado que se usa para comprobar el estado de revocación de un certificado.

Ejemplo: Carga manual de una CRL en el dispositivo

En este ejemplo, se muestra cómo cargar una CRL manualmente en el dispositivo.

Requisitos

Antes de comenzar:

  1. Genere un par de claves públicas y privadas. Consulte Certificados digitales autofirmados.

  2. Generar una solicitud de certificado. Consulte Ejemplo: Generar manualmente una CSR para el certificado local y enviarlo al servidor de CA.

  3. Configure un perfil de autoridad de certificación (CA). Consulte Ejemplo: Configuración de un perfil de CA.

  4. Cargue el certificado en el dispositivo. Consulte Ejemplo: Carga manual de certificados de CA y locales.

Descripción general

Puede cargar una CRL manualmente o puede hacer que el dispositivo la cargue automáticamente cuando verifique la validez del certificado. Para cargar una CRL manualmente, puede obtener la CRL de una CA y transferirla al dispositivo (por ejemplo, mediante FTP).

En este ejemplo, cargará un certificado CRL llamado revoke.crl desde el directorio /var/tmp en el dispositivo. El perfil de CA se llama ca-profile-ipsec. (El tamaño máximo de archivo es de 5 MB.)

Si ya se ha cargado una CRL en el perfil de ca, el comando clear security pki crl ca-profile ca-profile-ipsec debe ejecutarse primero para borrar la CRL antigua.

Configuración

Procedimiento

Procedimiento paso a paso

Para cargar un certificado CRL manualmente:

  1. Cargue un certificado CRL.

    Junos OS admite la carga de certificados de CA en formatos X509, PKCS n.º 7, DER o PEM.

Verificación

Para comprobar que la configuración funciona correctamente, ingrese el comando del show security pki crl modo operativo.

Descripción de la descarga y comprobación dinámicas de CRL

Los certificados digitales se emiten durante un período de tiempo establecido y no son válidos después de la fecha de vencimiento especificada. Una ENTIDAD de certificación puede revocar un certificado emitido enumerandolo en una lista de revocación de certificados (CRL). Durante la validación del certificado par, el estado de revocación de un certificado par se comprueba descargando la CRL de un servidor de CA al dispositivo local.

Para facilitar la comprobación de CRL para los certificados cuando no se configura un perfil de CA, se crea un perfil de CA dinámico. Un perfil de CA dinámico se crea automáticamente en el dispositivo local con el formato dynamic-nnn.

Un perfil de CA dinámico:

  • Permite que el dispositivo local descargue la CA dinámica y la CRL dinámica (para ca correspondiente) según el emisor de localcert del par
  • Comprueba el estado de revocación del certificado del par

Un dispositivo VPN comprueba el estado de revocación del certificado EE de un par. Un dispositivo VPN utiliza el certificado recibido de su par para hacer lo siguiente:

  • Extraiga la URL para descargar dinámicamente la CRL de la CA
  • Compruebe el estado de revocación del certificado EE del par

En Figura 1, host-A puede usar los certificados de VENTAS-CA y EE recibidos del Host-B para descargar dinámicamente la CRL para Sales-CA y comprobar el estado de revocación del certificado del Host-B.

Figura 1: Jerarquía multinivel para autenticación basada en certificados Jerarquía multinivel para autenticación basada en certificados

En caso de servidores de CA de jerarquía única o cadena de certificados de CA, el certificado EE local y el certificado de EE par recibido se emiten desde el mismo servidor de CA.

A continuación, se muestran algunos de los comportamientos del dispositivo serie SRX según diferentes configuraciones:

  • Si configuró un dispositivo de la serie SRX con un grupo de confianza o de confianza,entonces el dispositivo no valida ni confía en ninguna otra CA.
  • Si ha definido un perfil de CA que tiene una cadena de CA en la que el dispositivo de la serie SRX solo confía en la CA raíz y el par tiene un certificado firmado por una sub CA a esta raíz, a continuación, se agregará ca dinámica y CRL al dispositivo.

Tabla 1 ofrece algunos escenarios de ejemplo en los que no se crea una CA o CRL dinámicas:

Tabla 1: Escenarios de ejemplo

Escenario

Condición

Escenario de ejemplo 1

En el perfil de CA, ha definido una CA de confianza para el nombre-perfil de ca y recibe una conexión de un dispositivo que tiene un certificado firmado por una CA diferente que no se definió como una CA de confianza en su perfil de CA.

Ejemplo de escenario 2

Ha definido un perfil de CA que tiene una cadena de CA donde el dispositivo de la serie SRX solo confía en una sub CA, y el par tiene un certificado firmado por un nivel por encima de esta sub CA.

Para habilitar perfiles de CA dinámicos, debe configurar la revocation-check crl opción en un perfil de CA raíz en el nivel de jerarquía [edit security pki ca-profile profile-name].

Las propiedades de comprobación de revocación de un perfil de RAÍZ-CA se heredan para perfiles de CA dinámicos. En Figura 1, la configuración del perfil de CA en host-A para raíz-CA habilita perfiles de CA dinámicos como se muestra en el siguiente resultado:

Se crea un perfil de CA dinámico en Host-A para Sales-CA. La comprobación de revocación se hereda para el perfil de CA dinámico de CA de ca de raíz.

Si la revocation-check disable instrucción está configurada en un perfil de raíz-CA, no se crean perfiles de CA dinámicos y no se realiza la descarga y comprobación dinámicas de CRL.

Los datos de las CRLs descargadas desde perfiles de CA dinámicos se muestran con el comando del show security pki crl mismo modo que las CRLs descargadas por los perfiles de CA configurados. La CRL de un perfil de CA dinámico se actualiza periódicamente, al igual que las de los perfiles de CA configurados en el dispositivo. El certificado de CA par también es necesario para la validación de firma de CRL descargada del servidor de CA.

El certificado de CA es necesario para validar la CRL recibida de un servidor de CA; por lo tanto, el certificado de CA recibido de un par se almacena en el dispositivo local. El certificado de CA recibido del par se utiliza para validar la CRL y el certificado que emitió. Dado que el certificado de CA recibido no está inscrito por un administrador, el resultado de una verificación de certificado correcta no es concluyente hasta que se verifica toda la cadena de certificados hasta la CA raíz. El certificado de la CA raíz debe estar inscrito por un administrador.

Ejemplo: Configuración de un perfil de autoridad de certificación con ubicaciones CRL

En este ejemplo, se muestra cómo configurar un perfil de autoridad de certificación con ubicaciones CRL.

Requisitos

Antes de comenzar:

  1. Genere un par de claves en el dispositivo. Consulte Certificados digitales.

  2. Cree un perfil o perfiles de CA que contengan información específica de una CA. Consulte Ejemplo: Configuración de un perfil de CA.

  3. Obtenga un certificado personal de la CA. Consulte Ejemplo: Generar manualmente una CSR para el certificado local y enviarlo al servidor de CA.

  4. Cargue el certificado en el dispositivo. Consulte Ejemplo: Carga manual de certificados de CA y locales.

  5. Configure la reinscripción automática. Consulte Ejemplo: Configuración de autenticación de usuario SecurID.

  6. Si es necesario, cargue la CRL del certificado en el dispositivo. Consulte Ejemplo: Cargar manualmente una CRL en el dispositivo.

Descripción general

En este ejemplo, usted dirige al dispositivo para comprobar la validez del perfil de CA llamado my_profile y, si una CRL no acompaña a un certificado de CA y no se carga en el dispositivo, para recuperar la CRL de la URL http://abc/abc-crl.crl.

Configuración

Procedimiento

Procedimiento paso a paso

Para configurar el certificado mediante CRL:

  1. Especifique el perfil y la DIRECCIÓN URL de CA.

  2. Si ha terminado de configurar el dispositivo, confirme la configuración.

Verificación

Para comprobar que la configuración funciona correctamente, ingrese el comando del show security pki modo operativo.

Ejemplo: Verificar la validez del certificado

En este ejemplo, se muestra cómo comprobar la validez de un certificado.

Requisitos

No se requiere ninguna configuración especial más allá de la inicialización del dispositivo antes de configurar esta función.

Descripción general

En este ejemplo, comprobará los certificados manualmente para averiguar si se revocó un certificado o si el certificado de CA usado para crear un certificado local ya no está presente en el dispositivo.

Cuando se verifican certificados manualmente, el dispositivo utiliza el certificado de CA (ca-cert) para comprobar el certificado local ( local.cert). Si el certificado local es válido y si revocation-check está habilitado en el perfil de CA, el dispositivo verifica que la CRL esté cargada y sea válida. Si la CRL no está cargada y es válida, el dispositivo descarga la nueva CRL.

Para certificados emitidos por CA o certificados de CA, se debe configurar un DNS en la configuración del dispositivo. El DNS debe ser capaz de resolver el host en la CRL de distribución y en la url de lista de certificados/revocación de CA en la configuración del perfil de ca. Además, debe tener accesibilidad de red al mismo host para que se reciban las comprobaciones.

Configuración

Procedimiento

Procedimiento paso a paso

Para comprobar manualmente la validez de un certificado:

  1. Compruebe la validez de un certificado local.

  2. Verifique la validez de un certificado de CA.

    También se verifica la clave privada asociada y la firma.

Verificación

Para comprobar que la configuración funciona correctamente, escriba el show security pki ca-profile comando.

Si se devuelve un error en lugar de una verificación positiva, el error se registra en pkid.

Eliminación de una CRL cargada (procedimiento de CLI)

Puede eliminar una CRL cargada si ya no necesita usarla para administrar las revocaciones y validación de certificados.

Utilice el siguiente comando para eliminar una lista de revocación de certificados cargada:

Especifique un perfil de CA para eliminar una CRL asociada con la CA identificada por el perfil, o use all para eliminar todas las CRL.