Distribuire il certificato CA di Sophos Firewall per l'ispezione TLS

Quando un Sophos Firewall decripta le connessioni HTTPS tramite ispezione TLS o scansione HTTPS, il firewall crea un nuovo certificato per la connessione ispezionata e lo firma con una CA locale. I client devono fidarsi di questa CA, altrimenti appariranno avvisi del browser o le applicazioni interromperanno la connessione.

In Sophos Firewall è presente di default la CA integrata SecurityAppliance_SSL_CA. Questa CA può essere scaricata sotto Certificates > Certificate authorities e distribuita ai client gestiti. Tuttavia, non basta che sui client sia installata una qualsiasi CA di Sophos. La CA distribuita deve corrispondere a quella effettivamente utilizzata per il Re-Signing nella configurazione di TLS Inspection.

Un ambiente dotato di una propria PKI aziendale può invece emettere una CA subordinata dedicata per la TLS Inspection di Sophos Firewall. Questo percorso mantiene la chiave di firma sul firewall e collega l’attendibilità alla CA radice aziendale esistente, ma richiede un processo PKI e pilota controllato.

SecurityAppliance_SSL_CA non è la CA integrata Default per i certificati firmati localmente. Se occorre ruotare quest’altro trust anchor, si applica la procedura Rinnovare in modo controllato la Default CA di Sophos Firewall. Non sostituire insieme i due oggetti CA sulla base di un sospetto.

A seconda della modalità operativa, questa selezione si verifica in punti diversi: per le SSL/TLS Inspection Rules basate su DPI è rilevante la CA in Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. Un Decryption Profile assegnato alla regola può sostituire questi valori globali. Per il Web Proxy, la HTTPS Scanning CA si trova in Web > General settings > HTTPS decryption and scanning. Se il percorso attivo seleziona una CA diversa da quella considerata attendibile dai client, si verificano errori di certificato anche se è stata distribuita una CA di Sophos.

L’articolo Implementare correttamente l’ispezione TLS di Sophos Firewall descrive l’intero rollout. Questa guida si concentra sulla distribuzione del certificato CA su Windows, macOS e Firefox.

Cosa fa questo certificato

Il certificato CA di Sophos Firewall non è un certificato server per WebAdmin, WAF o VPN Portal. È la base di fiducia con cui i client accettano le connessioni HTTPS nuovamente firmate dal firewall.

È importante la separazione:

• Firewall CA: firma i certificati generati durante l’ispezione TLS.
• Re-Signing CA o HTTPS Scanning CA: la CA selezionata concretamente che il firewall utilizza in modalità DPI o Web Proxy.
• Client Trust Store: decide se i browser e le applicazioni si fidano di questa CA.
• SSL/TLS Inspection Rule: decide quale traffico viene decriptato.
• Decryption Profile: stabilisce quanto rigorosamente vengono trattati i certificati, le versioni TLS e gli errori.
• Exclusion List: impedisce la decriptazione per obiettivi problematici o volutamente esclusi.

La sola distribuzione della CA non attiva l’ispezione TLS. La distribuzione impedisce solo che i client gestiti mostrino avvisi di certificato per il traffico HTTPS decriptato. Se il traffico viene effettivamente decriptato dipende dalle regole del firewall, dalla politica web, dalle regole di ispezione SSL/TLS, dai profili di decriptazione e dalle eccezioni.

Inoltre, la distribuzione della CA non sostituisce un controllo corretto dei protocolli. Le SSL/TLS Inspection Rules si applicano al traffico TCP. Se il traffico web utilizza QUIC o HTTP/3 su UDP 443, l’ispezione segue un percorso diverso e deve essere gestita separatamente.

Prima del rollout

Prima della distribuzione, dovrebbe essere chiaro quali client utilizzeranno l’ispezione TLS. Un certificato CA non dovrebbe essere distribuito indiscriminatamente su ogni dispositivo, ma mirato ai client aziendali gestiti.

Preparazione:

• Definire un gruppo di test o un’unità organizzativa di test.
• Chiarire la modalità operativa: modalità DPI, Web Proxy o entrambe.
• Documentare la CA selezionata in SSL/TLS inspection settings, nei Decryption Profiles utilizzati e in Web General settings.
• Documentare il processo di rollback e di eccezione.
• Scaricare il certificato CA solo dal proprio firewall.
• Testare la distribuzione su pochi dispositivi.
• Verificare browser, applicazioni aziendali e aggiornamenti dopo la distribuzione.
• Valutare separatamente dispositivi mobili e app con un proprio Trust Store o Certificate Pinning.
• Rimuovere i certificati CA vecchi o non più utilizzati dal Client Trust Store.

⚠️ Attenzione: Se la CA o la chiave privata sono state compromesse, una nuova distribuzione non è sufficiente. In tal caso, la CA deve essere rigenerata sul firewall, ridistribuita e la vecchia CA rimossa dai client.

Scegliere il metodo di distribuzione

Il metodo di distribuzione corretto dipende da come vengono gestiti i dispositivi.

• Client Windows di dominio: GPO in Trusted Root Certification Authorities. pulito per ambienti Active Directory classici.
• Windows senza dominio: MDM, Intune o importazione locale. importazione locale solo per test o dispositivi singoli.
• macOS: Profilo MDM o portachiavi System. installazione manuale solo per test o piccoli ambienti.
• Firefox: Utilizzare il Trust Store di Windows o le Mozilla Enterprise Policies. il comportamento di Firefox deve essere verificato separatamente.
• BYOD o dispositivi privati: normalmente non distribuire. l’ispezione TLS appartiene ai dispositivi aziendali gestiti.
• Server: solo per carichi di lavoro server consapevolmente ispezionati. il traffico server in uscita può avere altri rischi ed eccezioni.

Per l’operatività produttiva è fondamentale che lo stesso rollout possa essere successivamente ritirato. Chi distribuisce la CA tramite GPO, MDM o Policy dovrebbe quindi anche testare la rimozione della vecchia CA.

Scaricare la CA di Sophos Firewall

Sul Sophos Firewall, il certificato viene scaricato dall’interfaccia web:

1. Accedere come amministratore al Sophos Firewall.
2. Aprire Certificates > Certificate authorities.
3. Cercare la CA SecurityAppliance_SSL_CA o la CA personalizzata utilizzata consapevolmente.
4. Scaricare il certificato tramite l’icona di download.
5. Verificare quindi che la stessa CA sia selezionata nella configurazione attiva di TLS Inspection.

Il certificato sarà solitamente disponibile come SecurityAppliance_SSL_CA.pem. Questo file contiene la parte pubblica della CA e può essere distribuito ai client. La chiave privata non deve essere distribuita ai client.

Il file dovrebbe essere trattato come un elemento di configurazione rilevante per la sicurezza. La parte pubblica non è una password, ma definisce a quale CA i client si fideranno in futuro. Pertanto, il file dovrebbe provenire dal proprio firewall produttivo, essere versionato o almeno tracciabile e non essere riutilizzato da vecchi progetti.

Per controllare la CA attiva esistono due percorsi aggiuntivi:

• Modalità DPI: aprire Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings e confrontare la CA selezionata con il file scaricato. Se la regola attiva utilizza un Decryption Profile, controllare anche la relativa Re-Signing CA.
• Web Proxy: aprire Web > General settings > HTTPS decryption and scanning e controllare la HTTPS Scanning CA.

Questa verifica evita un errore frequente di rollout: sui client viene distribuita la CA standard, mentre il firewall utilizza già una CA diversa in un Decryption Profile o nel Web Proxy.

Distribuire il certificato su Windows tramite GPO

Negli ambienti Active Directory, una policy di gruppo è il modo più pulito. Edge, Chrome e molte applicazioni Windows si fidano del certificato di Windows.

Percorso consigliato nella gestione delle policy di gruppo:

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

Procedura:

1. Aprire la gestione delle policy di gruppo su un Domain Controller o client amministrativo.
2. Utilizzare una GPO esistente per la baseline dei client o creare una nuova GPO per il gruppo di test dell’ispezione TLS.
3. Passare al percorso Trusted Root Certification Authorities > Certificates.
4. Fare clic con il tasto destro nell’elenco dei certificati.
5. Selezionare All Tasks > Import.
6. Importare SecurityAppliance_SSL_CA.pem.
7. Collegare la GPO solo con l’OU o il gruppo di sicurezza desiderato.
8. Eseguire gpupdate /force su un client di test o attendere l’aggiornamento regolare.

Per ambienti produttivi, la GPO non dovrebbe essere applicata direttamente a tutti i computer. Un’OU di test riduce il rischio se un certificato è stato importato erroneamente o un’applicazione reagisce inaspettatamente.

Installare localmente il certificato su Windows

Per singoli dispositivi di test, il certificato può essere importato localmente. Ci sono due varianti sensate:

• Local Computer Store: valido per tutti gli utenti sul dispositivo ed è solitamente corretto per i client gestiti.
• Current User Store: valido solo per l’utente connesso ed è a volte sufficiente per i test.

Per il computer locale:

1. Accedere come amministratore locale.
2. Avviare certlm.msc.
3. Aprire Trusted Root Certification Authorities > Certificates.
4. Fare clic con il tasto destro nell’elenco dei certificati.
5. Selezionare All Tasks > Import.
6. Importare SecurityAppliance_SSL_CA.pem.

Per l’utente corrente, può essere utilizzato alternativamente certmgr.msc.

Dopo l’importazione, i browser e le applicazioni dovrebbero essere riavviati. Per alcune applicazioni, è utile una disconnessione o un riavvio del client.

Fidarsi del certificato nel portachiavi di macOS

Su macOS, il certificato viene importato tramite la gestione del portachiavi.

Procedura:

1. Copiare SecurityAppliance_SSL_CA.pem sul Mac.
2. Aprire il certificato con un doppio clic.
3. Fornire nel portachiavi System o in un profilo MDM gestito.
4. Aprire il certificato e impostare Always Trust sotto Trust.
5. Confermare la modifica con un account amministrativo.
6. Riavviare browser e applicazioni interessate.

In ambienti macOS più grandi, la distribuzione dovrebbe avvenire tramite MDM. L’installazione manuale è più adatta per test o dispositivi singoli.

Dispositivi mobili con Sophos Mobile

Per un numero elevato di dispositivi Android, iOS e iPadOS gestiti, la CA va distribuita tramite una policy MDM. Sophos Mobile può aggiungere il certificato radice direttamente alla policy già assegnata ai dispositivi. Apple consiglia MDM o Apple Configurator; con Apple Configurator occorre prima creare un profilo di configurazione su macOS.

Esempio per iOS e iPadOS in Sophos Mobile:

1. Aprire Policies > iOS & iPadOS.
2. Selezionare la policy già assegnata ai dispositivi previsti.
3. Nella pagina Edit policy, selezionare Add > Root certificate.
4. In Root certificate, utilizzare Upload a file per caricare esclusivamente il certificato CA pubblico che i dispositivi devono considerare attendibile in base alla catena pianificata. Per SecurityAppliance_SSL_CA, si tratta della parte pubblica scaricata da SFOS.
5. Salvare con Apply e poi Save.
6. Nell’elenco delle policy, utilizzare la freccia e selezionare Update devices. Se l’opzione non è disponibile, la modifica viene distribuita alla successiva sincronizzazione automatica.

Per Android, il certificato radice viene aggiunto in modo analogo a una policy Android. In seguito non basta controllare lo stato della policy. In iOS, la verifica si trova in Settings > General > About > Certificate Trust Settings; in Android, in Settings > Security > Advanced > Encryption & credentials > User credentials. Una richiesta HTTPS realmente decrittografata rimane la prova conclusiva.

La chiave privata della CA di ri-firma non deve mai essere inserita in Sophos Mobile o su un endpoint. Viene distribuito solo il certificato pubblico della CA. Iniziare con un piccolo gruppo pilota e testare anche la rimozione della CA.

Verificare il certificato sui dispositivi gestiti

Dopo la distribuzione, si dovrebbe verificare su almeno un dispositivo di test per piattaforma se la CA è effettivamente finita nel Trust Store corretto.

• Windows Computer Store: Aprire certlm.msc e cercare sotto Trusted Root Certification Authorities > Certificates.
• Windows Current User Store: Aprire certmgr.msc e controllare il Trust Store dell’utente.
• macOS: Aprire la gestione del portachiavi e controllare lo stato di fiducia nel portachiavi System.
• Firefox: Aprire Settings > Privacy & Security > Certificates > View Certificates.

Se un certificato si trova solo nel Trust Store dell’utente, ma un’applicazione si aspetta il Trust Store del computer, il browser potrebbe funzionare e un’altra applicazione potrebbe comunque mostrare errori di certificato. Al contrario, i browser con un proprio Trust Store possono ignorare la distribuzione di Windows o macOS se non sono configurati di conseguenza.

Firefox su Windows

Le versioni attuali di Firefox su Windows cercano per impostazione predefinita nell’archivio certificati del sistema operativo le Root CA installate in aggiunta. Se la CA di Sophos Firewall viene distribuita tramite GPO nel Windows Computer Store, normalmente non è quindi necessario importarla una seconda volta in un database separato di Firefox. Questo comportamento è controllato in Firefox da Allow Firefox to automatically trust third-party root certificates you install, dalla preferenza security.enterprise_roots.enabled o dalla policy aziendale ImportEnterpriseRoots.

Negli ambienti Windows gestiti esistono quindi due percorsi sensati:

• Utilizzare il Windows Trust Store: percorso standard consigliato quando la CA viene già distribuita tramite una GPO computer. L’uso automatico delle CA del sistema operativo deve rimanere attivo nella configurazione gestita di Firefox.
• Importare direttamente il certificato tramite una Mozilla Enterprise Policy: alternativa quando il trust di Firefox viene gestito intenzionalmente in modo separato o non si deve utilizzare il Trust Store del sistema operativo.

Con il primo percorso, la CA ereditata da Windows può funzionare senza apparire come voce importata separatamente nella gestione dei certificati di Firefox. In questo caso fanno fede il Windows Computer Store e un test HTTPS reale. Le istruzioni GPO seguenti descrivono il secondo percorso con Install Certificates.

Scaricare i modelli GPO di Firefox

Mozilla fornisce i modelli di policy su GitHub. Sono necessari, tra gli altri:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

I file possono essere scaricati dal Mozilla Policy Templates Repository o come policy_templates.zip.

Importare i modelli

I file ADMX e ADML vengono copiati nel percorso centrale PolicyDefinitions.

Percorso locale tipico:

C:\Windows\PolicyDefinitions

In un Central Store nel dominio, viene invece utilizzata la cartella PolicyDefinitions sotto SYSVOL.

Configurare la policy di Firefox

Nella policy di gruppo, il certificato viene quindi inserito sotto le policy di Firefox:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedura:

1. Attivare la policy Install Certificates.
2. Inserire il nome del file del certificato, ad esempio SecurityAppliance_SSL_CA.pem.
3. Copiare il file del certificato tramite GPO o distribuzione software nella directory del profilo utente prevista.

A seconda della versione di Firefox e della configurazione delle policy, i certificati vengono letti da queste directory:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Dopo la prossima sessione di Firefox, il certificato dovrebbe essere visibile nella gestione dei certificati di Firefox.

Mozilla descrive il trust consigliato del sistema operativo e l’importazione tramite policy in Set up Certificate Authorities (CAs) in Firefox. Percorsi e varianti aggiuntivi sono documentati nel Wiki: Aggiungere un certificato radice a Firefox.

Verificare il funzionamento

Dopo la distribuzione, non si dovrebbe solo verificare se il certificato è presente. È fondamentale verificare se l’ispezione TLS funziona correttamente.

Test sensati:

1. Riavviare il client di test o riconnettere l’utente.
2. Aprire il browser e accedere a una pagina HTTPS decriptata dal Sophos Firewall.
3. Visualizzare il certificato del sito web nel browser.
4. Verificare se la catena di certificati passa attraverso SecurityAppliance_SSL_CA o esattamente la CA Sophos scelta.
5. Verificare nel Log Viewer > SSL/TLS inspection del firewall se il traffico viene visualizzato come decriptato e quale Rule o azione è stata applicata.
6. Testare applicazioni aziendali importanti, servizi di aggiornamento, strumenti di collaborazione e provider di identità.

Se l’avviso del browser scompare, ma le applicazioni continuano a mostrare errori, il problema spesso non è nel certificato stesso. Spesso sono il Certificate Pinning, le eccezioni TLS mancanti, un profilo di decriptazione errato o una regola di ispezione SSL/TLS inadeguata la causa.

Se il browser continua a mostrare il certificato pubblico originale del sito, questa connessione non è stata decriptata. In tal caso non si applica una SSL/TLS Inspection Rule adeguata, un’eccezione ha priorità, il traffico prende un altro percorso oppure QUIC/HTTP/3 evita il percorso TCP atteso.

Per il traffico web, dovrebbe essere inoltre verificato se QUIC o HTTP/3 aggirano l’ispezione prevista. L’articolo Bloccare correttamente QUIC e HTTP/3 su Sophos Firewall spiega perché Block QUIC protocol rimane rilevante per il filtraggio web, la scansione malware e l’ispezione TLS.

Errori tipici

• Il browser continua a mostrare avvisi di certificato: CA non nel Trust Store corretto. Verificare il certificato di Windows/macOS/Firefox.
• La CA è installata, ma l’avviso resta: La CA distribuita potrebbe non corrispondere alla CA nel Decryption Profile, negli SSL/TLS inspection settings o in Web General settings.
• DPI funziona, Web Proxy no o viceversa: I due percorsi possono essere configurati diversamente. Verificare CA scelta, percorso regola e Log Viewer per ogni modalità.
• Chrome funziona, Firefox no: verificare se Firefox può utilizzare le Root CA installate in aggiunta nel sistema operativo o se si applica una Mozilla Enterprise Policy separata. Riavviare quindi Firefox e testare il percorso HTTPS reale.
• Alcune applicazioni si interrompono: Certificate Pinning o verifica del certificato propria. Verificare il Log Viewer dell’ispezione TLS e le eccezioni.
• Solo alcuni client funzionano: La GPO non si applica o OU errata. Verificare gpresult e il collegamento GPO.
• Dopo la rigenerazione della CA ci sono avvisi: vecchia CA ancora sui client o nuova CA mancante. rimuovere la vecchia CA, distribuire la nuova CA.
• I feed URL o il filtro web non funzionano come previsto: Il percorso HTTPS non viene decriptato. Verificare l’ispezione TLS e la politica web.
• Il certificato è presente, ma il traffico non viene decriptato: Nessuna regola di ispezione SSL/TLS adatta o percorso DPI/Web-Proxy errato. Verificare il rollout TLS, la regola del firewall e il Log Viewer.
• Solo le app mobili o alcuni client si interrompono: Trust Store proprio, Certificate Pinning o verifica app-specifica. In particolare traffico Android e Mobile App dovrebbe essere testato in modo mirato ed escluso se necessario, invece di distribuire la CA in modo ampio e cieco.

Rotazione della CA e emergenza

Una CA non dovrebbe essere gestita inosservata per anni senza che la data di scadenza, l’origine e la distribuzione siano noti. Per ambienti produttivi dovrebbe esserci un piccolo processo di ciclo di vita.

Cambio pianificato:

1. Preparare una nuova CA o una nuova CA del firewall.
2. Distribuire la nuova CA a un gruppo di test.
3. Verificare l’ispezione TLS con il gruppo di test.
4. Distribuire la nuova CA a tutti i dispositivi gestiti interessati.
5. Controllare le regole del firewall e i profili di decriptazione.
6. Rimuovere la vecchia CA solo quando tutti i dispositivi produttivi hanno ricevuto la nuova CA.

Emergenza in caso di compromissione:

1. Limitare o disattivare temporaneamente l’ispezione TLS se necessario.
2. Sostituire la CA compromessa sul firewall.
3. Distribuire la nuova CA tramite il percorso di distribuzione definito.
4. Rimuovere la vecchia CA da tutti i Trust Store.
5. Verificare eccezioni, Log Viewer e applicazioni interessate.
6. Documentare la modifica nel sistema di incident o change.

Importante: Una CA compromessa non è un normale problema di certificato. Se un attaccante controlla la chiave privata, i client possono fidarsi di certificati falsi. In tal caso, la vecchia CA deve essere rimossa in modo coerente.

Operatività e manutenzione

Il certificato CA dovrebbe far parte del processo operativo:

• Documentare la data di scadenza e i responsabili.
• Rigenerare la CA solo pianificata.
• Rimuovere la vecchia CA dai client dopo la migrazione.
• Verificare regolarmente la distribuzione tramite GPO o MDM.
• Documentare e rivedere periodicamente le eccezioni TLS.
• Rigenerare la CA in caso di perdita del dispositivo o compromissione della CA.

In caso di modifica all’ispezione TLS, si dovrebbero anche verificare le regole del firewall, i profili di decriptazione e le liste di esclusione interessate. Altrimenti, il client si fida della CA, ma il firewall non decripta comunque il traffico desiderato.

FAQ