Certificados SSL en FortiGate con ADCS: elimina el aviso de certificado no confiable

El problema: ese aviso que aparece cada vez

#

Si administras un FortiGate y tienes usuarios conectándose por VPN SSL, ya conoces el escenario: el cliente FortiClient o el navegador muestra un aviso de “certificado no confiable” antes de establecer la conexión. Los usuarios hacen clic en “Continuar de todas formas” sin leerlo, y el área de seguridad pierde credibilidad cada vez que alguien les pregunta si eso es normal.

El motivo es simple: FortiGate viene de fábrica con un certificado autofirmado (Fortinet_CA_SSL o similar). Los navegadores y sistemas operativos no incluyen esa CA en su almacén de confianza, así que lo marcan como no confiable. No es un fallo del appliance; es el comportamiento correcto del cliente ante una CA desconocida.

La solución permanente es reemplazar ese certificado autofirmado por uno emitido por una autoridad en la que los clientes ya confíen.

Tres opciones para resolver el problema

#

Antes de entrar en detalle, conviene conocer las tres vías disponibles:

Opción 1 — CA interna con ADCS (recomendada si tienes dominio Windows): usas tu propia infraestructura de clave pública. Los equipos unidos al dominio ya confían en tu CA automáticamente. Sin coste adicional y con control total sobre la renovación.

Opción 2 — Let’s Encrypt con ACME nativo (FortiGate 6.4 en adelante): válida si el FortiGate tiene un FQDN público resolvible desde internet. FortiOS implementa el protocolo ACME y renueva el certificado automáticamente. No sirve para appliances detrás de NAT sin nombre público.

Opción 3 — Certificado comercial: compras un certificado a una CA reconocida (DigiCert, Sectigo, etc.). El proceso de importación es idéntico a la opción 1, pero sin necesitar ADCS. Tiene coste anual y depende de un tercero para la renovación.

En la mayoría de entornos corporativos con Active Directory, la opción 1 es la más limpia: aprovecha infraestructura ya existente, los equipos del dominio confían en la CA sin configuración adicional y tienes control total.

Opción 1 paso a paso: ADCS como CA firmante

#

Requisitos previos

#

• Windows Server con el rol Active Directory Certificate Services (ADCS) instalado y configurado como CA empresarial (Enterprise CA).
• Acceso de administrador al FortiGate.
• El FortiGate debe tener un FQDN o nombre DNS interno que resuelva correctamente desde los clientes. Puede ser solo un nombre interno, no necesita ser público.

Paso 1 — Generar el CSR en FortiGate

#

Un CSR (Certificate Signing Request) es la solicitud que el FortiGate genera para pedirle a la CA que emita un certificado. Contiene la clave pública y los datos de identidad del appliance.

En la interfaz de FortiGate:

1. Ve a System > Certificates > Generate.
2. Configura los campos:

3. En Subject Alternative Names añade:

   • Tipo DNS: el FQDN que usan los clientes para conectarse.
   • Tipo IP: la IP del interfaz SSL-VPN, si los clientes se conectan por IP.

   Los SAN son obligatorios para que Chrome y navegadores modernos acepten el certificado; el CN solo ya no es suficiente.

4. Haz clic en OK. FortiGate descarga automáticamente un archivo .csr.

Paso 2 — Firmar el CSR en ADCS

#

Transfiere el archivo .csr a un servidor con acceso a la CA. Hay dos métodos:

Método A — línea de comandos (recomendado para automatizar):

certreq -submit -attrib "CertificateTemplate:WebServer" fortigate.csr fortigate.cer

Si tienes varias CAs en el entorno, especifica cuál usar:

certreq -submit -config "CA-SERVER\Nombre-CA" -attrib "CertificateTemplate:WebServer" fortigate.csr fortigate.cer

El resultado es el archivo fortigate.cer con el certificado firmado.

Método B — interfaz web de ADCS:

1. Abre http://CA-SERVER/certsrv en un navegador.
2. Haz clic en Solicitar un certificado.
3. Elige Enviar una solicitud de certificado avanzada.
4. Selecciona Enviar una solicitud de certificado mediante un archivo PKCS#10 codificado en Base 64.
5. Pega el contenido del .csr y en Plantilla de certificado elige Servidor web.
6. Descarga el certificado en formato Base 64 (.cer).

Si el botón de descarga pide reiniciar la solicitud, usa el método de línea de comandos; es más fiable con CSRs generados fuera de Windows.

Paso 3 — Importar el certificado firmado en FortiGate

#

1. En FortiGate, ve a System > Certificates > Import > Local Certificate.
2. Selecciona el archivo fortigate.cer que generó la CA.
3. FortiGate lo asocia automáticamente con el CSR que generaste antes porque las claves coinciden.
4. Verifica que el nuevo certificado aparece en la lista con el nombre que configuraste y que el campo Issuer muestra el nombre de tu CA interna.

Paso 4 — Asignar el certificado a SSL-VPN

#

El certificado importado no entra en servicio hasta que lo asignas explícitamente:

1. Ve a VPN > SSL-VPN Settings.
2. En el campo Server Certificate, selecciona el certificado que acabas de importar (fortigate-vpn en el ejemplo).
3. Guarda los cambios. FortiGate recarga el servicio SSL; los clientes conectados en ese momento pueden notar una desconexión breve.

Distribución del certificado raíz via GPO

#

El certificado del FortiGate está firmado por tu CA interna, pero si los equipos cliente no tienen el certificado raíz de esa CA en su almacén de confianza, seguirán viendo el aviso. La distribución automática via Directiva de Grupo (GPO) resuelve esto de forma centralizada.

En el Controlador de Dominio o desde la consola GPMC:

1. Crea o edita una GPO aplicada a los equipos que usan la VPN.
2. Navega a:

   Computer Configuration > Windows Settings > Security Settings >
   Public Key Policies > Trusted Root Certification Authorities

3. Haz clic derecho > Import e importa el certificado raíz de tu CA (.cer de la CA, no del FortiGate).
4. Aplica y cierra. Los equipos recibirán el certificado raíz en el siguiente ciclo de actualización de directivas (normalmente 90 minutos, o puedes forzarlo con gpupdate /force).

Para los equipos que no están en el dominio (dispositivos personales, móviles), tendrás que distribuir el certificado raíz manualmente o mediante MDM.

Verificación

#

Una vez completado el proceso, verifica que todo funciona correctamente:

Desde FortiClient:

Abre FortiClient e intenta conectarte a la VPN SSL. Si el proceso fue correcto, la conexión se establece sin ningún aviso de certificado. La diferencia respecto al comportamiento anterior es inmediata.

Desde el navegador:

Accede a la interfaz de administración del FortiGate o al portal web SSL-VPN por HTTPS. El candado del navegador debe aparecer cerrado y sin advertencias. Haz clic en él para confirmar que el emisor es tu CA interna.

Validación con certutil:

En cualquier equipo Windows del dominio:

certutil -verify fortigate.cer

La salida debe terminar con CertUtil: -verify command completed successfully. Si hay errores de cadena, el problema está en la distribución del certificado raíz.

Para comprobar la cadena completa:

certutil -verify -urlfetch fortigate.cer

Esto verifica también los puntos de distribución CRL (listas de revocación) configurados en la CA.

Por qué ADCS es la opción más limpia en entornos con dominio

#

La ventaja real no está en la firma del certificado en sí, sino en la distribución de confianza. Cuando una organización tiene un dominio Windows, los equipos unidos al dominio reciben el certificado raíz de la CA interna de forma automática desde el momento en que se unen al dominio. No hay que hacer nada adicional: la GPO que distribuye el certificado raíz ya existe por defecto en la mayoría de instalaciones de ADCS empresarial.

Comparado con las alternativas:

• Let’s Encrypt: requiere que el FortiGate tenga un FQDN público y responda al desafío ACME. En redes corporativas con FortiGates detrás de NAT o con nombre solo interno, esto no es viable. Además, la renovación cada 90 días depende de que el proceso automático funcione sin interrupciones.
• Certificado comercial: resuelve el problema para cualquier dispositivo (incluso los que no están en el dominio), pero tiene coste anual y el ciclo de renovación es manual o semi-manual. Útil cuando hay clientes externos que no controlas.

Con ADCS, el ciclo de vida completo (emisión, renovación, revocación) queda dentro de tu infraestructura. La renovación antes de la expiración sigue el mismo proceso: nuevo CSR desde FortiGate, firma en ADCS, reimportación y reasignación. Algunos equipos automatizan este paso con scripts que invocan certreq contra la CA y suben el certificado resultado via la API de FortiGate.

Conclusión

#

El aviso de certificado no confiable no es un problema estético: erosiona la confianza de los usuarios en los controles de seguridad y, en el peor caso, los entrena a ignorar avisos SSL. Resolverlo con ADCS en entornos con Active Directory es directo, sin coste y deja la infraestructura en mejor estado que antes.

El proceso tiene cuatro pasos reales: generar el CSR en FortiGate, firmarlo en ADCS, importar el certificado firmado de vuelta y asignarlo a SSL-VPN. La distribución via GPO hace que la experiencia del usuario sea transparente desde el primer ciclo de actualización de directivas.