Il giorno in cui accendi la full SSL inspection su un traffico in uscita, ogni browser della rete comincia a lamentarsi. Il motivo è ovvio ma va detto per intero: il FortiGate emette al volo un certificato che imita quello del sito richiesto e lo firma con una propria CA, e quella CA nel client non c’è. Rendere silenzioso quell’avviso — sui client giusti, con il certificato giusto — è metà del lavoro; l’altra metà è saper leggere gli errori che restano anche dopo.

Sub CA, non CA radice

In laboratorio si usa il certificato di fabbrica Fortinet_CA_SSL. In produzione la strada raccomandata è un’altra: emettere dalla PKI aziendale una CA subordinata e installarla sul FortiGate come certificato di deep packet inspection.

La ragione è precisa e vale la pena ricordarla, perché è esattamente il tipo di scelta progettuale che una domanda mette alla prova. La chiave privata della sub CA deve essere esportata per finire sul FortiGate, quindi è per definizione più esposta; una CA subordinata compromessa si revoca, una CA radice no. Se esporti la radice e te la fanno uscire, l’unica risposta è rifare l’intera PKI.

La distribuzione è asimmetrica e conviene fissarla: la sub CA va sul FortiGate con la chiave privata, e sugli endpoint senza. Sugli endpoint di dominio il certificato radice della CA aziendale di solito c’è già, quindi il client completa da solo la catena e non vede alcun avviso.

Emettere e importare

Il percorso Microsoft parte dalla web enrollment della CA, raggiungibile all’indirizzo https://FQDN-del-server-CA/CertSrv — e solo in HTTPS, le richieste in HTTP non sono ammesse. Da lì: Request a certificate, advanced certificate request, template Subordinate Certification Authority, e soprattutto Mark keys as exportable, che è il flag che tutti dimenticano e che rende inutile il resto.

L’esportazione si fa dalla console MMC con lo snap-in Certificates, All Tasks > Export, scegliendo di esportare anche la chiave privata: l’unico formato disponibile è allora PKCS #12 (.PFX) e richiede una password. Come cifratura si sceglie AES256-SHA256.

Sul FortiGate, System > Certificates, Create/Import > Certificate, Import Certificate, Type impostato a PKCS #12. Da CLI:

execute vpn certificate local import tftp subca-AES256.pfx 10.1.100.20 p12 <password>

Se non trovi il menu, non è un bug: la funzione Certificates è nascosta di default e va attivata in System > Feature Visibility. Ricorda anche che un certificato caricato dentro una VDOM è visibile solo lì, mentre uno caricato nella VDOM globale è disponibile a tutte.

Vale la pena tenere separate le tre voci di import, perché si confondono facilmente: Local Certificate carica un solo file .CER e nessuna chiave, e si usa quando la CSR è stata generata dal FortiGate; PKCS #12 carica certificato e chiave nello stesso file cifrato; Certificate carica i due file separati, .CER e .PEM, con password. Chi non ha una PKI Microsoft può costruire la stessa gerarchia con XCA, generando prima la CA e poi la sub CA per la deep inspection.

Portare la CA sugli endpoint

Il certificato da distribuire si scarica dal profilo stesso: Security Profiles > SSL/SSH Inspection, apri il profilo in uso, e accanto al campo CA Certificate premi Download. Sui client Windows va importato nell’archivio Trusted Root Certification Authorities, a mano con il Certificate Import Wizard su una macchina singola, o via group policy su tutto il dominio.

Un avvertimento che ricorre nelle domande: Fortinet_CA_Untrusted non va mai importato nel browser. Esiste apposta perché il FortiGate abbia con cosa firmare quando il certificato del server originale non è attendibile, e renderlo affidabile sui client annullerebbe la segnalazione. Se dopo aver importato Fortinet_CA_SSL gli avvisi continuano, molto spesso è proprio Fortinet_CA_Untrusted a essere entrato in gioco: il sito a monte ha un certificato che non convince il FortiGate.

I certificati di fabbrica, se scadono o se la chiave è compromessa, si rigenerano da CLI.

execute vpn certificate local generate default-ssl-ca
execute vpn certificate local generate default-ssl-ca-untrusted
execute vpn certificate local generate default-gui-mgmt-cert

Leggere un errore di certificato

Quando qualcosa non torna, l’errore ha quasi sempre una delle quattro forme che il profilo SSL/SSH gestisce separatamente: certificato scaduto, revocato, con validazione andata in timeout o con validazione fallita. Le azioni di default bloccano scaduti, revocati e validazione fallita, mentre il timeout è più permissivo. Sapere quale delle quattro si è attivata dice già dove guardare, e il log UTM di sottotipo SSL lo registra.

Sulla revoca, la CRL è la lista dei certificati firmati da CA valide che non vanno più considerati attendibili: si importa da file oppure, meglio, in Online Updating via HTTP, LDAP o SCEP, così resta aggiornata da sola. Diverso e indipendente è il blocco dei certificati in blocklist, un pacchetto dinamico distribuito da FortiGuard come parte del servizio di web filtering e attivo di default sui profili SSL.

Attenzione infine a non confondere le due direzioni della fiducia. Importare una CA privata in System > Certificates > CA Certificate serve a far fidare il FortiGate di certificati firmati da quella CA — utenti PKI, LDAPS verso il controller di dominio, peer VPN. Non ha niente a che vedere con il certificato che il FortiGate usa per ri-firmare il traffico ispezionato.