Certificaten importeren en toewijzen op Sophos Firewall

Een certificaat is pas klaar voor gebruik op Sophos Firewall wanneer vier zaken overeenkomen: hostnaam, servercertificaat, privésleutel en de CA-keten van de uitgever. Daarna moet het certificaat nog aan de juiste dienst worden toegewezen. Alleen een vermelding onder Certificates > Certificates verandert nog niets aan een portal of WAF-regel.

Voor een certificaat van een interne of openbare CA is dit de veiligste standaardprocedure:

1. Maak onder Certificates > Certificates > Add een Certificate Signing Request (CSR) aan.
2. Laat de CSR door de gewenste CA ondertekenen.
3. Importeer het uitgegeven certificaat via de importactie bij de bestaande CSR.
4. Controleer onder Trusted de geïnstalleerde bijbehorende CA en onder Valid until de geldigheid.
5. Wijs het certificaat toe aan de gewenste dienst en test het vanaf een client.

Bij deze methode wordt de privésleutel op de firewall aangemaakt en hoeft deze het apparaat niet te verlaten. Een certificaat dat al extern is aangemaakt, kan eveneens worden geüpload, maar vereist de bijbehorende privésleutel en eventueel de ontbrekende Intermediate- en Root-CA’s.

Als er al een PFX- of PEM-bestand beschikbaar is, verloopt de snelle methode via Certificates > Certificates > Add > Upload certificate: kies het formaat, upload het certificaat met de vereiste privésleutel en het wachtwoord en controleer vervolgens de bijbehorende CA, de geldigheidsduur en de toewijzing aan de dienst.

Welke certificaatmethode past?

• Openbare of interne CA, nieuw certificaat: maak de CSR op de firewall aan. Dit beperkt het transport van sleutels en voorkomt dat certificaten en sleutels gemakkelijk worden verwisseld.
• Bestaand certificaat met privésleutel: upload het certificaat als PEM, DER, CER of PKCS12. Formaat, wachtwoord en CA-keten moeten kloppen.
• Let’s Encrypt voor een openbare firewalldienst: het ingebouwde proces kan de uitgifte en vernieuwing verzorgen. De volledige procedure staat in Let’s Encrypt-certificaten op Sophos Firewall configureren.
• Extern wildcard-certificaat: maak het buiten de firewall aan en importeer het vervolgens. De planning en DNS-01-validatie worden beschreven in Een Let’s Encrypt wildcard-certificaat aanmaken.
• Alleen voor interne, beheerde clients: een lokaal ondertekend certificaat kan volstaan als alle clients de interne CA die het certificaat heeft uitgegeven vertrouwen.

Een zelfondertekend of lokaal ondertekend certificaat gebruikt niet automatisch onveilige encryptie. Zonder een verspreide vertrouwensketen kan de client de identiteit echter niet betrouwbaar bevestigen en wordt een waarschuwing weergegeven. Voor openbaar bereikbare portals en WAF-applicaties is een openbare CA daarom doorgaans de betere keuze.

Certificaat, CA, privésleutel en CSR onderscheiden

Deze vier onderdelen hebben elk een andere taak:

• Servercertificaat: bevat de identiteit, informatie over de publieke sleutel, geldige namen en geldigheidsduur. Het wordt aan de client gepresenteerd.
• Privésleutel: bewijst dat de firewall het certificaat mag gebruiken. Deze mag nooit in tickets, screenshots of openbare opslaglocaties terechtkomen.
• CA-certificaten: vormen de vertrouwensketen van de uitgevende Intermediate-CA tot de Root-CA. Hiervoor is geen private CA-sleutel nodig.
• CSR: bevat de certificaataanvraag en de publieke sleutel. Wanneer de CSR op de firewall is aangemaakt, blijft de bijbehorende privésleutel op het apparaat.

Een CA voor TLS Inspection heeft een andere functie dan een servercertificaat voor WebAdmin of WAF. De Inspection-CA ondertekent tijdens de decryptie nieuwe certificaten voor clients. De selectie en distributie ervan worden uitgelegd in Sophos Firewall CA-certificaat voor TLS Inspection distribueren.

Namen, geldigheidsduur en keten voorbereiden

Vóór het importeren moet duidelijk zijn welke naam gebruikers en systemen daadwerkelijk openen. Moderne clients controleren vooral de Subject Alternative Names (SAN). Alleen de Common Name is geen betrouwbaar alternatief.

Voorbeeld:

• geopende URL: https://vpn.example.com
• certificaatnaam in SFOS: public-vpn-example-com-2026
• SAN in het certificaat: vpn.example.com
• DNS: vpn.example.com verwijst naar de bedoelde firewall- of WAF-toegang

vpn.example.com is een voorbeeld en wordt vervangen door de eigen FQDN. Als een beheerder in plaats daarvan verbinding maakt via het IP-adres of een andere alias, past het certificaat alleen wanneer ook die naam of dat IP-adres als SAN is opgenomen.

Controleer vóór de wijziging:

• Datum, tijd en NTP van de firewall kloppen.
• Alle vereiste FQDN’s zijn als SAN opgenomen in de aanvraag of het certificaat.
• Privésleutel en certificaat horen bij elkaar.
• Intermediate- en Root-CA zijn bekend.
• Vervaldatum en verantwoordelijkheid voor de vernieuwing zijn gedocumenteerd.
• Het huidige certificaat en de toewijzingen ervan blijven behouden om te kunnen terugkeren.

Aanbevolen methode: CSR op de firewall aanmaken

CSR aanmaken

1. Open Certificates > Certificates.
2. Kies Add.
3. Selecteer onder Action Generate certificate signing request (CSR).
4. Geef een duidelijke interne naam op, bijvoorbeeld public-vpn-example-com-2026.
5. Kies het vereiste Key Type, de sleutellengte of curve en de hash volgens de eigen beveiligings- en CA-vereisten.
6. Voer bij Common name de primaire FQDN in, bijvoorbeeld vpn.example.com.
7. Voeg onder Subject Alternative Names minimaal de daadwerkelijk gebruikte DNS-naam toe.
8. Sla de configuratie op en download de CSR via het downloadpictogram.

De interne certificaatnaam is alleen een SFOS-aanduiding. Deze hoeft niet overeen te komen met de FQDN, maar moet bij voorkeur het doel en het vernieuwingsjaar herkenbaar maken. De SAN-vermeldingen maken daarentegen deel uit van de technische identiteitscontrole en moeten overeenkomen met de URL die later wordt gebruikt.

CSR laten ondertekenen

Geef de gedownloade CSR door aan de verantwoordelijke openbare of interne CA. Laat daarbij geen nieuwe sleutelbestanden aanmaken wanneer de privésleutel moet worden gebruikt die op de firewall is gegenereerd. Vervolgens levert de CA het ondertekende servercertificaat en, afhankelijk van de aanbieder, aanvullende Intermediate-certificaten.

Controleer vóór het importeren:

• De CA heeft de juiste CSR ondertekend.
• De SAN-lijst bevat alle goedgekeurde namen.
• Geldigheidsduur en uitgever komen overeen met de bestelling of het interne beleid.
• De volledige CA-keten is beschikbaar.

Ondertekend certificaat bij de CSR importeren

1. Open Certificates > Certificates.
2. Kies in de regel van de juiste CSR onder Manage de importactie.
3. Upload het uitgegeven certificaat of plak de certificaattekst.
4. Kies als doel doorgaans Certificate only. Als hetzelfde bestand ook de CA-keten bevat, kiest u het passende doel voor certificaat en CA.
5. Voer Import certificate uit.

SFOS koppelt het certificaat aan de privésleutel die op de firewall aanwezig is en verwijdert daarna de CSR-vermelding. Controleer daarom vóór het importeren zorgvuldig of werkelijk de juiste CSR-regel is geselecteerd.

Bestaand certificaat met privésleutel uploaden

Als certificaat en sleutel al buiten de firewall zijn aangemaakt:

1. Open Certificates > Certificates > Add.
2. Kies Upload certificate.
3. Geef een unieke naam op.
4. Selecteer het bestaande bestandsformaat.
5. Upload het certificaat en de sleutelgegevens die voor het formaat vereist zijn.
6. Als de privésleutel versleuteld is, voert u het bijbehorende wachtwoord in.
7. Sla de configuratie op.

SFOS ondersteunt deze certificaatformaten:

• PEM (.pem): Base64-gecodeerd; certificaat en privésleutel staan normaal gesproken in afzonderlijke bestanden.
• DER (.der) en CER (.cer): binaire certificaatformaten; de privésleutel staat in een afzonderlijk bestand.
• PKCS7 (.p7b): kan certificaten en een keten bevatten, maar geen privésleutel.
• PKCS12 (.pfx of .p12): kan servercertificaat, CA-keten en privésleutel in één bestand bevatten.

RSA- en ECC-sleutels worden ondersteund. Voor het wachtwoord van een geïmporteerde privésleutel accepteert SFOS maximaal 30 tekens. Deze productbeperking is geen reden om een onbeveiligde privésleutel te gebruiken: stel voor de overdracht een sterk wachtwoord binnen deze grens in en verwijder het importbestand daarna uit onveilige tijdelijke opslaglocaties.

Ontbrekende CA-keten aanvullen

Onder Certificates > Certificates geeft een groene vermelding bij Trusted aan dat de bijbehorende CA op SFOS is geïnstalleerd. Ontbreekt deze, controleer dan eerst de uitgever en de keten:

1. Open Certificates > Certificate authorities.
2. Kies Add.
3. Upload de ontbrekende Intermediate- of Root-CA of plak de certificaattekst.
4. Gebruik voor een zuivere vertrouwensketen Validation only.
5. Sla de configuratie op en controleer opnieuw de status Trusted van het servercertificaat.

Een openbare Root- of Intermediate-CA heeft voor de validatie geen privésleutel nodig. Signing and validation is alleen bedoeld voor een CA waarmee de firewall zelf certificaten moet ondertekenen en waarvan de privésleutel bewust op de firewall aanwezig is.

Upgrade naar SFOS 21 of nieuwer: gereserveerde CA-namen controleren

Bij de eerste upgrade van een oudere installatie naar SFOS 21 of nieuwer kan NC-146082 de migratie blokkeren. De oorzaak is niet de geldigheid van het certificaat, maar een al geconfigureerde CA-vermelding met een naam die SFOS nodig heeft voor ingebouwde Let’s Encrypt-CA’s:

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

Vóór het onderhoudsvenster:

1. Maak een recente configuratieback-up en houd het back-upwachtwoord en de Secure Storage Master Key bij de hand.
2. Zoek onder Certificates > Certificate authorities naar de exacte namen. Als er geen overeenkomst is, hoeft vanwege NC-146082 niets te worden gewijzigd.
3. Documenteer bij een overeenkomst het type, Subject, Issuer, doel en of er een sleutelpictogram aanwezig is. Dit pictogram geeft aan dat de firewall de privésleutel van de CA bezit.
4. Exporteer een CA met privésleutel bovendien onder Backup and firmware > Import export > Export selective configuration als CertificateAuthority. Bepaal daarna welke certificaten en diensten afhankelijk zijn van de CA, bijvoorbeeld VPN, WebAdmin en portals, WAF, SMTP TLS of TLS Inspection.
5. Verwijder een door de beheerder geconfigureerde vermelding pas nadat alle afhankelijkheden zijn vervangen of aantoonbaar niet meer nodig zijn. Voer daarna de upgrade opnieuw uit.

Verwijder geen ingebouwde CA. Als WebAdmin de verwijdering weigert, de oorspronkelijke privésleutel ontbreekt of een verwijzing onduidelijk blijft, stop dan de upgrade en schakel Sophos Support in. Wijzigingen in de database of via Advanced Shell zijn geen veilig alternatief.

Controleer na de upgrade of de ingebouwde Let’s Encrypt-CA’s aanwezig zijn, afhankelijke certificaten weer Trusted tonen en de betrokken diensten werken.

Certificaat aan de juiste dienst toewijzen

Vóór de toewijzing: terugweg veiligstellen

Een certificaatwissel mag niet beginnen met het verwijderen van de oude vermelding:

1. Importeer het nieuwe certificaat en de volledige CA-keten.
2. Controleer SAN, uitgever, geldigheidsduur en Trusted.
3. Documenteer de huidige toewijzing en de betrokken diensten.
4. Wijs het nieuwe certificaat eerst aan één dienst toe.
5. Test deze dienst via de werkelijke FQDN en poort.
6. Selecteer bij fouten onmiddellijk opnieuw het oude certificaat.
7. Zet de overige diensten één voor één om en controleer ze telkens.
8. Verwijder het oude certificaat pas wanneer er geen verwijzingen meer bestaan en de nieuwe situatie stabiel werkt.

WAF en SMTP kunnen na elkaar worden omgezet. WebAdmin, User Portal, VPN Portal, Captive Portal en beide SPX-portals schakelen daarentegen via één gezamenlijke certificaatselectie gelijktijdig over.

Houd bij een wijziging aan WebAdmin ook een bestaande beheerderssessie en een alternatieve lokale beheertoegang open totdat de aanmelding en het certificaat via de bedoelde FQDN zijn gecontroleerd.

WebAdmin en portals

Onder Administration > Admin and user settings > Admin console and end-user interaction wordt één gezamenlijk certificaat geselecteerd voor deze diensten:

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

Selecteer in het veld Certificate het nieuwe certificaat en sla de wijziging op met Apply. Het certificaat moet alle FQDN’s dekken waarop de gebruikte diensten bereikbaar zijn. Als bijvoorbeeld admin.example.com voor WebAdmin en vpn.example.com voor het VPN Portal wordt gebruikt, moeten beide namen als SAN zijn opgenomen of moet de URL-planning worden gestroomlijnd.

Het certificaat van het VPN Portal beveiligt de HTTPS-website waar gebruikers profielen en clients downloaden. Het is niet automatisch het Local- of Remote-Certificate van een IPsec-tunnel.

WAF

Bewerk voor een WAF-publicatie de betreffende regel onder Rules and policies > Firewall, activeer HTTPS, selecteer bij HTTPS certificate het nieuwe certificaat en sla de wijziging op. De regel gebruikt Protect with web server protection. SNI, het domein in de regel en de SAN in het certificaat moeten dezelfde hostnaam beschrijven.

Een wijziging aan een WAF-regel start de Web-Server-Protection-regels opnieuw en verbreekt bestaande verbindingen. Voor productieapplicaties hoort de certificaatwissel daarom in een onderhoudsvenster. De volledige publicatie en controle worden beschreven in Sophos Firewall WAF: webservers veilig publiceren.

SMTP TLS in MTA-modus

Selecteer voor Mail Protection onder Email > General settings > SMTP TLS configuration bij TLS certificate het nieuwe servercertificaat en sla de wijziging op met Apply. Voor openbare SMTP-communicatie wordt een certificaat van een openbare CA aanbevolen, zodat andere systemen de identiteit kunnen controleren zonder een eigen CA te hoeven distribueren. De overige mailflow wordt beschreven in Sophos Firewall Mail Protection in MTA-modus.

Maak na de wijziging een nieuwe Sophos Firewall-back-up en documenteer de vervaldatum, eigenaar en volgende vernieuwing.

Certificaat en levering controleren

Bestand vóór het importeren controleren

Op een beheercomputer kan een PEM-certificaat met OpenSSL worden gecontroleerd zonder het te wijzigen:

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

Vervang firewall.pem door het lokale bestandspad. De uitvoer moet het verwachte Subject, de uitgever, de geldigheidsduur, de vereiste SAN’s en een SHA-256-fingerprint tonen. De opdracht leest geen privésleutel.

HTTPS-dienst extern controleren

Test WebAdmin, portals en WAF vanaf een beheercomputer met OpenSSL:

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

Vervang de FQDN en poort door die van de werkelijke HTTPS-dienst. -servername verstuurt de naam via SNI, zodat bij meerdere WAF- of portaldoelen het juiste certificaat wordt geselecteerd. De controle is geslaagd wanneer het verwachte certificaat verschijnt, de hostnaam overeenkomt en aan het einde Verification: OK staat.

Bij een interne CA moet de beheercomputer deze CA al vertrouwen of moet de CA voor de test uitdrukkelijk als vertrouwensanker worden opgegeven. Een verificatiefout kan anders aan het testapparaat liggen, ook als de firewall de juiste keten levert.

SMTP met STARTTLS controleren

SMTP op poort 25 of 587 begint normaal gesproken onversleuteld en schakelt pas met STARTTLS over op TLS. Hiervoor is een afzonderlijke test nodig:

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

Vervang mail.example.com en poort 25 door de SMTP-FQDN en de daadwerkelijk gebruikte STARTTLS-poort. Voor impliciete TLS op poort 465 wordt -starttls smtp niet gebruikt. Ook hier moeten het verwachte certificaat, de hostnaam en Verification: OK overeenkomen.

Controleer daarnaast in de browser of client:

• De URL gebruikt een van de opgenomen SAN’s.
• Uitgever en vervaldatum komen overeen met het nieuwe certificaat.
• Er verschijnt geen certificaatwaarschuwing.
• De verwachte WebAdmin-, portal-, WAF- of maildienst werkt.
• Een externe test ziet niet nog het certificaat van een voorgeschakelde load balancer of reverse proxy.

Veelvoorkomende fouten en volgende controle

• Trusted blijft leeg: de Intermediate-CA ontbreekt, de verkeerde CA is geïmporteerd of de keten hoort niet bij het servercertificaat. Controleer de Issuer en de volgorde van de CA’s.
• Import wordt geweigerd: controleer bestandsformaat, wachtwoord van de privésleutel, limiet van 30 tekens, combinatie van certificaat en sleutel en de systeemtijd.
• Browser meldt een onjuiste naam: de gebruikte FQDN of het IP-adres ontbreekt in de SAN’s. Vergelijk URL, DNS en certificaatnamen.
• Browser toont nog steeds het oude certificaat: de dienst gebruikt nog de oude toewijzing of een voorgeschakelde proxy beëindigt TLS. Controleer met openssl s_client en SNI rechtstreeks op het verwachte doel.
• WAF levert het verkeerde certificaat: controleer Hosted Address, Listen Port, Domain, SNI en de volgorde van overlappende WAF-regels.
• Alleen afzonderlijke clients geven een waarschuwing: controleer Trust Store, tussencertificaten, systeemtijd en eventuele Certificate-Pinning-beperkingen van de client.
• Een portal is na de wissel niet bereikbaar: selecteer opnieuw het oude certificaat en controleer eerst FQDN, poort, Device Access en certificaatketen afzonderlijk.

FAQ