Sophos Firewall Let's Encrypt-certificaten instellen

Met Let’s Encrypt-certificaten op Sophos Firewall kan men openbare HTTPS-certificaten rechtstreeks op de firewall aanmaken en automatisch laten vernieuwen. Dat is vooral praktisch voor WAF-publicaties, WebAdmin, User Portal, VPN Portal als webinterface, Captive Portal, SPX Portal, hotspot-inlogpagina’s en SMTP-TLS-configuraties.

De functie vermindert handmatig certificaatwerk, maar vervangt geen zorgvuldige planning. DNS, publieke bereikbaarheid, poort 80, certificaatnamen, WAF-regels, portaltoegang en monitoring moeten bij elkaar passen. Als validatie of vernieuwing ongemerkt mislukt, kan een portal of gepubliceerde webapplicatie ondanks een op zichzelf correcte WAF-regel plots met een certificaatwaarschuwing uitvallen.

Belangrijk is het onderscheid tussen portalcertificaat en VPN-certificaat: een Let’s-Encrypt-certificaat kan een VPN Portal netjes in de browser beveiligen. Voor Remote Access VPN, Site-to-Site VPN en Chromebook SSO noemt Sophos daarentegen beperkingen. Die gevallen moeten apart worden gepland.

Voor de daadwerkelijke publicatie van een webserver komt Sophos Firewall WAF: Publiceer webservers veilig als eerste in aanmerking. Dit artikel richt zich op de certificaatkant en de werking van Let’s Encrypt op de firewall.

Wanneer Let’s Encrypt zinvol is op de firewall

De ingebouwde Let’s Encrypt-methode is zinvol als de Sophos Firewall zelf de openbare dienst levert of er als reverse proxy voor staat.

WAF/webserverbescherming: publiekelijk toegankelijke HTTPS-applicaties met hun eigen FQDN.
WebAdmin: beheerderstoegang met een schoon certificaat als WebAdmin extern of intern via FQDN wordt gebruikt.
User Portal / VPN Portal: gebruikers melden zich aan bij een HTTPS-portal of downloaden configuraties; dit is niet hetzelfde als het certificaat voor de VPN-tunnel zelf.
Captive Portal/Hotspot: Gebruikers zien een HTTPS-inlogpagina zonder certificaatwaarschuwing.
SMTP-TLS: Mail Protection- of SMTP TLS-configuratie met openbaar certificaat.

Niet elke dienst past in dit pad. Voor wildcardcertificaten of certificaten die op meerdere systemen buiten de firewall gebruikt moeten worden, is een extern gegenereerd certificaat vaak beter. Hiervoor bestaat het bestaande artikel Maak een Let’s Encrypt wildcard-certificaat.

Grenzen en belangrijke verschillen

Sophos Firewall maakt Let’s Encrypt-certificaten aan voor specifieke FQDN’s. De integratie is niet hetzelfde als een vrij beheerde ACME-client op een Linux-server.

Belangrijke punten:

Het domein moet worden opgegeven als een volledige FQDN.
Wildcard-domeinen zijn niet de juiste manier voor het ingebouwde firewallproces.
IP-adressen zijn voor HTTP-01-validatie geen geldige certificaatnamen.
De HTTP-domeinvalidatie moet de firewall via poort 80 en IPv4 kunnen bereiken.
De firewall maakt voor de validatie tijdelijk een WAF-regel aan en verwijdert die na succesvolle validatie weer.
Tijdens deze validatie kunnen bestaande webapplicaties die via WAF-regels worden beschermd, kort niet via de firewall bereikbaar zijn.
Remote Access VPN, Site-to-Site VPN en Chromebook SSO moeten niet met dit certificaatpad worden gepland.
Certificaten zijn 90 dagen geldig; de firewall probeert automatisch te vernieuwen wanneer minder dan 30 dagen resterende looptijd overblijft.
Als de Let’s-Encrypt-registratie op de firewall wordt opgeheven, worden bestaande certificaten niet verder vernieuwd.

Sophos introduceerde de functie met SFOS 21. De Avanet-duiding van de toenmalige vernieuwingen staat in de blogpost Sophos Firewall v21: de belangrijkste vernieuwingen. In nieuwere release notes staan meerdere WAF- en Let’s-Encrypt-correcties. Voor productieomgevingen betekent dit: firmwarestand, certificaatstatus en WAF-bedrijf moeten samen worden gecontroleerd, niet geïsoleerd.

Vereisten

Voordat een certificaat wordt aangemaakt, moeten deze punten worden verduidelijkt:

De firewall draait op een SFOS-versie met Let’s Encrypt-ondersteuning.
Elke DNS-naam in het certificaat is publiek oplosbaar.
De publieke DNS-antwoorden wijzen wereldwijd consistent naar het WAN-adres of een IP-adres dat poort 80 naar de firewall routeert.
DNS mag niet afhankelijk van de regio verschillende doelen leveren. Publieke DNS-checkers uit meerdere regio’s helpen om split-brain- of GeoDNS-problemen vóór de aanvraag te vinden.
Per naam hoort normaal maar één relevante publieke IP-adres te antwoorden. Meerdere A-records zijn alleen netjes als alle betrokken doelen HTTP-verkeer op poort 80 betrouwbaar naar de firewall doorsturen.
Poort 80 is extern bereikbaar voor HTTP-validatie.
Er is geen actieve DNAT-, WAF- of andere regel op het betreffende publieke IP en poort 80 die het validatieverzoek naar een ander systeem onderschept.
GeoIP-filters, voorgeschakelde firewalls, providerfilters en SD-WAN-routes blokkeren de validatie niet.
De firewall kan zelf op internet communiceren.
De datum, tijd en NTP van de firewall zijn correct.
Voor latere service is duidelijk of het certificaat wordt gebruikt in WAF, WebAdmin, Portal of SMTP TLS.
Een eigenaar controleert regelmatig de vervaldatum van het certificaat, de verlengingsstatus en de betrokken services.

⚠️ Let’s Encrypt is geen workaround voor onzuivere publieke bereikbaarheid. Als poort 80 door een oude DNAT-regel, een andere WAF-regel, GeoIP, voorgeschakeld NAT of een providerfilter wordt geblokkeerd, kan de certificaataanvraag of vernieuwing mislukken.

Certificaatnamen plannen

Vóór de technische inrichting moet vaststaan welke hostnamen echt nodig zijn. Goede certificaatplanning voorkomt latere correcties aan WAF-regels, portals en DNS.

Voorbeelden:

portal.example.com: Gebruikersportaal of VPN-portaal.
vpn.example.com: VPN-portaal of SSL VPN-downloadpad.
admin.example.com: WebAdmin, indien extern of via beheer FQDN.
app.example.com: WAF gepubliceerde applicatie.
mail.example.com: SMTP TLS of e-mailbeveiliging.

Bij meerdere applicaties moet men niet te snel alles in één certificaat stoppen. Een certificaat met veel namen kan praktisch zijn, maar vergroot ook de afhankelijkheden. Wanneer een certificaat wordt vernieuwd, vervangen of teruggebouwd, zijn alle opgenomen hostnamen geraakt.

Voor WAF-regels is het ook belangrijk dat DNS, certificaat, domeinen in de WAF-regel en SNI overeenkomen. De basisprincipes van WAF worden beschreven in Sophos Firewall WAF: Publiceer webservers veilig.

Let’s Encrypt-account en certificaat aanmaken

De inrichting gebeurt in WebAdmin onder Certificates. Afhankelijk van de SFOS-versie kan de exacte weergave licht verschillen, maar het verloop blijft vergelijkbaar.

Account registreren

Eerst wordt de firewall bij Let’s Encrypt geregistreerd.

Certificates > Let’s Encrypt openen.
Subscriber Agreement en voorwaarden controleren.
Register account aanklikken.
Controleren of de registratie zonder waarschuwing actief is.

Als Let’s Encrypt de voorwaarden wijzigt, moet de registratie opnieuw worden bevestigd. Anders worden bestaande certificaten niet vernieuwd en kunnen geen nieuwe certificaten worden aangemaakt. In de praktijk hoort deze melding daarom in de normale firewallreview, niet in de categorie “later bekijken”.

Sophos Firewall wijst onder andere via administrator-e-mail en Control Center op gewijzigde voorwaarden. Deze meldingen mogen niet als puur informatief worden behandeld: zonder herbevestiging stopt de automatische certificaatwerking.

Certificaat aanvragen

Daarna wordt het eigenlijke certificaat aangemaakt.

Certificates > Certificates openen.
Add aanklikken.
Bij Action de optie Request Let’s Encrypt certificate kiezen.
Een duidelijke naam geven, bijvoorbeeld le-app-example-com.
Onder Domains de gewenste FQDN’s invoeren, bijvoorbeeld app.example.com.
Onder Hosted address het publieke WAN-adres kiezen waar deze domains naar wijzen.
Controleren of poort 80 van buitenaf werkelijk naar de firewall wijst.
Save aanklikken.
Na enkele minuten onder Certificates > Certificates controleren of het certificaat als vertrouwd verschijnt en een geldige Valid until-datum heeft.

Tijdens de validatie gebruikt de firewall het HTTP-challenge-responsmechanisme. Om dit te doen moeten externe Let’s Encrypt-systemen het validatiepad kunnen bereiken. Als de firewall zich achter een router, load balancer of provider NAT bevindt, moet de omleiding naar de firewall verwijzen.

Als de domeinnaam ongeldig is of niet bestaat, is de correctie afhankelijk van de toestand niet simpelweg een edit aan de bestaande CSR. Dan is het meestal schoner om de foutieve aanvraag te verwijderen en met gecorrigeerde FQDN opnieuw aan te maken.

Gebruik certificaat

Eenmaal uitgegeven bestaat het certificaat alleen nog maar. Het beschermt een dienst pas als deze daar actief is geselecteerd.

Typische opdracht:

WAF: betreffende WAF-regel onder Rules and policies > Firewall rules controleren.
WebAdmin: certificaat voor de WebAdmin-console in de admin-/Device-Access-nabije instellingen controleren.
User Portal / VPN Portal: portal- respectievelijk VPN-portalconfiguratie controleren.
Captive Portal/Hotspot: Inlogpagina en portaalcertificaat.
SMTP-TLS: E-mail- of SMTP TLS-configuratie.

Na de toewijzing moet men niet alleen in WebAdmin opslaan, maar de dienst ook extern testen. Bij WAF-publicaties past een test van buiten het eigen LAN, omdat interne DNS-weergave, NAT-loopback of browsercache anders schijnzekerheid kunnen geven.

Go-live-test

Een succesvolle go-live test bestaat uit DNS, TLS, servicefunctionaliteit en logging.

Controlelijst:

De FQDN wordt publiekelijk omgezet naar het verwachte adres.
Poort 80 is tijdens validatie toegankelijk voor de firewall.
Poort 443 of de gebruikte HTTPS-poort levert het nieuwe certificaat.
Browser toont geen certificaatwaarschuwing.
Certificaat bevat de verwachte hostnaam.
De vervaldatum komt overeen met het nieuw aangemaakte certificaat.
WAF-regel, portal, WebAdmin of SMTP TLS gebruikt werkelijk dit certificaat.
Log Viewer vertoont geen merkbare WAF-, portal- of certificaatfouten.
Voor WAF-releases komt reverseproxy.log overeen met het testtijdstip.

Ook kan met een eenvoudige externe TLS-test worden aangetoond welk certificaat daadwerkelijk wordt afgeleverd. Het is belangrijk om de test van buiten het klantennetwerk uit te voeren, en niet alleen van de interne klant.

Controleer de certificaatketen

Na het overstappen naar een nieuw Let’s Encrypt-certificaat moet niet alleen de algemene naam of SAN-vermelding worden gecontroleerd. Cruciaal is ook of de klant de volledige certificaatketen ziet. Als een browser, app of monitoringsysteem een onvolledige keten meldt, kan de oorzaak liggen aan de certificaatselectie, een oud geïmporteerd certificaat, een onjuiste WAF-regel of een tussenliggende reverse proxy.

Praktisch moeten deze punten worden gecontroleerd:

Externe HTTPS-test toont de verwachte FQDN zonder certificaatwaarschuwing.
Het geleverde certificaat is in werkelijkheid het nieuwe Let’s Encrypt-certificaat van de Sophos Firewall.
De certificaatketen is compleet en wordt niet vervangen door een oud backend- of proxycertificaat.
WAF-regel, portal of WebAdmin gebruiken hetzelfde certificaat dat zichtbaar is in de externe test.
Als er sprake is van een upstream load balancer, router of reverse proxy, wordt daar geen ander certificaat afgeleverd.

Deze controle is vooral belangrijk als hetzelfde domein eerder via een andere publicatie liep, of als meerdere WAF-regels, DNAT-regels of externe proxy’s dezelfde hostnaam gebruiken. Anders zie je in WebAdmin een geldig certificaat, terwijl klanten van buitenaf alsnog een andere of onvolledige keten ontvangen.

Vernieuwing in bedrijf bewaken

Let’s-Encrypt-certificaten zijn 90 dagen geldig. De kracht van de integratie is dat de firewall de vernieuwing automatisch kan uitvoeren zodra een certificaat minder dan 30 dagen resterende looptijd heeft. Toch mag men het proces niet blind laten lopen.

Deze punten moeten regelmatig worden gecontroleerd tijdens een bedrijfsaudit:

Draait de firewall op een huidige, stabiele SFOS-versie?
Is het certificaat nog geldig?
Was de automatische verlenging succesvol?
Is poort 80 nog steeds toegankelijk voor validatie?
Zijn er nieuwe DNAT- of WAF-regels die de validatie kunnen blokkeren?
Is de Let’s-Encrypt-registratie nog actief en zijn gewijzigde voorwaarden bevestigd?
Tonen gebruikers of monitoring certificaatwaarschuwingen?
Zijn er WAF- of portalfouten in Log Viewer?

Deze controle is vooral belangrijk na firewall-upgrades, WAF-wijzigingen, providerwijzigingen, DNS-wijzigingen en wijzigingen aan upstream-routers of reverse proxy’s.

Typische fouten

Certificaat is niet gemaakt: FQDN verwijst niet naar de firewall of poort 80 is niet bereikbaar. Controleer de openbare DNS-resolutie en externe poorttest.
Certificaataanvraag mislukt na WAF-wijziging: bestaande regel onderschept HTTP-validatie. Controleer DNAT-, WAF- en firewallregels op poort 80.
Validatie mislukt afhankelijk van herkomstland: GeoIP, voorgeschakelde filters of SD-WAN kunnen afzonderlijke validatiedoelen blokkeren. Voor uitgifte moet poort 80 niet alleen vanuit het eigen land bereikbaar zijn.
DNS levert per regio verschillende IP’s: Let’s Encrypt valideert niet noodzakelijk vanuit de regio van de administrator. Publieke DNS-antwoorden moeten wereldwijd naar een pad wijzen dat poort 80 naar de firewall brengt.
Meerdere A-records wijzen naar verschillende systemen: de validatie kan willekeurig een doel bereiken dat het challenge-pad niet naar de firewall doorstuurt. DNS vereenvoudigen of garanderen dat alle doelen het HTTP-challenge-pad correct routeren.
WAF-applicatie is tijdens uitgifte kort niet bereikbaar: de firewall gebruikt tijdelijke WAF-mechaniek voor de validatie. Kritieke publicaties moeten daarom niet tijdens een ongepland productievenster worden gewijzigd.
Certificaat is aangemaakt, maar browser toont oud certificaat: Service gebruikt een ander certificaat. Controleer WAF-regel, portal of WebAdmin-certificaatselectie.
Browser- of monitoringrapporten onvolledige certificaatketen: Verkeerd certificaat actief, keten wordt niet volledig geleverd of upstream proxy levert een ander certificaat. Vergelijk externe TLS-test, WAF-regel, portal mapping en mogelijke proxy’s.
WAF-applicatie werkt niet goed na certificaatwijziging: SNI, domein, backendhost of beveiligingsprofiel komen niet overeen. Controleer WAF-regel, domeinen, reverseproxy.log en backend-logboeken.
Verlengen werkt niet: Het validatiepad is veranderd sinds de creatie. Controleer DNS, poort 80, upstream NAT en firmwarestatus.
Vernieuwing stopt na gewijzigde voorwaarden: als het Let’s-Encrypt-Subscriber-Agreement opnieuw moet worden bevestigd, blijven nieuwe certificaten en vernieuwingen geblokkeerd totdat Register account opnieuw is bevestigd.
Certificaten worden na deregistratie niet vernieuwd: als het Let’s-Encrypt-account op de firewall is gederegistreerd, moet niet alleen het afzonderlijke certificaat maar eerst de accountstatus worden gecontroleerd.
Certificaat moet voor Remote Access VPN of Site-to-Site VPN worden gebruikt: dat is niet het ondersteunde doel van deze integratie. Voor VPN-certificaten moet een eigen certificaatpad worden gepland.
Control Center toont WAF- of certificaatwaarschuwing: oude WAF-regel, WAF-herstart of certificaatstatus kan problematisch zijn. Controleer Log Viewer, WAF-regels en certificaatlijst.

Als de WAF en het certificaat samen opvallen, moet je niet alleen naar het certificaat kijken. WAF-matching, gehost adres, domeinen, SNI en backend-toegankelijkheid behoren tot dezelfde foutketen.

Plan terugdraaien

Voor publieke portals en WAF-applicaties moet het duidelijk zijn hoe je terug kunt gaan voordat je een certificaat wijzigt.

Nuttige voorbereiding:

verwijder het vorige certificaat niet onmiddellijk
Documenteer de getroffen WAF-regel en portalconfiguratie
Zorg ervoor dat er externe testtoegang beschikbaar is
Ken DNS TTL als hostnamen worden gewijzigd
Selecteer onderhoudsvensters voor kritieke portals
Bereid gebruikerscommunicatie voor als een portal wordt getroffen

Als het nieuwe certificaat is aangemaakt, maar een dienst daarna niet goed werkt, kan meestal het vorige certificaat opnieuw worden gekozen. Als de oorzaak daarentegen een geblokkeerde HTTP-validatie is, helpt een certificaatrollback alleen kortstondig. Dan moet het validatiepad worden gecorrigeerd, anders mislukt de volgende verlenging opnieuw.

Controlelijst

FQDN’s en services gedocumenteerd.
Openbare DNS-resolutie gecontroleerd.
Poort 80 gecontroleerd op HTTP-validatie.
Conflicten met DNAT, WAF, GeoIP, SD-WAN of upstream NAT gecontroleerd.
Let’s-Encrypt-account geregistreerd en gewijzigde voorwaarden bevestigd.
Let’s-Encrypt-certificaat aangemaakt.
Certificaat toegewezen aan de juiste dienst.
Externe HTTPS-test uitgevoerd.
Log Viewer en bij WAF reverseproxy.log gecontroleerd.
Vernieuwingsverantwoordelijkheid en monitoring gedefinieerd.
Oud certificaat pas verwijderd na succesvolle bediening.

Veelgestelde vragen

Kan Sophos Firewall Let's Encrypt certificaten automatisch vernieuwen?

Ja. De firewall kan Let’s-Encrypt-certificaten automatisch vernieuwen. Toch moeten vervaldatum, renewalstatus, bereikbaarheid van poort 80 en betrokken diensten regelmatig worden gecontroleerd.

Wanneer vernieuwt Sophos Firewall een Let's-Encrypt-certificaat?

Let’s-Encrypt-certificaten zijn 90 dagen geldig. Sophos Firewall vraagt de vernieuwing aan wanneer een certificaat minder dan 30 dagen resterende looptijd heeft. Daarvoor moet het validatiepad via poort 80 blijven werken.

Ondersteunt Sophos Firewall Let's Encrypt wildcard-certificaten?

Voor wildcard-certificaten is het ingebouwde firewallproces niet de juiste keuze. Als een wildcardcertificaat vereist is, moet dit extern worden aangemaakt en vervolgens worden geïmporteerd.

Waarom heeft Let's Encrypt poort 80 nodig?

De Sophos firewall-integratie maakt gebruik van HTTP-domeinvalidatie. Hiervoor moet het validatiepad toegankelijk zijn vanaf de buitenkant van de firewall via poort 80.

Kan men een Let's-Encrypt-certificaat voor WAF gebruiken?

Ja. WAF is een van de typische toepassingen. Het is belangrijk dat het certificaat, de FQDN, de domeinen in de WAF-regel, het gehoste adres en de SNI overeenkomen.

Kan men het certificaat voor Remote Access VPN gebruiken?

Niet voor de VPN-tunnel zelf. Sophos ondersteunt Let’s-Encrypt-certificaten uit deze integratie voor portals en verschillende firewallservices, maar noemt beperkingen voor Remote Access VPN en Site-to-Site VPN. Een VPN Portal in de browser en de eigenlijke VPN-verbinding moeten daarom apart worden bekeken.

Wat controleer je als de verlenging mislukt?

Controleer eerst DNS, poort 80, upstream NAT, DNAT- of WAF-conflicten, certificaatstatus en Log Viewer. Voor WAF-publicaties is reverseproxy.log ook relevant.