Importera och tilldela certifikat på Sophos Firewall

Ett certifikat är inte klart att användas på Sophos Firewall förrän fyra delar stämmer överens: hostname, servercertifikat, privat nyckel och den utfärdande CA-kedjan. Därefter måste certifikatet tilldelas till rätt tjänst. En post under Certificates > Certificates ändrar i sig inte någon portal eller WAF-regel.

För ett certifikat från en intern eller offentlig CA är den säkraste standardmetoden:

1. Skapa en Certificate Signing Request (CSR) under Certificates > Certificates > Add.
2. Låt önskad CA signera CSR-begäran.
3. Importera det utfärdade certifikatet via importåtgärden för den befintliga CSR-begäran.
4. Kontrollera den installerade tillhörande CA:n under Trusted och giltighetstiden under Valid until.
5. Tilldela certifikatet till önskad tjänst och testa från en klient.

Med denna metod skapas den privata nyckeln på brandväggen och behöver inte lämna den. Ett certifikat som redan har skapats externt kan också laddas upp, men då krävs den tillhörande privata nyckeln och eventuellt de Intermediate- och Root-CA-certifikat som saknas.

Om det redan finns en PFX- eller PEM-fil är snabbaste vägen Certificates > Certificates > Add > Upload certificate: välj format, ladda upp certifikatet tillsammans med nödvändig privat nyckel och lösenord och kontrollera sedan tillhörande CA, giltighetstid och tjänstetilldelning.

Vilken certifikatmetod passar?

• Offentlig eller intern CA, nytt certifikat: Skapa CSR-begäran på brandväggen. Det minskar nyckelöverföringar och förhindrar att certifikat och nycklar enkelt blandas ihop.
• Befintligt certifikat med privat nyckel: Ladda upp certifikatet som PEM, DER, CER eller PKCS12. Format, lösenord och CA-kedja måste stämma.
• Let’s Encrypt för en offentlig brandväggstjänst: Den inbyggda processen kan hantera utfärdande och förnyelse. Hela arbetsflödet beskrivs i Konfigurera Let’s Encrypt-certifikat på Sophos Firewall.
• Externt wildcard-certifikat: Skapa det utanför brandväggen och importera det därefter. Planering och DNS-01-validering beskrivs i Skapa Let’s Encrypt wildcard-certifikat.
• Endast för interna, hanterade klienter: Ett lokalt signerat certifikat kan räcka om alla klienter litar på den utfärdande interna CA:n.

Ett självsignerat eller lokalt signerat certifikat har inte automatiskt osäker kryptering. Utan en distribuerad förtroendekedja kan klienten däremot inte verifiera identiteten på ett tillförlitligt sätt och visar en varning. För offentligt tillgängliga portaler och WAF-applikationer är därför en offentlig CA normalt det bättre valet.

Skillnaden mellan certifikat, CA, privat nyckel och CSR

De fyra komponenterna har olika uppgifter:

• Servercertifikat: innehåller identitet, information om den offentliga nyckeln, giltiga namn och giltighetstid. Det visas för klienten.
• Privat nyckel: bevisar att brandväggen får använda certifikatet. Den får aldrig hamna i ärenden, skärmbilder eller offentliga lagringsplatser.
• CA-certifikat: bildar förtroendekedjan från den utfärdande Intermediate-CA:n till Root-CA:n. Ingen privat CA-nyckel behövs för detta.
• CSR: innehåller certifikatbegäran och den offentliga nyckeln. När CSR-begäran skapas på brandväggen stannar den tillhörande privata nyckeln på enheten.

En CA för TLS Inspection har en annan uppgift än ett servercertifikat för WebAdmin eller WAF. Inspection-CA:n signerar nya certifikat åt klienter under dekrypteringen. Val och distribution av den beskrivs i Distribuera Sophos Firewall CA-certifikat för TLS Inspection.

Förbered namn, giltighetstid och kedja

Före importen måste det vara klart vilket namn användare och system faktiskt öppnar. Moderna klienter kontrollerar främst Subject Alternative Names (SAN). Enbart Common Name är ingen tillförlitlig ersättning.

Exempel:

• anropad URL: https://vpn.example.com
• certifikatnamn i SFOS: public-vpn-example-com-2026
• SAN i certifikatet: vpn.example.com
• DNS: vpn.example.com pekar på avsedd brandväggs- eller WAF-anslutning

vpn.example.com är ett exempel och ersätts med den egna FQDN-adressen. Om en administratör i stället ansluter via IP-adressen eller ett annat alias stämmer certifikatet endast om även detta namn eller denna IP-adress finns med som SAN.

Kontrollera före ändringen:

• Brandväggens datum, tid och NTP stämmer.
• Alla FQDN-adresser som behövs finns som SAN i begäran eller certifikatet.
• Privat nyckel och certifikat hör ihop.
• Intermediate- och Root-CA är kända.
• Utgångsdatum och ansvar för förnyelse är dokumenterade.
• Det tidigare certifikatet och dess tilldelningar behålls för en möjlig återgång.

Rekommenderad metod: skapa CSR på brandväggen

Skapa CSR

1. Öppna Certificates > Certificates.
2. Välj Add.
3. Välj Generate certificate signing request (CSR) under Action.
4. Ange ett tydligt internt namn, till exempel public-vpn-example-com-2026.
5. Välj Key Type, nyckellängd eller kurva samt hash enligt den egna säkerhetspolicyn och CA-kraven.
6. Ange primär FQDN under Common name, till exempel vpn.example.com.
7. Lägg under Subject Alternative Names till minst det DNS-namn som faktiskt ska användas.
8. Spara och ladda ned CSR-begäran via nedladdningsikonen.

Det interna certifikatnamnet är endast en beteckning i SFOS. Det behöver inte motsvara FQDN-adressen, men bör visa syfte och förnyelseår. SAN-posterna ingår däremot i den tekniska identitetskontrollen och måste stämma med den URL som senare används.

Låt signera CSR-begäran

Skicka den nedladdade CSR-begäran till ansvarig offentlig eller intern CA. Låt inte CA:n skapa nya nyckelfiler om den privata nyckel som skapades på brandväggen ska användas. CA:n levererar därefter det signerade servercertifikatet och, beroende på leverantör, ytterligare Intermediate-certifikat.

Kontrollera före importen:

• CA:n har signerat rätt CSR.
• SAN-listan innehåller alla godkända namn.
• Giltighetstid och utfärdare motsvarar beställningen eller den interna policyn.
• Hela CA-kedjan finns tillgänglig.

Importera det signerade certifikatet till CSR-begäran

1. Öppna Certificates > Certificates.
2. Välj importåtgärden under Manage på raden för rätt CSR.
3. Ladda upp det utfärdade certifikatet eller klistra in certifikattexten.
4. Välj normalt Certificate only som syfte. Om samma fil även innehåller CA-kedjan väljer du det syfte som motsvarar både certifikatet och CA:n.
5. Kör Import certificate.

SFOS kopplar certifikatet till den privata nyckel som finns på brandväggen och tar därefter bort CSR-posten. Kontrollera därför noggrant före importen att rätt CSR-rad verkligen har valts.

Ladda upp ett befintligt certifikat med privat nyckel

Om certifikat och nyckel redan har skapats utanför brandväggen:

1. Öppna Certificates > Certificates > Add.
2. Välj Upload certificate.
3. Ange ett unikt namn.
4. Välj det befintliga filformatet.
5. Ladda upp certifikatet och de nyckeluppgifter som formatet kräver.
6. Ange lösenordet om den privata nyckeln är krypterad.
7. Spara.

SFOS stöder följande certifikatformat:

• PEM (.pem): Base64-kodat; certifikat och privat nyckel finns normalt i separata filer.
• DER (.der) och CER (.cer): binära certifikatformat; den privata nyckeln finns separat.
• PKCS7 (.p7b): kan innehålla certifikat och en kedja, men ingen privat nyckel.
• PKCS12 (.pfx eller .p12): kan innehålla servercertifikat, CA-kedja och privat nyckel tillsammans.

RSA- och ECC-nycklar stöds. SFOS accepterar högst 30 tecken för lösenordet till en importerad privat nyckel. Denna produktbegränsning är inget skäl att använda en oskyddad privat nyckel: använd ett starkt lösenord inom gränsen för överföringen och ta därefter bort importfilen från osäkra mellanlagringsplatser.

Komplettera en CA-kedja som saknas

Under Certificates > Certificates visar en grön post i Trusted att tillhörande CA är installerad på SFOS. Om den saknas kontrollerar du först utfärdare och kedja:

1. Öppna Certificates > Certificate authorities.
2. Välj Add.
3. Ladda upp den Intermediate- eller Root-CA som saknas eller klistra in certifikattexten.
4. Använd Validation only för en ren förtroendekedja.
5. Spara och kontrollera servercertifikatets Trusted-status igen.

En offentlig Root- eller Intermediate-CA behöver ingen privat nyckel för validering. Signing and validation är endast avsett för en CA som brandväggen själv ska signera certifikat med och vars privata nyckel medvetet finns på brandväggen.

Uppgradering till SFOS 21 eller senare: kontrollera reserverade CA-namn

Vid den första uppgraderingen av en äldre installation till SFOS 21 eller senare kan NC-146082 blockera migreringen. Orsaken är inte certifikatets giltighet, utan en befintlig CA-post med ett namn som SFOS behöver för de inbyggda Let’s Encrypt-CA:erna:

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

Före underhållsfönstret:

1. Skapa en aktuell konfigurationsbackup och ha backupens lösenord samt Secure Storage Master Key tillgängliga.
2. Sök efter de exakta namnen under Certificates > Certificate authorities. Om ingen träff finns kräver NC-146082 ingen ändring.
3. Dokumentera typ, Subject, Issuer, användningsområde och om en nyckelikon visas för en träff. Ikonen visar att brandväggen har CA:ns privata nyckel.
4. Exportera dessutom en CA med privat nyckel under Backup and firmware > Import export > Export selective configuration som CertificateAuthority. Identifiera sedan vilka certifikat och tjänster som är beroende av CA:n, till exempel VPN, WebAdmin och portaler, WAF, SMTP TLS eller TLS Inspection.
5. Ta endast bort en administratörskonfigurerad post när alla beroenden har ersatts eller bevisligen inte längre behövs. Försök därefter uppgraderingen igen.

Ta inte bort en inbyggd CA. Om WebAdmin vägrar att radera posten, den ursprungliga privata nyckeln saknas eller en referens förblir oklar ska uppgraderingen avbrytas och Sophos Support kontaktas. Ändringar i databasen eller via Advanced Shell är inget säkert alternativ.

Kontrollera efter uppgraderingen att de inbyggda Let’s Encrypt-CA:erna finns, att beroende certifikat åter visar Trusted och att berörda tjänster fungerar.

Tilldela certifikatet till rätt tjänst

Säkra en återgång innan tilldelningen

Ett certifikatbyte bör inte börja med att den gamla posten tas bort:

1. Importera det nya certifikatet och hela CA-kedjan.
2. Kontrollera SAN, utfärdare, giltighetstid och Trusted.
3. Dokumentera tidigare tilldelning och berörda tjänster.
4. Tilldela först det nya certifikatet till en tjänst.
5. Testa tjänsten via dess riktiga FQDN och port.
6. Välj omedelbart det gamla certifikatet igen vid fel.
7. Ändra övriga tjänster en i taget och kontrollera varje ändring.
8. Ta inte bort det gamla certifikatet förrän inga referenser finns kvar och det nya läget fungerar stabilt.

WAF och SMTP kan ändras en i taget. WebAdmin, User Portal, VPN Portal, Captive Portal och de båda SPX-portalerna ändras däremot samtidigt via ett gemensamt certifikatval.

Vid en ändring för WebAdmin bör även en befintlig administratörssession och en alternativ lokal hanteringsanslutning hållas öppna tills inloggning och certifikat har kontrollerats via avsedd FQDN.

WebAdmin och portaler

Under Administration > Admin and user settings > Admin console and end-user interaction väljs ett gemensamt certifikat för följande tjänster:

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

Välj det nya certifikatet i fältet Certificate och spara med Apply. Certifikatet måste täcka alla FQDN-adresser som de använda tjänsterna nås via. Om exempelvis admin.example.com används för WebAdmin och vpn.example.com för VPN Portal måste båda namnen finnas som SAN, eller också måste URL-planeringen samordnas.

VPN-portalcertifikatet skyddar HTTPS-webbplatsen där användare hämtar profiler och klienter. Det är inte automatiskt Local- eller Remote-Certificate för en IPsec-tunnel.

WAF

För en WAF-publicering redigerar du den aktuella regeln under Rules and policies > Firewall, aktiverar HTTPS, väljer det nya certifikatet under HTTPS certificate och sparar. Regeln använder Protect with web server protection. SNI, domänen i regeln och SAN i certifikatet måste beskriva samma hostname.

När en WAF-regel ändras startas Web Server Protection-reglerna om och befintliga anslutningar bryts. För produktionsapplikationer hör certifikatbytet därför hemma i ett underhållsfönster. Hela publiceringen och kontrollen beskrivs i Sophos Firewall WAF: Publicera webbservern säkert.

SMTP TLS i MTA-läge

För Mail Protection väljer du det nya servercertifikatet i fältet TLS certificate under Email > General settings > SMTP TLS configuration och sparar med Apply. För offentlig SMTP-kommunikation rekommenderas ett certifikat från en offentlig CA så att motparter kan verifiera identiteten utan egen CA-distribution. Övrigt e-postflöde beskrivs i Sophos Firewall Mail Protection i MTA-läge.

Efter ändringen skapar du en ny Sophos Firewall-säkerhetskopia och dokumenterar utgångsdatum, ansvarig och nästa förnyelse.

Kontrollera certifikat och leverans

Kontrollera filen före importen

Ett PEM-certifikat kan kontrolleras skrivskyddat med OpenSSL på en administratörsdator:

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

Ersätt firewall.pem med den lokala filsökvägen. Utdata ska visa förväntat Subject, utfärdare, giltighetstid, nödvändiga SAN och ett SHA-256-fingeravtryck. Kommandot läser ingen privat nyckel.

Kontrollera HTTPS-tjänsten utifrån

Testa WebAdmin, portaler och WAF med OpenSSL från en administratörsdator:

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

Ersätt FQDN och port med den verkliga HTTPS-tjänsten. -servername skickar namnet via SNI så att rätt certifikat väljs när det finns flera WAF- eller portalmål. Kontrollen lyckas om det förväntade certifikatet visas, hostname stämmer och Verification: OK står i slutet.

Om en intern CA används måste administratörsdatorn redan lita på denna CA eller uttryckligen få den som förtroendeankare för testet. Annars kan ett verifieringsfel bero på testdatorn trots att brandväggen levererar rätt kedja.

Kontrollera SMTP med STARTTLS

SMTP på port 25 eller 587 börjar normalt okrypterat och växlar först till TLS med STARTTLS. Därför krävs ett separat test:

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

Ersätt mail.example.com och port 25 med SMTP-tjänstens FQDN och den STARTTLS-port som faktiskt används. För implicit TLS på port 465 används inte -starttls smtp. Även här måste förväntat certifikat, hostname och Verification: OK stämma överens.

Kontrollera dessutom i webbläsaren eller klienten:

• URL:en använder ett av de SAN som ingår.
• Utfärdare och utgångsdatum motsvarar det nya certifikatet.
• Ingen certifikatvarning visas.
• Förväntad WebAdmin-, portal-, WAF- eller e-posttjänst fungerar.
• Ett externt test ser inte fortfarande certifikatet från en framförliggande lastbalanserare eller Reverse Proxy.

Typiska fel och nästa kontroll

• Trusted förblir tomt: Intermediate-CA saknas, fel CA har importerats eller kedjan hör inte till servercertifikatet. Kontrollera Issuer och CA-ordning.
• Importen avvisas: Kontrollera filformat, lösenord för privat nyckel, gränsen på 30 tecken, certifikat-nyckelparet och systemtiden.
• Webbläsaren rapporterar fel namn: Använd FQDN eller IP-adress saknas i SAN. Jämför URL, DNS och certifikatnamn.
• Webbläsaren visar fortfarande det gamla certifikatet: Tjänsten använder fortfarande den gamla tilldelningen eller en framförliggande proxy terminerar TLS. Kontrollera med openssl s_client och SNI direkt mot förväntat mål.
• WAF levererar fel certifikat: Kontrollera Hosted Address, Listen Port, Domain, SNI och ordningen på överlappande WAF-regler.
• Endast enskilda klienter varnar: Kontrollera klientens Trust Store, Intermediate-certifikat, systemtid och möjliga begränsningar för Certificate Pinning.
• En portal kan inte nås efter bytet: Välj det gamla certifikatet igen och kontrollera först FQDN, port, Device Access och certifikatkedja var för sig.

Vanliga frågor