Konfigurera Sophos Firewall Let's Encrypt-certifikat

Med Let’s Encrypt certifikat på Sophos Firewall kan du skapa offentliga HTTPS-certifikat direkt på brandväggen och få dem förnyade automatiskt. Detta är särskilt användbart för WAF-publicering, WebAdmin, User Portal, VPN Portal, Captive Portal, SPX Portal, hotspot-inloggningssidor och SMTP TLS-konfigurationer.

Funktionen minskar manuellt certifikatarbete, men ersätter inte ordentlig planering. DNS, offentlig tillgänglighet, port 80, certifikatnamn, WAF-regler, portalåtkomst och övervakning måste matcha. Om validering eller förnyelse misslyckas obemärkt kan en portal eller publicerad webbapplikation plötsligt misslyckas med en certifikatvarning trots att WAF-regeln faktiskt är korrekt.

För själva publiceringen av en webbserver passar Sophos Firewall WAF: Publicera webbservrar säkert först. Den här artikeln fokuserar på certifikatsidan och driften av Let’s Encrypt på brandväggen.

When Let’s Encrypt är vettigt på brandväggen

Den inbyggda Let’s Encrypt-metoden är vettig om Sophos-brandväggen själv tillhandahåller public service eller står framför den som en omvänd proxy.

Inte alla tjänster passar denna väg. För jokerteckencertifikat eller certifikat som ska användas på flera system utanför brandväggen är ett externt genererat certifikat ofta bättre. Det finns den befintliga artikeln Skapa Let’s Encrypt jokerteckencertifikat.

Gränser och viktiga skillnader

Sophos Firewall skapar Let’s Encrypt-certifikat för specifika FQDN. Integrationen är inte samma sak som en fritt hanterad ACME-klient på en Linux-server.

Viktiga punkter:

• Domänen måste anges som ett fullständigt FQDN.
• Jokerteckendomäner är inte rätt sätt för den inbyggda brandväggsprocessen.
• IP-adresser är inte giltiga certifikatnamn.
• HTTP-domänvalidering måste kunna nå brandväggen via port 80.
• Brandväggen skapar en tillfällig webbserver eller WAF-komponenter för validering.
• Efter framgångsrik utfärdande tas de tillfälliga valideringskomponenterna bort igen. – Certifikaten är kortlivade och måste förnyas automatiskt.

Sophos introducerade funktionen med SFOS 21. Avanet-klassificeringen av innovationerna vid den tiden finns i blogginlägget Sophos Firewall v21: de viktigaste innovationerna. Flera WAF- och Let’s Encrypt-fixar listas i de senaste utgåvorna. För produktiva miljöer betyder detta: firmware-status, certifikatstatus och WAF-drift bör kontrolleras tillsammans, inte isolerat.

Krav

Innan du skapar ett certifikat bör dessa punkter förtydligas:

• Brandväggen körs på en SFOS-version med stöd för Let’s Encrypt.
• Det offentliga DNS-namnet pekar på WAN-adressen eller värdadressen för brandväggen.
• Port 80 kan nås externt för HTTP-validering.
• Det finns ingen aktiv DNAT, WAF eller annan regel som avlyssnar valideringsbegäran på port 80. – Brandväggen kan själv kommunicera på Internet.
• Datum, tid och NTP för brandväggen är korrekta.
• För senare tjänst framgår det om certifikatet används i WAF, WebAdmin, Portal eller SMTP TLS.
• En ägare kontrollerar regelbundet certifikatets utgångsdatum, förnyelsestatus och berörda tjänster.

⚠️ Let’s Encrypt är inte en lösning för oren offentlig tillgänglighet. Om port 80 blockeras av en gammal DNAT-regel, en annan WAF-regel, en uppströms NAT eller ett leverantörsfilter, kan certifikatbegäran eller förnyelsen misslyckas.

Schemalägg certifikatnamnFöre den tekniska installationen bör det fastställas vilka värdnamn som verkligen behövs. Bra certifikatplanering förhindrar senare korrigeringar av WAF-regler, portaler och DNS.

Exempel:

Om du har flera applikationer bör du inte skynda dig att packa allt i ett certifikat. Ett certifikat med många namn kan vara praktiskt, men det ökar också beroenden. När ett certifikat förnyas, ersätts eller återställs påverkas alla värdnamn som det innehåller.

För WAF-regler är det också viktigt att DNS, certifikat, domäner i WAF-regeln och SNI matchar. Grunderna i WAF beskrivs i Sophos Firewall WAF: Publicera webbservrar säkert.

Skapa Let’s Encrypt-konto och certifikat

Inställningen görs i WebAdmin i området Certifikat. Beroende på SFOS-versionen kan den exakta representationen variera något, men processen förblir densamma.

Grundläggande process:

1. Öppna Certifikat.
2. Öppna området Let’s Encrypt eller certifikatbegäran.
3. Förbered Let’s Encrypt-kontot på brandväggen.
4. Ange önskade FQDN.
5. Välj WAN-gränssnitt eller offentlig adress för HTTP-validering.
6. Kontrollera om port 80 pekar mot brandväggen från utsidan.
7. Begär intyg.
8. Efter framgångsrik utfärdande kontrollerar du under Certifikat > Certifikat om certifikatet är närvarande och giltigt.

Under valideringen använder brandväggen HTTP-utmaningssvarsmekanismen. För att göra detta måste externa Let’s Encrypt-system kunna nå valideringsvägen. Om brandväggen ligger bakom en router, lastbalanserare eller NAT-leverantör måste omdirigeringen peka på brandväggen.

Använd certifikat

När certifikatet har utfärdats finns det bara. Den skyddar bara en tjänst när den har valts ut där.

Typiskt uppdrag:

Efter uppdraget ska du inte bara spara i WebAdmin, utan även testa tjänsten externt. För WAF-publikationer är ett test utanför ditt eget LAN lämpligt eftersom intern DNS-vy, NAT loopback eller webbläsarcache annars kan ge falsk säkerhet.

Live-test

Ett lyckat go-live-test består av DNS, TLS, tjänstefunktionalitet och loggning.

Checklista:

• FQDN löser offentligt till den förväntade adressen.
• Port 80 är tillgänglig för brandväggen under validering.
• Port 443 eller den använda HTTPS-porten levererar det nya certifikatet.
• Webbläsaren visar inte certifikatvarning.
• Certifikatet innehåller det förväntade värdnamnet.
• Sista utgångsdatum matchar det nyskapade certifikatet.
• WAF-regeln, portalen eller WebAdmin använder verkligen detta certifikat.
• Log Viewer visar inga märkbara WAF-, portal- eller certifikatfel.
• För WAF-utgåvor matchar reverseproxy.log testtiden.

Ett enkelt externt TLS-test kan också visa vilket certifikat som faktiskt levereras. Det är viktigt att utföra testet utanför kundnätverket, inte bara från den interna klienten.

Kontrollera certifikatkedjan

Efter att ha bytt till ett nytt Let’s Encrypt-certifikat ska inte bara det vanliga namnet eller SAN-posten kontrolleras. Det är också avgörande om kunden ser hela certifikatkedjan. Om en webbläsare, app eller övervakningssystem rapporterar en ofullständig kedja kan orsaken vara certifikatvalet, ett gammalt importerat certifikat, en felaktig WAF-regel eller en mellanliggande omvänd proxy.

I praktiken bör du kontrollera dessa punkter:- Externt HTTPS-test visar förväntat FQDN utan certifikatvarning. – Certifikatet som levereras är egentligen det nya Let’s Encrypt-certifikatet från Sophos Firewall.

• Certifikatkedjan är komplett och ersätts inte av ett gammalt backend- eller proxycertifikat.
• WAF-regel, portal eller WebAdmin använder samma certifikat som är synligt i det externa testet.
• Om en uppströms lastbalanserare, router eller omvänd proxy är inblandad kommer inget annat certifikat att levereras där.

Denna kontroll är särskilt viktig om samma domän tidigare har körts genom en annan publikation, eller om flera WAF-regler, DNAT-regler eller externa proxyservrar använder samma värdnamn. Annars kommer du att se ett giltigt certifikat i WebAdmin, medan klienter utifrån fortfarande kommer att få en annan eller ofullständig kedja.

Övervaka förnyelse i företaget

Let’s Encrypt-certifikat är kortlivade. Styrkan med integrationen är att brandväggen kan utföra förnyelsen automatiskt. Ändå bör du inte låta processen gå blint.

Dessa punkter bör kontrolleras regelbundet i en företagsrevision:

• Körs brandväggen på en aktuell, stabil SFOS-version?
• Är certifikatet fortfarande giltigt?
• Var den automatiska förnyelsen framgångsrik?
• Är port 80 fortfarande tillgänglig för validering?
• Finns det nya DNAT- eller WAF-regler som kan blockera validering?
• Visar användare eller övervakning certifikatvarningar?
• Finns det WAF- eller portalfel i loggvisaren?

Denna kontroll är särskilt viktig efter brandväggsuppgraderingar, WAF-ändringar, leverantörsbyten, DNS-ändringar och ändringar av uppströmsroutrar eller omvända proxyservrar.

Typiska fel

Om WAF och certifikatet är iögonfallande tillsammans bör du inte bara titta på certifikatet. WAF-matchning, värdadress, domäner, SNI och backend-tillgänglighet hör till samma felkedja.

Planera återställning

För offentliga portaler och WAF-applikationer bör det framgå hur man går tillbaka innan man ändrar ett certifikat.

Användbar förberedelse:

• ta inte bort det tidigare certifikatet omedelbart
• Dokumentera den påverkade WAF-regeln och portalkonfigurationen
• Ha extern teståtkomst tillgänglig
• Känn till DNS TTL om värdnamn ändras
• Välj underhållsfönster för kritiska portaler
• Förbered användarkommunikation om en portal påverkas

Om det nya certifikatet har skapats, men en tjänst då fungerar fel, kan du oftast välja det tidigare certifikatet igen. Men om orsaken är en blockerad HTTP-validering, kommer en certifikatåterställning bara att hjälpa på kort sikt. Då måste valideringsvägen korrigeras, annars misslyckas nästa förnyelse igen.

Checklista- FQDN och tjänster dokumenterade.

• Offentlig DNS-upplösning kontrollerad.
• Port 80 kontrolleras för HTTP-validering.
• Konflikter med DNAT, WAF eller uppströms NAT kontrolleras.
• Låt oss kryptera certifikat skapat.
• Certifikat tilldelat rätt tjänst.
• Externt HTTPS-test utfört.
• Log Viewer och WAF reverseproxy.log kontrollerade.
• Förnyelseansvar och övervakning definieras.
• Gammalt certifikat togs bort först efter framgångsrik drift.

Vanliga frågor