Castro

onal de la
dad
t NSE 4, NSE 5
7

DAP Y
ADIUS
ure Access
Contenido
1. LDAP............................................................................................................................................3
1.1. Directorio Árbol......................................................................................................................3
1.2. Asociación Simple.................................................................................................................3
1.3. Flujo Asociación Simple........................................................................................................4
1.4. Asociación Regular...............................................................................................................4
1.5. Flujo de un enlace Regular...................................................................................................4
1.6. Configuración del enlace Regular.........................................................................................5
1.6.1. Comprobar Distinguished Name en Windows AD.........................................................6
1.6.2. Comprobar el Bind DN en Windows AD........................................................................6
1.7. Editor de Atributos.................................................................................................................6
1.8. Comprobar un usuario en LDAP...........................................................................................7
1.9. Debug en tiempo real............................................................................................................7
1.9.1. Admin Bind.....................................................................................................................7
1.9.2. User Search & User Binding..........................................................................................8
1.9.3. Attribute Query...............................................................................................................9
1.9.4. Primary group Query....................................................................................................10
1.10. Sniffer del tráfico entre LDAP y FGT...............................................................................10
1.11. Problemas comunes........................................................................................................11
1.11.1. Password incorrecta de Usuario...............................................................................11
1.11.2. Usuario no encontrado..............................................................................................12
1.11.3. Grupo no encontrado................................................................................................12
1.11.4. Consejos para resolver problemas LDAP.................................................................12
1.12. Comprobar la configuración BIND REGULAR en WINDOWS AD..................................13
2. RADIUS.....................................................................................................................................13
2.1. PAP vs CHAP......................................................................................................................13
2.2. Atributos..............................................................................................................................14
2.3. Flujo de la consulta RADIUS..............................................................................................14
2.4. Configuración en FGT.........................................................................................................14
2.5. Troubleshooting..................................................................................................................15
2.5.1. Comprobar el SECRET servidor RADIUS...................................................................15
2.5.2. Comprobar un usuario en RADIUS..............................................................................15
2.5.3. Debug en tiempo real (fnbamd)....................................................................................15
3. FORTIAUTHENTICATOR.........................................................................................................15
3.1. Integrando FortiAuthenticator en Security Fabric...............................................................16
3.2. FortiGate vs FortiAuthenticator...........................................................................................16
3.3. Dilema CHAP y LDAP.........................................................................................................17
1
 3.3.1. Soluciones al dilema CHAP & LDAP...........................................................................17
3.4. Servidor de autenticación remoto – LDAP..........................................................................17
3.5. Servidor de autenticación remoto – RADIUS.....................................................................18
3.6. Añadir usuarios a FortiAuthenticator...................................................................................19
3.7. Clientes RADIUS.................................................................................................................19
3.8. Debug logs..........................................................................................................................20
4. CERTIFICADOS DIGITALES....................................................................................................20
4.1. Clasificación de los Algoritmos...........................................................................................20
4.2. Cifrado asimétrico (Clave Pública)......................................................................................20
4.3. SSL entre FGT y Web Server.............................................................................................21
4.4. ¿Qué es un certificado digital?...........................................................................................23
4.5. Autoridad de Certificación - Certificate Authority (CA).......................................................23
4.6. Tipos de certificados...........................................................................................................24
4.7. Autenticación de Servidor...................................................................................................24
4.8. Autenticación de usuario.....................................................................................................25
4.9. Cadena de confianza..........................................................................................................25
4.10. Proceso de validación de certificado...............................................................................26
4.11. Obtención de un certificado.............................................................................................26
5. SCEP.........................................................................................................................................27
5.1. Características....................................................................................................................27
6. PKI usuarios FGT......................................................................................................................27
6.1. Autorizando usuarios PKI –userPrincipalName (UPN).......................................................28
6.2. Filtrado de Grupo de usuarios PKI......................................................................................28
7. Revocación de certificados........................................................................................................29
7.1. Lista de Revocación de Certificados - CRL........................................................................29
7.2. OCSP - Online Certificate Status Protocol.........................................................................29
7.2.1. Configurando la lista de servidores OSCP...................................................................29
7.2.2. URL OSCP dentro del certificado.................................................................................30
8. Troubleshooting Autenticación basada en certificado...............................................................31
8.1. Real-Time Debug................................................................................................................31
8.2. Errores comunes que vemos en el Debug.........................................................................32
9. FortiAutheticator actuando como CA.........................................................................................32
9.1. Certificate Management > Local CA...................................................................................32
9.2. Emitiendo Certificados........................................................................................................33
9.3. Firmando certificados..........................................................................................................34
9.4. SCEP RA.............................................................................................................................34

2
1. LDAP
Veamos como configurar y resolver problemas usando servidores de autenticación LDAP y
RADIUS con FortiGate (FGT). También revisaremos algunos aspectos básicos de
FortiAuthenticator.

1.1. Directorio Árbol

Arriba está la raíz del directorio, donde comienza el árbol LDAP en cualquier esquema.

1.2. Asociación Simple

Hay tres métodos diferentes para que FortiGate (FGT) se asocie con un servidor LDAP:
 Simple
 Anonymous
 Regular

Simple: Trabaja con todas las cuentas que están en la misma rama del árbol LDAP. El campo
Distinguished Name (DN) define el comienzo y alcance de la búsqueda en el servidor LDAP.

3
 1.3. Flujo Asociación Simple
Por ejemplo, si Distinguished Name se fija a
ou=it,ou=france,dc=trainingad,dc=training,dc=lab podrán autenticarse los usuarios que se
encuentren dentro de la ou IT > France y no lo podrán hacer los que se encuentren en cualquier
otro contenedor.

1.4. Asociación Regular

El campo Common Name Identifier permite elegir cn o sAMAccountName.
 Si usas cn, los usuarios deben autenticar con el nombre completo (John Smith).
 Si usas sAMAccountName, los usuarios deben autenticar con el nombre de logon (jsmith).

4
Puedes determinar el campo Distinguished Name mediante una consulta en el servidor AD con
el comando dsquery en su consola.
Puedes determinar el campo Username (administrador LDAP), con el mismo comando dsquery.
Finalmente, el campo Password se configura con la contraseña del administrador LDAP.

1.5. Flujo de un enlace Regular

Es el método más versátil, complejo y comúnmente usado.
La autenticación LDAP usando la asociación Regular se completa en 4 pasos:
Paso 1: FGT enlaza con en el servidor LDAP usando la cuenta de administrador.

Paso 2: FGT realiza una consulta a la base de objetos LDAP para localizar al usuario.
Si encuentra el usuario, el servidor LDAP responde con el DN del usuario.
Entonces FGT cierra la sesión de Administrador con el servidor.
Paso 3: FGT enlaza, otra vez, en el servidor LDAP usando las credenciales de usuario.
Paso 4: FGT obtiene los atributos del usuario y la información de grupo.

1.6. Configuración del enlace Regular

La mayoría de los problemas de autenticación LDAP, habitualmente se deben a una mala
configuración en cualquiera de los campos que debes configurar.

5
El atributo usado típicamente como el Common Name Identifier es cn. Como comentamos,
antes en los entornos Windows AD también podemos usar sAMAccountName.
1.1.1. Comprobar Distinguished Name en Windows AD
Desde la consola C:\ del servidor Windows AD, ejecuta el siguiente comando:
dsquery user -name <NOMBRE COMPLETO del usuario> o sí conoces el login de usuario:
dsquery user -samid <LOGIN del usuario>
Por ejemplo, si haces la siguiente consulta:
C:\ dsquery user –samid jsmith
cn= John Smith,ou=It,ou=france,dc=example,dc=com
Podrías configurar Distinguished Name como: dc=example,dc=com

1.1.2. Comprobar el Bind DN en Windows AD

Para comprobar la cuenta de Administrador (Username), que FGT usará para enlazar con el
LDAP, al igual que hemos hecho con el usuario:
C:> dsquery user –samid Administrator.
cn=administrator,ou=It,ou=france,dc=example,dc=com
Puedes copiar y pegar directamente en FGT la salida en el campo Username.

1.7. Editor de Atributos

Puedes ver los atributos LDAP, en la pestaña Editor de Atributos, dentro de las propiedades de
cada objeto en el LDAP. Desde aquí puedes configurar atributos adicionales si se necesitan.
NOTA: Para habilitar la vista de los atributos LDAP de un usuario, debes habilitar las Advanced
Features en el servidor LDAP Windows AD.

6
 1.8. Comprobar un usuario en LDAP
Si las credenciales son correctas y la configuración LDAP está bien hecha, el servidor devuelve
una confirmación de la autenticación y los grupos de usuario a los que pertenece.
diag test authserver ldap <server_name> <username> <password>

1.9. Debug en tiempo real

El demonio Fortinet non-blocking authentication module se denomina (fnbamd), y es el
proceso que maneja la autenticación LDAP y RADIUS.
diagnose debug application fnbamd -1
diagnose debug enable

En el siguiente ejemplo se describe el proceso. FGT recibe el mensaje handle_req-Rcvd, lo que

indica que FGT ha recibido una solicitud de autenticación para un usuario.
A partir de entonces, veamos el intercambio de mensajes entre el servidor LDAP y FGT.

7
Debajo encontramos más información, como el atributo que se usará para la búsqueda en el
árbol, DN base, la dirección IP y nombre del servidor LDAP.

1.9.1. Admin Bind

Continuando con la salida del debug nos encontramos el primer mensaje (ID 1).
Representa el primer paso del proceso que ejecuta FGT: "Admin Binding"
El enlace entre el servidor y FGT es exitoso: “fnbamd_ldap_parse_response-ret=0”.
El cambio de estado a "DN search", indica que el primer paso es correcto y FGT inicia el segundo
paso dentro del flujo en un emparejamiento "Regular".

1.9.2. User Search & User Binding

Continuando con la salida del Debug, vemos como FGT inicia el segundo paso (‘DN search’),
consultando el usuario en el árbol del servidor LDAP Windows AD.

8
Encontramos el segundo mensaje (ID 2).
El mensaje incluye la base de la rama (DN) y el nombre del atributo usado para localizar al
usuario sAMAccountName=jsmith.
Si el servidor LDAP encuentra al usuario “fnbamd_ldap_parse_response-ret=0”, descubrimos que
la respuesta incluye el user DN completo.

El cambio de estado a "User Binding" indica que el tercer paso del emparejamiento se ha
producido. FGT solicita la autenticación usando las credenciales del usuario.
Encontramos el tercer mensaje (ID 3).
Si la autenticación del usuario tiene éxito (fnbamd_ldap_parse_response-ret=0), el proceso pasa
al último paso.

9
Aparece el mensaje "Attr query", que es la solicitud de FGT para conocer el resto de atributos.

1.9.3. Attribute Query

En el cuarto paso del proceso Regular Bind, vemos como FGT solicita el grupo y atributos del
usuario ("memberOf"). El servidor responde con la información.
Encontramos el cuarto mensaje (ID 4).
Vemos la respuesta del servidor con los grupos a los que pertenece.

1.9.4. Primary group Query

Por último, FGT realiza la solicitud "Primary group query", que es el grupo principal al que
corresponde el usuario, el LDAP devuelve la información (ID 5), lo que completa los pasos en el
proceso LDAP Regular bind. "SUCCESS" indica que ha sido un éxito la autenticación.

10
 1.10. Sniffer del tráfico entre LDAP y FGT
Si encontramos algún problema en los pasos 1 o 3 del emparejamiento, puedes esnifar el tráfico
entre FGT y el LDAP.
En el ejemplo, el archivo sniffer se ha convertido al formato WireShark. Puedes ver el código de
error AD “data 52e”.
diag sniffer packet any "port 389" 3

También deberías tener en cuenta los "Common industry-standard LDAP result codes".
La lista total de códigos la encuentras en el RFC 4511.

1.11. Problemas comunes

Después de cualquier cambio en la configuración:
1. Conviene des-autenticar al usuario objeto del test en el firewall:

11
User& Device > Monitor > Firewall -> Seleccionar el usuario y clic en De-authenticate
2. Borra las entradas en la tabla de sesiones, filtrando por el puerto destino o por la IP:
diagnose sys session filter dport 80
diagnose sys session clear
3. Borra la cache del navegador (si estamos haciendo pruebas de navegación) o refresca la
página con F5.

1.11.1. Password incorrecta de Usuario

Un error muy común es introducir credenciales incorrectas.
Si hay un problema en el paso 1 o 3, LDAP enviará un código. En el ejemplo, el error de FGT al
intentar emparejarse con el servidor LDAP, no permite establecer la asociación y pasar del paso 1
de la asociación. Podemos ver el Error 49 al hacer el debug en tiempo real.

1.11.2. Usuario no encontrado

Si vemos el mensaje "No DN is found" en el paso 2, esto nos indica que no se ha podido
encontrar al usuario en la rama del LDAP o que el usuario corresponde a otra rama para la que
FGT no puede hacer búsquedas.

12
 1.11.3. Grupo no encontrado
El siguiente error muestra un problema en el paso 4 "get_member_of_groups-attr=’memberof’
- found 0 values" donde las credenciales de usuario son correctas, pero el usuario no es
miembro otros grupos de usuario.

Nota: en algunas implementaciones LDAP, la información del grupo al que pertenece el usuario
no es un atributo del usuario, en vez de eso, los usuarios se consideran un atributo del grupo; en
estos casos necesitas hacer una consulta al grupo sobre el usuario. Hay una configuración
adicional que permite a FGT trabajar en este entorno, pero el debug seguirá indicando el error,
que tendrás que ignorar.

1.11.4. Consejos para resolver problemas LDAP

¿Qué deberías hacer si tienes un problema en el paso 1?
1. Usa el comando dsquery para comprobar si la cuenta (DN) de administrador se puede
emparejar con el LDAP
2. Comprueba la password de administrador.
3. Esnifa el tráfico y obtén el código de error que envía el servidor.

¿Qué deberías hacer si tienes un problema en el paso 2? El servidor LDAP no encuentra el

usuario.
1. Si el identificador Common Name se configuró a sAMAccountName, el usuario debe usar
el login name, pero si está fijado a CN, el usuario debe usar el nombre completo.
2. Comprueba el identificador Distinguished Name usando el comando dsquery.

1.12. Comprobar la configuración BIND REGULAR en WINDOWS AD

Desde la consola msdos del servidor AD, introducimos los siguientes comandos en función del
formato de nombre de usuario que empleas:
dsquery user -name <NOMBRE COMPLETO del usuario>
o
dsquery user -samid <login del usuario>

13
2. RADIUS
Remote Authentication Dial-In User Service, es un protocolo cliente-servidor ampliamente
utilizado, que ofrece autenticación, autorización y funciones de accounting de forma
centralizada.
Los servidores RADIUS utilizan paquetes UDP (1812, 1813, 1645 y 1646) para comunicar con los
“clientes RADIUS” en la red para autenticar a los usuarios.
Debemos configurar el servidor RADIUS para aceptar a FGT como cliente RADIUS. FGT usará
las funciones de autenticación y accounting del servidor.
FGT soporta los siguientes esquemas de autenticación RADIUS:
 CHAP
 PAP
 MSCHAP (*hay que cambiar el Método de Autenticación default x Manual)
 MSCHAP2

2.1. PAP vs CHAP

Password Authetication Protocol (PAP) y Challenge Handshake Authetication Protocol (CHAP),
son los esquemas más comúnmente usados con RADIUS.
 PAP es un esquema inseguro porque transmite la password en claro.
No se recomienda su uso.
 CHAP es un esquema fuerte, porque nunca envía la password. Usa hashing para realizar
la autenticación.
Tras establecer comunicación entre el cliente y el servidor ocurre lo siguiente:
1. El servidor envía un mensaje con un desafío al cliente, que incluye un valor para el
desafío.
2. El cliente responde con un hash one-way realizado con la combinación de su password y
el valor para el desafío que recibió del servidor.
3. El servidor calcula un hash one-way usando la password que tiene del usuario y el valor
para el desafío y compara el hash resultante con el recibido del cliente.

2.2. Atributos
Podemos usar los atributos RADIUS para ofrecer información del usuario o del grupo de usuarios.
Configurados a nivel de usuario, provén información del usuario que puede usarse para asignar la
dirección IP.
Configurados a nivel de grupo de usuarios, ofrecen información que puede ser aplicada a todos
los usuarios de un grupo específico.
Los atributos específicos de fabricante o Vendor-specific attributes (VSA) se usan para extender
las funcionalidades básicas de RADIUS.
Cada fabricante usa un único “VSA ID” para transmitir información adicional, en función de si la
autenticación fue exitosa o falló. Se necesitan los diccionarios VSA, para entender los atributos
propietarios que suministra el fabricante.
14
Fortinet RADIUS vendor ID es 12356.

2.3. Flujo de la consulta RADIUS

Una consulta de autenticación RADIUS comienza con un mensaje del tipo Access-Request que
FGT envía al servidor RADIUS.
Las respuestas válidas son:
 Access-Accept
 Access-Reject
Si está habilitado el 2º factor de autenticación, el servidor enviará otro mensaje Access-
Challenge, para indicar que necesita más información.

2.4. Configuración en FGT

Necesitas indicar los datos del servidor:
 Name
 Primary Server IP/Name
 Primary Server Secret
 Authentication method
Si el método de autenticación en FGT es Default, FGT intentará usar diferentes esquemas,
empezando con MSCHAP2, CHAP y por ultimo PAP.
Puedes indicar la dirección IP del cliente RADIUS, en el campo NAS IP, indicar en la consulta de
autenticación la NAS-IP-Address o atributo Called Station ID.
*Nota: FGT no usa nunca MSCHAP, sí el método de autenticación es Default. Si quieres utilizarlo
debes especificarlo manualmente.

2.5. Troubleshooting
El servidor RADIUS no responde a las solicitudes enviadas desde un cliente, si este no está
autorizado. En ese caso recibes un Server Unreachable.

2.5.1. Comprobar el SECRET servidor RADIUS

diag test authserver radius-direct <server IP> <port> <secret>
Ofrece tres tipos de salida:
1. OK = El secreto es correcto.
2. Secret Invalid = El secreto es incorrecto.
3. Server Unreachable = IP o puerto incorrecto, o no es un cliente autorizado.

2.5.2. Comprobar un usuario en RADIUS

Similar a LDAP, tenemos el comando que permite comprobar las credenciales del usuario.
diag test authserver radius <server_name> <chap | pap | mschap | mschap2> <username>
<password>

15
Además de las credenciales del cliente RADIUS, debes indicar el esquema de autenticación que
vas a usar. La autenticación RADIUS es un proceso de 1 o 2 pasos, dependiendo de si se ha
habilitado el segundo factor de autenticación.
No es un proceso de 4 pasos como ocurre con LDAP y el método Regular.

2.5.3. Debug en tiempo real (fnbamd)

Como comentamos en el apartado LDAP, el proceso que maneja la autenticación RADIUS es el
mismo que el que maneja la autenticación LDAP; el demonio fnbamd:
diagnose debug application fnbamd -1
diagnose debug enable
diagnose test authserver radius <server_name> <chap | pap | mschap | mschap2>
<username> <password>
Nota: <server_name> tal y como está definido en el FGT
La salida de este comando es más corta y si la autenticación es exitosa veremos el mensaje:
"Result for radius srv 'nombre del servidor' 'IP del servidor' (1) is 0".
El 0 indica éxito, el 1 indica fracaso. Pero hay más códigos de respuesta además del 0 y el 1;
tenemos hasta el 12.

3. FORTIAUTHENTICATOR
FortiAutenticator es un dispositivo que permite gestionar la identidad y la autenticación de los
usuarios. Soporta RADIUS, LDAP, 802.1x, Gestión de certificados, Portal Cautivo, Portal de
autoregistro y Fortinet single sign-on (FSSO).

Es compatible con FortiToken para ofrecer 2º factor de autenticación cuando usas varios FGTs o
dispositivos de terceros.
La suma de FortiGate, FortiAutenticator y FortiToken, ofrece una solución efectiva y escalable
para gestión de la identidad, la autenticación segura y el control del acceso seguro a la red.
16
 3.1. Integrando FortiAuthenticator en Security Fabric
FortiAuthenticator es una pieza clave de la solución de acceso seguro de Fortinet.
FortiAuthenticator ofrece autenticación, que usa FGT y/o controladores para asignar el acceso
apropiado a los clientes. En base a los roles y configuraciones de FGT, puedes forzar las reglas
de autenticación a los clientes en redes cableadas y WiFi.

3.2. FortiGate vs FortiAuthenticator

La siguiente tabla muestra las principales diferencias entre FortiAuthenticator y FGT respecto de
RADIUS, 2º Factor de Autenticación, FSSO, Active Directory, Autenticación WiFi y gestión de
invitados.

3.3. Dilema CHAP y LDAP

Si FGT usa LDAP para autenticar a los usuarios, no podemos usar CHAP o MSCHAP2.
Esto afecta a los usuarios de VPN IPsec y Wireless, que usen esquemas PEAP/MSCHAP2 y
CHAP.
La razón es que el usuario envía un hash de su password, mientras que el LDAP espera
recibir la password en claro.
FGT que está actuando como cliente LDAP, no tiene la password de usuario y tampoco puede
convertir el hash a texto plano. Esto solo lo puede hacer el servidor que tiene las credenciales del
usuario.

17
 3.3.1. Soluciones al dilema CHAP & LDAP
Hay tres métodos posibles para resolver el problema del dilema CHAP & LDAP:
1. Usa PAP: Debemos configurar FGT para que use PAP en lugar de CHAP. No es
recomendable por lo inseguro del protocolo PAP.
2. Usa RADIUS: Cambia el servidor de autenticación de LDAP a RADIUS.
3. Si estás usando tu Windows AD como LDAP, una alternativa es usar FortiAuthenticator
como un proxy de autenticación.
3.1 FortiAuthenticator debe estar situado entre FGT (cliente RADIUS en FortiAuthenticator)
y el servidor Windows de dominio.
3.2 Necesitas configurar FortiAuthenticator para que se registre en el servidor Windows
con las credenciales de administrador.
3.3 Esto añade a FortiAuthenticator como un dispositivo de confianza en el dominio,
permitiendo actuar de proxy de autenticación del usuario en el servidor Windows, utilizando
los tickets Kerberos obtenidos.

3.4. Servidor de autenticación remoto – LDAP

FortiAuthenticator puede almacenar una base de datos de usuarios local.
Como hemos visto, también puede hacer de proxy de autenticación para las solicitudes de los
clientes hacia un servidor remoto LDAP (Windows AD).
Para configurar FortiAuthenticator: Authentication > Remote Auth Servers > LDAP
 Name
 Primary server name/IP
 Base distinguished name (nodo raiz)
 Bind type
 Administrator username y password
Hay unas plantillas predefinidas de los servidores LDAP bien conocidos: Windows AD,
OpenLDAP y Novell eDirectory.

18
Nota: Para que trabaje como relay de la autenticación CHAP hacia un Windows AD, debemos
configurar la sección Windows Active Directory Authentication e introducir las credenciales de
administrador del servidor AD.

3.5. Servidor de autenticación remoto – RADIUS

FortiAuthenticator puede configurarse para conectar con un servidor RADIUS existente.
Authentication > Remote Auth Servers > RADIUS
Si no se usa la base de datos local de usuarios, FortiAuthenticator actuará como proxy en las
solicitudes de autenticación RADIUS.

3.6. Añadir usuarios a FortiAuthenticator

Hay dos formas de añadir usuarios locales a FortiAuthenticator:
1. Manualmente.
2. Importar los usuarios con un archivo CSV (comma-separated value).
También se incluye un portal de auto-servicio para que los usuarios se registren ellos mismos.
Puedes añadir usuarios remotos LDAP y RADIUS de formas diferentes:
19
  Importar los usuarios LDAP, solo a través del servidor remoto LDAP.
 Para los usuarios RADIUS, puedes crearlos en base al servidor remoto RADIUS. Puedes
migrar los usuarios de RADIUS a LDAP; también puedes editarlos y borrarlos o puedes
poner una etiqueta a los usuarios con el rol de usuario o administrador.

3.7. Clientes RADIUS

FortiAuthenticator solo aceptará las solicitudes de autenticación RADIUS, de los clientes RADIUS
autorizados.
Después de configurar los servidores remotos de autenticación o la bbdd de usuarios local, debes
permitir a FGT para que haga solicitudes de autenticación en FortiAuthenticator.
Authentication > RADIUS Service > Clients.
Defines el tipo de solicitudes de autenticación que serán procesadas y las opciones que
FortiAuthenticator podría aplicar al cliente RADIUS.

3.8. Debug logs

FortiAuthenticator no tiene un debug en tiempo real, en su lugar debemos acceder a la url:
https://<FortiAuthenticator_IP>/debug
Hay una opción para habilitar el modo debug, en la ventana debug logs, que te permitirá probar
la autenticación RADIUS usando credenciales de un usuario.

20
4. CERTIFICADOS DIGITALES
2.
3.1. Clasificación de los Algoritmos
Revisemos algo de la terminología que usaremos. Hay dos tipos generales de cifrado: simétrico y
asimétrico.
El cifrado simétrico utiliza una clave única para cifrar y descifrar. Esta clave se comparte entre
las partes que intercambian la información cifrada.
El cifrado asimétrico usa un par de claves que están matemáticamente relacionadas. Una de las
claves se usa para cifrar la información y la otra clave se usa para descifrar la información

Por otro lado, los hashes no son información cifrada, ya que no se pueden descifrar. Un algoritmo
hash genera una salida irreversible desde cualquier entrada.

3.2. Cifrado asimétrico (Clave Pública)

La criptografía asimétrica, también conocida como criptografía de clave pública, consiste en un
par de claves matemáticamente inter-relacionadas y que realizan funciones inversas.
Todo aquello que se cifre con una clave, solo puede ser descifrado con la otra clave de la pareja.
Una de las claves de la pareja se construye pública para poder ser distribuida y la otra clave es
privada.
El emisor del mensaje conoce la clave pública del receptor, así que utiliza la clave pública del
receptor para cifrar el mensaje.

21
Como el mensaje fue cifrado con la clave pública del receptor, solo podrá ser descifrado con la
clave privada del receptor, que solo tiene el.

3.3. SSL entre FGT y Web Server

Vamos a repasar como se establece una sesión SSL.

1. FGT conecta con un servidor web configurado para SSL. En el mensaje hello inicial, el
navegador provee información que incluye la version SSL y los tipos de cifrado que
soporta.
2. El servidor web recibe el mensaje de FGT y contesta con el conjunto de algoritmos que se
usarán y su certificado, que va en texto claro sobre la red pública.
3. FGT valida el certificado comprobando una lista de chequeo para asegurar que es de
confianza y válido:
 CA que firma el certificado.
 Validez de la firma.
 Validez de las fechas.
 Lista de revocación.
Si FGT determina que el certificado es de confianza, entonces continua el SSL handshake.

22
 4. FGT genera un valor conocido como pre-master secret y usa la clave pública del servidor,
que está en el certificado, para cifrar el pre-master secret y enviarlo al servidor web.
Si alguien interceptase el pre-master secret, no podría descifrarlo porque no tiene la clave
privada.
5. El servidor web usa su clave privada para descifrar el pre-master secret, ahora ambos,
FGT y el servidor web, conocen el valor del pre-master secret.

6. FGT y el servidor web crean el master secret derivado del pre-master secret.
7. FGT y el servidor web generan la clave de sesión (clave de simétrica) derivada de la
master secret.
Esta clave se necesita para cifrar y descifrar los datos.
Como ambos tienen la clave de sesión, pueden cifrar y descifrar los datos de cada uno.
8. En el paso final, antes que las dos entidades establezcan una conexión segura,
intercambian un resumen (Digest o asimilación) de los mensajes enviados.
El resumen está cifrado con la clave de sesión.
Este resumen asegura que ninguno de los mensajes intercambiados fue interceptado o
manipulado.
Si el resumen coincide en ambos, se establece un canal de comunicación segura.

3.4. ¿Qué es un certificado digital?

Un documento digital que identifica a una entidad que puede ser una persona o un servidor.
 El contenido se considera público.
 Normalmente incluye la clave pública de la entidad.
23
  Incluye una huella o hash del contenido del certificado firmado por la CA (Certificate
Authority), para asegurar que los datos no fueron modificados en tránsito.

Otra información importante que contiene un certificado es:

 Serial number: un número único que emite la CA e identifica al certificado.
 Signature algorithm: hashing y algoritmos asimétricos que se usaron para producir la
firma digital que asegura el certificado.
 Issuer y Subject: identifica la CA que ha producido el certificado y la entidad para la que
ha sido emitido. Los valores se suelen expresar usando X.500 o formatos LDAP.
 Valid from y Valid to: periodo de validez.
 CRL Distribution Points: identifica la aplicación desde donde debería recuperar la lista de
revocación de certificados.

3.5. Autoridad de Certificación - Certificate Authority (CA)

Las Autoridades de Certificación o CAs emiten y firman los certificados de las entidades finales.
La CA se comporta como un tercero de confianza al que no se cuestiona, en un modelo de
relaciones de confianza.
Cuando una CA emite un certificado y lo firma, la CA esencialmente está proclamando, “Esta es
la entidad que yo digo que es y lo certifico”.
La CA firma en el certificado digital y lo cifra usando su la clave privada.
PKI (Public Key Infraestructure) usa un modelo de relaciónes de confianza y la CA es la raiz de la
jerarquía, como el tercero de confianza. Todo comienza con la CA, que emite su propio certificado
digital, conocido como root certificate, y así se establece este punto como máxima confianza.
Una vez creado el root certificate, la CA puede generar certificados digitales emitidos y firmados
por la raiz.
Si los usuarios confían en la CA y pueden verificar que la firma de la CA es auténtica, entonces
deben confiar en que la clave pública del certificado digital que pertenece a la entidad identificada.

24
 3.6. Tipos de certificados
Una CA puede generar varios tipos de certificados, cada uno con diferentes funciones y con
diferentes nombres (algunas veces confusamente):
 CA certificates
También llamados root o autority. Identifican la CA y crean la raiz de una jerarquía CA. Como tal,
los detalles del certificado tienen los mismos datos en los campos Issuer y Subject. Son
autofirmados y contienen la clave pública que necesitas para descifrar y validar las firmas
contenidas en los certificados firmados por esa CA.
 Web server certificates
También llamados local service. Identifican los servicios y se usan en las comunicaciones
seguras hacia y desde los servidores, como un servidor Secure Shell (SSH), sitios web HTTPS o
la autenticación de servidores EAP 802.1X. Los detalles del certificado incluyen el FQDN o
dirección IP del servidor en el campo Subject y la clave pública del servidor.
 User certificates
También llamados client. Identifican una persona ante otra, una persona ante un dispositivo /
gateway o un dispositivo ante otro dispositivo. También se incluye la clave pública de la entidad.

Tanto los certificados client (USER) como los certificados local service (SERVER) pertenecen a
la categoría certificados de end-entity.

3.7. Autenticación de Servidor

Como hemos comentado, cuando el navegador de un usuario conecta con una página web
HTTPS, recibe el certificado del sitio web firmado por una CA.
El navegador debe tener el certificado de la CA, que contiene la clave pública, para poder
descifrar y comprobar la firma en el certificado del sitio web.

Muchos navegadores ya tienen preinstalados los certificados de las CAs públicas más conocidas.
Sin embargo, si el certificado del servidor está firmado por una CA privada, el certificado de esa
CA debe estar instalado en el navegador para que pueda usar la clave pública y validar a la CA.

25
 3.8. Autenticación de usuario
Los certificados digitales pueden usarse para autenticar a usuarios y combinarse con las
credenciales de usuario para usarlo como un 2º factor de autenticación.
En este caso, cuando un usuario se autentica contra un servidor de acceso, el usuario envía el
certificado digital, que está firmado por una CA.

La firma de la CA está cifrada con la clave privada de la CA. El servidor de acceso debe tener el
certificado de la CA instalado para descifrar y validar el certificado del usuario (con la clave
pública de la CA que lo firmó).

3.9. Cadena de confianza

Los certificados digitales se validan a través de la cadena de confianza.
La cadena de confianza más simple se da cuando la CA raiz (root) es la que directamente firma
los certificados de las entidades finales (end-entity).
Una cadena de confianza puede incluir una o más CAs intermediate.
La CA intermediate es un tipo de CA subordinada firmada por una CA root o por otra CA
intermediate.
Tanto las CAs root como las CAs intermediate pueden firmar certificados end-entity.

La ruta que debe seguirse para validar un certificado es lo que denominamos cadena de
confianza o ruta de certificación.
El proceso va de abajo hacia arriba en la cadena de confianza.

26
 1. La clave pública del certificado intermediate (incluida en el certificado de la CA
intermediate) se usa para validar la firma del certificado end-entity.
2. Adicionalmente, la clave pública de root (incluida en el certificado de la CA root) se usa
para validar la firma en el certificado CA intermediate. Por esta razón el certificado end-
entity requiere los certificados de la CA root y la CA intermediate.

3.10. Proceso de validación de certificado

En cada paso de la validación de la cadena de confianza, se comprueban los siguientes checks
para validar el certificado:
 Periodo de validez - Valid period
 Conformidad con el standard X.509
 Información de los campos es correcta y apropiada
 Uso al que está destinado
 La CA emisora es de confianza
 Huella digital e integridad de la firma
 Estado de revocación

3.11. Obtención de un certificado

El proceso de obtener un certificado digital comienza con la creación de un CSR (Certificate
Signing Request):
1. El solicitante genera un CSR y se crea una pareja de claves pública y privada . El CSR se
firma con la clave privada.
2. El solicitante envía el CSR a la CA. El CSR incluye la clave pública del solicitante e
información específica del solicitante (dirección IP / FQDN, distinguished name, dirección
de correo, etc). OJO, la clave privada se mantiene confidencial (el solicitante nunca envía
su clave privada).

27
 3. La CA verifica que la información del CSR es válida y entonces crea un certificado digital
para el solicitante. El certificado está firmado digitalmente usando la clave privada de la
CA.
4. La CA envía el certificado de entidad al solicitante.

5. SCEP
Simple Certificate Enrollment Protocol (SCEP) es probablemente el protocolo de gestión de
certificados usado más ampliamente.
Permite realizar solicitudes de consulta a una Autoridad de Registro (RA) para obtener
certificados, listas de revocación y enviar CSRs.

La RA valida y autoriza al solicitante, para luego enviar la consulta a la CA y obtener la

información para el solicitante.

4.1. Características
SCEP se basa en solicitudes HTTP y usa el método regular HTTP GET para enviar las consultas
a la RA.
Aunque los datos están cifrados y firmados usando el standard PKCS#7, los CSRs enviados por
los solicitantes utilizan el formato PKCS#10.
Cuando la RA recibe un CSR, contesta con una de las siguientes respuestas: reject, pending y
success.
Cuando el CSR se recibe exitosamente y ha sido aprobado por un administrador, la RA emite,
firma y envía el certificado al solicitante.
SCEP tiene algunas desventajas:
 Soporta un muy limitado número de solicitudes CRL
 No soporta la comprobación online de la revocación del certificado
 No soporta autenticación fuerte, solo una password compartida.

28
6. PKI usuarios FGT
Si vas a trabajar con usuarios PKI en FGT, debes crear al primer usuario PKI desde la consola
CLI. Después de crear el primer usuario y mientras exista al menos un usuario PKI, la opción
para crear y administrar más usuarios PKI aparece en la GUI.

Antes de crear el primer usuario vía CLI, debes haber instalado el certificado de la CA que
firma los certificados end-entity.
Puedes combinar la autenticación basada en certificado, con las credenciales de usuario para
establecer 2º factor de autenticación. Debes indicar la password para el 2º factor de autenticación.

5.1. Autorizando usuarios PKI –userPrincipalName (UPN)

En algunas ocasiones el certificado del usuario podría incluir el campo UPN
(userPrincipalName): atributo en un controlador de dominio Windows AD y que puede utilizarse
para identificar al usuario.
Puedes configurar FGT para usar LDAP y validar ese campo contra el servidor Windows AD.
La autenticación fallará si no hay un usuario valido que coincida con el campo UPN del certificado
del usuario.
Para que FGT pueda comprobar el UPN del certificado de usuario, debes cambiar el modo LDAP
a principal-name e introducir el nombre del servidor LDAP que previamente configuraste en
FGT, para validar el UPN.

29
 5.2. Filtrado de Grupo de usuarios PKI
Cuando configures la validación UPN para los usuarios PKI y el UPN es un usuario válido; FGT
consultará los grupos de usuarios LDAP al que pertenece y usará esta información para autorizar
accesos, solo a los usuarios UPN que pertenezcan a grupos específicos.
Debes crear un grupo de usuarios y añadir como miembros el usuario y el servidor LDAP.
Debes indicar a que grupo del LDAP debe pertenecer el usuario cuyo UPN coincida.

7. Revocación de certificados
Veamos como consultar las listas de revocación de certificados (CRLs) y configurar el protocolo
OCSP para permitir extender esta comprobación online.

6.1. Lista de Revocación de Certificados - CRL

Una lista CRL contiene los números de serie de los certificados que han sido revocados.
Suele haber una CRL por cada CA root.
Los certificados revocados son colocados automáticamente en la CRL.
Los administradores pueden exportar manualmente CRLs desde CAs a los dispositivos de red
como FGT; y comprobar si el número de serie está incluido en la CRL, de la CA que ha firmado el
certificado.

6.2. OCSP - Online Certificate Status Protocol

OSCP ofrece un servicio online que informa del estado de revocación de un certificado digital.
Usando este protocolo, los administradores no necesitan importar manualmente la CRL en FGT.
Cada vez que el usuario presenta un certificado, FGT usa OSCP para enviar el número de serie
al servidor OSCP. El servidor OSCP puede responder con tres posibles opciones:
 Good: no está revocado
 Revoked: esta revocado
 Unknown: fue emitido por otra CA

30
1.
7.2.1. Configurando la lista de servidores OSCP
Puedes configurar una lista de servidores OSCP, para validar el estado de revocación de los
certificados de usuario.
Por cada servidor OSCP, configura su URL y el certificado de la CA que ha firmado el
certificado del servidor (se usa para autenticar el servidor OSCP).
Opcionalmente, puedes configurar un servidor OSCP secundario (backup).

Si la opción unavail-action es revoke, el certificado será rechazado si el servidor OSCP no

responde. Si es ignore, el certificado será aceptado, incluso si el servidor OSCP no responde.
Si stric-ocsp-check está habilitado, el certificado será rechazado si el servidor OSCP responde
con un Unkown.
Si estamos usando una lista CRL en lugar de OSCP, la opción strict-crl-check define que acción
tomar cuando la CRL expiró.
Debajo de config vpn certificate settings, puedes seleccionar que servidor OSCP (de una lista
previa), será usado por defecto para el chequeo del estado de revocación.
Puedes anular esta configuración por usuario usando oscp-override-server en config user
peer.

31
 7.2.2. URL OSCP dentro del certificado
En algunos casos el certificado incluye la URL del servidor OSCP, para comprobar el estado de
revocación.
Puedes configurar FGT para que use esta información, certificate si está disponible en el
certificado, o ignorarla server y seguir usando el servidor OSCP configurado en FGT.
config vpn certificate setting
set ocsp-option [certificate | server]
end

8. Troubleshooting Autenticación basada en certificado

Veamos cómo resolver problemas de autenticación basada en certificado.

7.1. Real-Time Debug

El demonio Fortinet non-bloking authentication module (fnbamd), es el proceso que valida la
autenticación de los usuarios, también cuando usan certificados.
La salida del debug muestra paso a paso, que hace este demonio cuando se recibe un certificado
de usuario que debe validar.
FGT primero comprueba la cadena de confianza hasta que encuentra que el certificado fue
firmado por una CA de confianza.
FGT encuentra el grupo de usuario al que pertenece y comprueba el campo subject.
La salida muestra la URL OSCP y la consulta que ha sido enviada.

En este ejemplo, FGT está configurado para validar el estado de revocación usando OSCP.
Entonces, la salida muestra la respuesta del servidor OSCP, *** Certificate status is good, lo que
nos indica que no está revocado.

32
 7.2. Errores comunes que vemos en el Debug
Si ocurre algún problema con la validación del certificado de usuario, la salida mostrará un error
explicando porque ha fallado. Las posibles razones se ven en la imagen anterior.

9. FortiAutheticator actuando como CA

8.1. Certificate Management > Local CA

FortiAuthenticator puede actuar como CA local / autofirmada (tanto CA root como intermediate),
para emitir y revocar certificados digitales.
Actuando como CA, el administrador puede importar los certificados de las CA y listas de
revocación (CRL).

33
FortiAuthenticator puede actuar también como un servidor OSCP (para comprobar la revocación)
y como SCEP RA (para recibir CSRs y emitir certificados).

8.2. Emitiendo Certificados

Certificate Management > End Entities
Los certificados de usuario y de servidor se necesitan para autenticaciones mutuas en muchos
recursos de red (HTTPS, SSL e IPsec VPN).
Puedes importar y firmar un CSR en FortiAuthenticator.

34
FortiAuthenticator puede generar los siguientes tipos de certificados:
 Certificados de USUARIO: Clientes/end users, se usan para identificar clientes, usuarios y
dispositivos. Permite descargar la clave privada, solo una vez.
 Certificados LOCAL SERVICE: Servidores, se usan para identificar servidores, aplica a
solo a los servicios habilitados en FortiAuthenticator. No puedes recuperar la clave privada.
Los certificados de usuario, de cliente o local computer (máquina) son el mismo tipo de
certificado.
Nota: tener en cuenta que los certificados End Entities, solo pueden usarse para verificar la
identidad del cliente y no se pueden usar para firmar otros certificados.

8.3. Firmando certificados

Certificate Management > End Entities > Users
Una vez que has creado el certificado CA, FortiAuthenticator puede empezar a emitir certificados
de usuarios. En cada certificado de usuario puedes definir los campos:
 Subject
 Expiration date
 UPN
 URL donde se descargará la CRL
 URL del OSCP
35
 8.4. SCEP RA
FortiAutheticator soporta SCEP. Cuando actúa como servidor SCEP, puede recibir las CSRs de
cualquier dispositivo de tu red.
Dispone de dos tipos de inscripción:
Automática: los administradores preaprueban el CSR antes de llegar. Una vez que llega,
FortiAuthenticator responde con el certificado firmado.
Manual: los solicitantes envían el CSR primero. El CSR se mantiene como pending hasta que el
administrador lo aprueba.

36