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 caducidad, sin embargo, antes de la expiración, es posible que un certificado ya no sea 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 (CRL) de entidad de certificación (CA).

Descripción del protocolo de estado de certificados 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 el estado de revocación de los certificados en tiempo real y es útil en situaciones sensibles al tiempo, como transacciones bancarias y operaciones bursátiles.

El estado de revocación de un certificado se comprueba enviando una solicitud a un servidor OCSP que resida fuera de un firewall de la serie SRX. Según la respuesta del servidor, la conexión VPN está permitida o denegada. Las respuestas OCSP no se almacenan en caché en los firewalls 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 las ubicaciones de servidor OCSP que se configuran manualmente en perfiles de CA con la instrucción en el nivel de jerarquía []; se pueden configurar hasta dos ubicaciones para cada perfil de CA.ocsp urledit security pki ca-profile profile-name revocation-check Si no se puede acceder al primer servidor OCSP configurado, la solicitud se envía al segundo servidor OCSP. Si no se puede acceder al segundo servidor OCSP, la solicitud se envía a la ubicación en el campo de extensión AuthorityInfoAccess del certificado. La opción también debe estar configurada, ya que la lista de revocación de certificados (CRL) es el método de comprobación predeterminado.use-ocsp

Los firewalls 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 firewall de la serie SRX. Una vez validado el certificado de CA el certificado recibido, se utiliza para validar la respuesta OCSP.

La respuesta del servidor OCSP puede ser 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 del OCSP. El firewall de la serie SRX verifica la firma de respuesta OCSP mediante el certificado de CA inscrito en el firewall de la serie SRX. Una vez validada la respuesta OCSP, se comprueba el estado de revocación del certificado.

  • Un respondedor autorizado firma la respuesta de estado de revocación de OCSP. El certificado para el respondedor autorizado y el certificado de entidad final que se está verificando deben ser emitidos por la misma CA. El respondedor autorizado se verifica primero mediante el certificado de CA inscrito en el firewall de la serie SRX. La respuesta OCSP se valida mediante el certificado de CA del respondedor. A continuación, el firewall 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 participan en una negociación de IKE deben tener al menos una CA de confianza común en sus respectivas cadenas de certificados). La CA del respondedor OCSP se comprueba mediante una CA de 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 nonce en una solicitud OCSP. Las cargas Nonce se envían de forma predeterminada a menos que estén deshabilitadas explícitamente. Si está habilitado, el firewall de la serie SRX espera que la respuesta OCSP contenga una carga nonce; de lo contrario, se producirá un error en la comprobación de revocación. Si los respondedores de OCSP no son capaces de responder con una carga nonce, entonces la carga de nonce debe deshabilitarse en el firewall de la serie SRX.

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

Puede administrar las 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 entidad de certificación (CA): puede acceder automáticamente a la CRL en línea a los intervalos que especifique o en el intervalo predeterminado establecido por la CA.

En las negociaciones de fase 1, el firewall 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 del mismo nivel es una CA de confianza:

  1. Junos OS recupera la CRL a través de las ubicaciones LDAP o HTTP CRL configuradas (es decir, los puntos de distribución de CRL (CDP)), si están definidas en el perfil de CA.
  2. Si los puntos de distribución de 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 el certificado EE no es emitido por una CA raíz, los certificados de cada CA intermedia pasan por la misma comprobación de verificación y revocación. La CRL de la CA raíz se usa para comprobar si se ha revocado 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 de 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 a través del 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 a través de la configuración de infraestructura de clave pública (PKI). Cuando la comprobación de CRL está deshabilitada, 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. Hay ventajas y desventajas para cada método.

  • OCSP proporciona el estado del 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 los certificados.

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

En los firewalls 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 empezar:

  1. Generar un par de claves pública y privada. Consulte Certificados digitales autofirmados.

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

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

  4. Cargue su certificado en el dispositivo. Consulte Ejemplo: Cargar certificados locales y de CA manualmente.

Descripción general

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

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

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

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 #7, DER o PEM.

Verificación

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

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

Los certificados digitales se emiten por un período de tiempo determinado y no son válidos después de la fecha de caducidad especificada. Una CA puede revocar un certificado emitido incluyéndolo en una lista de revocación de certificados (CRL). Durante la validación del certificado del mismo nivel, el estado de revocación de un certificado del mismo nivel se comprueba descargando la CRL desde un servidor de CA al dispositivo local.

Para facilitar la comprobación de CRL de los certificados cuando no se configura un perfil de CA, se crea un perfil de CA dinámico. Se crea automáticamente un perfil de CA dinámico 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 la CA correspondiente) según el emisor 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 usa el certificado recibido de su par para hacer lo siguiente:

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

En , el host A puede utilizar los certificados Sales-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

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

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

A continuación se presentan algunos de los comportamientos del firewall de la serie SRX en función de diferentes configuraciones:

  • Si ha configurado un firewall de la serie SRX con una ca de confianza o un grupo de ca de confianza, 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 firewall de la serie SRX solo confía en la CA raíz y el par tiene un certificado firmado por una subCA para esta raíz, se agregarán CA y CRL dinámicas al dispositivo.

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

Tabla 1: Escenarios de ejemplo

Escenario

Condición

Ejemplo de escenario 1

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

Escenario de ejemplo 2

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

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

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

Se crea un perfil de CA dinámico en el host A para la CA de ventas. La comprobación de revocación se hereda del perfil de CA dinámica de la CA de ventas de la CA raíz.

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

Los datos de las CRL descargadas de los perfiles de CA dinámicos se muestran con el comando del mismo modo que los CRL descargados por los perfiles de CA configurados.show security pki crl La CRL de un perfil de CA dinámico se actualiza periódicamente, al igual que los perfiles de CA configurados en el dispositivo. El certificado de CA del mismo nivel también es necesario para la validación de la firma de la 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 usa para validar la CRL y el certificado que emitió. Dado que un administrador no inscribe el certificado de CA recibido, el resultado de una comprobación de certificado correcta no es concluyente hasta que se comprueba toda la cadena de certificados hasta la CA raíz. Un administrador debe inscribir el certificado de la CA raíz.

Ejemplo: Configuración de un perfil de entidad emisora de certificados con ubicaciones de CRL

En este ejemplo se muestra cómo configurar un perfil de entidad emisora de certificados con ubicaciones de CRL.

Requisitos

Antes de empezar:

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

  2. Cree uno o varios 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 enviarla al servidor de CA.

  4. Cargue el certificado en el dispositivo. Consulte Ejemplo: Cargar certificados locales y de CA manualmente.

  5. Configure la reinscripción automática. Consulte Ejemplo: Configuración de la autenticación de usuario de 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, se indica al dispositivo que compruebe la validez del perfil de CA al que se llama y, si una CRL no acompaña a un certificado de CA y no está cargada en el dispositivo, que recupere la CRL de la dirección URL.my_profile http://abc/abc-crl.crl

Configuración

Procedimiento

Procedimiento paso a paso

Para configurar el certificado mediante CRL:

  1. Especifique el perfil de CA y la URL.

  2. Cuando termine de configurar el dispositivo, confirme la configuración.

Verificación

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

Ejemplo: Verificar la validez del certificado

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

Requisitos

No se necesita 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, los certificados se verifican manualmente para averiguar si se ha revocado un certificado o si el certificado de CA utilizado para crear un certificado local ya no está presente en el dispositivo.

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

Para los certificados emitidos por CA o los certificados de CA, se debe configurar un DNS en la configuración del dispositivo. El DNS debe poder resolver el host en la CRL de distribución y en la dirección URL de la lista de revocaciones o certificados de CA en la configuración del perfil de ca. Además, debe tener acceso 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. Comprobar la validez de un certificado local.

  2. Compruebe la validez de un certificado de CA.

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

Verificación

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

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 la CLI)

Puede optar por eliminar una CRL cargada si ya no necesita usarla para administrar las revocaciones y la 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 a la CA identificada por el perfil o utilícelo para eliminar todas las CRL.all