Rinnovare in modo controllato la Default CA di Sophos Firewall

La CA integrata Default di Sophos Firewall non è una normale voce descrittiva. Non appena se ne salvano le impostazioni, SFOS rigenera automaticamente la CA. Vengono così creati una nuova chiave e quindi un nuovo trust anchor. Le relazioni di trust precedenti non si adeguano automaticamente.

Un rinnovo controllato non inizia quindi con Save, ma con un elenco completo delle dipendenze. Questo comprende certificati firmati localmente, WebAdmin e portali, profili SSL VPN, peer IPsec basati su certificati e sistemi esterni che considerano attendibile la CA precedente.

⚠️ Importante: Rinnovare la CA Default solo con un backup verificato, un accesso di gestione indipendente, una finestra di manutenzione e un piano per tutti i servizi dipendenti. Una modifica estetica a paese, organizzazione o common name non giustifica una rigenerazione non pianificata.

Rinnovare la Default CA in dieci passaggi

1. Documentare il motivo tecnico, il responsabile della modifica, la finestra di manutenzione e i criteri di successo.
2. Identificare tutti i certificati, i servizi, i profili VPN, i peer e i client che considerano attendibile l’attuale CA Default.
3. Verificare se l’obiettivo effettivo è soltanto l’ApplianceCertificate o la CA separata SecurityAppliance_SSL_CA.
4. Testare con esito positivo il backup di configurazione attuale, SSMK, l’accesso admin locale e il percorso di ripristino.
5. Scaricare la vecchia CA Default e registrare fingerprint SHA-256, subject, numero di serie e validità.
6. Approvare per iscritto i nuovi dati della CA, il tipo di chiave e la compatibilità con tutti i peer.
7. In Certificates > Certificate authorities > Default, inserire i valori preparati e salvarli solo durante la finestra di manutenzione.
8. Scaricare la nuova CA pubblica e distribuirla in modo controllato a peer, client e trust store.
9. Testare separatamente WebAdmin, portali, SSL VPN, IPsec e ogni altro servizio dipendente.
10. Documentare fingerprint, log, risultati dei test e profili precedenti ancora presenti. Utilizzare il percorso di ripristino predisposto in caso di errore critico.

Distinguere Default CA, ApplianceCertificate e Inspection CA

Sophos Firewall contiene più oggetti con funzioni differenti:

• Default: CA interna per i certificati firmati localmente.
• ApplianceCertificate: certificato server integrato utilizzato per impostazione predefinita per WebAdmin, User Portal e Captive Portal. È firmato dalla CA Default e può essere rigenerato separatamente.
• SecurityAppliance_SSL_CA: CA integrata separata per HTTPS Inspection e Re-Signing, se selezionata nella configurazione TLS Inspection.

Questi oggetti non devono essere considerati equivalenti. Un problema con un singolo ApplianceCertificate non dimostra che la CA Default sia difettosa. Allo stesso modo, modificare la CA Default non esegue automaticamente una rotazione pianificata di SecurityAppliance_SSL_CA.

Importare e assegnare certificati su Sophos Firewall spiega le operazioni generali con certificati, chiavi private, CSR e catene CA. Per la Inspection CA si applica la procedura separata Distribuire il certificato CA per HTTPS Scanning.

Se la Inspection CA deve provenire dalla PKI aziendale, la CA Default non è il sostituto corretto. Si applica invece la procedura separata per configurare una CA subordinata per la TLS Inspection di Sophos Firewall.

Quando una rigenerazione è giustificata

Un rinnovo può essere necessario quando:

• la chiave della CA precedente è compromessa in modo accertato o plausibile,
• la CA è in scadenza ed è ancora utilizzata in produzione,
• identità, tipo di chiave o requisiti crittografici vengono migrati in modo controllato,
• Sophos Support richiede la rigenerazione per un problema confermato.

Occorre distinguere una rotazione pianificata con una vecchia catena verificata come valida e non compromessa dal ripristino dopo un incidente dovuto alla compromissione sospetta o confermata della chiave, oppure a una CA già scaduta. Solo il primo caso consente un periodo di coesistenza limitato. In caso di incidente, il contenimento e un momento di interruzione approvato hanno priorità sul normale piano di migrazione; i servizi interessati non devono continuare a utilizzare il vecchio trust non sicuro fino alla migrazione di tutti gli utenti.

Un singolo download VPN non riuscito, un avviso del browser senza analisi della catena, una richiesta estetica relativa al subject o un vecchio comando della community non sono motivi sufficienti. Per un problema con .ovpn e ApplianceCertificate, prima diagnosticare sistematicamente il download della configurazione SSL VPN.

Inventariare le dipendenze prima della modifica

Certificati e servizi assegnati

In Certificates > Certificates, registrare almeno nome, subject, issuer, validità e assegnazione effettiva di ogni certificato firmato localmente. A seconda dell’ambiente, sono inclusi:

• WebAdmin, User Portal e Captive Portal,
• il certificato server SSL VPN,
• IPsec site-to-site e remote access con Digital certificate,
• WAF, SMTP, API o altri servizi TLS,
• certificati client o server generati localmente al di fuori del firewall.

Un certificato visibile non è automaticamente una dipendenza. È determinante sapere se viene utilizzato da un servizio di produzione e se il peer considera attendibile la CA Default che lo ha emesso.

Sistemi che considerano attendibile la CA e percorsi di distribuzione

Documentare inoltre:

• browser e sistemi operativi con la vecchia CA importata,
• MDM, GPO o distribuzione software per la nuova CA,
• peer IPsec con Default.pem, Remote CA o associazione DN importati,
• utenti SSL VPN e il percorso di distribuzione dei nuovi profili .ovpn,
• sistemi di monitoraggio, client API o integrazioni con certificate pinning,
• accesso di gestione HA, di emergenza ed esterno.

Se non è chiaro chi abbia distribuito la CA precedente o quali peer la considerino attendibile, la modifica deve essere interrotta.

Preservare lo stato iniziale e il percorso di ripristino

Prima della finestra di manutenzione, scaricare la CA Default in Certificates > Certificate authorities. L’archivio contiene la parte pubblica, non automaticamente un’esportazione utilizzabile separatamente della sua chiave privata.

I dati PEM possono essere controllati in sola lettura su un computer amministrativo:

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

Per un file DER si specifica il formato di input:

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

Conservare fingerprint e output nello stato iniziale insieme al nome del firewall, al numero di serie, alla build SFOS e al ticket della modifica. Non allegare senza protezione file di certificato e dati PKI interni a ticket pubblici.

Il download dalla pagina della CA conserva soltanto il certificato della CA. SFOS 22 offre inoltre la voce CertificateAuthority in Backup and firmware > Import export > Export selective configuration. Con Apply selected items > Export > Download si può esportare la configurazione della CA, inclusa la chiave privata. Questo file è altamente sensibile: conservarlo cifrato, con accesso controllato e fuori dal firewall, annotando nel change il periodo di conservazione.

L’export selettivo è una protezione aggiuntiva, non un comando Undo da usare senza test. Per importarlo su un altro firewall o dopo un reset o un reimage, SFOS richiede la SSMK valida al momento dell’export; senza di essa, le chiavi private e le configurazioni dipendenti non vengono importate. Prima della modifica, verificare quindi l’export e la procedura di importazione approvata su un firewall compatibile non di produzione con la stessa versione firmware o una successiva, oppure ottenere conferma da Sophos Support. Non provare a importare la vecchia CA sul firewall di produzione. Finché questo percorso non è stato verificato con esito positivo, non pianificarlo come rollback; un ripristino completo di un backup compatibile è un ultimo percorso di recupero della vecchia catena solo se questa è verificata come valida e non compromessa. Anche una procedura di importazione verificata consente il recupero della vecchia catena solo se questa è verificata come valida e non compromessa; ripristinare una vecchia chiave compromessa non giustifica la ripresa di un servizio sicuro.

Conservare inoltre esternamente un backup attuale di Sophos Firewall con password e SSMK. Un ripristino sostituisce l’intera configurazione, riavvia il firewall e può annullare modifiche successive. È un ultimo percorso di ripristino pianificato verso una vecchia catena verificata come valida e non compromessa, non una funzione di annullamento rapida per la CA.

Preparare la finestra di manutenzione

Prima di Save, tutti i seguenti punti devono essere verificati:

• account admin locale o secondo amministratore testato dalla rete di gestione,
• console o altro percorso di ripristino indipendente disponibile,
• nuovi valori della CA e crittografia compatibili con tutti i sistemi peer,
• responsabili dei peer VPN, di MDM/GPO e dei portali disponibili,
• nuovi profili, distribuzione ai trust store e account di test preparati,
• tempo sufficiente per un ripristino completo del backup, se necessario.

In un cluster HA, eseguire la modifica WebAdmin supportata sul Primary corrente. SFOS non documenta la continuità ininterrotta della CA o delle sessioni per questa modifica. Dopo un failover pianificato, testare quindi nuovi accessi e tutti i servizi critici. Non modificare la CA in modo indipendente su entrambi i nodi.

Aggiornare la Default CA in SFOS

1. Aprire Certificates > Certificate authorities.
2. Fare clic su Default. Il nome non può essere modificato.
3. Controllare Country name, State, Locality name, Organization name, Organization unit name, Common name e l’indirizzo e-mail della persona di contatto.
4. In Key type, scegliere consapevolmente RSA o Elliptic curve, impostare Key length per RSA oppure Curve name per Elliptic curve e definire l’algoritmo in Secure hash. Se è già impostata una Private key password e si intende modificarla, includere questa modifica nella stessa modifica approvata.
5. Confrontare i valori con il ticket della modifica e l’elenco di compatibilità.
6. Fare clic su Save solo durante la finestra di manutenzione.

Valori di esempio come CH, Zurich, Example AG, IT Security, fw01.example.com e pki@example.com sono esclusivamente dati di documentazione. Sostituirli con l’organizzazione, il riferimento effettivo del firewall e la convenzione di denominazione PKI approvata.

I campi descrivono l’identità della CA: Country name è il paese in cui è installato il firewall, State la regione e Locality name la città. Organization name identifica il proprietario del certificato, Organization unit name il reparto assegnato e Common name l’hostname o FQDN. L’indirizzo e-mail è quello della persona di contatto.

Private key password riguarda una password già impostata per la chiave privata. Non è né la password del backup né la SSMK. Una modifica pianificata deve essere registrata nel gestore di password approvato, non nel ticket della modifica o in uno screenshot. La guida per SFOS 22 e 23 descrive questo cambio di password condizionale, ma non una funzione di reset né il significato di un campo password vuoto. Se la password esistente non è nota o la schermata è diversa, chiarire la situazione con Sophos Support prima di Save, anziché provare a svuotare il campo.

Con RSA, chiavi più grandi offrono maggiore sicurezza, ma richiedono più tempo per la cifratura e la decifratura. La lunghezza della chiave viene quindi approvata insieme alla compatibilità e ai requisiti operativi; per Elliptic curve, si seleziona invece Curve name. Secure hash specifica l’algoritmo hash.

⚠️ Save è il punto di passaggio. SFOS rigenera automaticamente la CA Default. Reinserire in seguito i precedenti valori del subject non ripristina la vecchia chiave né il vecchio fingerprint.

Subito dopo, scaricare la nuova CA Default ed eseguire lo stesso controllo OpenSSL. Dopo la rigenerazione è previsto un nuovo fingerprint SHA-256. Campi imprevisti, un errore di download o uno stato non documentabile sono condizioni di arresto.

La guida all’aggiornamento per SFOS 22 e 23 conferma la rigenerazione automatica della CA, ma non descrive una riemissione o una riassegnazione automatica per ogni certificato dipendente. Verificare quindi, per ciascun servizio, il certificato effettivamente presentato e la relativa catena; il solo download della nuova CA non dimostra che tutti i servizi siano già passati alla nuova catena.

Migrare i servizi dipendenti in modo controllato

WebAdmin e portali

Controllare quale certificato è selezionato per WebAdmin, User Portal e Captive Portal in Administration > Admin and user settings. Se viene utilizzato un certificato firmato localmente con la nuova CA, i client che vi accedono devono considerare attendibile la nuova CA.

Mantenere aperta una sessione Full Admin esistente durante il test. Nuove finestre private del browser verificano FQDN, catena del certificato e accesso dall’origine di gestione prevista. Il comando CLI che ripristina il certificato WebAdmin al certificato predefinito del dispositivo non è un rollback della vecchia chiave CA.

SSL VPN

Se SSL VPN utilizza l’ApplianceCertificate o un altro certificato server firmato localmente, gli utenti devono scaricare e importare un nuovo file .ovpn dopo la modifica delle impostazioni della CA Default. Un nome file esistente o un tunnel verde con un vecchio profilo non sono una convalida sufficiente.

Almeno un utente pilota scarica il nuovo profilo tramite il percorso del portale previsto, stabilisce una nuova connessione e verifica DNS, route e traffico applicativo reale. Durante una rotazione pianificata, i vecchi profili possono restare in distribuzione solo per un periodo di coesistenza approvato e limitato, finché la vecchia catena è verificata come valida e non compromessa; la distribuzione deve cessare al più tardi dopo la migrazione riuscita di tutti gli utenti.

In caso di compromissione sospetta o confermata, il responsabile dell’incidente deve approvare il contenimento e il momento di interruzione. In quel momento, ritirare i vecchi profili dalla distribuzione e rimuovere il trust nella vecchia CA compromessa dai client e dai peer interessati; non attendere la migrazione di tutti gli utenti. Anche una catena già scaduta esclude questa coesistenza. Se non è possibile fornire una catena sicura, indipendente e validata, interrompere il servizio interessato e coinvolgere il team di Incident Response o Sophos Support. Ripristinare la vecchia chiave compromessa non ristabilisce un servizio sicuro.

Peer IPsec basati su certificati

Con Digital certificate, i peer Sophos Firewall si scambiano i certificati CA. Se in precedenza il peer aveva importato il Default.pem remoto, sostituire o aggiungere in modo controllato la nuova CA pubblica sul peer e verificare nuovamente l’associazione.

L’aggiunta della nuova CA accanto alla vecchia è consentita solo per un periodo di coesistenza approvato e limitato, con una vecchia catena verificata come valida e non compromessa. In caso di compromissione, rimuovere il vecchio trust del peer nel momento di interruzione approvato per l’incidente; non mantenere il servizio neppure con una vecchia catena scaduta. Senza una catena sostitutiva sicura e validata, interrompere il tunnel interessato e coinvolgere i responsabili.

La configurazione completa della connessione rimane in Configurare IPsec site-to-site su Sophos Firewall. Per il cambio di CA, testare almeno l’instaurazione IKE, la Child SA, entrambe le direzioni del traffico e le applicazioni reali. Un tunnel verde da solo non dimostra il percorso di ritorno.

HTTPS Inspection e altri percorsi di firma

Per HTTPS Inspection, identificare innanzitutto la Signing CA effettivamente selezionata in Web > General settings. Se è SecurityAppliance_SSL_CA o una CA esterna, non ridistribuirla solo perché la CA Default è stata rigenerata.

Includere un percorso di firma nella modifica solo quando è dimostrato che utilizza la CA Default modificata o un certificato dipendente. In questo modo le modifiche ai trust store restano limitate agli endpoint realmente interessati.

Verificare il risultato e i log

La convalida separa configurazione e funzionamento:

1. Scaricare la nuova CA e documentare subject, issuer, numero di serie, validità e fingerprint SHA-256.
2. In Certificates > Certificates, controllare issuer, Trusted e gli oggetti certificato interessati.
3. Testare singolarmente WebAdmin, portali, SSL VPN, IPsec e gli altri servizi assegnati.
4. Controllare in vpncertificate.log l’operazione relativa a CA e certificato all’ora della modifica.
5. Controllare in configuration-audit.log amministratore, ora e dati prima/dopo supportati.
6. Correlare nei relativi log di servizio soltanto gli errori e i successi appartenenti al test.

Un segno di spunta in Trusted conferma soltanto che la CA associata è installata sul firewall. Non dimostra né che i client esterni la considerino attendibile né che l’accesso o il traffico applicativo funzionino correttamente. Anche se il subject rimane invariato, la vecchia e la nuova CA si distinguono tramite il fingerprint; non basarsi soltanto sul nome.

Ricostruire le modifiche di configurazione con configuration-audit.log spiega l’audit trail. Non tutti i servizi scrivono lo stesso livello di dettaglio in configuration-audit.log, quindi la convalida funzionale resta obbligatoria.

Rollback e condizioni di arresto

Una CA rigenerata non dispone di un semplice controllo Undo. Salvare nuovamente il testo precedente non ripristina la vecchia chiave privata.

Anche reimportare soltanto la vecchia CA pubblica su un peer o attivare un vecchio profilo client non ripristina la vecchia chiave della CA sul firewall. Il percorso di ripristino di un servizio funziona solo se anche il certificato utilizzato, la sua chiave privata disponibile e i peer sono compatibili con la vecchia catena approvata. Se la chiave della CA è compromessa o la CA è scaduta, il ritorno alla vecchia catena di trust non costituisce un funzionamento normale sicuro; in tal caso, coinvolgere il team di Incident Response o Sophos Support e utilizzare un percorso alternativo sicuro.

Per questo il percorso di ripristino viene definito in anticipo per ogni servizio:

• mantenere un accesso di gestione indipendente e la sessione admin esistente,
• riassegnare ai portali un certificato esterno indipendente già verificato, se disponibile e assegnabile in sicurezza,
• ripristinare il trust dei peer e i profili client solo in base allo stato precedente documentato e se la vecchia catena è verificata come valida e non compromessa,
• utilizzare un ripristino completo del backup per tornare alla vecchia catena solo se questa è verificata come valida e non compromessa e sono accettabili gli effetti, il riavvio, SSMK e la perdita delle modifiche successive; altrimenti utilizzare una catena sicura, indipendente e validata oppure interrompere il servizio interessato e coinvolgere i responsabili,
• inoltrare le evidenze a Sophos Support quando una dipendenza è sconosciuta o lo stato del certificato non è riproducibile.

Non eseguire modifiche al database dalla shell, eliminazioni massive di certificati, riavvii di servizi o una seconda rigenerazione della CA per sospetto. Interrompere la modifica se un peer critico non può essere coordinato, il nuovo trust anchor non è distribuito o il percorso di ripristino non è stato testato con esito positivo.

Errori tipici dopo la rigenerazione

Il browser segnala una connessione non attendibile

Controllare la catena del certificato effettivamente fornita per il FQDN. Se il certificato server è firmato dalla nuova CA Default, nel trust store deve essere presente esattamente questa CA. Non importare indiscriminatamente SecurityAppliance_SSL_CA.

SSL VPN non si connette più con il vecchio profilo

Correlare il certificato server SSL selezionato, la nuova CA, il download dal portale e sslvpn.log. Scaricare un nuovo file .ovpn e importarlo come nuovo profilo. Distinguere i profili vecchi e nuovi mediante il certificato e la connessione riuscita, non mediante il nome del file.

IPsec rimane down dopo il cambio di CA

Su entrambi i lati, controllare importazione della CA, stato Trusted, Local/Remote certificate, ID e strongswan.log. Con DER ASN1 DN, una modifica del subject della CA può influire anche sull’identità. Non allentare profili o ID per sospetto.

HTTPS Inspection mostra errori di certificato

Controllare prima la Signing CA effettivamente selezionata. Se SecurityAppliance_SSL_CA è ancora in uso e non è cambiata, l’errore non è automaticamente causato dalla nuova CA Default. Esaminare separatamente la catena del certificato, la Decryption Rule e il trust dell’endpoint.

Checklist

• Il motivo e l’ambito della rigenerazione della CA sono documentati.
• Il vecchio certificato CA, l’export selettivo CertificateAuthority, il backup, la password e SSMK sono conservati in modo sicuro.
• Tutti i certificati, i servizi, i peer, i client e i percorsi di distribuzione sono inventariati.
• Default, ApplianceCertificate e SecurityAppliance_SSL_CA sono stati valutati separatamente.
• La finestra di manutenzione, il percorso di ripristino admin e i responsabili sono pronti.
• I nuovi valori della CA e la crittografia sono compatibili con tutti i peer.
• La CA è stata salvata solo nella finestra approvata e scaricata successivamente.
• WebAdmin, portali, SSL VPN, IPsec e altri servizi sono stati testati separatamente.
• vpncertificate.log, configuration-audit.log e i log di servizio sono stati conservati.
• Il rollback o l’escalation al supporto sono possibili senza interventi incontrollati dalla shell.

FAQ