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.

Utöver den inbyggda CA:n kan du importera en externt skapad signerings-CA eller skapa en Certificate Signing Request (CSR) på brandväggen och låta en extern CA, exempelvis Active Directory Certificate Services, utfärda en underordnad signerings-CA. Vid extern signering ska både den underordnade signerings-CA:n och dess rot-CA importeras på brandväggen. Klienterna behöver motsvarande publika förtroendeankare och den nödvändiga publika kedjan, inte den privata signeringsnyckeln. Den länkade PKI-proceduren beskriver utfärdandet; följande steg beskriver val, distribution och kontroll.

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

Sophos Firewall CA-certifikatet är inte ett servercertifikat för WebAdmin, WAF eller VPN Portal. 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.
• Klientens certifikatlager: 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 certifikatlager eller Certificate Pinning separat.
• Ta bort gamla eller inte längre använda CA-certifikat från klientens certifikatlager.

⚠️ 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 certifikatlager eller distribuera Mozilla Enterprise Policies. Kontrollera Firefox beteende separat.
• BYOD eller privata enheter: distribuera normalt inte CA:n till dessa. TLS Inspection hör hemma på hanterade företagsenheter.
• Servrar: distribuera endast för serverarbetsbelastningar där inspektionen har bedömts. Utgående servertrafik kan innebära andra risker och undantag.

I produktionsmiljöer måste utrullningen också kunna återställas. Den som distribuerar CA:n via GPO, MDM eller policy bör därför även testa hur den gamla CA:n tas bort.

Hämta CA-certifikatet från Sophos Firewall

Förbered Web Proxy-regeln och CA:n

Öppna Rules and policies > Firewall rules för en Web Proxy-pilot, välj IPv4 eller IPv6 och skapa en regel via Add firewall rule > New firewall rule. Använd exempelvis det valfria namnet TLS-CA-Pilot, ställ Source zones på LAN, Source networks and devices på pilotnätet, Destination zones på WAN och Destination networks på de avsedda målen. Anpassa zoner, nät och mål efter den faktiska trafikvägen; ge inte alla klienter åtkomst bara för att testa ett certifikat.

Dokumentera tidigare regelvärden och vald CA före ändringen så att den kan återställas. Kontrollera separat HTTPS scanning certificate authority (CA) under Web > General settings > HTTPS decryption and scanning, distribuera först dess publika certifikat till alla berörda pilotenheter och verifiera förtroendet med fingerprint. Den gemensamma Web Proxy-CA:n är global: ett byte är inte en CA-pilot för en enskild regel utan påverkar alla Web Proxy-klienter och kräver att dessa redan litar på den nya CA:n samt ett underhållsfönster.

Välj först därefter lämplig webbpolicy i den valda brandväggsregeln under Security features > Web filtering, aktivera Scan HTTP and decrypted HTTPS, Use web proxy instead of DPI engine och uttryckligen Decrypt HTTPS during web proxy filtering, och spara med Save. Skanningsalternativet ensamt dekrypterar inte; valet av CA under Web > General settings ersätter inte brandväggsregelns dekrypteringsalternativ.

Kontrollera vid första konfigurationen under Certificates > Certificate authorities > Default att alla inställningar för Default CA är konfigurerade. Detta är en konfigurationskontroll, inte en uppmaning att återskapa CA:n eller distribuera Default i stället för den aktiva SecurityAppliance_SSL_CA.

Hämta det publika CA-certifikatet

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 till klienter.

För en manuell pilot kan den verifierade publika filen göras tillgänglig via företagets intranät eller kontrollerad e-postdistribution. Användarna sparar den lokalt och jämför dess identitet med separat dokumenterade certifikatuppgifter innan de ger sitt förtroende. För större grupper är GPO eller MDM fortfarande att föredra.

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å ställen där den aktiva CA:n kan kontrolleras:

• 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 grupprinciper den rekommenderade metoden. Edge, Chrome och många Windows-applikationer litar på Windows certifikatlager.

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. Länka GPO:n till avsedd test-OU. Använd vid behov en säkerhetsgrupp genom säkerhetsfiltrering, inte som länkmål för GPO:n.
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:

• Den lokala datorns certifikatlager: gäller för alla användare på enheten och är oftast rätt för hanterade klienter.
• Den aktuella användarens certifikatlager: gäller endast den inloggade användaren och räcker ibland för tester.

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: ange förtroende för certifikatet i nyckelringen

På macOS importeras certifikatet via Keychain Access.

För en enda användare går det även att använda nyckelringen login: dubbelklicka på den hämtade filen för att öppna Keychain Access, kontrollera identiteten och välj Always Trust. Safari använder också detta macOS-förtroende. För en hanterad utrullning på hela enheten är System eller MDM fortfarande lämpligt; blanda inte ihop användaromfattning och systemomfattning.

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

⚠️ Android: en certifikatinstallation är inte ett godkännande för dekryptering. Sophos beskriver CA-import men rekommenderar också att alla Android-enheter undantas från SSL/TLS-inspektion i DPI-läge på grund av certifikatfel. Den här guiden utgår därför från att alla Android-enheter undantas från DPI. Android-stegen för import och HTTPS-test nedan gäller endast en separat godkänd, snävt avgränsad pilot på hanterade enheter: ett dokumenterat verksamhetsbehov måste motivera avsteget för namngivna enheter och appar. Kontrollera vilket certifikatlager som faktiskt används och varje berörd app före godkännandet; avbryt piloten och återställ undantaget vid fel. MDM-installation löser inte certificate pinning och garanterar inte förtroende i alla appar. DPI-rekommendationen är inte ett generellt besked om Web Proxy-kompatibilitet; även den trafikvägen kräver separat appvalidering.

Manuell mobilpilot

Om enheten inte accepterar PEM-filen kan konvertering till ett kompatibelt certifikatformat som .der, .cer eller .crt behövas. Filändelsen ensam avgör inte kodningen; använd aldrig en fil med privat nyckel. Menynamn varierar med Android-version och tillverkare. Ett Pixel-exempel använder Settings > Security & location > Advanced > Encryption & credentials:

1. Välj Install from storage eller Install from SD card under Credential storage.
2. Välj lagringsplats via Menu > Open from i filväljaren och öppna den publika certifikatfilen.
3. Ange enhetens PIN, ge certifikatet ett tydligt namn och välj VPN and apps för denna app-pilot; Wi-Fi är den andra tillgängliga kategorin. Bekräfta med OK.
4. Kontrollera identitet och import under User credentials och testa sedan en dekrypterad HTTPS-begäran. En lyckad import garanterar inte att alla Android-appar litar på användarens certifikatlager.

För en manuell iOS-pilot gör du den publika CA-filen tillgänglig på enheten och importerar den. Aktivera förtroende endast för det identifierade rotcertifikatet under Settings > General > About > Certificate Trust Settings > Enable full trust for root certificates och testa HTTPS. Aktivera inte flera okända rot-CA:er.

Distribuera centralt genom enhetspolicyn

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. Anslut sedan en eller flera iOS-enheter till Mac-datorn för att installera profilen med CA-certifikatet.

Exempel för iOS och iPadOS i Sophos Mobile:

Rotcertifikat som installeras på iOS- och iPadOS-enheter via MDM eller Apple Configurator blir automatiskt betrodda, till skillnad från manuell import. Kontrollen nedan är inte en uppmaning att ändra ett förtroende som redan är aktiverat.

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.

På iOS kontrollerar du där förtroendestatusen för det avsedda rotcertifikatet efter att ha verifierat dess identitet mot det dokumenterade fingerprint-värdet. Om förtroendet fortfarande är inaktiverat aktiverar du det under Enable full trust for root certificates endast för detta rotcertifikat. Om det redan är betrott lämnar du inställningen oförändrad; upprepa sedan den dekrypterade HTTPS-begäran för att kontrollera resultatet.

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

Kontrollera efter distributionen minst en testenhet per plattform för att verifiera att CA:n verkligen hamnade i rätt certifikatlager.

• Windows datorcertifikatlager: öppna certlm.msc och sök under Trusted Root Certification Authorities > Certificates.
• Windows användarcertifikatlager: öppna certmgr.msc och kontrollera användarens certifikatlager.
• 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ändarens certifikatlager men ett program använder datorns certifikatlager kan webbläsaren fungera medan ett annat program visar certifikatfel. Omvänt kan webbläsare med eget certifikatlager ignorera Windows- eller macOS-distributionen om de inte är konfigurerade för den.

Firefox på Windows

För en enda testprofil går det också att importera manuellt: öppna Settings > Privacy & Security > Certificates > View Certificates > Authorities > Import, välj den publika CA-filen och klicka på Open. Aktivera endast Trust this CA to identify websites i Downloading Certificate för den CA vars identitet redan har kontrollerats och välj OK. Starta om Firefox och testa den dekrypterade HTTPS-vägen. Denna profilimport ersätter inte central distribution.

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 certifikatlager: 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 certifikatlager 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.

Hämta Firefox GPO-mallar

Mozilla tillhandahåller policymallarna på GitHub. Följande filer 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

Kopiera firefox.admx och mozilla.admx direkt till den valda PolicyDefinitions-mappen. Motsvarande firefox.adml och mozilla.adml ska ligga i dess språkspecifika undermapp, inte bredvid ADMX-filerna.

Typisk lokal sökväg:

C:\Windows\PolicyDefinitions

För domänens Central Store använder du i stället \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions. Ersätt båda förekomsterna av <domain> med AD-domänens DNS-namn. Om en Central Store finns ska Mozilla-mallarna placeras där; en kopia enbart i den lokala mappen räcker inte för att redigera domänens GPO:er.

Behåll språkmapparna från det hämtade paketet och använd ADMX- och ADML-filer från samma mallversion. Placera exempelvis de engelska ADML-filerna i C:\Windows\PolicyDefinitions\en-US eller, när Central Store används, i \\<domain>\SYSVOL\<domain>\Policies\PolicyDefinitions\en-US. Kopiera andra nödvändiga språk till respektive undermapp från paketet. en-US är ett exempel på mallspråk, inte ett krav som följer av artikelns språk.

Öppna grupprincipredigeraren igen och kontrollera att Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates visas utan resursfel. Om policyn saknas ska du först korrigera målmappen, språkundermappen och versionskombinationen innan du fortsätter med certifikatpolicyn.

Konfigurera Firefox-policy

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

Administrative Templates > Mozilla > Firefox > Certificates > Install Certificates

Procedur:

1. Aktivera policyn Install Certificates.
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.

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. Korrelera den nya begäran på brandväggen med källa, mål och tid, fastställ det faktiska driftläget och använd motsvarande kontroller nedan.
6. Testa viktiga affärsapplikationer, uppdateringstjänster, samarbetsverktyg och identitetsleverantörer.

DPI: Kontrollera den matchande inspektionsregeln, dess åtgärd, Decryption Profile och CA för omsignering under Rules and policies > SSL/TLS inspection rules. Korrelera samma nya begäran med källa, mål och tid under Log Viewer > SSL/TLS inspection och verifiera dekryptering samt tillämpad regel eller åtgärd. Kontrollera även DPI-undantagen.

Web Proxy: Bekräfta den brandväggsregel som faktiskt matchar, dess webbpolicy och Decrypt HTTPS during web proxy filtering. Kontrollera den gemensamma HTTPS scanning certificate authority (CA) under Web > General settings och tillämpliga undantag under Web > Exceptions. Korrelera relevanta webbfiltrerings-/proxyloggar i Log Viewer för samma nya begäran med källa, mål och tid; utfärdaren och certifikatkedjan i webbläsaren måste motsvara vald CA. SSL/TLS-inspektionsregler styr inte Web Proxy-dekryptering. En DPI-dekrypteringspost är varken garanterad eller nödvändig här; en webbfiltreringspost ensam bevisar inte dekryptering.

Om webbläsaren fortfarande visar webbplatsens ursprungliga offentliga certifikat har anslutningen inte dekrypterats. Kontrollera inspektionsregeln och undantagen i DPI; kontrollera matchande brandväggsregel, dekrypteringsalternativ och webbundantag i Web Proxy. En annan trafikväg eller QUIC/HTTP/3 kan också kringgå den förväntade TCP-vägen.

Om webbläsarvarningen försvinner men appar fortfarande ger fel är orsaken ofta inte själva certifikatet. Det kan handla om certificate pinning eller eget certifikatlager. Kontrollera även Decryption Profile, inspektionsregel och TLS-undantag i DPI; kontrollera brandväggsregel och webbundantag i Web Proxy enligt kontrollerna ovan.

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

Typiska misstag

• Webbläsaren visar fortfarande certifikatvarning: CA:n finns kanske inte i rätt certifikatlager. Kontrollera certifikatlagret i Windows, macOS eller Firefox.
• 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 applikationer avbryter anslutningen: Certificate pinning eller egen certifikatkontroll är en trolig orsak. Kontrollera SSL/TLS-loggar och TLS-undantag i DPI; kontrollera webbfiltrerings-/proxyloggar och Web > Exceptions i Web Proxy, alltid för samma begäran.
• Endast vissa klienter fungerar: GPO fungerar inte eller är länkad till fel organisationsenhet. Kontrollera resultatet från gpresult och GPO-länkningen.
• 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: Använd kontrollerna för det faktiska driftläget ovan: inspektionsregel, profil och SSL/TLS-loggar i DPI; brandväggsregel, dekrypteringsalternativ, gemensam CA, webbundantag och webbfiltrerings-/proxyloggar i Web Proxy.
• Varningar efter att CA:n har återskapats: Klienterna kan sakna den nya aktiva CA:n. Distribuera först den nya publika CA:n och kontrollera dess fingerprint. Ta bort en gammal, icke komprometterad CA först när ingen aktiv trafikväg längre använder den; följ nödproceduren vid kompromettering.
• URL-flöden eller webbfilter fungerar inte som förväntat: Kontrollera om HTTPS-trafiken dekrypteras och om rätt TLS Inspection- och webbpolicy används.
• Certifikatet finns, men trafiken är inte dekrypterad: I DPI kan en matchande inspektionsregel saknas; i Web Proxy kan brandväggsregelns dekrypteringsalternativ saknas eller ett webbundantag gälla. Använd kontrollerna för driftläget och bekräfta den faktiska trafikvägen.
• Endast mobilappar eller enskilda klienter misslyckas: Ta hänsyn till egna certifikatlager, certificate pinning och appspecifik validering. Undanta Android från DPI som standard; en separat godkänd Android-pilot måste återgå till undantaget vid fel. Bedöm andra undantag snävt i stället för att stänga av inspektionen globalt.

CA-rotation och nödsituation

En CA bör inte användas i flera år utan uppföljning av giltighetstid, ursprung och distribution. I produktionsmiljöer bör det finnas en enkel process för att hantera CA:ns livscykel.

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 certifikatlager 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 kompromettering:

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 den gamla CA:n från alla certifikatlager där den är betrodd.
5. Kontrollera undantag, Log Viewer och berörda applikationer.
6. Dokumentera ändringen i systemet för incident- eller ändringshantering.

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:

• Dokumentera CA:ns utgångsdatum och vem som är ansvarig.
• Återskapa CA:n endast som en planerad åtgärd.
• 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