Configurazione di Sophos Firewall Let's Encrypt dei certificati

Con certificati Let’s Encrypt su Sophos Firewall è possibile creare certificati HTTPS pubblici direttamente sul firewall e farli rinnovare automaticamente. Ciò è particolarmente utile per pubblicazioni WAF, WebAdmin, User Portal, VPN Portal come interfaccia web, Captive Portal, SPX Portal, pagine di login hotspot e configurazioni SMTP TLS.

La funzione riduce il lavoro manuale di certificazione, ma non sostituisce una corretta pianificazione. DNS, accessibilità pubblica, porta 80, nomi di certificati, regole WAF, accesso al portale e monitoraggio devono corrispondere. Se la convalida o il rinnovo falliscono inosservati, un portale o un’applicazione web pubblicata possono improvvisamente fallire con un avviso di certificato nonostante la regola WAF sia effettivamente corretta.

È importante distinguere tra certificato del portale e certificato VPN: un certificato Let’s Encrypt può proteggere correttamente un VPN Portal nel browser. Per Remote Access VPN, Site-to-Site VPN e Chromebook SSO, Sophos indica invece limitazioni. Questi casi devono essere pianificati separatamente.

Per la pubblicazione vera e propria di un server web, Sophos Firewall WAF: server web pubblico in modo sicuro si adatta per primo. Questo articolo si concentra sul lato certificato e sul funzionamento di Let’s Encrypt sul firewall.

Quando Let’s Encrypt ha senso sul firewall

Il metodo Let’s Encrypt integrato ha senso se è il Sophos Firewall stesso a fornire il servizio pubblico o a fungere da proxy inverso.

• WAF/Protezione server Web: applicazioni HTTPS accessibili pubblicamente con il proprio FQDN.
• WebAdmin: accesso amministrativo con certificato pulito se WebAdmin viene utilizzato esternamente o internamente tramite FQDN.
• User Portal / VPN Portal: gli utenti accedono a un portale HTTPS o scaricano configurazioni; non è la stessa cosa del certificato per il tunnel VPN stesso.
• Captive Portal/Hotspot: Gli utenti visualizzano una pagina di accesso HTTPS senza avviso di certificato.
• TLS SMTP: Configurazione Mail Protection o SMTP TLS con certificato pubblico.

Non tutti i servizi si adattano a questo percorso. Per i certificati con caratteri jolly o da utilizzare su più sistemi all’esterno del firewall, spesso è preferibile un certificato generato esternamente. A questo scopo esiste l’articolo Crea il certificato Let’s Encrypt with caratteri jolly.

Limiti e differenze importanti

Sophos Firewall crea certificati Let’s Encrypt per FQDN specifici. L’integrazione non è la stessa di un client ACME gestito liberamente su un server Linux.

Punti importanti:

• Il dominio deve essere specificato come FQDN completo.
• I domini jolly non sono la soluzione corretta per il processo firewall integrato.
• Gli indirizzi IP non sono nomi di certificati validi per la validazione HTTP-01.
• La validazione del dominio HTTP deve poter raggiungere il firewall tramite porta 80 e IPv4.
• Il firewall crea temporaneamente una regola WAF per la validazione e la rimuove dopo la validazione riuscita.
• Durante questa validazione, le applicazioni web esistenti protette tramite regole WAF possono non essere raggiungibili per breve tempo attraverso il firewall.
• Remote Access VPN, Site-to-Site VPN e Chromebook SSO non dovrebbero essere pianificati con questo percorso certificati.
• I certificati sono validi 90 giorni; il firewall tenta il rinnovo automatico quando restano meno di 30 giorni.
• Se la registrazione Let’s Encrypt viene rimossa dal firewall, i certificati esistenti non vengono più rinnovati.

Sophos ha introdotto questa funzionalità con SFOS 21. La classificazione Avanet delle innovazioni all’epoca si trova nel post del blog Sophos Firewall v21: la nuova cosa importante. Diverse correzioni WAF e Let’s Encrypt sono elencate nelle note di rilascio recenti. Per gli ambienti produttivi, ciò significa: lo stato del firmware, lo stato del certificato e il funzionamento del WAF devono essere controllati insieme, non separatamente.

Requisiti

Prima di creare un certificato è opportuno chiarire questi punti:

• Il firewall funziona su una versione SFOS con supporto Let’s Encrypt.
• Ogni nome DNS nel certificato è risolvibile pubblicamente.
• Le risposte DNS pubbliche puntano in modo coerente a livello mondiale all’indirizzo WAN o a un indirizzo IP che instrada la porta 80 verso il firewall.
• Il DNS non dovrebbe fornire destinazioni diverse a seconda della regione. DNS checker pubblici da più regioni aiutano a trovare problemi Split-Brain o GeoDNS prima della richiesta.
• Per ogni nome dovrebbe normalmente rispondere un solo indirizzo IP pubblico rilevante. Più A-Record sono puliti solo se tutti i target coinvolti inoltrano in modo affidabile il traffico HTTP sulla porta 80 verso il firewall.
• La porta 80 può essere raggiunta esternamente per la convalida HTTP.
• Non sono presenti DNAT, WAF o altre regole attive sull’IP pubblico interessato e sulla porta 80 che intercettano la richiesta di validazione verso un altro sistema.
• GeoIP filter, firewall upstream, filtri del provider e route SD-WAN non bloccano la validazione.
• Il firewall può comunicare su Internet stesso.
• La data, l’ora e l’NTP del firewall sono corretti.
• Per il servizio successivo è chiaro se il certificato viene utilizzato in WAF, WebAdmin, Portal o SMTP TLS.
• Un proprietario controlla regolarmente la scadenza del certificato, lo stato di rinnovo e i servizi interessati.

⚠️ Let’s Encrypt non è una soluzione alternativa per un’accessibilità pubblica non pulita. Se la porta 80 è bloccata da una vecchia regola DNAT, da un’altra regola WAF, da GeoIP, da un NAT upstream o da un filtro del provider, la richiesta o il rinnovo del certificato può fallire.

Pianificare i nomi dei certificati

Prima della configurazione tecnica, è necessario determinare quali nomi host sono realmente necessari. Una buona pianificazione dei certificati evita correzioni successive a regole WAF, portali e DNS.

Esempi:

• portal.example.com: Portale utente o Portale VPN.
• vpn.example.com: Portale VPN o percorso di download SSL VPN.
• admin.example.com: WebAdmin, se utilizzato esternamente o tramite gestionale FQDN.
• app.example.com: Applicazione pubblicata WAF.
• mail.example.com: SMTP TLS o protezione posta.

Se disponi di più applicazioni, non dovresti affrettarti a racchiudere tutto in un unico certificato. Un certificato con molti nomi può essere pratico, ma aumenta anche le dipendenze. Quando un certificato viene rinnovato, sostituito o ripristinato, tutti i nomi host in esso contenuti sono interessati.

Per le regole WAF, è importante anche che DNS, certificato, domini nella regola WAF e SNI corrispondano. Le basi del WAF sono descritte in Sophos Firewall WAF: server web pubblico in modo sicuro.

Creare account e certificato Let’s Encrypt

La configurazione viene eseguita nel WebAdmin nell’area Certificati. A seconda della versione SFOS, la rappresentazione esatta può variare leggermente, ma il processo rimane simile.

Registrare l’account

Per prima cosa il firewall viene registrato presso Let’s Encrypt.

1. Aprire Certificates > Let’s Encrypt.
2. Verificare Subscriber Agreement e condizioni.
3. Fare clic su Register account.
4. Controllare che la registrazione sia attiva senza avvisi.

Se Let’s Encrypt modifica le condizioni, la registrazione deve essere confermata di nuovo. Altrimenti i certificati esistenti non vengono rinnovati e non è possibile crearne di nuovi. Nella pratica, questo messaggio appartiene quindi al normale review del firewall, non alla categoria “da guardare più tardi”.

Sophos Firewall segnala condizioni modificate anche tramite e-mail amministratore e Control Center. Questi avvisi non dovrebbero essere trattati come pura informazione: senza nuova conferma, il funzionamento automatico dei certificati si ferma.

Richiedere il certificato

Poi viene creato il certificato vero e proprio.

1. Aprire Certificates > Certificates.
2. Fare clic su Add.
3. In Action selezionare Request Let’s Encrypt certificate.
4. Assegnare un nome parlante, ad esempio le-app-example-com.
5. In Domains inserire gli FQDN desiderati, ad esempio app.example.com.
6. In Hosted address selezionare l’indirizzo WAN pubblico a cui puntano questi domini.
7. Verificare che la porta 80 punti davvero al firewall dall’esterno.
8. Fare clic su Save.
9. Dopo alcuni minuti, verificare in Certificates > Certificates che il certificato risulti trusted e abbia una data Valid until valida.

Durante la convalida, il firewall utilizza il meccanismo di sfida-risposta HTTP. Per fare ciò, i sistemi Let’s Encrypt esterni devono essere in grado di raggiungere il percorso di validazione. Se il firewall si trova dietro un router, un bilanciatore del carico o un provider NAT, il reindirizzamento deve puntare al firewall.

Se il nome di dominio non è valido o non esiste, la correzione, a seconda dello stato, non è semplicemente una modifica del CSR esistente. In genere è più pulito eliminare la richiesta errata e crearne una nuova con FQDN corretto.

Usa il certificato

Una volta emesso, il certificato esiste solo. Protegge un servizio solo dopo che è stato selezionato attivamente lì.

Incarico tipico:

• WAF: regola WAF interessata in Regole e policy > Regole firewall.
• WebAdmin: Certificato per la console WebAdmin nelle impostazioni relative all’accesso all’amministratore/dispositivo.
• Portale utente/Portale VPN: Configurazione portale o portale VPN.
• Captive Portal/Hotspot: Pagina di login e certificato del portale.
• TLS SMTP: Configurazione e-mail o SMTP TLS.

Dopo l’assegnazione non dovresti solo salvare in WebAdmin, ma anche testare il servizio esternamente. Per le pubblicazioni WAF è opportuno un test esterno alla propria LAN, poiché altrimenti la vista DNS interna, il loopback NAT o la cache del browser potrebbero fornire una falsa sicurezza.

Test di avvio

Un test di go-live di successo comprende DNS, TLS, funzionalità del servizio e registrazione.

Lista di controllo:

-L’FQDN risolve pubblicamente l’indirizzo previsto.

• La porta 80 è accessibile al firewall durante la convalida.
• La porta 443 o la porta HTTPS utilizzata consegna il nuovo certificato.
• Il browser non mostra l’avviso relativo al certificato.
• Il certificato contiene il nome host previsto.
• La data di scadenza corrisponde al certificato appena creato.
• La regola WAF, il portale, WebAdmin o SMTP TLS utilizza realmente questo certificato.
• Il visualizzatore log non mostra errori WAF, portali o certificati evidenti.
• Per le versioni WAF, reverseproxy.log corrisponde all’ora del test.

Un semplice test TLS esterno può anche mostrare quale certificato viene effettivamente consegnato. È importante eseguire il test dall’esterno della rete del cliente, non solo dal cliente interno.

Controlla la catena di certificati

Dopo il passaggio a un nuovo certificato Let’s Encrypt, non è necessario controllare solo il nome comune o la voce SAN. È anche fondamentale che il cliente veda l’intera catena di certificati. Se un browser, un’app o un sistema di monitoraggio segnalano una catena incompleta, la causa potrebbe essere la selezione del certificato, un vecchio certificato importato, una regola WAF errata o un proxy inverso intermediario.

In pratica si dovrebbero verificare questi punti:

• Il test HTTPS esterno mostra l’FQDN previsto senza avviso di certificato.
• Il certificato consegnato è in realtà il nuovo certificato Let’s Encrypt del Sophos Firewall.
• La catena di certificati è completa e non è sostituita da un vecchio backend o certificato proxy.
• La regola WAF, il portale o WebAdmin utilizzano lo stesso certificato visibile nel test esterno.
• Se è coinvolto un bilanciatore del carico upstream, un router o un proxy inverso, nessun altro certificato verrà consegnato lì.

Questo controllo è particolarmente importante se lo stesso dominio veniva precedentemente eseguito attraverso una pubblicazione diversa o se più regole WAF, regole DNAT o proxy esterni utilizzano lo stesso nome host. Altrimenti vedrai un certificato valido in WebAdmin, mentre i client esterni riceveranno comunque una catena diversa o incompleta.

Monitorare il rinnovamento in azienda

I certificati Let’s Encrypt sono validi 90 giorni. Il punto di forza dell’integrazione è che il firewall può eseguire il rinnovo automaticamente non appena un certificato ha meno di 30 giorni di validità residua. Tuttavia, non si dovrebbe lasciare che il processo proceda alla cieca.

Questi punti dovrebbero essere controllati regolarmente in un audit aziendale:

• Il firewall è in esecuzione su una versione SFOS attuale e stabile?
• Il certificato è ancora valido?
• Il rinnovo automatico è andato a buon fine?
• La porta 80 è ancora accessibile per la convalida?
• Esistono nuove regole DNAT o WAF che potrebbero bloccare la convalida?
• La registrazione Let’s Encrypt è ancora attiva e le condizioni modificate sono state confermate?
• Gli utenti o il monitoraggio mostrano avvisi sui certificati?
• Sono presenti errori WAF o del portale nel visualizzatore di log?

Questo controllo è particolarmente importante dopo aggiornamenti del firewall, modifiche WAF, modifiche del provider, modifiche DNS e modifiche ai router upstream o ai proxy inversi.

Errori tipici

• Il certificato non è stato creato: L’FQDN non punta al firewall o la porta 80 non è raggiungibile. Controlla la risoluzione DNS pubblica e il test della porta esterna.
• La richiesta di certificato non riesce dopo la modifica WAF: la regola esistente intercetta la convalida HTTP. Controlla le regole DNAT, WAF e Firewall sulla porta 80.
• Il certificato è stato creato, ma il browser mostra il vecchio certificato: Il servizio utilizza un altro certificato. Controllare la selezione della regola WAF, del portale o del certificato WebAdmin.
• Il browser o il monitoraggio segnalano una catena di certificati incompleta: Certificato attivo errato, la catena non viene consegnata completamente o il proxy upstream consegna un certificato diverso. Confronta test TLS esterno, regola WAF, mappatura del portale e possibili proxy.
• La validazione fallisce a seconda del paese di origine: GeoIP, filtri upstream o SD-WAN possono bloccare singoli target di validazione. Per l’emissione, la porta 80 non dovrebbe essere raggiungibile solo dal proprio paese.
• Il DNS fornisce IP diversi a seconda della regione: Let’s Encrypt non valida necessariamente dalla regione dell’amministratore. Le risposte DNS pubbliche devono puntare globalmente a un percorso che porta la porta 80 al firewall.
• Più A-Record puntano a sistemi diversi: la validazione può raggiungere casualmente un target che non inoltra il percorso challenge al firewall. Semplificare il DNS o assicurare che tutti i target instradino correttamente il percorso HTTP challenge.
• L’applicazione WAF non è raggiungibile per breve tempo durante l’emissione: il firewall usa meccanismi WAF temporanei per la validazione. Le pubblicazioni critiche non dovrebbero quindi essere modificate durante una finestra produttiva non pianificata.
• L’applicazione WAF non funziona correttamente dopo la modifica del certificato: SNI, dominio, host backend o profilo di protezione non corrispondono. Controlla la regola WAF, i domini, reverseproxy.log e i log di backend.
• Il rinnovo non funziona: Il percorso di convalida è cambiato dalla creazione. Controlla DNS, porta 80, NAT upstream e stato del firmware.
• Control Center mostra l’avviso WAF o certificato: vecchia regola WAF, riavvio WAF o stato del certificato problematico. Controlla il visualizzatore di log, le regole WAF e l’elenco dei certificati.
• Il rinnovo si ferma dopo condizioni modificate: se il Let’s-Encrypt-Subscriber-Agreement deve essere confermato di nuovo, nuovi certificati e rinnovi restano bloccati finché Register account non viene confermato nuovamente.
• I certificati non vengono rinnovati dopo la deregistrazione: se l’account Let’s Encrypt sul firewall è stato deregistrato, bisogna verificare prima lo stato dell’account e non solo il singolo certificato.
• Il certificato deve essere usato per Remote Access VPN o Site-to-Site VPN: non è lo scopo supportato di questa integrazione. Per i certificati VPN si dovrebbe pianificare un percorso certificati dedicato.

Se il WAF e il certificato sono evidenti insieme, non dovresti limitarti a guardare il certificato. La corrispondenza WAF, l’indirizzo ospitato, i domini, l’SNI e l’accessibilità del backend appartengono alla stessa catena di errori.

Pianifica il rollback

Per i portali pubblici e le applicazioni WAF, dovrebbe essere chiaro come tornare indietro prima di modificare un certificato.

Preparazione utile:

• non eliminare immediatamente il certificato precedente
• Documentare la regola WAF interessata e la configurazione del portale
• Avere a disposizione l’accesso ai test esterni
• Conoscere DNS TTL se i nomi host vengono modificati
• Selezionare le finestre di manutenzione per i portali critici
• Preparare le comunicazioni degli utenti se un portale è interessato

Se è stato creato il nuovo certificato, ma un servizio funziona in modo errato, di solito è possibile selezionare nuovamente il certificato precedente. Tuttavia, se la causa è una convalida HTTP bloccata, il rollback del certificato sarà di aiuto solo a breve termine. Successivamente è necessario correggere il percorso di convalida, altrimenti il ​​rinnovo successivo fallirà nuovamente.

Lista di controllo

• FQDN e servizi documentati.
• Risoluzione DNS pubblica controllata.
• La porta 80 ha controllato la convalida HTTP.
• Conflitti con DNAT, WAF, GeoIP, SD-WAN o NAT upstream controllati.
• Account Let’s Encrypt registrato e condizioni modificate confermate.
• Certificato Let’s Encrypt creato.
• Certificato assegnato al servizio corretto.
• Test HTTPS esterno eseguito.
• Visualizzatore registro e WAF reverseproxy.log selezionati.
• Definizione delle responsabilità e del monitoraggio del rinnovo.
• Il vecchio certificato viene rimosso solo dopo l’operazione riuscita.

Domande frequenti