Importare e assegnare certificati su Sophos Firewall

Un certificato è pronto per l’uso su Sophos Firewall solo quando quattro elementi corrispondono: hostname, certificato server, chiave privata e catena della CA emittente. Il certificato deve poi essere assegnato al servizio corretto. La sola presenza della voce in Certificates > Certificates non modifica alcun portale o regola WAF.

Per un certificato di una CA interna o pubblica, il percorso standard più sicuro è:

1. Generare un Certificate Signing Request (CSR) in Certificates > Certificates > Add.
2. Far firmare il CSR dalla CA desiderata.
3. Importare il certificato emesso tramite l’azione di importazione del CSR esistente.
4. Verificare in Trusted che la CA associata sia installata e in Valid until che il certificato sia valido.
5. Assegnare il certificato al servizio desiderato e testarlo da un client.

Con questo metodo, la chiave privata viene generata sul firewall e non deve lasciarlo. È anche possibile caricare un certificato già generato esternamente, ma servono la chiave privata corrispondente ed eventualmente le CA Intermediate e Root mancanti.

Se è già disponibile un file PFX o PEM, il percorso rapido è Certificates > Certificates > Add > Upload certificate: scegliere il formato, caricare il certificato con la chiave privata richiesta e la password, quindi verificare la CA associata, la validità e l’assegnazione al servizio.

Quale procedura scegliere per il certificato?

• CA pubblica o interna, nuovo certificato: generare il CSR sul firewall. In questo modo si riducono i trasferimenti della chiave e si evita di confondere facilmente coppie di certificato e chiave.
• Certificato esistente con chiave privata: caricare il certificato in formato PEM, DER, CER o PKCS12. Formato, password e catena CA devono essere corretti.
• Let’s Encrypt per un servizio pubblico del firewall: il processo integrato può gestire emissione e rinnovo. La procedura completa è descritta in Configurare certificati Let’s Encrypt su Sophos Firewall.
• Certificato wildcard esterno: generarlo all’esterno del firewall e poi importarlo. La pianificazione e la validazione DNS-01 sono descritte in Creare un certificato wildcard Let’s Encrypt.
• Solo per client interni gestiti: può bastare un certificato firmato localmente, purché tutti i client considerino attendibile la CA interna emittente.

Un certificato autofirmato o firmato localmente non utilizza automaticamente una cifratura non sicura. Tuttavia, senza una catena di attendibilità distribuita, il client non può confermare con certezza l’identità e mostra un avviso. Per portali e applicazioni WAF accessibili pubblicamente, una CA pubblica è quindi normalmente la scelta migliore.

Distinguere certificato, CA, chiave privata e CSR

Questi quattro componenti hanno funzioni diverse:

• Certificato server: contiene l’identità, le informazioni sulla chiave pubblica, i nomi validi e il periodo di validità. Viene presentato al client.
• Chiave privata: dimostra che il firewall è autorizzato a utilizzare il certificato. Non deve mai finire in ticket, screenshot o archivi pubblici.
• Certificati CA: formano la catena di attendibilità dalla CA Intermediate emittente fino alla Root CA. Per questo non serve alcuna chiave CA privata.
• CSR: contiene la richiesta di certificato e la chiave pubblica. Se il CSR viene generato sul firewall, la relativa chiave privata rimane sul dispositivo.

Una CA per TLS Inspection svolge una funzione diversa da un certificato server per WebAdmin o WAF. Durante la decifratura, la CA di ispezione firma nuovi certificati per i client. La scelta e la distribuzione sono descritte in Distribuire il certificato CA di Sophos Firewall per TLS Inspection.

Preparare nomi, validità e catena

Prima dell’importazione deve essere chiaro quale nome apriranno effettivamente utenti e sistemi. I client moderni verificano soprattutto i Subject Alternative Names (SAN). Il Common Name da solo non è un sostituto affidabile.

Esempio:

• URL aperto: https://vpn.example.com
• nome del certificato in SFOS: public-vpn-example-com-2026
• SAN nel certificato: vpn.example.com
• DNS: vpn.example.com punta all’accesso firewall o WAF previsto

vpn.example.com è un esempio e va sostituito con il proprio FQDN. Se un amministratore accede invece tramite l’indirizzo IP o un altro alias, il certificato risulta valido solo se anche quel nome o indirizzo IP è incluso come SAN.

Prima della modifica verificare che:

• Data, ora e NTP del firewall siano corretti.
• Tutti gli FQDN necessari siano presenti come SAN nella richiesta o nel certificato.
• Chiave privata e certificato appartengano alla stessa coppia.
• Le CA Intermediate e Root siano note.
• Data di scadenza e responsabilità del rinnovo siano documentate.
• Il certificato precedente e le sue assegnazioni rimangano disponibili per un eventuale rollback.

Procedura consigliata: generare il CSR sul firewall

Creare il CSR

1. Aprire Certificates > Certificates.
2. Selezionare Add.
3. In Action, scegliere Generate certificate signing request (CSR).
4. Assegnare un nome interno descrittivo, ad esempio public-vpn-example-com-2026.
5. Scegliere Key Type, lunghezza della chiave o curva e hash necessari in base ai propri requisiti di sicurezza e della CA.
6. In Common name, inserire l’FQDN principale, ad esempio vpn.example.com.
7. In Subject Alternative Names, aggiungere almeno il nome DNS effettivamente utilizzato.
8. Salvare e scaricare il CSR tramite l’icona di download.

Il nome interno del certificato è solo una denominazione SFOS. Non deve corrispondere all’FQDN, ma dovrebbe indicare chiaramente scopo e anno di rinnovo. Le voci SAN fanno invece parte della verifica tecnica dell’identità e devono corrispondere all’URL che verrà utilizzato.

Far firmare il CSR

Inviare il CSR scaricato alla CA pubblica o interna competente. Se si intende utilizzare la chiave privata generata sul firewall, non far generare nuovi file di chiave. La CA fornirà poi il certificato server firmato e, a seconda del provider, ulteriori certificati Intermediate.

Prima dell’importazione verificare che:

• La CA abbia firmato il CSR corretto.
• L’elenco SAN contenga tutti i nomi approvati.
• Validità ed emittente corrispondano all’ordine o alla policy interna.
• La catena CA sia completa.

Importare nel CSR il certificato firmato

1. Aprire Certificates > Certificates.
2. Nella riga del CSR corretto, scegliere l’azione di importazione in Manage.
3. Caricare il certificato emesso o incollare il testo del certificato.
4. Come scopo, scegliere normalmente Certificate only. Se lo stesso file contiene anche la catena CA, scegliere lo scopo appropriato per certificato e CA.
5. Eseguire Import certificate.

SFOS associa il certificato alla chiave privata presente sul firewall e poi rimuove la voce del CSR. Prima dell’importazione verificare quindi con attenzione di aver selezionato la riga del CSR corretta.

Caricare un certificato esistente con chiave privata

Se certificato e chiave sono già stati generati all’esterno del firewall:

1. Aprire Certificates > Certificates > Add.
2. Selezionare Upload certificate.
3. Assegnare un nome univoco.
4. Selezionare il formato del file esistente.
5. Caricare il certificato e i dati della chiave richiesti dal formato.
6. Se la chiave privata è cifrata, inserire la relativa password.
7. Salvare.

SFOS supporta questi formati di certificato:

• PEM (.pem): codificato in Base64; certificato e chiave privata sono normalmente contenuti in file separati.
• DER (.der) e CER (.cer): formati binari del certificato; la chiave privata è fornita separatamente.
• PKCS7 (.p7b): può contenere certificati e una catena, ma non una chiave privata.
• PKCS12 (.pfx o .p12): può contenere insieme certificato server, catena CA e chiave privata.

Sono supportate chiavi RSA ed ECC. Per la password di una chiave privata importata, SFOS accetta un massimo di 30 caratteri. Questo limite del prodotto non giustifica l’uso di una chiave privata non protetta: per il trasferimento, impostare una password sicura entro il limite e rimuovere poi il file di importazione da eventuali archivi intermedi non sicuri.

Integrare la catena CA mancante

In Certificates > Certificates, una voce verde in Trusted indica che la CA associata è installata su SFOS. Se manca, verificare prima l’emittente e la catena:

1. Aprire Certificates > Certificate authorities.
2. Selezionare Add.
3. Caricare la CA Intermediate o Root mancante oppure incollare il testo del certificato.
4. Per una semplice catena di attendibilità, utilizzare Validation only.
5. Salvare e verificare nuovamente lo stato Trusted del certificato server.

Una Root CA o CA Intermediate pubblica non richiede una chiave privata per la validazione. Signing and validation è destinato esclusivamente a una CA con cui il firewall deve firmare direttamente certificati e la cui chiave privata è stata deliberatamente installata sul firewall.

Upgrade a SFOS 21 o versioni successive: verificare i nomi CA riservati

Durante il primo upgrade di un’installazione precedente a SFOS 21 o versioni successive, NC-146082 può bloccare la migrazione. La causa non è la validità del certificato, ma una voce CA già configurata con un nome riservato da SFOS alle CA Let’s Encrypt integrate:

Lets_Encrypt_R10
Lets_Encrypt_R11
Lets_Encrypt_R12
Lets_Encrypt_R13
Lets_Encrypt_R14
Lets_Encrypt_E5
Lets_Encrypt_E6
Lets_Encrypt_E7
Lets_Encrypt_E8
Lets_Encrypt_E9

Prima della finestra di manutenzione:

1. Creare un backup aggiornato della configurazione e tenere disponibili la password del backup e la Secure Storage Master Key.
2. In Certificates > Certificate authorities, cercare i nomi esatti. Se non ci sono corrispondenze, NC-146082 non richiede alcuna modifica.
3. In caso di corrispondenza, documentare tipo, Subject, Issuer, scopo e presenza dell’icona della chiave. L’icona indica che il firewall possiede la chiave privata della CA.
4. Esportare inoltre una CA con chiave privata da Backup and firmware > Import export > Export selective configuration come CertificateAuthority. Individuare quindi i certificati e i servizi che dipendono dalla CA, ad esempio VPN, WebAdmin e portali, WAF, SMTP TLS o TLS Inspection.
5. Rimuovere una voce configurata dall’amministratore solo dopo aver sostituito tutte le dipendenze o aver dimostrato che non sono più necessarie. Ripetere quindi l’upgrade.

Non rimuovere una CA integrata. Se WebAdmin rifiuta l’eliminazione, manca la chiave privata originale o un riferimento rimane poco chiaro, interrompere l’upgrade e coinvolgere il supporto Sophos. Le modifiche al database o tramite Advanced Shell non sono un’alternativa sicura.

Dopo l’upgrade, verificare che le CA Let’s Encrypt integrate siano presenti, che i certificati dipendenti mostrino nuovamente Trusted e che i servizi interessati funzionino.

Assegnare il certificato al servizio corretto

Prima dell’assegnazione: garantire il rollback

La sostituzione di un certificato non dovrebbe iniziare eliminando la voce precedente:

1. Importare il nuovo certificato e la catena CA completa.
2. Verificare SAN, emittente, validità e Trusted.
3. Documentare l’assegnazione precedente e i servizi interessati.
4. Assegnare inizialmente il nuovo certificato a un solo servizio.
5. Testare il servizio tramite il suo FQDN e la sua porta reali.
6. In caso di errore, selezionare immediatamente il certificato precedente.
7. Convertire gli altri servizi uno alla volta e verificarli singolarmente.
8. Rimuovere il vecchio certificato solo quando non esistono più riferimenti e il nuovo stato è stabile.

WAF e SMTP possono essere convertiti uno dopo l’altro. WebAdmin, User Portal, VPN Portal, Captive Portal e i due portali SPX cambiano invece contemporaneamente tramite una selezione condivisa del certificato.

Quando si modifica WebAdmin, mantenere aperte anche una sessione amministrativa esistente e una modalità alternativa di gestione locale finché login e certificato non sono stati verificati tramite l’FQDN previsto.

WebAdmin e portali

In Administration > Admin and user settings > Admin console and end-user interaction si seleziona un certificato comune per questi servizi:

• WebAdmin Console
• User Portal
• VPN Portal
• Captive Portal
• SPX Registration Portal
• SPX Reply Portal

Nel campo Certificate, selezionare il nuovo certificato e salvare con Apply. Il certificato deve coprire tutti gli FQDN tramite cui sono raggiungibili i servizi utilizzati. Se, ad esempio, si usa admin.example.com per WebAdmin e vpn.example.com per il VPN Portal, entrambi i nomi devono essere inclusi come SAN oppure la pianificazione degli URL deve essere uniformata.

Il certificato del VPN Portal protegge il sito HTTPS da cui gli utenti scaricano profili e client. Non è automaticamente il Local o Remote Certificate di un tunnel IPsec.

WAF

Per una pubblicazione WAF, modificare la regola interessata in Rules and policies > Firewall, attivare HTTPS, selezionare il nuovo certificato in HTTPS certificate e salvare. La regola utilizza Protect with web server protection. SNI, dominio nella regola e SAN nel certificato devono descrivere lo stesso hostname.

La modifica di una regola WAF riavvia le regole Web Server Protection e interrompe le connessioni esistenti. Per le applicazioni di produzione, la sostituzione del certificato deve quindi avvenire durante una finestra di manutenzione. La pubblicazione e la verifica complete sono descritte in Sophos Firewall WAF: pubblicare un server web in modo sicuro.

SMTP TLS in modalità MTA

Per Mail Protection, selezionare il nuovo certificato server nel campo TLS certificate in Email > General settings > SMTP TLS configuration e salvare con Apply. Per le comunicazioni SMTP pubbliche è consigliabile un certificato di una CA pubblica, così i sistemi remoti possono verificare l’identità senza dover distribuire una CA propria. Il resto del flusso di posta è descritto in Sophos Firewall Mail Protection in modalità MTA.

Dopo la modifica, creare un nuovo backup di Sophos Firewall e documentare data di scadenza, owner e prossimo rinnovo.

Verificare il certificato e la sua distribuzione

Verificare il file prima dell’importazione

Su un computer amministrativo, è possibile verificare in sola lettura un certificato PEM con OpenSSL:

openssl x509 -in firewall.pem -noout -subject -issuer -dates -ext subjectAltName -fingerprint -sha256

Sostituire firewall.pem con il percorso locale del file. L’output deve mostrare Subject ed emittente previsti, il periodo di validità, i SAN necessari e un fingerprint SHA-256. Il comando non legge alcuna chiave privata.

Verificare il servizio HTTPS dall’esterno

Testare WebAdmin, portali e WAF da un computer amministrativo con OpenSSL:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -verify_hostname vpn.example.com -verify_return_error </dev/null

Sostituire FQDN e porta con il servizio HTTPS reale. -servername invia il nome tramite SNI, in modo che venga selezionato il certificato corretto in presenza di più destinazioni WAF o portali. La verifica è riuscita se viene mostrato il certificato previsto, l’hostname corrisponde e alla fine compare Verification: OK.

Con una CA interna, il computer amministrativo deve già considerare attendibile tale CA oppure riceverla esplicitamente come trust anchor per il test. In caso contrario, l’errore di verifica può dipendere dal dispositivo di test anche se il firewall fornisce la catena corretta.

Verificare SMTP con STARTTLS

SMTP sulle porte 25 o 587 parte normalmente senza cifratura e passa a TLS solo tramite STARTTLS. Serve quindi un test specifico:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Sostituire mail.example.com e la porta 25 con l’FQDN SMTP e la porta STARTTLS effettivamente utilizzati. Per TLS implicito sulla porta 465, non si usa -starttls smtp. Anche in questo caso devono corrispondere il certificato previsto e l’hostname e deve comparire Verification: OK.

Verificare inoltre nel browser o nel client che:

• L’URL utilizzi uno dei SAN inclusi.
• Emittente e data di scadenza corrispondano al nuovo certificato.
• Non compaiano avvisi relativi al certificato.
• Il servizio WebAdmin, portale, WAF o e-mail previsto funzioni.
• Un test esterno non rilevi ancora il certificato di un Load Balancer o Reverse Proxy a monte.

Errori tipici e verifica successiva

• Trusted rimane vuoto: manca la CA Intermediate, è stata importata la CA errata oppure la catena non appartiene al certificato server. Verificare emittente e ordine delle CA.
• L’importazione viene rifiutata: verificare formato del file, password della chiave privata, limite di 30 caratteri, coppia certificato-chiave e ora di sistema.
• Il browser segnala un nome errato: l’FQDN o l’indirizzo IP richiamato non è presente nei SAN. Confrontare URL, DNS e nomi del certificato.
• Il browser continua a mostrare il vecchio certificato: il servizio usa ancora la vecchia assegnazione oppure un proxy a monte termina TLS. Verificare direttamente la destinazione prevista con openssl s_client e SNI.
• WAF fornisce il certificato errato: controllare Hosted Address, Listen Port, dominio, SNI e ordine delle regole WAF sovrapposte.
• Solo alcuni client mostrano avvisi: verificare Trust Store, certificati intermedi, ora di sistema ed eventuali limitazioni di Certificate Pinning del client.
• Dopo la sostituzione un portale non è raggiungibile: selezionare nuovamente il vecchio certificato e verificare separatamente FQDN, porta, Device Access e catena del certificato.

FAQ