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.

Oltre alla CA integrata, è possibile importare una CA di firma generata esternamente oppure creare sul firewall una Certificate Signing Request (CSR) e far emettere una CA di firma subordinata da una CA esterna, ad esempio Active Directory Certificate Services. In questo caso, sul firewall vanno importate sia la CA di firma subordinata sia la sua CA radice. Ai client servono l’ancora di fiducia pubblica corrispondente e la catena pubblica necessaria, non la chiave privata di firma. La procedura PKI collegata spiega l’emissione; i passaggi seguenti coprono selezione, distribuzione e verifica.

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: utilizzare una GPO per distribuire il certificato in Trusted Root Certification Authorities. È il metodo consigliato negli ambienti Active Directory tradizionali.
• Windows senza dominio: utilizzare MDM, Intune o l’importazione locale. Quest’ultima è più adatta ai test o ai singoli dispositivi che a una distribuzione su larga scala.
• macOS: utilizzare un profilo MDM oppure il portachiavi System. Riservare l’installazione manuale ai test o agli ambienti di piccole dimensioni.
• Firefox: utilizzare l’archivio certificati di Windows oppure distribuire le Mozilla Enterprise Policies. Verificare separatamente il comportamento di Firefox: la distribuzione sul sistema operativo non basta a dimostrare che il browser consideri attendibile la CA.
• BYOD o dispositivi privati: di norma, non distribuire la CA su questi dispositivi. L’ispezione TLS è destinata ai dispositivi aziendali gestiti.
• Server: distribuire la CA solo dopo aver valutato l’ispezione dei carichi di lavoro interessati. Il traffico HTTPS in uscita dai server può comportare rischi diversi e richiedere eccezioni specifiche.

In produzione deve essere possibile annullare la distribuzione. Chi distribuisce la CA tramite GPO, MDM o criteri dovrebbe quindi verificare anche come rimuovere il vecchio certificato CA dai client.

Scaricare la CA di Sophos Firewall

Preparare la regola Web Proxy e la CA

Per un pilota Web Proxy, aprire Rules and policies > Firewall rules, scegliere IPv4 o IPv6 e creare una regola tramite Add firewall rule > New firewall rule. Ad esempio, usare il nome libero TLS-CA-Pilot, impostare Source zones su LAN, Source networks and devices sulla rete pilota, Destination zones su WAN e Destination networks sulle destinazioni previste. Adattare zone, reti e destinazioni al percorso effettivo; non autorizzare indiscriminatamente tutti i client per una prova del certificato.

Prima di apportare modifiche, registrare i valori precedenti della regola e la CA selezionata per il rollback. Verificare separatamente HTTPS scanning certificate authority (CA) in Web > General settings > HTTPS decryption and scanning, distribuire prima il suo certificato pubblico a tutti i dispositivi pilota interessati e verificarne l’attendibilità tramite fingerprint. La CA condivisa del Web Proxy è globale: cambiarla non è un pilota di CA per singola regola, interessa tutti i client Web Proxy e richiede che siano già configurati per considerarla attendibile, oltre a una finestra di manutenzione.

Solo dopo, nella regola del firewall selezionata, scegliere la policy web appropriata in Security features > Web filtering, attivare Scan HTTP and decrypted HTTPS, Use web proxy instead of DPI engine ed esplicitamente Decrypt HTTPS during web proxy filtering, quindi salvare con Save. La sola opzione di scansione non decripta; selezionare la CA in Web > General settings non sostituisce il controllo di decriptazione nella regola del firewall.

Durante la configurazione iniziale, verificare in Certificates > Certificate authorities > Default che tutte le impostazioni della Default CA siano configurate. È un controllo, non un invito a rigenerare la CA o a distribuire Default al posto della SecurityAppliance_SSL_CA attiva.

Scaricare il certificato pubblico della CA

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.

Per un pilota manuale, rendere disponibile il file pubblico verificato tramite l’intranet aziendale o un invio e-mail controllato. Gli utenti lo salvano localmente e ne confrontano l’identità con i dettagli del certificato documentati separatamente prima di accordare il trust. Per gruppi più grandi restano preferibili GPO o MDM.

In SFOS 22 è possibile scaricare la CA effettivamente selezionata anche direttamente nel punto in cui viene utilizzata. Nel percorso DPI, l’icona di download compare accanto a Re-sign RSA with e Re-sign EC with. Se sono selezionate due CA diverse, i client interessati devono considerarle entrambe attendibili. Nel percorso Web Proxy, l’icona compare accanto a HTTPS scanning certificate authority (CA). Scaricare la CA nel punto di utilizzo riduce il rischio di distribuire un oggetto con nome simile ma non attivo.

Il file dovrebbe essere trattato come un elemento di configurazione rilevante per la sicurezza. La parte pubblica non è una password, ma definisce quale CA sarà considerata attendibile dai client. Il file deve quindi provenire dal firewall di produzione, essere versionato o almeno conservato in modo tracciabile e non essere riutilizzato da vecchi progetti. Prima della distribuzione, registrare Subject, Issuer, numero di serie, periodo di validità e fingerprint mostrati nei dettagli del certificato. Dopo l’importazione, confrontare questi valori su almeno un client pilota; il solo nome visualizzato non è una prova affidabile dell’identità.

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, i criteri di gruppo sono il metodo consigliato. Edge, Chrome e molte applicazioni Windows utilizzano l’archivio certificati di Windows per verificare l’attendibilità della CA.

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 all’OU di test prevista. Se necessario, usare un gruppo di sicurezza tramite il filtro di sicurezza, non come destinazione del collegamento GPO.
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.

Impostare l’attendibilità del certificato nel portachiavi di macOS

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

Per un singolo utente è possibile anche il portachiavi login: aprire il file scaricato con un doppio clic in Keychain Access, verificarne l’identità e selezionare Always Trust. Anche Safari utilizza questo trust di macOS. Per un rollout gestito sull’intero dispositivo restano appropriati System o MDM; non confondere l’ambito utente con quello di sistema.

Procedura:

1. Copiare SecurityAppliance_SSL_CA.pem sul Mac.
2. Aprire il certificato con un doppio clic.
3. Importare il certificato nel portachiavi System oppure distribuirlo tramite 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

⚠️ Android: l’installazione non autorizza la decriptazione. Sophos documenta l’importazione della CA, ma raccomanda anche di escludere tutti i dispositivi Android dall’ispezione SSL/TLS in modalità DPI a causa degli errori di certificato. Questa guida adotta quindi l’esclusione DPI per tutti i dispositivi Android come impostazione predefinita. I successivi passaggi Android di importazione e test HTTPS si applicano solo a un pilota su dispositivi gestiti, ristretto e approvato separatamente: un’esigenza aziendale documentata deve giustificare la deroga per dispositivi e applicazioni identificati. Verificare l’archivio di attendibilità effettivamente usato e ogni applicazione interessata prima dell’approvazione; in caso di errore, annullare il pilota e ripristinare l’esclusione. L’installazione tramite MDM non risolve né il Certificate Pinning né l’attendibilità per tutte le app. La raccomandazione DPI non è un’affermazione generale sulla compatibilità del Web Proxy; anche quel percorso richiede una verifica separata delle applicazioni.

Pilota mobile manuale

Se il dispositivo non accetta il file PEM, può essere necessaria una conversione in un formato compatibile come .der, .cer o .crt. La sola estensione non determina la codifica; non usare mai un file di chiave privata. Le voci variano in base a versione Android e produttore. Un esempio Pixel usa Settings > Security & location > Advanced > Encryption & credentials:

1. In Credential storage, scegliere Install from storage o Install from SD card.
2. Nel selettore di file, scegliere la posizione con Menu > Open from e aprire il certificato pubblico.
3. Inserire il PIN del dispositivo, assegnare un nome riconoscibile al certificato e scegliere VPN and apps per questo pilota applicativo; Wi-Fi è l’altra categoria proposta. Confermare con OK.
4. Verificare identità e importazione in User credentials, poi provare una richiesta HTTPS decrittografata. Un’importazione riuscita non garantisce che ogni app Android si fidi dell’archivio certificati utente.

Per un pilota iOS manuale, fornire e importare il file CA pubblico sul dispositivo. In Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates, accordare fiducia solo al certificato radice identificato e provare HTTPS. Non attivare più CA radice sconosciute.

Distribuire tramite la policy del dispositivo

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. Collegare quindi uno o più dispositivi iOS al Mac per installare il profilo contenente il certificato della CA.

Esempio per iOS e iPadOS in Sophos Mobile:

I certificati radice installati sui dispositivi iOS e iPadOS tramite MDM o Apple Configurator sono automaticamente attendibili, a differenza dell’importazione manuale. Il controllo seguente non richiede di modificare un’impostazione di trust già attiva.

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.

In iOS, controllare in questa schermata lo stato di attendibilità del certificato radice previsto, dopo averne verificato l’identità tramite il fingerprint documentato. Se l’attendibilità è ancora disattivata, attivarla in Enable full trust for root certificates esclusivamente per quel certificato radice. Se è già attendibile, lasciare l’impostazione invariata; quindi ripetere la richiesta HTTPS decrittografata per verificare il risultato.

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

Per un singolo profilo di test è possibile anche l’importazione manuale: aprire Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import, selezionare il file CA pubblico e fare clic su Open. In Downloading Certificate, attivare solo Trust this CA to identify websites per la CA di cui è già stata verificata l’identità, poi selezionare OK. Riavviare Firefox e provare il percorso HTTPS decrittografato. Questa importazione nel profilo non sostituisce la distribuzione centralizzata.

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

Copiare firefox.admx e mozilla.admx direttamente nella cartella PolicyDefinitions scelta. I file corrispondenti firefox.adml e mozilla.adml vanno invece nella relativa sottocartella della lingua, non accanto ai file ADMX.

Percorso locale tipico:

C:\Windows\PolicyDefinitions

Per il Central Store del dominio, utilizzare invece \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions. Sostituire entrambe le occorrenze di <domain> con il nome DNS del dominio AD. Se esiste un Central Store, distribuire lì i modelli Mozilla; una copia nella sola cartella locale non basta per modificare le GPO del dominio.

Conservare le cartelle delle lingue presenti nel pacchetto scaricato e utilizzare file ADMX e ADML della stessa versione dei modelli. Ad esempio, collocare gli ADML inglesi in C:\Windows\PolicyDefinitions\en-US oppure, se si utilizza il Central Store, in \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Copiare le altre lingue necessarie nelle rispettive sottocartelle del pacchetto. en-US è un esempio di lingua dei modelli, non un requisito legato alla lingua di questo articolo.

Riaprire l’editor dei criteri di gruppo e verificare che Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates sia visibile senza errori di risorse. Se il criterio manca, correggere la cartella di destinazione, la sottocartella della lingua e la corrispondenza delle versioni prima di proseguire con la configurazione del certificato.

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.

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. Correlare la nuova richiesta sul firewall per origine, destinazione e orario, identificare la modalità effettiva e seguire le verifiche corrispondenti riportate di seguito.
6. Testare applicazioni aziendali importanti, servizi di aggiornamento, strumenti di collaborazione e provider di identità.

DPI: In Rules and policies > SSL/TLS inspection rules, verificare la regola di ispezione corrispondente, l’azione, il Decryption Profile e la CA di rifirma. In Log Viewer > SSL/TLS inspection, correlare la stessa nuova richiesta per origine, destinazione e orario, quindi verificare la decriptazione e la regola o l’azione applicata. Controllare anche le esclusioni DPI.

Web Proxy: Confermare la regola del firewall effettivamente applicata, la sua policy web e Decrypt HTTPS during web proxy filtering. Verificare la HTTPS scanning certificate authority (CA) condivisa in Web > General settings e le eccezioni applicabili in Web > Exceptions. In Log Viewer, correlare i log pertinenti del filtro web/proxy per la stessa nuova richiesta usando origine, destinazione e orario; l’emittente e la catena del certificato nel browser devono corrispondere alla CA selezionata. Le regole di ispezione SSL/TLS non controllano la decriptazione del Web Proxy. Qui una voce di decriptazione DPI non è né garantita né richiesta; una voce del filtro web da sola non dimostra la decriptazione.

Se l’avviso del browser scompare ma le applicazioni mostrano ancora errori, spesso la causa non è il certificato. Può trattarsi di Certificate Pinning o di un archivio di attendibilità separato. In DPI, controllare anche Decryption Profile, regola di ispezione ed esclusioni TLS; per Web Proxy, regola del firewall ed eccezioni web secondo le verifiche precedenti.

Se il browser continua a mostrare il certificato pubblico originale del sito, la connessione non è stata decriptata. In DPI, verificare la regola di ispezione e le sue esclusioni; per Web Proxy, la regola del firewall corrispondente, il controllo di decriptazione e le eccezioni web. Anche un altro percorso del traffico o QUIC/HTTP/3 può aggirare 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: la CA potrebbe non trovarsi nell’archivio certificati corretto. Verificare l’archivio certificati di Windows, macOS o 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: Usare le verifiche della modalità effettiva riportate sopra: regola di ispezione, profilo e log SSL/TLS per DPI; regola del firewall, controllo di decriptazione, CA condivisa, eccezioni web e log del filtro web/proxy per Web Proxy.
• 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 interrompono la connessione: Le cause probabili sono il Certificate Pinning o una verifica propria del certificato. In DPI, controllare log SSL/TLS ed esclusioni TLS; per Web Proxy, log del filtro web/proxy e Web > Exceptions, sempre per la stessa richiesta.
• Solo alcuni client funzionano: la GPO potrebbe non essere applicata o essere collegata alla OU sbagliata. Verificare il risultato di gpresult e il collegamento della GPO.
• Dopo la rigenerazione della CA ci sono avvisi: sui client potrebbe mancare la nuova CA attiva. Distribuire prima la nuova CA pubblica e verificarne il fingerprint. Rimuovere una vecchia CA non compromessa solo quando nessun percorso attivo la usa più; in caso di compromissione, seguire la procedura di emergenza.
• 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: In DPI può mancare una regola di ispezione corrispondente; per Web Proxy può mancare il controllo di decriptazione della regola del firewall o applicarsi un’eccezione web. Usare le verifiche specifiche della modalità e confermare il percorso effettivo del traffico.
• Solo le app mobili o alcuni client interrompono la connessione: Considerare archivi di attendibilità separati, Certificate Pinning e verifica specifica dell’applicazione. Escludere Android da DPI per impostazione predefinita; un pilota Android approvato separatamente deve tornare all’esclusione in caso di errore. Valutare altre eccezioni mirate invece di disattivare globalmente l’ispezione.

Rotazione della CA e emergenza

Una CA non dovrebbe essere utilizzata per anni senza controllarne scadenza, origine e distribuzione. In produzione è opportuno prevedere un semplice processo di gestione del ciclo di vita della CA.

La CA integrata SecurityAppliance_SSL_CA può essere rigenerata. Questa operazione non è però un passaggio preparatorio privo di rischi: la vecchia e la nuova CA non diventano automaticamente attendibili in parallelo su tutti i client. Per una transizione DPI pianificata con sovrapposizione, utilizzare una CA di firma preparata separatamente e provarla tramite un Decryption Profile con ambito ristretto. Il Web Proxy, invece, dispone della sola HTTPS scanning certificate authority (CA) globale. La sua modifica interessa l’intero percorso Web Proxy e richiede quindi una finestra di manutenzione; la nuova CA pubblica deve essere già considerata attendibile da tutti i client interessati. In entrambi i casi, la chiave privata resta sul firewall.

Cambio pianificato:

1. Registrare la selezione CA attiva, i fingerprint e tutti i riferimenti. Preparare una CA di firma separata senza rigenerare la CA integrata come primo passo.
2. Distribuire solo il certificato pubblico o la catena CA pubblica necessaria: prima al gruppo pilota DPI, oppure a tutti i client interessati prima di una modifica globale del Web Proxy.
3. In modalità DPI, attivare la nuova CA mediante un Decryption Profile con ambito ristretto e verificare l’Issuer, la voce di log e le applicazioni del gruppo pilota.
4. Dopo il buon esito del pilota DPI, distribuire il certificato pubblico a tutti i dispositivi gestiti interessati e confermare l’importazione tramite fingerprint.
5. Modificare i restanti campi DPI oppure la CA globale del Web Proxy. Con nuove connessioni, verificare che firmi la nuova CA e che venga applicata la regola prevista.
6. Rimuovere la vecchia CA dai Trust Store dei client solo quando nessun percorso di ispezione vi fa più riferimento e tutti i dispositivi interessati 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.

Per un rollback normale, ripristinare prima nel percorso di ispezione la CA documentata in precedenza oppure disattivare la regola pilota. Rimuovere la CA distribuita solo per il pilota soltanto dopo che una nuova connessione mostra di nuovo il vecchio Issuer o il percorso originale non decriptato. Revocare prima il trust dei client mentre il firewall continua a firmare con quella CA provoca errori di certificato. Non eliminare CA condivise o ancora referenziate.

Operatività e manutenzione

Il certificato CA dovrebbe far parte del processo operativo:

• Documentare la data di scadenza e i responsabili.
• Rigenerare la CA solo nell’ambito di un intervento pianificato.
• Rimuovere la vecchia CA dai client dopo la migrazione.
• Verificare regolarmente la distribuzione tramite GPO o MDM.
• Documentare e rivedere periodicamente le eccezioni TLS.
• Avviare il processo di incident e cambio CA se si sospetta la compromissione della chiave privata di firma o del firewall. La perdita di un client che contiene solo il certificato CA pubblico non compromette la chiave di firma.

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