Een ondergeschikte CA voor Sophos Firewall TLS-inspectie instellen

Voor TLS-inspectie moet Sophos Firewall de certificaten voor bezochte HTTPS-bestemmingen opnieuw ondertekenen. In plaats van de ingebouwde SecurityAppliance_SSL_CA kan een toegewezen ondergeschikte enterprise-CA worden gebruikt. Beheerde clients blijven dan de eigen root-CA van de organisatie vertrouwen, terwijl de privésleutel van de ondergeschikte CA op de firewall blijft.

Het veilige proces bestaat uit zes stappen:

1. Op Sophos Firewall een CSR voor de nieuwe ondergeschikte CA genereren.
2. De CSR door een Microsoft AD CS Enterprise CA met de sjabloon Subordinate Certification Authority laten ondertekenen.
3. Het uitgegeven CA-certificaat rechtstreeks bij de bestaande CSR importeren.
4. De bijbehorende root-CA als Validation only op de firewall toevoegen.
5. De ondergeschikte CA als CA voor herondertekening selecteren en eerst alleen in een pilotregel gebruiken.
6. Certificaatketen, echt HTTPS-verkeer, logs en rollback controleren.

⚠️ Een CA voor herondertekening kan certificaten voor domeinen van derden uitgeven. De privésleutel is daarom bijzonder gevoelig. De CA mag alleen voor het bedoelde inspectiepad worden gebruikt en mag niet worden geëxporteerd of in tickets worden gedeeld. Zonder geteste herstelroute wordt ze niet in productie geactiveerd.

Deze procedure is beschreven voor AD CS in Enterprise CA-modus. Sophos vermeldt uitdrukkelijk dat de gedocumenteerde werkwijze niet voor een Standalone CA geldt. Een andere interne PKI kan eveneens een ondergeschikte CA uitgeven, maar daarvoor is een eigen, door de PKI-beheerder gecontroleerd proces nodig.

Wanneer een ondergeschikte CA nuttig is

Een eigen ondergeschikte CA past vooral in beheerde bedrijfsnetwerken waarin clients al een interne root-CA vertrouwen. Daardoor hoeft geen extra, onafhankelijke Sophos trust anchor naar elk apparaat te worden uitgerold. Rotatie, intrekking en verantwoordelijkheid kunnen in de bestaande PKI-governance worden opgenomen.

De oplossing is echter niet automatisch eenvoudiger. De firewall krijgt een sleutel waarmee certificaten voor TLS-inspectie kunnen worden ondertekend. De CA heeft daarom een nauw omschreven doel, gedocumenteerde beheerders, een beperkte geldigheidsduur en geteste intrekkings- en vernieuwingsprocedures nodig.

Voor kleinere omgevingen zonder eigen PKI is de ingebouwde Sophos CA vaak de eenvoudigere route. Het Sophos Firewall CA-certificaat voor TLS-inspectie distribueren legt selectie en clientdistributie uit. Sophos Firewall TLS-inspectie correct invoeren behandelt het volledige pilot- en uitzonderingsproces.

CA-ontwerp en herstelroute voorbereiden

Vóór het genereren van de CSR worden doel, namen en afhankelijkheden vastgelegd. Een mogelijk voorbeeld is:

• SFOS-objectnaam: SFOS-TLS-Inspection-SubCA-2026
• Common Name: SFOS TLS Inspection SubCA 2026
• uitgevende root-CA: Example Enterprise Root CA
• bedoeld gebruik: uitsluitend TLS-inspectie en HTTPS-decryptie op FW01
• pilotnetwerk: 10.20.30.0/24

Deze waarden zijn documentatievoorbeelden en moeten worden vervangen door de eigen naamgevingsconventie, PKI en pilotgroep. Een afzonderlijke CA per firewall of duidelijk afgebakend inspectiecluster vereenvoudigt later toewijzing, intrekking en rotatie.

Vóór de wijziging moeten beschikbaar zijn:

• een actuele configuratieback-up en werkende onafhankelijke beheertoegang,
• documentatie van de huidige CA voor herondertekening en de distributie ervan naar clients,
• toegang tot een AD CS Enterprise CA en goedkeuring van de PKI-beheerder,
• een kleine beheerde testgroep met een werkende herstelroute,
• een plan voor intrekking, vernieuwing en gecontroleerde terugkeer naar de vorige CA.

Een Sophos Firewall-back-up maken en terugzetten beschrijft de back-up- en herstelprocedure. Een back-up vervangt niet de documentatie van de momenteel geselecteerde CA voor herondertekening en de clients die deze vertrouwen.

De CSR op Sophos Firewall genereren

De CSR wordt op de firewall gegenereerd, zodat de privésleutel daar ontstaat en niet tussen AD CS, een beheerwerkstation en de firewall hoeft te worden getransporteerd.

1. Open Certificates > Certificates.
2. Selecteer Add.
3. Selecteer onder Action Generate certificate signing request (CSR).
4. Voer een unieke naam in, bijvoorbeeld SFOS-TLS-Inspection-SubCA-2026.
5. Kies sleuteltype, sleutellengte of curve en secure hash volgens het eigen PKI-beleid. Sophos toont in het voorbeeld RSA, 2048 bit en SHA-256; dit zijn productvoorbeelden, geen universele voorschriften.
6. Voer de door de interne PKI goedgekeurde subjectgegevens en Subject Alternative Names in.
7. Sla de CSR op en open deze via het downloadpictogram.
8. Gebruik Copy to clipboard en lever de CSR uitsluitend via het geautoriseerde AD CS-proces aan.

De CSR bevat geen privésleutel. Toch hoort deze bij het gecontroleerde PKI-proces, omdat identiteit, publieke sleutel en aangevraagd CA-doel erin worden vastgelegd.

De ondergeschikte CA met AD CS uitgeven

De Sophos-CSR wordt via de webinschrijving van de verantwoordelijke AD CS Enterprise CA ingediend:

1. Open Request a certificate.
2. Selecteer Advanced certificate request.
3. Plak de volledige CSR.
4. Selecteer bij Certificate template Subordinate Certification Authority.
5. Controleer de aanvraag volgens het interne goedkeuringsproces en geef deze uit met Submit.
6. Kies onder Certificate Issued een geschikt formaat, bijvoorbeeld Base 64 encoded.
7. Download het uitgegeven certificaat van de ondergeschikte CA.
8. Download ook het certificaat van de root-CA die de ondergeschikte CA heeft ondertekend.

Belangrijke EKU-grens: Als het uitgegeven CA-certificaat een sectie Extended Key Usage bevat, moet voor dit ondertekeningsdoel TLS Web Server Authentication aanwezig zijn. Ontbreekt deze waarde, gebruik het certificaat dan niet als CA voor herondertekening in productie. De PKI-beheerder moet de CA-sjabloon corrigeren en een nieuw certificaat uitgeven.

Controleer vóór de import in de certificaatweergave issuer, subject, geldigheid, Basic Constraints en, indien aanwezig, Extended Key Usage. Geef de root- en subordinate-bestanden ondubbelzinnige namen, zodat ze niet met servercertificaten worden verwisseld.

De ondergeschikte en root-CA importeren

De ondergeschikte CA bij de bestaande CSR importeren

1. Open Certificates > Certificates.
2. Selecteer de importactie bij de eerder gemaakte CSR.
3. Selecteer het door AD CS uitgegeven certificaat van de ondergeschikte CA.
4. Selecteer Certificate authority only. SFOS herkent het CA-type en toont de CA-opties.
5. Controleer de naam en selecteer Import certificate.
6. Open Certificates > Certificate authorities en zoek de geïmporteerde CA.

SFOS koppelt de privésleutel van de CSR automatisch aan de ondergeschikte CA. Daarom moet in de CA-lijst bij deze CA het privésleutelpictogram zichtbaar zijn. Ontbreekt het, dan is de CA niet gereed om te ondertekenen; het bestand op een andere plaats opnieuw uploaden herstelt de ontbrekende sleutelkoppeling niet.

De root-CA alleen voor validatie toevoegen

1. Open Certificates > Certificate authorities en selecteer Add.
2. Upload het root-CA-certificaat dat de ondergeschikte CA heeft uitgegeven.
3. Behoud onder Use certificate for Validation only.
4. Vergelijk naam en fingerprint met de goedgekeurde root-CA-documentatie.
5. Sla op en controleer de keten van de ondergeschikte CA opnieuw.

De firewall heeft de privésleutel van de root-CA niet nodig. Signing and validation is uitsluitend bedoeld voor de ondergeschikte CA waarvan de privésleutel via de CSR al op de firewall staat. Certificaten op Sophos Firewall importeren en toewijzen legt de algemene verschillen tussen certificaat, CSR, privésleutel en CA-keten uit.

De CA voor TLS-inspectie selecteren

Alleen importeren verandert nog geen verkeer. De nieuwe CA wordt eerst in een nauw begrensde pilot geactiveerd. Afhankelijk van het inspectiepad staat de selectie op verschillende plaatsen:

• 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

Alleen een CA met doel Signing and validation en een aanwezige privésleutel mag als CA voor herondertekening worden gebruikt. Wijzig een gebruikte signing-CA niet in Validation only; het actieve pad voor herondertekening zou daarmee zijn sleutel verliezen.

Voor de pilot:

1. Documenteer de huidige selectie en de betrokken regels.
2. Selecteer de nieuwe CA in het bedoelde inspectiepad.
3. Beperk de regel tot de vastgelegde testgroep of het pilotnetwerk.
4. Controleer de CA-keten op de pilotclients. In een AD-domein zou de enterprise root-CA al vertrouwd moeten zijn, maar de volledige keten naar de nieuwe ondergeschikte CA moet nog steeds correct kunnen worden opgebouwd.
5. Genereer een echte HTTPS-aanvraag en controleer certificaatdetails, Inspection Rule, Decryption Profile en logvermelding samen.

Voer pas een brede productiewijziging uit nadat de pilot is geslaagd. Het selecteren van de CA activeert niet automatisch een Inspection Rule en vertrouwen op de client bewijst niet dat verkeer werkelijk wordt ontsleuteld.

Werking en beveiliging valideren

Een geslaagde test bevat meerdere bewijzen:

1. Onder Certificates > Certificate authorities is de root-CA als Validation only aanwezig.
2. De ondergeschikte CA heeft Signing and validation en toont het privésleutelpictogram.
3. Een pilotclient vertrouwt de root-CA en kan de volledige keten opbouwen.
4. Een bewust ontsleutelde HTTPS-site toont een servercertificaat dat door de nieuwe ondergeschikte CA is ondertekend.
5. Hostname, oorspronkelijke bestemming en browserstatus zijn correct en er verschijnt geen onverwachte certificaatwaarschuwing.
6. Log Viewer toont de verwachte SSL/TLS Inspection Rule en actie voor precies deze test.
7. Een bron buiten de pilot blijft op het vorige pad.

Test toepassingen met certificate pinning, eigen trust stores of gevoelige updatepaden afzonderlijk. Eén geslaagde browseraanvraag is niet voldoende om de volledige uitrol goed te keuren.

Rotatie en rollback

Vernieuw de ondergeschikte CA vóór de vervaldatum. Houd de nieuwe en oude CA tijdens een gecontroleerde overgang duidelijk van elkaar te onderscheiden. Geef de nieuwe CA eerst uit, importeer en test deze op pilotclients en selecteer ze pas daarna stapsgewijs in het inspectiepad.

Gebruik bij fouten de voorbereide herstelroute:

1. Schakel de pilotregel uit of zet deze terug op de vorige CA voor herondertekening.
2. Controleer met een nieuw browserproces of het vorige certificaatpad opnieuw actief is.
3. Verwijder de nieuwe CA niet zolang regels, Decryption Profiles of Web Proxy-instellingen ernaar verwijzen.
4. Betrek de PKI-beheerder als EKU, keten, sjabloon of intrekkingsstatus onduidelijk zijn.
5. Gebruik gecompromitteerde sleutels niet verder; trek de CA in, geef een nieuwe uit en ruim trust stores gecontroleerd op.

Verwijder een CA pas wanneer geen configuratie ernaar verwijst, het oude pad niet langer nodig is en aan bewaar- en auditvereisten is voldaan.

Fouten gericht afbakenen

Het privésleutelpictogram ontbreekt

Als het certificaat niet via de bijbehorende CSR is geïmporteerd, kan SFOS het niet koppelen aan de sleutel die op de firewall is gemaakt. Controleer het CSR-koppelingspad en het uitgegeven certificaat. Importeer geen privésleutels uit tickets, e-mail of onbeheerde opslag.

De CA kan niet voor herondertekening worden geselecteerd

Controleer CA-doel, privésleutelpictogram en certificaatextensies. Als Extended Key Usage aanwezig is, moet dit TLS Web Server Authentication bevatten. Een root-CA met Validation only is bewust niet beschikbaar voor herondertekening.

Een client meldt een niet-vertrouwde keten

Controleer de root- en ondergeschikte CA, hun fingerprints en de trust store van de betrokken client. Vergelijk vervolgens de issuer die de browser werkelijk toont met de CA die in SFOS is geselecteerd. De aanwezigheid van de root-CA op de firewall of client bewijst niet dat de juiste CA voor herondertekening actief is.

De browser werkt, maar een toepassing niet

De toepassing kan een eigen trust store of certificate pinning gebruiken. Documenteer eerst bestemming, client, Inspection Rule en tijdstip van de fout. Voeg geen globale Don't decrypt-uitzondering toe; isoleer het probleem in de kleine pilot en keur alleen de noodzakelijke uitzondering met gedocumenteerde reden goed.

FAQ