Förnya Sophos Firewall Default CA kontrollerat

Den inbyggda CA:n Default i Sophos Firewall är inte en vanlig beskrivningspost. Så snart inställningarna sparas regenererar SFOS automatiskt CA:n. Då skapas en ny nyckel och därmed en ny trust anchor. Befintliga förtroenderelationer anpassas inte automatiskt efteråt.

En kontrollerad förnyelse börjar därför inte med Save, utan med en fullständig lista över beroenden. Dit hör lokalt signerade certifikat, WebAdmin och portaler, SSL VPN-profiler, certifikatbaserade IPsec-peers och externa system som litar på den tidigare CA:n.

⚠️ Viktigt: Förnya endast CA:n Default med en verifierad backup, oberoende administrationsåtkomst, ett underhållsfönster och en plan för alla beroende tjänster. En kosmetisk ändring av land, organisation eller common name motiverar inte en oplanerad regenerering.

Förnya Default CA i tio steg

1. Dokumentera tekniskt skäl, ändringsansvarig, underhållsfönster och framgångskriterier.
2. Kartlägg alla certifikat, tjänster, VPN-profiler, peers och klienter som litar på den befintliga CA:n Default.
3. Kontrollera om det egentliga målet endast är ApplianceCertificate eller den separata SecurityAppliance_SSL_CA.
4. Testa aktuell konfigurationsbackup, SSMK, lokal administratörsåtkomst och återställningsväg med godkänt resultat.
5. Hämta den gamla CA:n Default och dokumentera SHA-256-fingerprint, subject, serienummer och giltighet.
6. Godkänn skriftligen nya CA-uppgifter, nyckeltyp och kompatibilitet med alla peers.
7. Ange de förberedda värdena under Certificates > Certificate authorities > Default och spara dem först under underhållsfönstret.
8. Hämta den nya publika CA:n och distribuera den kontrollerat till peers, klienter och trust stores.
9. Testa WebAdmin, portaler, SSL VPN, IPsec och alla andra beroende tjänster separat.
10. Dokumentera fingerprint, loggar, testresultat och kvarvarande gamla profiler. Använd den förberedda återställningsvägen om ett kritiskt fel uppstår.

Skilj mellan Default CA, ApplianceCertificate och Inspection CA

Sophos Firewall innehåller flera objekt med olika uppgifter:

• Default: intern CA för lokalt signerade certifikat.
• ApplianceCertificate: inbyggt servercertifikat som standard används för WebAdmin, User Portal och Captive Portal. Det är signerat av CA:n Default och kan regenereras separat.
• SecurityAppliance_SSL_CA: separat inbyggd CA för HTTPS Inspection och Re-Signing när den är vald i TLS Inspection-konfigurationen.

Dessa objekt får inte likställas. Ett problem med ett enskilt ApplianceCertificate bevisar inte att CA:n Default är defekt. En ändring av CA:n Default genomför inte heller automatiskt en planerad rotation av SecurityAppliance_SSL_CA.

Importera och tilldela certifikat i Sophos Firewall förklarar det allmänna arbetet med certifikat, privata nycklar, CSR:er och CA-kedjor. För Inspection CA gäller den separata processen Distribuera CA-certifikatet för HTTPS Scanning.

När en regenerering är motiverad

En planerad ändring kan behövas när:

• den tidigare CA-nyckeln bevisligen eller rimligen kan antas vara komprometterad,
• CA:n håller på att löpa ut och fortfarande används i produktion,
• identitet, nyckeltyp eller kryptografiska krav migreras kontrollerat,
• Sophos Support kräver regenerering för ett bekräftat problem.

En enstaka misslyckad VPN-hämtning, en webbläsarvarning utan kedjeanalys, ett kosmetiskt önskemål om subject eller ett gammalt community-kommando är inte tillräckliga skäl. Vid ett problem med .ovpn och ApplianceCertificate, börja med att systematiskt felsöka hämtningen av SSL VPN-konfigurationen.

Inventera beroenden före ändringen

Certifikat och tilldelade tjänster

Dokumentera under Certificates > Certificates minst namn, subject, issuer, giltighet och faktisk tilldelning för varje lokalt signerat certifikat. Beroende på miljön omfattar detta:

• WebAdmin, User Portal och Captive Portal,
• SSL VPN-servercertifikatet,
• site-to-site och remote access IPsec med Digital certificate,
• WAF-, SMTP-, API- eller andra TLS-tjänster,
• egengenererade klient- eller servercertifikat utanför brandväggen.

Ett synligt certifikat är inte automatiskt ett beroende. Det avgörande är om en produktionstjänst använder det och om peeren litar på den utfärdande CA:n Default.

System som litar på CA:n och distributionsvägar

Dokumentera även:

• webbläsare och operativsystem där den gamla CA:n är importerad,
• MDM, GPO eller programvarudistribution för den nya CA:n,
• IPsec-peers med importerad Default.pem, Remote CA eller DN-mappning,
• SSL VPN-användare och distributionsvägen för nya .ovpn-profiler,
• övervakning, API-klienter eller integrationer med certificate pinning,
• HA-, nöd- och extern administrationsåtkomst.

Stoppa ändringen om det är oklart vem som distribuerade den tidigare CA:n eller vilka peers som litar på den.

Bevara utgångsläget och återställningsvägen

Hämta CA:n Default under Certificates > Certificate authorities före underhållsfönstret. Arkivet innehåller den publika delen, inte automatiskt en separat användbar export av den privata nyckeln.

PEM-data kan kontrolleras skrivskyddat på en administrationsdator:

openssl x509 -in Default.pem -noout -subject -issuer -serial -dates -fingerprint -sha256

För en DER-fil anges indataformatet:

openssl x509 -inform DER -in Default.der -noout -subject -issuer -serial -dates -fingerprint -sha256

Spara fingerprint och utdata i föreläget tillsammans med brandväggsnamn, serienummer, SFOS-build och change-ticket. Bifoga inte certifikatfiler och interna PKI-data oskyddat i publika ärenden.

Spara dessutom en aktuell Sophos Firewall-backup med lösenord och SSMK externt. En restore ersätter hela konfigurationen, startar om brandväggen och kan återställa senare ändringar. Den är en sista planerad återställningsväg, inte en snabb undo-funktion för CA:n.

Förbered underhållsfönstret

Före Save måste följande punkter vara godkända:

• lokalt admin-konto eller en andra administratör testad från administrationsnätet,
• konsol eller annan oberoende återställningsväg tillgänglig,
• nya CA-värden och kryptografi kompatibla med alla peersystem,
• ansvariga för VPN-peers, MDM/GPO och portaler tillgängliga,
• nya profiler, trust store-distribution och testkonton förberedda,
• tillräckligt med tid för en fullständig backup-restore om det behövs.

I ett HA-kluster görs den stödda WebAdmin-ändringen på aktuell Primary. SFOS dokumenterar inte avbrottsfri CA- eller sessionskontinuitet för denna ändring. Testa därför nya inloggningar och alla kritiska tjänster på nytt efter en planerad failover. Redigera inte CA:n oberoende på båda noderna.

Uppdatera Default CA i SFOS

1. Öppna Certificates > Certificate authorities.
2. Klicka på Default. Själva namnet kan inte ändras.
3. Kontrollera Country, State, Locality, Organization, Organizational unit, Common name och e-postadress.
4. Välj medvetet RSA eller Elliptic curve, motsvarande nyckellängd eller kurva samt Secure hash under Private key settings.
5. Kontrollera värdena mot change-ticket och kompatibilitetslistan.
6. Klicka på Save endast under underhållsfönstret.

Exempelvärden som CH, Zurich, Example AG, IT Security, fw01.example.com och pki@example.com är enbart dokumentationsvärden. Ersätt dem med den egna organisationen, den faktiska brandväggsreferensen och den godkända PKI-namnkonventionen.

⚠️ Save är växlingspunkten. SFOS regenererar automatiskt CA:n Default. Att senare ange de tidigare subject-värdena igen återställer inte den gamla nyckeln eller fingerprint.

Hämta direkt därefter den nya CA:n Default och kör samma OpenSSL-kontroll. Efter regenereringen förväntas ett nytt SHA-256-fingerprint. Oväntade fält, hämtningsfel eller ett tillstånd som inte kan dokumenteras är stoppvillkor.

Migrera beroende tjänster kontrollerat

WebAdmin och portaler

Kontrollera under Administration > Admin and user settings vilket certifikat som är valt för WebAdmin, User Portal och Captive Portal. Om ett lokalt signerat certifikat med den nya CA:n används måste klienterna som ansluter lita på den nya CA:n.

Låt en befintlig Full Admin-session vara öppen under testet. Nya privata webbläsarfönster testar FQDN, certifikatkedja och inloggning från den avsedda administrationskällan. CLI-kommandot som återställer WebAdmin-certifikatet till enhetens standardcertifikat är inte en rollback av den gamla CA-nyckeln.

SSL VPN

Om SSL VPN använder ApplianceCertificate eller ett annat lokalt signerat servercertifikat måste användarna hämta och importera en ny .ovpn-fil efter ändringen av inställningarna för CA:n Default. Ett befintligt filnamn eller en grön tunnelstatus med en gammal profil är inte tillräcklig validering.

Minst en pilotanvändare hämtar den nya profilen via den avsedda portalvägen, upprättar en ny anslutning och testar DNS, routes och verklig programtrafik. Ta bort gamla profiler från distributionen först när alla användare har migrerats framgångsrikt.

Certifikatbaserade IPsec-peers

Med Digital certificate utbyter Sophos Firewall-peers sina CA-certifikat. Om peeren tidigare importerade den fjärranslutna Default.pem ska den nya publika CA:n kontrollerat ersättas eller läggas till på peeren och mappningen verifieras på nytt.

Den fullständiga anslutningskonfigurationen finns kvar i Konfigurera site-to-site IPsec i Sophos Firewall. För CA-ändringen testas minst IKE-etablering, Child SA, båda trafikriktningarna och de faktiska programmen. En grön tunnel bevisar inte i sig returvägen.

HTTPS Inspection och andra signeringsvägar

Identifiera först den Signing CA som faktiskt är vald under Web > General settings för HTTPS Inspection. Om detta är SecurityAppliance_SSL_CA eller en extern CA ska den inte distribueras på nytt bara för att CA:n Default har regenererats.

Ta endast med en signeringsväg i ändringen när det är bevisat att den använder den ändrade CA:n Default eller ett beroende certifikat. Därmed begränsas trust store-ändringarna till de endpoints som verkligen påverkas.

Verifiera resultatet och loggarna

Valideringen skiljer konfiguration från funktion:

1. Hämta den nya CA:n och dokumentera subject, issuer, serienummer, giltighet och SHA-256-fingerprint.
2. Kontrollera issuer, Trusted och berörda certifikatobjekt under Certificates > Certificates.
3. Testa WebAdmin, portaler, SSL VPN, IPsec och andra tilldelade tjänster individuellt.
4. Kontrollera CA- och certifikatåtgärden vid tidpunkten för ändringen i vpncertificate.log.
5. Kontrollera administratör, tid och stödda före-/efterdata i configuration-audit.log.
6. Korrelera endast de fel och framgångar som hör till testet i respektive tjänsteloggar.

Spåra konfigurationsändringar med configuration-audit.log förklarar audit trail. Alla tjänster skriver inte samma detaljnivå i configuration-audit.log, så funktionsvalidering är fortfarande obligatorisk.

Rollback och stoppvillkor

En regenererad CA har ingen enkel Undo-funktion. Att spara den tidigare texten igen återställer inte den gamla privata nyckeln.

Definiera därför återställningsvägen för varje tjänst i förväg:

• behåll oberoende administrationsåtkomst och den befintliga administratörssessionen,
• växla tillbaka portaler till ett redan verifierat, oberoende externt certifikat om ett sådant finns och kan tilldelas säkert,
• återställ peer-trust och klientprofiler endast enligt det dokumenterade tidigare läget,
• använd fullständig backup-restore endast när effekterna, omstarten, SSMK och förlusten av senare ändringar är acceptabla,
• eskalera till Sophos Support med bevis när ett beroende är okänt eller certifikattillståndet inte kan återskapas.

Gör inga databasändringar via shell, massradering av certifikat, tjänsteomstarter eller en andra CA-regenerering på misstanke. Stoppa ändringen om en kritisk peer inte kan samordnas, den nya trust anchor inte har distribuerats eller återställningsvägen inte har testats med godkänt resultat.

Vanliga fel efter regenereringen

Webbläsaren rapporterar en ej betrodd anslutning

Kontrollera certifikatkedjan som faktiskt levereras för FQDN. Om servercertifikatet är signerat av den nya CA:n Default måste exakt den CA:n finnas i trust store. Importera inte SecurityAppliance_SSL_CA slentrianmässigt.

SSL VPN ansluter inte längre med den gamla profilen

Korrelera valt SSL-servercertifikat, den nya CA:n, portalhämtningen och sslvpn.log. Hämta en ny .ovpn-fil och importera den som en ny profil. Skilj gamla och nya profiler åt med hjälp av certifikatet och en lyckad anslutning, inte filnamnet.

IPsec förblir down efter CA-ändringen

Kontrollera CA-import, Trusted-status, Local/Remote certificate, ID och strongswan.log på båda sidor. Med DER ASN1 DN kan ett ändrat CA-subject även påverka identiteten. Lätta inte på profiler eller ID:n på misstanke.

HTTPS Inspection visar certifikatfel

Kontrollera först den Signing CA som faktiskt är vald. Om SecurityAppliance_SSL_CA fortfarande används och är oförändrad orsakas felet inte automatiskt av den nya CA:n Default. Undersök certifikatkedja, Decryption Rule och endpoint-trust separat.

Checklista

• Skäl och omfattning för CA-regenereringen är dokumenterade.
• Den gamla CA:n, fingerprint, backup, lösenord och SSMK är bevarade.
• Alla certifikat, tjänster, peers, klienter och distributionsvägar är inventerade.
• Default, ApplianceCertificate och SecurityAppliance_SSL_CA har bedömts separat.
• Underhållsfönster, administrativ återställningsväg och ansvariga är redo.
• De nya CA-värdena och kryptografin är kompatibla med alla peers.
• CA:n sparades endast under det godkända fönstret och hämtades därefter.
• WebAdmin, portaler, SSL VPN, IPsec och andra tjänster har testats separat.
• vpncertificate.log, configuration-audit.log och tjänsteloggar har bevarats.
• Rollback eller supporteskalering är möjlig utan okontrollerade shell-ingrepp.

FAQ