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.

För WAF-certifikat får det interna certifikatobjektnamnet endast innehålla ASCII-bokstäver och siffror, inga blanksteg eller specialtecken. PublicVpnExampleCom2026 uppfyller detta krav. Objektnamnet är inte DNS-namnet; tjänstens namn finns fortfarande som ett FQDN i SAN.

• Automatisera DigiCert eller en annan offentlig CA: Förnya ett Sophos Firewall-certifikat via XML API och kontrollera tjänster förenar utfärdande, uppladdning via XML API, tjänstetilldelning och ett externt listenertest i en kontrollerad process från början till slut.
• 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.

Inbyggd Let’s Encrypt-begäran

Välj Request Let’s Encrypt certificate under Certificates > Certificates > Add, ange ett namn och lägg till FQDN under Domains. HTTP-01 stöder inte IP-adresser eller wildcarddomäner. Välj under Hosted address den publika WAN-adress som domänerna pekar på. Om en uppströmsrouter har den publika adressen måste dess DNAT för TCP 80 vidarebefordra valideringen till brandväggens WAN-gränssnitt; på själva brandväggen får ingen DNAT-regel leda bort denna adress och port från valideringen. Kontrollera befintliga publiceringar och planera ändringen utan att radera regler blint.

Efter Save visar Type värdet Let’s Encrypt CSR. Valideringen kan ta några minuter; ladda ned och tilldela certifikatet först när Valid from, Valid until och den gröna Trusted-markeringen visas. En ogiltig eller obefintlig domän kan inte rättas i den befintliga begäran: rätta DNS och domänval, ta bort endast den misslyckade begäran och skapa en ny. Let’s Encrypt-proceduren som länkas ovan behandlar förutsättningar, förnyelse och tjänstekontroller.

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.

Information och åtgärder i certifikatlistan

Som standard är ApplianceCertificate valt för WebAdmin, User Portal och Captive Portal. En befintlig konfiguration kan skilja sig; kontrollera alltid den faktiska tjänsttilldelningen före ett byte.

Under Certificates > Certificates visar SFOS Subject, Issuer och Purpose när muspekaren förs över ett certifikatnamn. Med åtgärderna kan certifikatet kopieras eller laddas ned som en .crt-fil; den nedladdade filen innehåller ingen privat nyckel. Regenerate är endast tillgängligt för det inbyggda ApplianceCertificate. Lokalt signerade certifikat kan återkallas direkt; SFOS lägger automatiskt till dem i CRL-listan Default. Det kontrollerade återkallningsförloppet beskrivs i Certificate Revocation Lists på Sophos Firewall.

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.

Även krypterad hämtning via POP3 och IMAP har en egen TLS-tilldelning under Email > General settings. Skanna och testa POP3 och IMAP på Sophos Firewall förklarar hur e-postserverns CA, certifikatvalidering, skanningsalternativ och brandväggsregel samverkar.

Om brandväggen ska integreras med organisationens PKI för detta ändamål beskriver Konfigurera en underordnad CA för TLS-inspektion på Sophos Firewall CSR-, AD CS-, EKU- och importförloppet för en dedikerad CA för omsignering.

Den inbyggda CA:n Default är trust anchor för lokalt signerade certifikat. När inställningarna sparas regenereras CA:n, vilket kan påverka portaler, SSL VPN, IPsec-peers och klienter som litar på den. Förnya Sophos Firewall Default CA kontrollerat ger den säkra ändringsprocessen.

Giltighetstid och förtroendekedja räcker inte om ett certifikat har återkallats i förtid. Den separata CRL-processen förklarar hur lokala och externa Certificate Revocation Lists importeras, uppdateras och kontrolleras i Sophos Firewall.

I FIPS 140-3-läge validerar SFOS dessutom nya och importerade certifikat mot de tillåtna nyckel- och digest-algoritmerna. Aktiveringen av läget är en separat fabriksåterställningsmigrering, inte ett normalt certifikatbyte.

Förstå CA-typer och nyckelinnehav

Under Certificates > Certificate authorities skiljer Type mellan brandväggens CA:er och externa CA:er:

• Internal: Default signerar lokalt skapade certifikat; inställningarna kan ändras och det publika certifikatet laddas ned.
• Built-in på brandväggen: SecurityAppliance_SSL_CA är den inbyggda signerings-CA:n för dekryptering. Den kan laddas ned och regenereras.
• Externa Built-in: de medföljande, globalt betrodda rot-CA:erna. Typen betyder inte att brandväggen har deras privata nycklar.
• Uploaded: egna uppladdade CA:er för Validation only eller Signing and validation.

Ikonen för privat nyckel visar att nyckeln faktiskt finns på brandväggen. En vanlig CA-nedladdning används för att distribuera det publika certifikatet. Behövs ett återställningspaket med CA-nycklar, öppna Backup and firmware > Import export > Export selective configuration: välj CertificateAuthority, sedan Apply selected items, Export och Download. Skydda paketet som en hemlighet och distribuera det inte till klienter; den selektiva exportproceduren som länkas nedan behandlar lösenord, SSMK och återimport.

Regenerate roterar en CA; det löser inte en saknad Trusted-status. Utgången giltighet eller kompromettering kan kräva rotation, men kontrollera först beroende tjänster och klienternas tillit. Att spara ändringar i Default utlöser redan regenerering. Följ utrullningen av inspektions-CA:n som länkas ovan för SecurityAppliance_SSL_CA och den separata förnyelseproceduren för Default.

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: PublicVpnExampleCom2026
• 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.

Synkronisera helst tiden med den förinställda NTP-servern eller en egen NTP-server. En felaktig manuellt inställd klocka kan hindra certifikatimport. Kontrollera först den faktiska tiden vid importfel i stället för att ändra certifikatets giltighetstid.

Skapa ett lokalt signerat certifikat

För en intern tjänst kan SFOS signera ett certifikat direkt med den inbyggda CA:n Default. Det är bara en lämplig metod när de anslutande enheterna redan litar på denna CA eller får dess publika certifikat genom en kontrollerad process. För publikt åtkomliga tjänster är ett certifikat från en publik CA normalt ett bättre val.

Under Certificates > Certificates > Add väljs Generate locally-signed certificate. Ange sedan ett unikt namn och önskad giltighetstid; SFOS föreslår som standard ett år. Key type (RSA eller Elliptic curve), nyckellängd eller kurva och Secure hash måste motsvara organisationens kryptografiska krav och klienternas stöd.

Common name är obligatoriskt i Subject. SFOS fyller först i Country name, State, Locality name, Organization name, Organization unit name och kontaktens e-postadress med licensuppgifter, men alla värden måste kontrolleras mot den faktiska organisationen och det avsedda syftet innan inställningarna sparas. Under Subject Alternative Names anges alla DNS-namn och nödvändiga IPv4- eller IPv6-adresser.

Minst ett SAN eller ett Certificate ID krävs. Certificate ID under Advanced settings är endast avsett för kompatibilitet med äldre SFOS-versioner och ersätter inte en korrekt SAN-lista för moderna HTTPS-klienter. Efter Save kontrolleras utfärdaren Default, giltighetstiden, SAN-posterna och den efterföljande tilldelningen till tjänsten.

Använd kalendrarna för Valid from och Valid until. Större RSA-nycklar ökar beräkningsarbetet för kryptering och dekryptering; välj längden enligt säkerhetspolicy och klientkompatibilitet, inte alltid den största.

För lokalt signerade certifikat och CSR anger Country name, State och Locality name land, region och ort; Organization name certifikatets innehavare och Organization unit name ansvarig avdelning. Distinguished name uppdateras dynamiskt när uppgifterna ändras. Lägg till varje DNS-, IPv4- eller IPv6-SAN i listan med plusknappen och kontrollera listan före Save.

För äldre SFOS-versioner erbjuder Advanced settings > Certificate ID typerna DNS, IP address, Email och DER ASN1 DN [X.509]. DNS är ett domännamn som kan lösas, IP address en egen publik adress och Email kontaktadressen. DER ASN1 DN [X.509] ger objektet som ska skyddas en distinguished-name-identitet. Välj typen enligt motpartens krav; detta äldre ID ersätter inte HTTPS-SAN, inte heller i en CSR.

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 PublicVpnExampleCom2026.
5. Välj Key type, nyckellängd eller kurva samt Secure 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.

Kontrollera även övriga Subject-fält och kontaktens e-postadress. SFOS kan förifylla dem med licensuppgifter, men de hör till den specifika certifikatbegäran och får inte godtas utan granskning.

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.

CSR-formuläret stöder också DNS-, IPv4- och IPv6-SAN och de äldre Certificate ID-typerna ovan. Efter sparandet visas CSR i certifikatlistan. Visningsåtgärden öppnar en dialog där begäran kan kopieras eller laddas ned som .csr. Skicka bara begäran, aldrig den privata nyckeln; CA:n kan utfärda en underordnad CA i stället för ett servercertifikat utifrån den.

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 det syfte som motsvarar det utfärdade objektet:
   • Certificate only: det utfärdade server- eller klientcertifikatet lagras under Certificates > Certificates.
   • Certificate authority only: alternativet gäller en CA som utfärdats utifrån CSR-begäran, till exempel en underordnad CA. Den visas sedan under Certificates > Certificate authorities.
   • Certificate and certificate authority: uppladdningen innehåller både det utfärdade certifikatet och dess Root- eller underordnade CA.
5. Kör Import certificate.

Vid en CA-import använder SFOS först Common Name som CA-namn; det kan ändras före importen. SFOS kopplar certifikatet eller CA-certifikatet som utfärdats från CSR-begäran till den tillhörande privata nyckeln på brandväggen. Därefter tas CSR-posten bort. 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) / CER (.cer): DER är binärt; .cer kan innehålla DER- eller PEM-kodning. Kontrollera den faktiska kodningen, inte bara filändelsen. 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.

När en CA laddas upp direkt identifierar SFOS automatiskt X.509-filformatet; .pem, .der och .cer stöds. Om CA:n motsvarar en CSR-begäran som skapats på brandväggen övertar SFOS CSR-namnet och ställer in syftet på Signing and validation, eftersom den tillhörande privata nyckeln redan finns på brandväggen. Kontrollera därefter ikonen för den privata nyckeln. Användning som CA för omsignering hör till den separata proceduren för en underordnad TLS Inspection-CA.

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.

Importera en extern signerings-CA utan matchande CSR på brandväggen

Den här proceduren gäller en externt skapad Intermediate-CA som brandväggen ska signera certifikat med, inte servercertifikatet eller en kedja som endast används för validering. CA-certifikatet och den CA:ns egen privata nyckel måste finnas som ett verifierat par. Överför inte Root-CA:ns nyckel till brandväggen. En CSR som skapats på brandväggen är fortfarande att föredra eftersom den undviker nyckeltransport.

Om signerings-CA:n innehåller Extended Key Usage (EKU) måste den omfatta TLS Web Server Authentication. Ändra inte en CA som redan används för omsignering till Validation only: då förlorar den signeringsfunktionen som krävs för att åter kryptera dekrypterad SSL/TLS-trafik. Bevara före ändringen en säkerhetskopia, tidigare CA-val och dess beroenden.

Kontrollera före tilldelningen även alla avsedda val för omsignering: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings, Profiles > Decryption profiles och Web > General settings under HTTPS decryption and scanning. Där får endast en CA med Signing and validation användas. En CA med grön Trusted-status men utan signeringsnyckel är ingen ersättning.

1. Öppna Certificates > Certificate authorities och välj Add, inte servercertifikatlistan.
2. Ladda upp Intermediate-CA-certifikatet eller klistra in certifikattexten. SFOS identifierar automatiskt .pem, .der och .cer.
3. SFOS söker efter en matchande CSR på brandväggen. Om en matchning finns används dess namn och Signing and validation; den privata nyckeln finns redan på brandväggen. Ändra det föreslagna namnet vid behov och välj Save. Ingen ytterligare nyckeluppladdning behövs.
4. Utan matchande CSR visas ytterligare alternativ. Välj Signing and validation för denna signerings-CA under Use certificate for.
5. Ladda upp denna Intermediate-CA:s Private key, inte servercertifikatets privata nyckel. Ange nyckellösenordet för kryptering; det får innehålla högst 30 tecken. Använd en skyddad nyckel och ett starkt lösenord inom denna gräns vid överföringen.
6. Ange ett unikt CA-namn eller ändra det föreslagna namnet och välj Save.
7. Ladda upp eller klistra in tillhörande Root-CA separat via Certificates > Certificate authorities > Add, ställ Use certificate for på Validation only och välj Save. Den validerar Intermediate-CA:n och behöver ingen privat nyckel för detta.
8. Kontrollera under Certificates > Certificates den gröna bocken i Trusted för det importerade servercertifikatet. Öppna sedan filtret bredvid Type under Certificates > Certificate authorities, välj Uploaded och klicka på Apply. Ikonen för privat nyckel måste visas bredvid Intermediate-/underordnad CA; den bekräftar att signeringsnyckeln finns, inte att ett trafiktest har lyckats.

Om Trusted saknas kontrolleras utfärdaren och hela kedjan; om nyckelikonen saknas kontrolleras CA-nyckelparet, importen och lösenordet före tilldelning. Enbart import ändrar inte CA-valet för TLS-inspektion. Företags-CSR/AD CS, trafikval och pilottest finns kvar i den länkade proceduren för underordnad TLS Inspection-CA. Behåll vid ett senare byte det tidigare valet för återgång; ta bort nya CA-poster först när de saknar beroenden. Ett återbyte kan inte ångra en nyckelöverföring: ta bort importfiler från osäkra tillfälliga lagringsplatser och behåll skyddade återställningskopior enligt PKI-policyn.

Uppgradering till SFOS 21: kontrollera reserverade CA-namn

Vid uppgradering till SFOS 21 kan NC-146082 blockera migreringen. Orsaken är inte certifikatets giltighet, utan en befintlig CA-post med ett namn som SFOS 21 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. Det säkra arbetsflödet för paket, SSMK och återimport beskrivs i Exportera och importera konfiguration selektivt. 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 ett tilldelningsmål. WebAdmin-/portalgruppen ändras gemensamt, medan WAF-regler och SMTP kan ändras individuellt.
5. Testa alla tjänster som påverkas av tilldelningsmålet via deras riktiga FQDN och portar.
6. Välj omedelbart det gamla certifikatet igen vid fel.
7. Ändra övriga tilldelningsmål ett 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.

Den fullständiga proceduren för portal-FQDN, lösenordsregistrering, Reply Portal och e-postflöde finns i Konfigurera och testa SPX-e-postkryptering.

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.

För enbart intern administration kan SFOS även skydda WebAdmin-namnet med ett lokalt signerat certifikat. Under Certificates > Certificates > Add väljer du Generate locally-signed certificate och anger brandväggens exakta internt upplösbara värdnamn i både Common name och DNS names, till exempel fw01.example.com. Ange sedan samma värde som Hostname under Administration > Admin and user settings, välj det nya Certificate och aktivera Use the firewall’s configured hostname.

För att webbläsare ska lita på certifikatet laddar du ned det publika certifikatet för CA:n Default under Certificates > Certificate authorities, packar upp arkivet och distribuerar Default.der eller Default.pem som Default.crt till de hanterade enheterna. Distribuera Sophos Firewall CA-certifikat för TLS-inspektion beskriver säker distribution och kontroll för Windows, macOS och Firefox. Endast det publika CA-certifikatet distribueras, aldrig en privat nyckel.

Att byta namn till Default.crt ändrar bara filnamnet; det konverterar inte DER till PEM och skapar ingen tillit. Använd ett format som importdialogen stöder och jämför SHA-256-fingeravtrycket för den egna Default-CA:n före och efter importen. Ett matchande hostname löser inte ensamt ett tillitsfel: även CA-tillit, SAN och giltighet måste stämma. Kontrollera sedan en ny webbläsaranslutning och inloggning via avsedd FQDN; kringgå inte kvarvarande varningar.

⚠️ Den här metoden tar endast bort webbläsarvarningen på hanterade enheter som litar på CA:n Default. Certifikatet blir inte publikt betrott. Om CA:n Default senare genereras om måste certifikaten och förtroendedistributionen förnyas under kontrollerade former.

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.

Konfigurera IPsec Site-to-Site med certifikat beskriver hur CA, Certificate ID, Local Certificate och Remote Certificate samverkar mellan två brandväggar.

Återställ WebAdmin-certifikatet till standard via konsolen

Om WebAdmin inte längre kan användas efter en felaktig certifikattilldelning kan fungerande CLI-åtkomst till Main Menu användas som break-glass-väg. Dokumentera först det använda FQDN-namnet, den tidigare certifikattilldelningen och förväntat fingerprint. Behåll en befintlig öppen administratörssession.

Om du redan befinner dig i 4. Device Console, återgå först till Main Menu. Öppna där 2. System Configuration > 4. Reset Default Web Admin Certificate och bekräfta återställningen med y. SFOS ställer in WebAdmin-konsolens certifikat på enhetens standardcertifikat. Åtgärden återställer varken det tidigare valda certifikatet eller en gammal privat nyckel för CA:n Default och den regenererar inte CA:n. Den medföljande CA:n Default ingår också i HTTPS-kedjan för webproxyns blockerings- och varningssidor, men alternativ 4 återställer inte den proxyfunktionen. En webbläsarvarning eller ett namnfel kan därför förväntas med det lokalt signerade standardcertifikatet.

Öppna efter bekräftelsen WebAdmin på nytt endast via den avsedda hanteringsvägen, kontrollera certifikatet som faktiskt presenteras och testa en ny inloggning. Eftersom WebAdmin och flera portaler använder samma certifikatval testas även alla portaler som används. Därefter kan ett korrigerat produktionscertifikat tilldelas på nytt under kontrollerade former i Administration > Admin and user settings. Konsolåterställningen är en återställningsväg, inte en permanent lösning för offentligt förtroende.

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

Under Email > General settings > SMTP TLS configuration använder TLS certificate, beroende på konfigurationen, ett CA- eller servercertifikat för att skanna SMTP-anslutningar via TLS. Dokumentera därför tidigare syfte, certifikatverifiering och berörda inkommande och utgående anslutningar före bytet. Om brandväggen själv presenterar en serveridentitet vid offentlig SMTP-kommunikation rekommenderas ett certifikat från en offentlig CA för detta. Testa båda trafikriktningarna med de TLS-lägen som faktiskt används efter Apply. Ö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.

För ett externt genererat certifikat måste den offentliga nyckel som härleds från den privata nyckeln stämma överens med certifikatets offentliga nyckel:

(
tmpdir=$(mktemp -d)
trap 'rm -rf -- "$tmpdir"' EXIT
openssl x509 -in firewall.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
  openssl pkey -in firewall.key -pubout > "$tmpdir/key-public-key.pem" &&
  cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

Ersätt firewall.key med den lokala sökvägen till den privata nyckeln. För en krypterad nyckel frågar openssl pkey interaktivt efter lösenordet. cmp ger ingen utdata när de offentliga nycklarna är identiska; annars får paret inte importeras. De tillfälliga filerna innehåller endast offentliga nycklar men tas ändå bort efter jämförelsen. Visa eller ladda aldrig upp den privata nyckeln och bifoga den inte till ett supportärende.

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 -showcerts -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. -showcerts visar alla certifikat som tjänsten skickar; servern behöver normalt inte skicka Root-CA:n. Det förväntade servercertifikatet och de Intermediate-CA:er som krävs för att bygga kedjan måste visas i utdata. Verification: OK bekräftar dessutom kontrollen av hostname och kedjan mot testdatorns trust store. En Intermediate-CA som redan finns där kan dock dölja att servern levererar en ofullständig kedja.

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: Det använda FQDN-namnet eller den använda IP-adressen 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