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.

Alternativt kan CSR:n och CA:erna genereras med ett externt verktyg som OpenSSL. Externt genererade underordnade CA:er och rot-CA:er laddas upp under Certificates > Certificate authorities; en signerings-CA utan matchande CSR på brandväggen kräver även sin privata nyckel via den godkända PKI-processen. Roten förblir utan privat nyckel. Detta är en annan väg för nyckelöverföring, inte den CSR-import som beskrivs nedan. Den underordnade CA:n kan också användas för TLS-konfigurationer för e-post; aktiveringen och valideringen nedan gäller endast webbtrafik och aktiverar ingen TLS-konfiguration för e-post.

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.

Under Subject name attributes innehåller CSR-formuläret Country name, State, Locality name, Organization name, Organization unit name, Common name och Email address. Ange identitetsuppgifter som godkänts av PKI:n, inte uppgifter från en godtycklig besökt webbplats. Subject Alternative Names accepterar DNS-namn eller IP-adresser, exempelvis web.exampleorg.com, fd12:3456:789a:1:: eller 203.0.113.10. Dessa produktvärden är exempel, inte krav för en inspektions-CA; fastställ SAN tillsammans med PKI-ansvarig.

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. Välj Download certificate för att ladda ned det utfärdade certifikatet för den underordnade CA:n.
8. Öppna Download a CA certificate på AD CS-startsidan, välj rot-CA:n som signerade den underordnade CA:n och välj sedan Download CA certificate och Save.

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 filtret bredvid Name under Certificates > Certificate authorities, ange CA-namnet och välj Apply.

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. Den allmänna CA-importen under Certificates > Certificate authorities > Add kan också identifiera en befintlig matchande CSR. Importen direkt vid CSR:n som beskrivs här gör kopplingen tydlig, men är inte den enda dokumenterade vägen. Utan matchande CSR eller privat nyckel skapar en ny uppladdning av certifikatet ingen signeringsnyckel.

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

Sophos stegvisa exempel kallar syftet Validation, medan CA-fältreferensen kallar det Validation only. Här avses samma säkra roll: rotcertifikat endast för validering, utan rotens privata nyckel; välj inte Signing and validation för roten. Välj filen under Certificate med Browse vid uppladdningen.

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. DPI har ett globalt val och en möjlig åsidosättning per regel, medan Web Proxy har ett separat val:

• DPI, globalt: Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings
• DPI, per regel: den Decryption Profile som tilldelats under Profiles > Decryption profiles kan ärva eller åsidosätta det globala valet.
• Web Proxy: Web > General settings > HTTPS decryption and scanning

DPI-inställningarna har separata fält för Re-sign RSA with och Re-sign EC with. De syftar på om webbplatsens ursprungliga certifikat signerades med RSA eller EC. SFOS accepterar en RSA- eller EC-CA i båda fälten. Därför kan samma underordnade CA normalt väljas för båda. En andra EC-CA är främst användbar när en applikation endast accepterar en viss certifikattyp; även denna CA måste vara betrodd av alla berörda endpoints.

En Decryption Profile som tilldelats en Inspection Rule kan avsiktligt ärva det globala valet med Use CAs defined in SSL/TLS settings. Om egna värden för Re-sign RSA with och Re-sign EC with anges i profilen åsidosätter de de globala inställningarna för regeln. Kontrollera därför både det globala CA-valet och den profil som faktiskt har tilldelats regeln före piloten.

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 skulle inte längre kunna användas för aktiv omsignering. Detta säger inte om SFOS raderar den lagrade nyckeln.

Säkra pilotens omfattning först: En global DPI-CA-ändring påverkar även befintliga regler vars profiler ärver det globala valet. Använd en separat Decryption Profile med uttryckliga CA-värden för en isolerad DPI-pilot och tilldela den endast till pilotregeln som redan begränsats till testgruppen. Redigera inte en profil som delas med produktionen. En ny pilotregel isolerar inte det globala CA-valet för Web Proxy; om proxyskanning redan är aktiv krävs en separat godkänd ändring för alla berörda klienter. Låt tills dess den befintliga globala CA:n vara oförändrad.

För piloten:

1. Dokumentera nuvarande val och berörda regler.
2. Välj den nya CA:n för RSA- och EC-certifikat i den avsedda inspektionsvägen och kontrollera för DPI om tilldelad Decryption Profile ärver eller åsidosätter det globala valet.
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.

API-avstämning: skilj CA-val från globala inställningar

Den som kontrollerar eller automatiserar CA-valet via XML API måste skilja mellan fälten i objektet SSLTLSInspectionSettings. Referenserna för SFOS 22.0 och 23.0 anger samma fält; detta bevisar inte att en viss brandvägg redan har tillämpat en ändring framgångsrikt.

• RSACA och ECCA anger CA-valet för omsignering av RSA- respektive EC-servercertifikat och motsvarar Re-sign RSA with och Re-sign EC with. Värdet ska vara namnet på det avsedda CA-objektet, exempelvis SFOS-TLS-Inspection-SubCA-2026, inte en sökväg till en certifikatfil, en privat nyckel eller ett aktiveringsvärde. Valet skapar eller importerar ingen CA och distribuerar inte tillit till klienterna. De tidigare beskrivna kraven på signeringsändamål, privat nyckel, kedja och profilåsidosättningar gäller fortfarande; om två olika CA:er används måste de berörda klienterna kunna verifiera båda kedjorna.

• SSLTLSEngine styr TLS-motorn och SSLTLSInspection den globala SSL/TLS-inspektionen; båda accepterar Enabled eller Disabled. Dessa fält anger varken CA-valet eller statusen för den enskilda pilotregeln. En CA-rotation är inget skäl att ändra dessa globala inställningar. API-referensen anger standardvärdet Enabled för båda; vid ändringen är det dock det avlästa faktiska tillståndet som gäller, inte ett dokumenterat standardvärde.

• TLS13Decryption anger den globala hanteringen av TLS 1.3-anslutningar: Decrypt as 1.3 eller Downgrade to TLS 1.2 and decrypt, med det dokumenterade standardvärdet Decrypt as 1.3. Fältet väljer varken signerings-CA eller åtgärd för en enskild inspektionsregel. En nedgradering är därför ingen lösning på en saknad CA-kedja eller signeringsnyckel; vid ett rent CA-byte ska den godkända TLS 1.3-inställningen förbli oförändrad.

Även SSLv2SSLv3, SSLCompression och SSLConnectionsExceeded är separata globala beslut för äldre protokoll, SSL-komprimering respektive överskriden kapacitet för SSL-anslutningar. Varje fält accepterar Allow without decryption, Drop eller Reject; API:et anger Allow without decryption som standardvärde för samtliga, inte som en säkerhetsrekommendation. Dessa beslut ska inte samtidigt återställas till exempelvärden vid en CA-rotation.

Före en API-ändring ska de faktiskt lagrade globala värdena, båda CA-objektnamnen, profilåsidosättningarna och de berörda reglerna säkerhetskopieras, och en exakt återställningsprocedur fastställas. Referensen anger att de nämnda fälten är valfria; detta bevisar inte att utelämnade fält förblir oförändrade i varje firmwareversion. Utför inget automatiserat skrivanrop utan att uppdaterings- och återställningsbeteendet har bekräftats för den aktuella buildversionen. Ett dokumenterat API-svar 200 betyder att operationen lyckades, medan 500 betyder att operationen misslyckades; inte heller ett meddelande om framgång ersätter en ny avläsning av de lagrade värdena och test med nya HTTPS-anslutningar. Ett oväntat värde eller ett oklart tillstånd ska stoppa utökningen av piloten.

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.

För godkännandet ska både ett RSA- och ett EC-servercertifikat testas i den avsedda DPI-vägen. Jämför för vart och ett den presenterade utfärdaren, den fullständiga kedjan med rot- och underordnade CA:er, klientens tillit, den faktiskt tilldelade profilen och den loggade åtgärden. Om olika signerings-CA:er används ska båda tillitskedjorna verifieras separat. Bekräfta dessutom att de globala inställningarna, TLS 1.3-hanteringen och de övriga globala besluten motsvarar sitt dokumenterade tidigare tillstånd och att en källa utanför piloten förblir oförändrad. Detta är ett verifieringsuppdrag för den egna miljön, inte ett enhetstest som har utförts här.

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:

Återställ helst föregående CA eller profil vid en CA-återställning. Att enbart inaktivera en pilotregel garanterar varken föregående CA eller föregående dekryptering: en senare regel kan ta över. Kontrollera den faktiska reservvägen i förväg och verifiera certifikatet och loggarna på nytt efteråt.

En CA-återställning återställer endast de CA- och profiländringar som gjorts inom piloten till det säkerhetskopierade tidigare tillståndet. Att generellt sätta SSLTLSEngine eller SSLTLSInspection till Disabled eller ändra TLS13Decryption återställer varken den tidigare CA:n eller den tidigare skyddsvägen. Läs därefter återigen av det lagrade valet och åsidosättningarna samt kontrollera certifikatkedjan och loggarna med nya anslutningar. Om en verifierad återställningsprocedur saknas ska utrullningen inte fortsätta.

1. Återställ den tidigare CA:n för omsignering respektive den tidigare dekrypteringsprofilen. Inaktivera pilotregeln endast om den i förväg verifierade efterföljande hanteringsvägen återställer det godkända tidigare tillståndet; ingen generell avstängning av den globala motorn eller inspektionen.
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

Kontrollera befintlig CSR, certifikatet som utfärdats för den och den automatiska nyckelkopplingen. Även import under Certificates > Certificate authorities > Add beror på om SFOS hittar en matchande CSR. Om matchande CSR saknas eller certifikatet inte matchar den är kopplingen inte bekräftad. 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