Konfigurera en underordnad CA för TLS-inspektion på Sophos Firewall

För TLS-inspektion måste Sophos Firewall signera om certifikaten för de HTTPS-destinationer som besöks. I stället för den inbyggda CA:n SecurityAppliance_SSL_CA kan en dedikerad underordnad företags-CA användas. Hanterade klienter fortsätter då att lita på organisationens egen rot-CA, medan den privata nyckeln för den underordnade CA:n stannar på brandväggen.

Det säkra förloppet består av sex steg:

1. Generera en CSR för den nya underordnade CA:n på Sophos Firewall.
2. Låt en Microsoft AD CS Enterprise CA signera CSR:n med mallen Subordinate Certification Authority.
3. Importera det utfärdade CA-certifikatet direkt vid den befintliga CSR:n.
4. Lägg till motsvarande rot-CA på brandväggen som Validation only.
5. Välj den underordnade CA:n som CA för omsignering och använd den först endast i en pilotregel.
6. Kontrollera certifikatkedjan, verklig HTTPS-trafik, loggar och återställning.

⚠️ En CA för omsignering kan utfärda certifikat för främmande domäner. Den privata nyckeln är därför särskilt känslig. CA:n får endast användas för den avsedda inspektionsvägen och får inte exporteras eller delas i ärenden. Den ska inte aktiveras i produktion utan en testad återställningsväg.

Den här proceduren gäller AD CS i Enterprise CA-läge. Sophos anger uttryckligen att det dokumenterade förfarandet inte gäller för en Standalone CA. En annan intern PKI kan också utfärda en underordnad CA, men behöver då en egen process som granskats av PKI-ansvarig.

När en underordnad CA är lämplig

En egen underordnad CA passar framför allt i hanterade företagsnät där klienterna redan litar på en intern rot-CA. Då behöver ingen ytterligare, fristående Sophos trust anchor distribueras till varje enhet. Rotation, spärrning och ansvar kan byggas in i den befintliga PKI-styrningen.

Lösningen blir dock inte automatiskt enklare. Brandväggen får en nyckel som kan användas för att signera certifikat för TLS-inspektion. CA:n behöver därför ett snävt definierat syfte, dokumenterade ansvariga, en begränsad giltighetstid samt testade rutiner för spärrning och förnyelse.

I mindre miljöer utan egen PKI är Sophos inbyggda CA ofta enklare. Distribuera Sophos Firewall CA-certifikat för TLS-inspektion beskriver valet och distributionen till klienter. Inför TLS-inspektion på Sophos Firewall på rätt sätt behandlar hela pilot- och undantagsprocessen.

Förbered CA-design och återställningsväg

Syfte, namn och beroenden fastställs innan CSR:n skapas. Ett möjligt exempel är:

• SFOS-objektnamn: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• utfärdande rot-CA: Example Enterprise Root CA
• planerad användning: endast TLS-inspektion och HTTPS-dekryptering på FW01
• pilotnät: 10.20.30.0/24

Värdena är dokumentationsexempel och ska ersättas med organisationens namnstandard, PKI och pilotgrupp. En separat CA per brandvägg eller tydligt avgränsat inspektionskluster förenklar senare tilldelning, spärrning och rotation.

Före ändringen ska följande finnas:

• en aktuell konfigurationsbackup och fungerande oberoende hanteringsåtkomst,
• dokumentation av nuvarande CA för omsignering och dess klientdistribution,
• åtkomst till en AD CS Enterprise CA och godkännande från PKI-ansvarig,
• en liten hanterad testgrupp med fungerande återställningsväg,
• en plan för spärrning, förnyelse och kontrollerad återgång till föregående CA.

Skapa och återställ en Sophos Firewall-backup beskriver backup- och återställningsförloppet. En backup ersätter inte dokumentationen av den CA för omsignering som är vald nu eller av de klienter som litar på den.

Generera CSR:n på Sophos Firewall

CSR:n genereras på brandväggen så att den privata nyckeln skapas där och inte behöver transporteras mellan AD CS, administratörens dator och brandväggen.

1. Öppna Certificates > Certificates.
2. Välj Add.
3. Välj Generate certificate signing request (CSR) under Action.
4. Ange ett entydigt namn, till exempel SFOS-TLS-Inspection-SubCA-2026.
5. Välj nyckeltyp, nyckellängd eller kurva och secure hash enligt organisationens PKI-policy. Sophos visar RSA, 2048 bitar och SHA-256 i sitt exempel. Det är produktexempel, inte universella krav.
6. Ange de subject-attribut och Subject Alternative Names som godkänts av den interna PKI:n.
7. Spara CSR:n och öppna den via nedladdningsikonen.
8. Använd Copy to clipboard och lämna CSR:n endast genom den auktoriserade AD CS-processen.

CSR:n innehåller inte den privata nyckeln. Den tillhör ändå den kontrollerade PKI-processen eftersom den fastställer identitet, publik nyckel och begärt CA-syfte.

Utfärda den underordnade CA:n med AD CS

Sophos-CSR:n lämnas in på registreringswebbplatsen för ansvarig AD CS Enterprise CA:

1. Öppna Request a certificate.
2. Välj Advanced certificate request.
3. Klistra in hela CSR:n.
4. Välj Subordinate Certification Authority som Certificate template.
5. Granska begäran enligt den interna godkännandeprocessen och utfärda den med Submit.
6. Välj ett lämpligt format under Certificate Issued, till exempel Base 64 encoded.
7. Ladda ned det utfärdade certifikatet för den underordnade CA:n.
8. Ladda även ned certifikatet för den rot-CA som signerade den underordnade CA:n.

Viktig EKU-gräns: Om det utfärdade CA-certifikatet har en sektion för Extended Key Usage måste TLS Web Server Authentication ingå för detta signeringssyfte. Om värdet saknas ska certifikatet inte användas som CA för omsignering i produktion. PKI-ansvarig måste korrigera CA-mallen och utfärda ett nytt certifikat.

Kontrollera issuer, subject, giltighet, Basic Constraints och, om det finns, Extended Key Usage i certifikatvisningen före importen. Ge rot- och subordinate-filerna entydiga namn så att de inte förväxlas med servercertifikat.

Importera underordnad CA och rot-CA

Importera den underordnade CA:n vid befintlig CSR

1. Öppna Certificates > Certificates.
2. Välj importåtgärden vid den CSR som skapades tidigare.
3. Välj certifikatet för den underordnade CA som utfärdades av AD CS.
4. Välj Certificate authority only. SFOS identifierar CA-typen och visar CA-alternativen.
5. Kontrollera namnet och välj Import certificate.
6. Öppna Certificates > Certificate authorities och sök efter den importerade CA:n.

SFOS kopplar automatiskt den privata nyckeln som hör till CSR:n till den underordnade CA:n. Därför måste ikonen för privat nyckel visas för denna CA i CA-listan. Om den saknas är CA:n inte klar för signering. Att ladda upp filen igen på en annan plats återställer inte den saknade nyckelkopplingen.

Lägg endast till rot-CA:n för validering

1. Öppna Certificates > Certificate authorities och välj Add.
2. Ladda upp certifikatet för den rot-CA som utfärdade den underordnade CA:n.
3. Behåll Validation only under Use certificate for.
4. Jämför namn och fingerprint med den godkända dokumentationen för rot-CA:n.
5. Spara och kontrollera kedjan för den underordnade CA:n igen.

Brandväggen behöver inte rot-CA:ns privata nyckel. Signing and validation är endast avsett för den underordnade CA vars privata nyckel redan finns på brandväggen genom CSR:n. Importera och tilldela certifikat på Sophos Firewall förklarar de allmänna skillnaderna mellan certifikat, CSR, privat nyckel och CA-kedja.

Välj CA för TLS-inspektion

Enbart import ändrar ingen trafik. Den nya CA:n aktiveras först i en snävt avgränsad pilot. Valet finns på olika platser beroende på inspektionsväg:

• DPI: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• Decryption Profile: Profiles > Decryption profiles
• Web Proxy: Web > General settings > HTTPS decryption and scanning

Endast en CA med syftet Signing and validation och en tillgänglig privat nyckel får användas för omsignering. Ändra inte en CA som används för signering till Validation only; den aktiva omsigneringsvägen skulle då förlora sin nyckel.

För piloten:

1. Dokumentera nuvarande val och berörda regler.
2. Välj den nya CA:n i den avsedda inspektionsvägen.
3. Begränsa regeln till den definierade testgruppen eller pilotnätet.
4. Kontrollera CA-kedjan på pilotklienterna. I en AD-domän bör enterprise root-CA:n redan vara betrodd, men hela kedjan till den nya underordnade CA:n måste ändå kunna byggas korrekt.
5. Skapa en verklig HTTPS-begäran och granska certifikatdetaljer, Inspection Rule, Decryption Profile och loggpost tillsammans.

Genomför en bred produktionsändring först när piloten har godkänts. Valet av CA aktiverar inte automatiskt en Inspection Rule, och klientförtroende bevisar inte att trafiken faktiskt dekrypteras.

Validera funktion och säkerhet

Ett godkänt test innehåller flera bevis:

1. Under Certificates > Certificate authorities finns rot-CA:n som Validation only.
2. Den underordnade CA:n har Signing and validation och visar ikonen för privat nyckel.
3. En pilotklient litar på rot-CA:n och kan bygga hela kedjan.
4. En avsiktligt dekrypterad HTTPS-webbplats visar ett servercertifikat som signerats av den nya underordnade CA:n.
5. Hostname, ursprunglig destination och webbläsarstatus är korrekta utan oväntad certifikatvarning.
6. Log Viewer visar förväntad SSL/TLS Inspection Rule och åtgärd för just detta test.
7. En källa utanför piloten ligger kvar på föregående väg.

Testa även applikationer med certificate pinning, egna trust stores eller känsliga uppdateringsvägar separat. En lyckad webbläsarbegäran räcker inte för att godkänna hela utrullningen.

Rotation och återställning

Den underordnade CA:n måste förnyas innan den upphör att gälla. Ny och gammal CA ska vara tydligt åtskilda under en kontrollerad övergång. Den nya CA:n utfärdas, importeras och verifieras först på pilotklienter och väljs därefter stegvis i inspektionsvägen.

Använd den förberedda återställningsvägen om ett test misslyckas:

1. Inaktivera pilotregeln eller byt tillbaka till föregående CA för omsignering.
2. Kontrollera med en ny webbläsarprocess att föregående certifikatväg används igen.
3. Ta inte bort den nya CA:n så länge regler, Decryption Profiles eller Web Proxy-inställningar hänvisar till den.
4. Involvera PKI-ansvarig om EKU, kedja, mall eller spärrstatus är oklar.
5. Fortsätt inte att använda komprometterade nycklar. Spärra CA:n, utfärda en ny och rensa trust stores kontrollerat.

Ta bort en CA först när ingen konfiguration längre hänvisar till den, den gamla vägen inte längre behövs och kraven på bevarande och revision är uppfyllda.

Avgränsa fel

Ikonen för privat nyckel saknas

Om certifikatet inte importerades via matchande CSR kan SFOS inte koppla det till nyckeln som skapades på brandväggen. Kontrollera CSR-kopplingen och det utfärdade certifikatet. Importera inte privata nycklar från ärenden, e-post eller okontrollerad lagring.

CA:n kan inte väljas för omsignering

Kontrollera CA-syfte, ikonen för privat nyckel och certifikattillägg. Om Extended Key Usage finns måste TLS Web Server Authentication ingå. En rot-CA med Validation only är avsiktligt inte tillgänglig för omsignering.

En klient rapporterar en ej betrodd kedja

Kontrollera rot-CA:n och den underordnade CA:n, deras fingerprints och trust store på den berörda klienten. Jämför därefter den issuer som webbläsaren faktiskt visar med den CA som valts i SFOS. Att rot-CA:n finns på brandväggen eller klienten bevisar inte att rätt CA för omsignering är aktiv.

Webbläsaren fungerar, men inte en applikation

Applikationen kan använda en egen trust store eller certificate pinning. Dokumentera först destination, klient, Inspection Rule och tidpunkt för felet. Lägg inte till ett globalt undantag för Don't decrypt. Avgränsa problemet i den lilla piloten och godkänn endast det nödvändiga undantaget med dokumenterad motivering.

FAQ