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 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 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 use-ocsp 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.
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:
-
El certificado de CA inscrito para el perfil de CA configurado se usa para validar la respuesta.
-
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:
- 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.
- 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.
Consulte también
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:
Generar un par de claves pública y privada. Consulte Certificados digitales autofirmados.
Generar una solicitud de certificado. Consulte Ejemplo: Generar manualmente una CSR para el certificado local y enviarla al servidor de CA.
Configure un perfil de entidad de certificación (CA). Consulte Ejemplo: Configuración de un perfil de CA.
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 revoke.crl desde el directorio /var/tmp del dispositivo. 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 clear security pki crl ca-profile ca-profile-ipsec para borrar la CRL antigua.
Configuración
Procedimiento
Procedimiento paso a paso
Para cargar un certificado CRL manualmente:
Cargue un certificado CRL.
[edit] user@host> request security pki crl load ca-profile ca-profile-ipsec filename /var/tmp/revoke.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 show security pki crl modo operativo.
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 Figura 1, 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.
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:
|
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 revocation-check crl opción en un perfil de CA raíz en el nivel jerárquico [edit 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 Figura 1, 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:
admin@host-A# show security
pki {
ca-profile Root-CA {
ca-identity Root-CA;
enrollment {
url “www.example.net/scep/Root/”;
}
revocation-check {
crl;
}
}
}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 revocation-check disable 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.
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 show security pki crl perfiles de CA configurados. 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.
Consulte también
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:
Genere un par de claves en el dispositivo. Consulte Certificados digitales.
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.
Obtenga un certificado personal de la CA. Consulte Ejemplo: Generar manualmente una CSR para el certificado local y enviarla al servidor de CA.
Cargue el certificado en el dispositivo. Consulte Ejemplo: Cargar certificados locales y de CA manualmente.
Configure la reinscripción automática. Consulte Ejemplo: Configuración de la autenticación de usuario de SecurID.
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 my_profile 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 http://abc/abc-crl.crl.
Configuración
Procedimiento
Procedimiento paso a paso
Para configurar el certificado mediante CRL:
Especifique el perfil de CA y la URL.
[edit] user@host# set security pki ca-profile my_profile revocation-check crl url http://abc/abc-crl.crl
Cuando termine de configurar el dispositivo, confirme la configuración.
[edit] user@host# commit
Verificación
Para comprobar que la configuración funciona correctamente, introduzca 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 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 (ca-cert) para comprobar el certificado local ( local.cert). Si el certificado local es válido y está revocation-check habilitado en el perfil de CA, el dispositivo comprueba que la CRL está cargada y es válida. 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:
Comprobar la validez de un certificado local.
[edit] user@host> request security pki local-certificate verify certificate-id local.cert
Compruebe la validez de un certificado de CA.
[edit] user@host> request security pki ca-certificate verify ca-profile ca-profile-ipsec
También se verifican 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 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:
user@host> clear security pki crl ca-profile (ca-profile all)
Especifique un perfil de CA para eliminar una CRL asociada a la CA identificada por el perfil o utilícelo all para eliminar todas las CRL.