EN ESTA PÁGINA
Información general sobre la administración de certificados
En este tema se incluyen las siguientes secciones:
Información general sobre el uso de métodos SSL e IPsec/IKE
Actualmente, Junos OS solo admite el método de seguridad IP/Intercambio de claves por Internet (IPsec/IKE) para usar certificados para la validación de claves públicas y el enlace de identidad.
En la tabla 1 se compara la autenticación mediante el método SSL y el método IPsec/IKE.
Implementación de SSL |
Implementación de IPsec/IKE |
|---|---|
El proceso es unilateral y simple. |
El proceso es bidireccional y utiliza certificados. |
El dispositivo de seguridad actúa como un servidor SSL y el navegador web del administrador (o para webauth, el navegador web del usuario) actúa como cliente SSL. |
Cada dispositivo VPN envía su certificado al otro dispositivo. |
El dispositivo de seguridad envía un certificado al navegador web para su identificación, y el navegador web inicia una sesión SSL segura. |
Cada dispositivo IPsec valida el certificado del otro dispositivo mediante el certificado de entidad de certificación (CA). |
El dispositivo de seguridad autentica al usuario o administrador mediante un nombre de usuario y una contraseña (protegidos con cifrado SSL). |
El dispositivo de seguridad comprueba el certificado del otro dispositivo a través de una lista de revocación de certificados (CRL) para ver si se ha revocado. |
El dispositivo de seguridad no requiere un certificado SSL basado en el usuario del explorador web y no necesita CA ni CRL cargadas en él. |
Los elementos PKI mínimos necesarios para usar la autenticación basada en certificados son: un certificado local, un certificado de CA y la CRL de la CA. |
Proceso para configurar los elementos de PKI
Los elementos mínimos de infraestructura de clave pública (PKI) necesarios para la autenticación basada en certificados en Junos OS son un certificado local, un certificado de entidad de certificación (CA) y la lista de revocación de certificados (CRL) de la CA.
Para cargar manualmente un certificado local, un certificado de CA y la CRL de CA en el dispositivo:
Configure los ajustes básicos del dispositivo según lo requiera PKI:
Establezca el reloj preciso, la fecha, la zona horaria y el horario de verano.
Establezca el Sistema de nombres de dominio (DNS) para resolver los nombres de host que se pueden usar en certificados y para puntos de distribución de CRL (CDP).
Establezca el Protocolo de tiempo de red (NTP) para mantener una sincronización precisa, ya que los certificados tienen una duración basada en una fecha y hora específicas.
Cree un perfil de CA para la solicitud de certificado y el proceso de inscripción.
Genere la solicitud de certificado (archivo p10) y guárdela en un sistema de archivos local o envíela por correo electrónico.
Envíe el archivo p10 a la CA (a través de un servidor web que actúe como front-end de la CA. Tenga en cuenta que una CA SSL abierta solo admite la interfaz de línea de comandos).
Recupere el certificado de CA (a través de la interfaz front-end del servidor web de CA).
Recupere el nuevo certificado local del dispositivo Junos OS después de que la CA lo haya verificado (normalmente a través de la interfaz front-end del servidor web de CA).
Recupere la CA CRL (mediante una URL preespecificada al servidor web de CA).
Cargue el certificado de CA, el certificado local y la CRL en el dispositivo Junos OS.
Defina la política y la puerta de enlace de IKE para utilizar el método de autenticación RSA-Signature (en lugar de las claves previamente compartidas) y los certificados locales y de CA.
La desventaja de la carga manual de certificados y CRL es el tiempo y el esfuerzo adicionales necesarios para mantener una CRL actualizada en todos los dispositivos.
Como alternativa, puede definir un CDP para que el dispositivo Junos OS recupere automáticamente las CRL más recientes. La mayoría de las CA tienen el CDP definido en el propio certificado de CA, que el dispositivo Junos OS puede usar automáticamente. También puede definir el CDP en la configuración del perfil de CA.
Para obtener más información sobre los certificados, consulte la documentación de Junos OS en https://www.juniper.net/documentation/software/junos/.
Elegir la identidad de IKE que se utilizará en la VPN y el certificado
Junos OS admite los siguientes cuatro tipos de ID de Intercambio de claves por Internet (IKE) que las puertas de enlace de red privada virtual (VPN) pueden usar para identificarse entre sí:
Dirección IP (ejemplo: 2.2.2.2)
Nombre de dominio completo (FQDN) (ejemplo: vpn1.juniper.net)
Nombre de dominio completo del usuario (U-FQDN) o dirección de correo electrónico (ejemplo: johndoe@juniper.net)
Nombre distintivo (DN) (ejemplo: CN=John Doe, OU=ventas, O=Juniper Networks, C=US)
Al configurar claves previamente compartidas, solo se utilizan la dirección IP, el FQDN y la dirección U-FQDN/correo electrónico.
Si utiliza una dirección IP, FQDN o U-FQDN/dirección de correo electrónico como tipo de ID de IKE, entonces:
Debe definirse en el
SubjectAlternativeNamecampo del certificadoDebe coincidir con la configuración del mismo nivel en la
security ike gateway <gateway-name>jerarquía
Debe definir al menos una dirección IP, FQDN o U-FQDN/dirección de correo electrónico al generar una solicitud de certificado.
Si sus certificados no tienen un SubjectAlternativeName campo, debe usar DN para el ID de IKE. Para utilizar DN, debe definir un nombre distintivo en la configuración dinámica de IKE especificando un contenedor (el DN debe coincidir exactamente) o un comodín (solo una parte del DN debe coincidir).
A continuación se muestran las diferencias entre el método contenedor y el método comodín:
Si se utiliza la palabra clave contenedor, todos los valores DN especificados deben coincidir exactamente con los valores del certificado recibido. Además, el orden de los valores tanto en el certificado remoto recibido como en la definición de puerta de enlace debe coincidir.
Si se utiliza la palabra clave comodín, cualquiera de los valores DN especificados debe coincidir con un valor DN del certificado recibido. El orden de los valores en el certificado remoto recibido y en la definición de puerta de enlace puede ser diferente. El dispositivo Junos OS analiza y compara solo los campos DN definidos; se omiten los campos DN no especificados.
Si el certificado utiliza varios campos del mismo tipo (por ejemplo: OU=ventas, OU=engr, OU=central), debe utilizar el método contenedor y asegurarse de que los campos DN se definen exactamente como los recibe el par remoto.
Validación de certificados durante la configuración de la fase 1 de IKE
Durante el intercambio de claves por Internet (IKE), cuando dos pares VPN establecen un túnel, cada dispositivo VPN recibe un certificado del otro par IKE. Al recibir los certificados, el dispositivo completa las siguientes tareas:
Extrae el ID de IKE (definido en la fase 1 de IKE) del par y busca la definición de IKE correspondiente en la puerta de enlace.
Valida el certificado verificando la firma digital en el certificado de dispositivo remoto mediante la clave pública del certificado de entidad emisora de certificados (CA).
Valida la hora actual mencionada en los certificados en los campos "Válido desde" y "Válido para".
Valida que el certificado contenga la identidad del par remoto.
Realiza la comprobación de revocación (a menos que la comprobación de revocación esté deshabilitada) en el certificado para asegurarse de que el número de serie del certificado no está en la lista de revocación de certificados (CRL) de CA. Esto puede hacer que el dispositivo Junos OS recupere automáticamente una nueva CRL del CDP.
Cuando todas las comprobaciones de certificados se completen correctamente, IKE continuará con la configuración del túnel.
A menos que se deshabilite explícitamente en la configuración, las CRL se comprueban siempre que el dispositivo Junos OS reciba un certificado para una puerta de enlace VPN remota. Si la CRL no se carga manualmente, el sistema puede:
Cargue la CRL desde el punto de distribución de CRL (CDP) definido en el certificado. Los dispositivos Junos OS admiten HTTP y Protocolo ligero de acceso a directorios (LDAP) para CDP.
Si el CDP no está disponible en el certificado, el dispositivo Junos OS busca una configuración de CDP en el perfil de CA.
Utilice el CDP global o predeterminado (si ya está configurado).
Al verificar un certificado, una cadena de certificados se forma a partir de lo siguiente:
Certificado local del servidor remoto
Cadena de certificados opcional del par IKE
Certificados de CA almacenados localmente
Cualquier certificado de CA cargado desde el almacenamiento local durante el arranque se considera certificado "de confianza". Junos OS admite la validación de rutas de certificados hacia arriba a través de hasta siete niveles de autoridades de CA en la jerarquía.
Actualmente, Junos OS solo admite la validación "parcial" de rutas de certificados. A diferencia de la validación de ruta de certificado "completa", la validación "parcial" no requiere que el último certificado de la cadena de certificados sea un certificado de CA raíz (una CA autofirmada). Con la validación de ruta de certificado "parcial", el último certificado puede ser un certificado de CA no raíz. Sin embargo, el último certificado de la cadena de validación debe ser de almacenamiento local.
Protocolos PKI no compatibles en Junos OS
Junos OS no admite los siguientes protocolos de infraestructura de clave pública (PKI), que son principalmente formas alternativas de protocolos de administración para la comunicación entre CA y entidades que usan certificados:
CMC: administración de certificados de mensajes a través de CMS definida en RFC 2797.
CMC está respaldado por Microsoft y VeriSign, pero tiene soporte limitado de otros productos.
CMP: protocolo de administración de certificados definido en RFC 2510.
CMP está respaldado por Entrust, Baltimore, SSH, RSA y OpenSSL. Aunque este protocolo funciona, tiene una implementación e interoperabilidad limitadas con otras interfaces de diferentes proveedores.
XKMS: las especificaciones de administración de claves XML se definen en http://www.w3.org/TR/xkms/.
XKMS es un protocolo relativamente nuevo que actualmente no es compatible con Juniper Networks.