Distribuera Sophos Firewall CA-certifikat för TLS Inspection

När en Sophos Firewall dekrypterar HTTPS-anslutningar via TLS Inspection eller HTTPS-skanning, skapar brandväggen ett nytt certifikat för anslutningen som kontrolleras och signerar det med en lokal CA. Klienter måste lita på denna CA, annars visas webbläsarvarningar eller program avbryter anslutningen.

Den inbyggda CA:n SecurityAppliance_SSL_CA är tillgänglig som standard i Sophos Firewall. Den kan hämtas under Certificates > Certificate authorities och distribueras till hanterade klienter. Det räcker dock inte att en valfri Sophos CA finns på klienterna. Den distribuerade CA:n måste motsvara den CA som faktiskt används för Re-Signing i TLS Inspection-konfigurationen.

En miljö med egen enterprise-PKI kan i stället utfärda en dedikerad underordnad CA för TLS-inspektion på Sophos Firewall. Den här vägen håller signeringsnyckeln på brandväggen och förankrar förtroendet i den befintliga enterprise root-CA:n, men kräver en kontrollerad PKI- och pilotprocess.

SecurityAppliance_SSL_CA är inte den inbyggda CA:n Default för lokalt signerade certifikat. Om denna andra trust anchor måste roteras gäller processen Förnya Sophos Firewall Default CA kontrollerat. Ersätt inte båda CA-objekten tillsammans på misstanke.

Beroende på driftläge kontrolleras detta val på olika ställen: för DPI-baserade SSL/TLS Inspection-regler är CA:n under Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings relevant. En Decryption Profile som tilldelats regeln kan åsidosätta dessa globala värden. För Web Proxy finns HTTPS Scanning CA under Web > General settings > HTTPS decryption and scanning. Om den aktiva sökvägen väljer en annan CA än den som klienterna litar på uppstår certifikatfel, även om en Sophos CA har distribuerats.

Artikeln Inför TLS Inspection korrekt på Sophos Firewall beskriver hela utrullningen. Den här guiden fokuserar på att distribuera CA-certifikatet till Windows, macOS och Firefox.

Vad detta certifikat gör

Certifikatet Sophos Firewall CA är inte ett servercertifikat för portalen WebAdmin, WAF eller VPN. Det är grunden för förtroende med vilken klienter accepterar HTTPS-anslutningarna som omsigneras av brandväggen.

Separationen är viktig:

• Firewall CA: signerar nya certifikat som skapas under TLS Inspection.
• Re-Signing CA eller HTTPS Scanning CA: den CA som uttryckligen har valts för brandväggens DPI-läge eller Web Proxy-läge.
• Client Trust Store: avgör om webbläsare och applikationer litar på denna CA.
• SSL/TLS Inspection Regel: bestämmer vilken trafik som dekrypteras.
• Dekrypteringsprofil: bestämmer hur strikt certifikat, TLS-versioner och fel hanteras.
• Uteslutningslista: förhindrar dekryptering av problematiska eller avsiktligt uteslutna mål.

CA-distributionen aktiverar alltså inte TLS Inspection. Den förhindrar bara att hanterade klienter visar certifikatvarningar för dekrypterad HTTPS-trafik. Om trafiken faktiskt dekrypteras beror på brandväggsregler, web policy, SSL/TLS Inspection-regler, Decryption Profiles och undantag.

CA-distributionen ersätter inte heller korrekt protokollstyrning. SSL/TLS Inspection-regler gäller TCP-trafik. Om webbtrafiken går via QUIC eller HTTP/3 på UDP 443 följer inspektionen en annan väg och måste hanteras separat.

Innan utrullningen

Före distributionen ska det vara klart vilka klienter som ska använda TLS Inspection. Ett CA-certifikat ska inte installeras okontrollerat på alla enheter, utan riktat på hanterade företagsklienter.

Förberedelser:

• Definiera testgrupp eller test-OU.
• Förtydliga driftläge: DPI-läge, Web Proxy eller båda varianterna.
• Dokumentera vald CA i SSL/TLS inspection settings, använda Decryption Profiles och Web General settings.
• Dokumentera rollback och undantagsprocessen.
• Hämta CA-certifikatet endast från den egna brandväggen.
• Testa distributionen på några enheter först.
• Kontrollera webbläsare, affärsapplikationer och uppdateringar efter distribution.
• Bedöm mobila enheter och appar med eget Trust Store eller Certificate Pinning separat.
• Ta bort gamla eller inte längre använda CA-certifikat från Client Trust Store.

⚠️ Obs: Om CA:n eller den privata nyckeln har komprometterats räcker det inte med en ny distribution. Då måste CA:n återskapas på brandväggen, distribueras på nytt och den gamla CA:n tas bort från klienterna.

Välj distributionsväg

Den korrekta distributionsvägen beror på hur enheterna hanteras.

• Windows domänklienter: Använd GPO i Trusted Root Certification Authorities. Detta är det renaste sättet för klassiska Active Directory-miljöer.
• Windows utan domän: Använd MDM, Intune eller lokal import. Lokal import är mer lämplig för tester eller enskilda enheter.
• macOS: Använd MDM-profil eller nyckelring System. Manuell installation är mer lämplig för testning eller små miljöer.
• Firefox: Använd Windows Trust Store eller lansera Mozilla Enterprise Policies. Firefox-beteende måste kontrolleras separat.
• BYOD eller personliga enheter: distribueras normalt inte. TLS Inspection tillhör hanterade företagsenheter.
• Server: distribuerar endast till avsiktligt testade serverarbetsbelastningar. Utgående servertrafik kan ha andra risker och undantag.

För produktiv verksamhet är det avgörande att samma utbyggnad kan vändas senare. Den som distribuerar CA via GPO, MDM eller policy bör därför också testa tillbakadragandet av den gamla CA.

Sophos Firewall CA ladda ner

På Sophos Firewall laddas certifikatet ner i webbgränssnittet:

1. Logga in på Sophos Firewall som administratör.
2. Öppna Certificates > Certificate authorities.
3. Hitta CA SecurityAppliance_SSL_CA eller din egen CA som du medvetet använder.
4. Ladda ner certifikatet med hjälp av nedladdningssymbolen.
5. Kontrollera sedan om samma CA är vald i den aktiva TLS Inspection-konfigurationen.

Certifikatet är då vanligtvis tillgängligt som SecurityAppliance_SSL_CA.pem. Den här filen innehåller den offentliga delen av CA och kan distribueras till klienter. Den privata nyckeln får inte distribueras mellan klienter.

I SFOS 22 kan du även hämta den CA som faktiskt är vald direkt där den används. I DPI-sökvägen finns nedladdningsikonen bredvid Re-sign RSA with och Re-sign EC with. Om två olika CA:er är valda måste de berörda klienterna lita på båda. I Web Proxy-sökvägen finns ikonen bredvid HTTPS scanning certificate authority (CA). Hämtning vid användningsstället minskar risken att distribuera ett CA-objekt med liknande namn som inte är aktivt.

Filen ska behandlas som ett säkerhetsrelevant konfigurationsobjekt. Den offentliga delen är inte ett lösenord, men den anger vilken CA klienterna kommer att lita på. Filen ska därför komma från den egna produktionsbrandväggen, versionshanteras eller åtminstone lagras spårbart och inte återanvändas från gamla projekt. Före distributionen dokumenterar du Subject, Issuer, serienummer, giltighetstid och fingerprint från certifikatdetaljerna. Efter importen jämför du värdena på minst en pilotklient; visningsnamnet ensamt är inget tillförlitligt identitetsbevis.

Det finns ytterligare två vägar för att styra den aktiva CA:

• DPI-läge: Öppna Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings och jämför den valda CA:n med den nedladdade filen. Om den aktiva regeln använder en Decryption Profile ska även dess Re-Signing CA kontrolleras.
• Web Proxy: Öppna Web > General settings > HTTPS decryption and scanning och kontrollera vald HTTPS Scanning CA.

Denna kontroll förhindrar ett vanligt utrullningsfel: standard-CA:n distribueras till klienterna, medan brandväggen redan använder en annan CA i en Decryption Profile eller i Web Proxy.

Windows: Distribuera certifikat via GPO

I Active Directory-miljöer är en grupppolicy det renaste sättet. Edge, Chrome och många Windows-applikationer litar på Windows-certifikatarkivet.

Rekommenderad sökväg i Group Policy Management:

Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities > Certificates

Procedur:

1. Öppna grupprinciphantering på en domänkontrollant eller administratörsklient.
2. Använd en befintlig GPO för klientbaslinjen eller skapa en ny GPO för TLS Inspection-testgruppen.
3. Gå till sökväg Trusted Root Certification Authorities > Certificates.
4. Högerklicka i certifikatlistan.
5. Välj All Tasks > Import.
6. Importera SecurityAppliance_SSL_CA.pem.
7. Koppla endast GPO till önskad organisationsenhet eller säkerhetsgrupp.
8. Kör gpupdate /force på en testklient eller vänta på den vanliga uppdateringen.

I produktionsmiljöer ska GPO:n inte tillämpas direkt på alla datorer. En test-OU minskar risken om ett certifikat importeras felaktigt eller en applikation reagerar oväntat.

Windows: Installera certifikat lokalt

Certifikatet kan importeras lokalt för individuella testenheter. Det finns två vettiga varianter:

• Lokal datorbutik: gäller för alla användare på enheten och är oftast korrekt för hanterade klienter.
• Current User Store: gäller endast den inloggade användaren och räcker ibland för att testa.

För den lokala datorn:

1. Logga in som lokal administratör.
2. Starta certlm.msc.
3. Öppna Trusted Root Certification Authorities > Certificates.
4. Högerklicka i certifikatlistan.
5. Välj All Tasks > Import.
6. Importera SecurityAppliance_SSL_CA.pem.

Alternativt kan certmgr.msc användas för den aktuella användaren.

Efter import bör webbläsare och applikationer startas om. För vissa applikationer är det vettigt att logga ut eller starta om klienten.

macOS: Trustcertifikat i nyckelring

På macOS importeras certifikatet via Keychain Access.

Procedur:

1. Kopiera SecurityAppliance_SSL_CA.pem till Mac.
2. Öppna certifikatet genom att dubbelklicka.
3. Distribuera till nyckelring System eller en hanterad MDM-profil.
4. Öppna certifikatet och ställ in posten Always Trust under Trust.
5. Bekräfta ändringen med ett administratörskonto.
6. Starta om webbläsaren och berörda appar.

I större macOS-miljöer bör distribution ske via MDM. Manuell installation är mer lämplig för testning eller enskilda enheter.

Mobila enheter med Sophos Mobile

För ett större antal hanterade Android-, iOS- och iPadOS-enheter bör CA:n distribueras med en MDM-policy. Sophos Mobile kan lägga till rotcertifikatet direkt i den enhetspolicy som redan är tilldelad. Apple rekommenderar MDM eller Apple Configurator; med Apple Configurator skapas först en konfigurationsprofil på macOS.

Exempel för iOS och iPadOS i Sophos Mobile:

1. Öppna Policies > iOS & iPadOS.
2. Välj den policy som redan är tilldelad de avsedda enheterna.
3. Välj Add > Root certificate på sidan Edit policy.
4. Använd Upload a file under Root certificate för att endast ladda upp det publika CA-certifikat som enheterna ska lita på enligt den planerade kedjan. För SecurityAppliance_SSL_CA är detta den publika CA-delen som hämtats från SFOS.
5. Spara med Apply och därefter Save.
6. Använd pilen i policylistan och välj Update devices. Om alternativet saknas distribueras ändringen vid nästa automatiska synkronisering.

För Android läggs rotcertifikatet till på motsvarande sätt i en Android-policy. Kontrollera inte bara policystatusen efteråt. På iOS finns kontrollen under Settings > General > About > Certificate Trust Settings; på Android under Settings > Security > Advanced > Encryption & credentials > User credentials. En verklig dekrypterad HTTPS-begäran är fortfarande det slutliga beviset.

Den privata nyckeln för CA:n för omsignering hör aldrig hemma i Sophos Mobile eller på en endpoint. Endast det publika CA-certifikatet distribueras. Börja med en liten pilotgrupp och testa även borttagning av CA:n.

Kontrollera certifikatet på hanterade enheter

Efter distributionen ska minst en testenhet per plattform kontrolleras för att verifiera att CA:n verkligen hamnade i rätt Trust Store.

• Windows Computer Store: Öppna certlm.msc och sök under Trusted Root Certification Authorities > Certificates.
• Windows Current User Store: Öppna certmgr.msc och kontrollera användarens förtroendearkiv.
• macOS: Öppna Keychain Access och kontrollera förtroendestatusen i System-nyckelringen.
• Firefox: Öppna Settings > Privacy & Security > Certificates > View Certificates.

Om ett certifikat bara finns i användararkivet men ett program förväntar sig datorarkivet kan webbläsaren fungera medan en annan applikation fortfarande visar certifikatfel. Omvänt kan webbläsare med ett eget Trust Store ignorera Windows- eller macOS-distributionen om de inte är konfigurerade för den.

Firefox på Windows

Aktuella Firefox-versioner på Windows söker som standard i operativsystemets certifikatlager efter ytterligare installerade Root CA:er. Om Sophos Firewall CA distribueras via GPO till Windows Computer Store behövs därför normalt ingen andra import till en separat Firefox-databas. Beteendet styrs i Firefox genom Allow Firefox to automatically trust third-party root certificates you install, inställningen security.enterprise_roots.enabled eller företagspolicyn ImportEnterpriseRoots.

Det finns därför två lämpliga vägar i hanterade Windows-miljöer:

• Använd Windows förtroendelager: den rekommenderade standardvägen när CA:n redan distribueras genom en dator-GPO. Automatisk användning av operativsystemets CA:er måste vara fortsatt aktiverad i den hanterade Firefox-konfigurationen.
• Importera certifikatet direkt genom en Mozilla Enterprise Policy: ett alternativ när Firefox förtroende avsiktligt hanteras separat eller operativsystemets förtroendelager inte ska användas.

Med den första vägen kan den CA som hämtas från Windows fungera utan att visas som en separat importerad post i Firefox Certificate Manager. Windows Computer Store och ett verkligt HTTPS-test är då avgörande. Följande GPO-instruktioner beskriver den andra vägen med Install Certificates.

Ladda ner Firefox GPO mallar

Mozilla gör policymallarna tillgängliga på GitHub. Det som behövs bland annat:

• firefox.admx
• mozilla.admx
• firefox.adml
• mozilla.adml

Filerna kan laddas ner från Mozilla Policy Templates Repository eller som policy_templates.zip.

Importera mallar

Filerna ADMX och ADML kopieras till den centrala PolicyDefinitions-sökvägen.

Typisk lokal sökväg:

C:\Windows\PolicyDefinitions

Om det finns en Central Store i domänen används istället mappen PolicyDefinitions under SYSVOL.

Konfigurera Firefox-policy

Certifikatet läggs sedan in i grupppolicyn under Firefox-policyerna:

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedur:

1. Aktivera policyn Installera certifikat.
2. Ange filnamnet på certifikatet, till exempel SecurityAppliance_SSL_CA.pem.
3. Kopiera certifikatfilen via GPO eller programvarudistribution till den förväntade användarprofilkatalogen.

Beroende på Firefox-version och policykonfiguration läses certifikat från dessa kataloger:

%USERPROFILE%\AppData\Local\Mozilla\Certificates
%USERPROFILE%\AppData\Roaming\Mozilla\Certificates

Efter nästa Firefox-session bör certifikatet vara synligt i Firefox Certificate Manager.

Mozilla beskriver rekommenderat förtroende för operativsystemets lager och policyimport i Set up Certificate Authorities (CAs) in Firefox. Ytterligare sökvägar och varianter finns i wikin: Lägg till rotcertifikat till Firefox.

Kontrollera funktionen

Efter distribution ska du inte bara kontrollera om certifikatet finns. Det som spelar roll är om TLS Inspection fungerar korrekt.

Användbara tester:

1. Starta om testklienten eller logga in på nytt.
2. Öppna webbläsaren och gå till en HTTPS-sida, som dekrypteras av Sophos Firewall.
3. Se webbplatsens certifikat i webbläsaren.
4. Kontrollera om certifikatkedjan körs via SecurityAppliance_SSL_CA eller exakt den valda Sophos CA.
5. Kontrollera på brandväggen i Log Viewer > SSL/TLS inspection om trafiken visas som dekrypterad och vilken regel eller åtgärd som vidtogs.
6. Testa viktiga affärsapplikationer, uppdateringstjänster, samarbetsverktyg och identitetsleverantörer.

Om webbläsaren fortsätter att visa det ursprungliga offentliga webbplatscertifikatet har denna anslutning inte dekrypterats. Då gäller antingen ingen lämplig SSL/TLS Inspection-regel, ett undantag vinner, trafiken körs över en annan väg eller QUIC/HTTP/3 kringgår den förväntade TCP-vägen.

Om webbläsarvarningen försvinner men applikationer fortsätter att visa fel ligger problemet ofta inte i själva certifikatet. Certifikatpinning, saknade TLS-undantag, en felaktig dekrypteringsprofil eller en olämplig SSL/TLS Inspection-regel är ofta orsaken.

För webbtrafik bör det också kontrolleras om QUIC eller HTTP/3 går förbi den förväntade inspektionen. Artikeln Sophos Firewall Blockera QUIC och HTTP/3 korrekt förklarar varför Block QUIC-protokollet fortfarande är relevant för webbfiltrering, skanning av skadlig programvara och TLS Inspection.

Typiska misstag

• Webbläsaren visar fortfarande certifikatvarning: CA är förmodligen inte i rätt förtroendelager. Kontrollera Windows, macOS eller Firefox certifikatbutik.
• Chrome fungerar, Firefox gör det inte: kontrollera om Firefox får använda de ytterligare Root CA:er som installerats i operativsystemet eller om en separat Mozilla Enterprise Policy gäller. Starta sedan om Firefox och testa den faktiska HTTPS-sökvägen.
• Enskilda ansökningar går sönder: Certifikatfästning eller din egen certifikatkontroll är troligt. TLS Inspection Log Viewer och kontrollera undantag.
• Endast vissa klienter fungerar: GPO fungerar inte eller är länkad till fel organisationsenhet. Kontrollera länkarna gpresult och GPO.
• CA är installerad, men varningen kvarstår: Den distribuerade CA kanske inte matchar CA i dekrypteringsprofilen, i SSL/TLS inspektionsinställningarna eller under allmänna webbinställningar.
• DPI fungerar, Web Proxy gör det inte eller vice versa: Båda sökvägarna kan konfigureras på olika sätt. Kontrollera valda CA, styrväg och Log Viewer per driftläge.
• Efter CA-regenerering finns det varningar: Den gamla CA finns fortfarande kvar på klienter eller så saknas den nya CA. Ta bort gamla CA och distribuera nya CA.
• URL-flöden eller webbfilter fungerar inte som förväntat: HTTPS-sökvägen är inte dekrypterad. TLS Inspection och kontrollera webbpolicyn.
• Certifikatet finns, men trafiken är inte dekrypterad: En lämplig SSL/TLS Inspection-regel saknas eller så använder trafiken fel DPI/webproxysökväg. Kontrollera TLS utrullning, brandväggsregel och Log Viewer.
• Endast mobilappar eller enskilda klienter misslyckas: Egen trust store, certificate pinning eller appspecifik kontroll är sannolikt. Särskilt Android- och mobilappstrafik bör testas riktat och vid behov undantas, istället för att distribuera CA brett och blint.

CA rotation och nödsituation

En CA bör inte användas obemärkt i flera år utan att utgångsdatum, ursprung och distribution är känt. För produktiva miljöer bör det finnas en liten livscykelprocess.

Den inbyggda CA:n SecurityAppliance_SSL_CA kan återskapas. Det är dock inte ett riskfritt förberedelsesteg: den gamla och den nya CA:n blir inte automatiskt betrodda parallellt på alla klienter. För ett planerat DPI-byte med överlappning använder du en separat förberedd signerings-CA och testar den genom en snävt avgränsad Decryption Profile. Web Proxy har däremot bara den globala HTTPS scanning certificate authority (CA). Ett byte påverkar hela Web Proxy-sökvägen och ska därför göras i ett underhållsfönster; den nya publika CA:n måste först vara betrodd på alla berörda klienter. I båda fallen stannar den privata nyckeln på brandväggen.

Planerad förändring:

1. Dokumentera det aktiva CA-valet, fingerprint och alla referenser. Förbered en separat signerings-CA utan att återskapa den inbyggda CA:n som första steg.
2. Distribuera endast det publika certifikatet eller den nödvändiga publika CA-kedjan: först till DPI-pilotgruppen, eller till alla berörda klienter före ett globalt Web Proxy-byte.
3. Aktivera den nya CA:n i DPI-läge genom en snävt avgränsad Decryption Profile och kontrollera Issuer, loggpost och pilotgruppens applikationer.
4. Efter en godkänd DPI-pilot distribuerar du det publika certifikatet till alla berörda hanterade enheter och bekräftar importen med hjälp av fingerprint.
5. Ändra återstående DPI-fält eller den globala Web Proxy-CA:n. Kontrollera med nya anslutningar att den nya CA:n signerar och att den förväntade regeln tillämpas.
6. Ta bort den gamla CA:n från klienternas trust stores först när ingen inspektionssökväg längre refererar till den och alla berörda enheter har fått den nya CA:n.

Nödsituation vid kompromiss:

1. Om det behövs, begränsa eller tillfälligt avaktivera TLS Inspection på ett kontrollerat sätt.
2. Ersätt berörda CA på brandväggen.
3. Rulla ut nya CA via den definierade distributionsvägen.
4. Ta bort gamla CA från alla förtroendebutiker.
5. Kontrollera undantag, Log Viewer och berörda applikationer.
6. Dokumentera förändringar i incidenten eller byt system.

Viktigt: En komprometterad CA är inte ett normalt certifikatproblem. Om en angripare kontrollerar den privata nyckeln kan klienter lita på falska certifikat. Sedan måste den gamla CA konsekvent tas bort.

Vid en normal rollback återställer du först inspektionssökvägen till den tidigare dokumenterade CA:n eller inaktiverar pilotregeln. Ta bort den CA som endast distribuerades för piloten först när en ny anslutning åter visar den gamla Issuer eller den ursprungliga, icke dekrypterade sökvägen. Om klientförtroendet tas bort först medan brandväggen fortsätter att signera med CA:n uppstår certifikatfel. Ta inte bort delade CA:er eller CA:er som fortfarande refereras.

Drift och underhåll

CA-certifikatet bör vara en del av den operativa processen:

• Dokumentets utgångsdatum och ansvarig person.
• Utför endast CA regenerering som planerat.
• Ta bort gamla CA från klienter efter migreringen.
• Kontrollera distributionen via GPO eller MDM regelbundet.
• Dokumentera TLS undantag och granska dem med jämna mellanrum.
• Starta incident- och CA-bytesprocessen om signeringsnyckeln eller brandväggen kan vara komprometterad. Förlusten av en klient som endast innehåller det publika CA-certifikatet komprometterar inte signeringsnyckeln.

Om du gör en ändring i TLS Inspection bör du också kontrollera de berörda brandväggsreglerna, dekrypteringsprofilerna och undantagslistorna. Annars litar klienten på CA, men brandväggen dekrypterar fortfarande inte den önskade trafiken.

FAQ