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.

Quando una rigenerazione è giustificata

Una modifica pianificata può essere necessaria 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.

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.

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. È l’ultimo percorso di ripristino pianificato, 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, State, Locality, Organization, Organizational unit, Common name e indirizzo e-mail.
4. In Private key settings, selezionare consapevolmente RSA o Elliptic curve, la lunghezza della chiave o la curva corrispondente e il Secure hash.
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.

⚠️ 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.

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. Rimuovere i vecchi profili dalla distribuzione solo dopo la migrazione riuscita di tutti gli utenti.

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.

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.

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.

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,
• utilizzare un ripristino completo del backup solo se sono accettabili gli effetti, il riavvio, SSMK e la perdita delle modifiche successive,
• 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.
• La vecchia CA, il fingerprint, il backup, la password e SSMK sono conservati.
• 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