Configurare una CA subordinata per la TLS Inspection di Sophos Firewall

Per la TLS Inspection, Sophos Firewall deve firmare nuovamente i certificati delle destinazioni HTTPS visitate. Invece di utilizzare la CA integrata SecurityAppliance_SSL_CA, è possibile usare una CA aziendale subordinata dedicata. I client gestiti continuano così a considerare attendibile la CA radice dell’azienda, mentre la chiave privata della CA subordinata rimane sul firewall.

La procedura sicura comprende sei passaggi:

1. Generare su Sophos Firewall una CSR per la nuova CA subordinata.
2. Fare firmare la CSR da una Enterprise CA Microsoft AD CS con il modello Subordinate Certification Authority.
3. Importare il certificato CA emesso direttamente nella CSR esistente.
4. Aggiungere al firewall la CA radice corrispondente come Validation only.
5. Selezionare la CA subordinata come CA di ri-firma e utilizzarla inizialmente solo in una regola pilota.
6. Verificare la catena dei certificati, il traffico HTTPS reale, i log e il rollback.

⚠️ Una CA di ri-firma può emettere certificati per domini di terzi. La sua chiave privata è quindi particolarmente sensibile. La CA deve essere utilizzata solo per il percorso di inspection previsto e non deve essere esportata o condivisa nei ticket. Non va attivata in produzione senza un percorso di ripristino verificato.

Questa procedura è descritta per AD CS in modalità Enterprise CA. Sophos specifica espressamente che la procedura documentata non è applicabile a una Standalone CA. Anche un’altra PKI interna può emettere una CA subordinata, ma richiede una procedura propria verificata dal responsabile della PKI.

Quando è utile una CA subordinata

Una CA subordinata dedicata è particolarmente adatta alle reti aziendali gestite nelle quali i client considerano già attendibile una CA radice interna. In questo modo non è necessario distribuire a ogni dispositivo un ulteriore trust anchor Sophos indipendente. Rotazione, revoca e responsabilità possono essere integrate nella governance della PKI esistente.

La soluzione, tuttavia, non è automaticamente più semplice. Il firewall riceve una chiave con cui può firmare certificati per la TLS Inspection. La CA richiede quindi uno scopo definito in modo restrittivo, responsabili documentati, una validità limitata e procedure verificate di revoca e rinnovo.

Per gli ambienti più piccoli privi di una PKI interna, la CA Sophos integrata è spesso la soluzione più semplice. Distribuire il certificato CA di Sophos Firewall per la TLS Inspection ne spiega la selezione e la distribuzione ai client. Introdurre correttamente la TLS Inspection di Sophos Firewall descrive l’intero processo pilota e di gestione delle eccezioni.

Preparare il design della CA e il percorso di ripristino

Prima di generare la CSR si definiscono scopo, nomi e dipendenze. Un possibile esempio è:

• nome dell’oggetto SFOS: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• CA radice emittente: Example Enterprise Root CA
• utilizzo previsto: esclusivamente TLS Inspection e HTTPS Decryption su FW01
• rete pilota: 10.20.30.0/24

Questi valori sono esempi di documentazione e vanno sostituiti con la convenzione di denominazione, la PKI e il gruppo pilota della propria organizzazione. Una CA separata per ogni firewall o cluster di inspection chiaramente delimitato semplifica in seguito l’assegnazione, la revoca e la rotazione.

Prima della modifica devono essere disponibili:

• un backup attuale della configurazione e un accesso di gestione indipendente funzionante,
• la documentazione della CA di ri-firma attuale e della sua distribuzione ai client,
• l’accesso a una Enterprise CA AD CS e l’approvazione del responsabile della PKI,
• un piccolo gruppo di test gestito con un percorso di ripristino funzionante,
• un piano per revoca, rinnovo e ritorno controllato alla CA precedente.

Creare e ripristinare un backup di Sophos Firewall spiega la procedura di backup e ripristino. Un backup non sostituisce la documentazione della CA di ri-firma attualmente selezionata e dei client che la considerano attendibile.

Generare la CSR su Sophos Firewall

La CSR viene generata sul firewall affinché la chiave privata venga creata lì e non debba essere trasferita tra AD CS, la postazione di amministrazione e il firewall.

1. Aprire Certificates > Certificates.
2. Selezionare Add.
3. In Action, selezionare Generate certificate signing request (CSR).
4. Inserire un nome univoco, ad esempio SFOS-TLS-Inspection-SubCA-2026.
5. Scegliere tipo e lunghezza della chiave o curva e hash sicuro in base alla policy PKI dell’organizzazione. Nell’esempio Sophos vengono mostrati RSA, 2048 bit e SHA-256; sono valori esemplificativi del prodotto, non requisiti universali.
6. Inserire gli attributi del soggetto e i Subject Alternative Names approvati dalla PKI interna.
7. Salvare la CSR e aprirla tramite l’icona di download.
8. Utilizzare Copy to clipboard e trasmettere la CSR esclusivamente attraverso il processo AD CS autorizzato.

La CSR non contiene la chiave privata. Fa comunque parte del processo PKI controllato perché definisce identità, chiave pubblica e scopo CA richiesto.

Emettere la CA subordinata con AD CS

La CSR di Sophos viene inviata dalla pagina di registrazione Web della Enterprise CA AD CS competente:

1. Aprire Request a certificate.
2. Selezionare Advanced certificate request.
3. Incollare la CSR completa.
4. In Certificate template, selezionare Subordinate Certification Authority.
5. Verificare la richiesta secondo il processo di approvazione interno ed emetterla con Submit.
6. In Certificate Issued, scegliere un formato adeguato, ad esempio Base 64 encoded.
7. Scaricare il certificato della CA subordinata emesso.
8. Scaricare anche il certificato della CA radice che ha firmato la CA subordinata.

Importante limite EKU: Se il certificato CA emesso contiene una sezione Extended Key Usage, questa deve includere TLS Web Server Authentication per tale scopo di firma. Se il valore manca, il certificato non va utilizzato come CA di ri-firma in produzione. Il responsabile della PKI deve correggere il modello CA ed emettere un nuovo certificato.

Prima dell’importazione, nel visualizzatore dei certificati si controllano emittente, soggetto, validità, Basic Constraints ed eventualmente Extended Key Usage. I file radice e subordinato vengono denominati in modo univoco per non confonderli con certificati server.

Importare le CA subordinata e radice

Importare la CA subordinata nella CSR esistente

1. Aprire Certificates > Certificates.
2. Selezionare l’azione di importazione per la CSR creata in precedenza.
3. Scegliere il certificato della CA subordinata emesso da AD CS.
4. Selezionare Certificate authority only. SFOS riconosce il tipo CA e mostra le relative opzioni.
5. Controllare il nome e selezionare Import certificate.
6. Aprire Certificates > Certificate authorities e cercare la CA importata.

SFOS associa automaticamente alla CA subordinata la chiave privata appartenente alla CSR. Nell’elenco delle CA deve quindi essere visibile l’icona della chiave privata per questa CA. Se manca, la CA non è pronta per firmare; caricare nuovamente il file in un altro punto non ripristina l’associazione mancante.

Aggiungere la CA radice solo per la validazione

1. Aprire Certificates > Certificate authorities e selezionare Add.
2. Caricare il certificato della CA radice che ha emesso la CA subordinata.
3. In Use certificate for, mantenere Validation only.
4. Confrontare nome e fingerprint con la documentazione approvata della CA radice.
5. Salvare e ricontrollare la catena della CA subordinata.

Il firewall non necessita della chiave privata della CA radice. Signing and validation è previsto esclusivamente per la CA subordinata la cui chiave privata si trova già sul firewall grazie alla CSR. Importare e assegnare certificati su Sophos Firewall spiega le differenze generali tra certificato, CSR, chiave privata e catena CA.

Selezionare la CA per la TLS Inspection

La sola importazione non modifica il traffico. La nuova CA viene prima attivata in un progetto pilota con ambito ristretto. La posizione della selezione dipende dal percorso di inspection:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile: Profiles > Decryption profiles
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Solo una CA con scopo Signing and validation e chiave privata disponibile può essere utilizzata come CA di ri-firma. Una CA di firma già in uso non deve essere modificata in Validation only, perché il percorso di ri-firma attivo perderebbe la propria chiave.

Per il progetto pilota:

1. Documentare la selezione attuale e le regole interessate.
2. Selezionare la nuova CA nel percorso di inspection previsto.
3. Limitare la regola al gruppo di test o alla rete pilota definiti.
4. Controllare la catena CA sui client pilota. In un dominio AD, la Enterprise Root CA dovrebbe già essere attendibile, ma la catena completa fino alla nuova CA subordinata deve comunque essere costruita correttamente.
5. Generare una richiesta HTTPS reale e controllare insieme dettagli del certificato, Inspection Rule, Decryption Profile e voce di log.

Il passaggio generale in produzione avviene solo dopo il superamento del progetto pilota. La selezione della CA non attiva automaticamente una Inspection Rule e l’attendibilità sul client non prova che il traffico venga effettivamente decrittografato.

Verificare funzionamento e sicurezza

Un test riuscito comprende diverse prove:

1. In Certificates > Certificate authorities, la CA radice è presente come Validation only.
2. Alla CA subordinata è assegnato Signing and validation ed è visibile l’icona della chiave privata.
3. Un client pilota considera attendibile la CA radice e può costruire la catena completa.
4. Un sito HTTPS deliberatamente decrittografato presenta un certificato server firmato dalla nuova CA subordinata.
5. Hostname, destinazione originale e stato del browser sono corretti e non appare alcun avviso imprevisto sul certificato.
6. Log Viewer mostra la SSL/TLS Inspection Rule e l’azione previste per questo test specifico.
7. Una sorgente esterna al progetto pilota rimane sul percorso precedente.

Vanno testate separatamente anche le applicazioni con certificate pinning, trust store propri o percorsi di aggiornamento sensibili. Una singola richiesta riuscita nel browser non è sufficiente per approvare l’intero rollout.

Rotazione e rollback

La CA subordinata deve essere rinnovata prima della scadenza. Durante una transizione controllata, la nuova e la vecchia CA devono rimanere chiaramente distinguibili. La nuova CA viene prima emessa, importata e verificata sui client pilota e solo successivamente selezionata gradualmente nel percorso di inspection.

In caso di errore si utilizza il percorso di ripristino preparato:

1. Disattivare la regola pilota o ripristinare la CA di ri-firma precedente.
2. Verificare con un nuovo processo del browser che venga utilizzato nuovamente il percorso dei certificati precedente.
3. Non eliminare la nuova CA finché regole, Decryption Profiles o impostazioni Web Proxy fanno ancora riferimento a essa.
4. Coinvolgere il responsabile della PKI se EKU, catena, modello o stato di revoca non sono chiari.
5. Non continuare a utilizzare chiavi compromesse; revocare la CA, emetterne una nuova e ripulire i trust store in modo controllato.

Una CA viene eliminata solo quando nessuna configurazione la utilizza più, il vecchio percorso non è più necessario e sono soddisfatti i requisiti di conservazione e audit.

Circoscrivere gli errori

Manca l’icona della chiave privata

Se il certificato non è stato importato tramite la CSR corrispondente, SFOS non può associarlo alla chiave creata sul firewall. Controllare il percorso di associazione della CSR e il certificato emesso. Non importare chiavi private da ticket, e-mail o archivi non controllati.

Non è possibile selezionare la CA per la ri-firma

Controllare scopo della CA, icona della chiave privata ed estensioni del certificato. Se Extended Key Usage è presente, deve includere TLS Web Server Authentication. Una CA radice con Validation only non è intenzionalmente disponibile per la ri-firma.

Un client segnala una catena non attendibile

Controllare CA radice e subordinata, fingerprint e trust store del client interessato. Confrontare quindi l’emittente realmente presentato nel browser con la CA selezionata su SFOS. La semplice presenza della CA radice sul firewall o sul client non dimostra che sia attiva la CA di ri-firma corretta.

Il browser funziona, ma un’applicazione no

L’applicazione può utilizzare un trust store proprio o il certificate pinning. Documentare prima destinazione, client, Inspection Rule e ora dell’errore. Non aggiungere un’eccezione globale Don't decrypt; circoscrivere il problema nel progetto pilota e approvare solo l’eccezione necessaria con una motivazione documentata.

FAQ