Zertifikate auf der Sophos XGS aus der eigenen ADCS-PKI: Schluss mit Warnmeldungen

Das Sophos-XGS-Zertifikat aus der internen CA — für viele Umgebungen der überfällige Aufräumschritt, und die Kurzantwort vorab: Ja, die XGS nimmt Zertifikate aus deiner ADCS-PKI an allen relevanten Stellen an — WebAdmin, Benutzerportal, VPN bekommen ordentliche Server-Zertifikate per CSR-Verfahren, und die TLS-Inspection bekommt eine untergeordnete CA aus deiner Hierarchie, womit Domänen-Clients den geprägten Zertifikaten automatisch vertrauen. Warum sich der Aufwand lohnt, steht in der Kernbotschaft: Selbstsignierte Zertifikate erziehen Benutzer zum Wegklicken von Warnungen — und wer seiner Belegschaft jahrelang beibringt, dass rote Zertifikatsfehler »normal« sind, hat die wichtigste menschliche Verteidigungslinie gegen echte Angriffe eigenhändig abgeschaltet. Dieser Artikel führt durch die komplette Strecke: die Zertifikatslandkarte der XGS, das CSR-Verfahren gegen die ADCS, die Inspection-Sub-CA, die Verteilung der Vertrauensstellung — und den Betrieb mit Laufzeiten, Erneuerung und Monitoring, damit das Ganze nicht in zwei Jahren als Überraschung endet.

Wo die Sophos XGS überall Zertifikate nutzt

Bevor irgendein CSR entsteht, lohnt die Landkarte — denn die XGS nutzt Zertifikate in vier Rollen, und die verlangen zwei grundverschiedene Sorten aus drei Quellen. Rolle eins: die Portale — WebAdmin, Benutzerportal, Captive Portal. Hier weist sich die Firewall selbst aus; gebraucht wird ein normales Server-Zertifikat auf ihren FQDN, und das kommt aus der ADCS. Rolle zwei: das VPN — auch hier prüfen Clients die Identität der Gegenstelle, auch hier passt das ADCS-Server-Zertifikat (gern dasselbe wie für die Portale, wenn der Name stimmt). Rolle drei: die WAF für veröffentlichte Dienste — und hier gilt die wichtige Ausnahme: mail.firma.de wird von Externen besucht, die deine Root nicht kennen; diese Zertifikate kommen von einer öffentlichen CA, und ihre Behandlung steht im Publishing-Artikel [LINK: B4] — die ADCS hat dort nichts verloren. Rolle vier schließlich ist die Sonderrolle: Die TLS-Inspection braucht kein Server-, sondern ein CA-Zertifikat, denn die XGS prägt damit laufend neue Zertifikate für jede inspizierte Seite. Warum diese CA niemals eine öffentliche sein kann, klärt der Faktenkasten gleich vorab — es ist die meistgestellte Frage des ganzen Themas.

Skizze 1: Vier Rollen, zwei Sorten, drei Quellen — Portale und VPN aus der ADCS, WAF von der öffentlichen CA, und die Inspection als einzige CA-Rolle.

CSR erzeugen und gegen die ADCS signieren

Der Weg für die Server-Zertifikate (Portale, VPN) ist das klassische CSR-Verfahren, bei dem der private Schlüssel die Firewall nie verlässt — genau so soll es sein. Schritt eins auf der XGS: unter Zertifikate eine Zertifikatsignieranforderung erzeugen — mit dem FQDN der Firewall als Namen und, entscheidend, mit demselben FQDN (plus eventuellen Zweitnamen) als SAN-Einträgen, dazu einer zeitgemäßen Schlüssellänge. Schritt zwei auf der ADCS: den CSR gegen eine Webserver-Vorlage einreichen — per Zertifizierungsstellen-Weboberfläche oder certreq — und das ausgestellte Zertifikat Base64-codiert abholen. Schritt drei zurück auf der XGS: das signierte Zertifikat zur wartenden Anforderung hochladen, außerdem die ausstellende Zwischen-CA und die Root als CA-Zertifikate hinterlegen, damit die Firewall die vollständige Kette ausliefern kann. Schritt vier: zuweisen — in den Verwaltungseinstellungen das neue Zertifikat für WebAdmin und Benutzerportal auswählen, beim VPN entsprechend. Danach der Beweis im Browser: Portal aufrufen, Schloss prüfen, Kette ansehen.

Die Sub-CA für die TLS-Inspection

Jetzt zur Sonderrolle. Ab Werk prägt die XGS ihre Inspection-Zertifikate mit einer selbstsignierten Appliance-CA — funktioniert, verlangt aber, deren Zertifikat auf jedes Gerät zu verteilen. Der elegantere Weg hängt die Firewall in die bestehende Hierarchie: Die ADCS stellt der XGS ein untergeordnetes CA-Zertifikat aus (Vorlage »Untergeordnete Zertifizierungsstelle«), das samt privatem Schlüssel als PKCS#12-Paket auf die Firewall wandert und dort als signierende CA für die Entschlüsselung hinterlegt wird. Der Gewinn steckt in der Vertrauenskette, die die Skizze zeigt: Die geprägten Zertifikate hängen über die XGS-Sub-CA an der Unternehmens-Root — und der vertrauen die Domänengeräte ohnehin, womit die Inspection ohne jede zusätzliche Verteilung flächendeckend grün wird. Drei Bauregeln gehören dazu: die Laufzeit der Sub-CA deutlich kürzer als die der Root (drei bis fünf Jahre — Details im Laufzeiten-Kasten), die Sperrlisten-Verteilpunkte der Hierarchie müssen für Clients erreichbar bleiben, und der Transportweg des PKCS#12-Pakets verdient dieselbe Sorgfalt wie sein Inhalt — der Warn-Kasten sagt, warum. Was hier bewusst nicht steht: der Aufbau der PKI selbst — zweistufige Hierarchie, Offline-Root, Vorlagen-Härtung gehören in den [LINK: PKI-Track]; und welcher Verkehr überhaupt inspiziert werden soll samt aller Ausnahmen, regelt [LINK: A7].

Skizze 2: Root signiert die XGS-Sub-CA, die Sub-CA prägt je Seite — und der Domänen-Client findet am Kettenende seine vertraute Root. Verteilung: keine nötig.

Verteilung der Vertrauensstellung an die Clients

Die schönste Kette nützt nichts, wenn das letzte Glied fehlt: Der Client muss der Root vertrauen. Die gute Nachricht zuerst — beim ADCS-Weg ist genau dieser Schritt meist schon erledigt: Eine AD-integrierte Zertifizierungsstelle verteilt ihre Root über die Domäneninfrastruktur automatisch an alle Mitgliedsgeräte; wo das nicht greift, erledigt es eine Gruppenrichtlinie mit dem Root-Zertifikat im Speicher der vertrauenswürdigen Stammzertifizierungsstellen. Für die Cloud-verwaltete Flotte übernimmt Intune dieselbe Aufgabe: ein Konfigurationsprofil vom Typ »Vertrauenswürdiges Zertifikat« je Plattform, einmal angelegt, dauerhaft gültig — damit sind auch reine Entra-Geräte versorgt. Bleibt die dritte Gruppe, und für die lautet die ehrliche Antwort meist anders als erwartet: Nicht verwaltete Geräte und BYOD sollten die Root gar nicht erst brauchen — sie gehören ins Gastnetz, und dessen Verkehr gehört von der TLS-Inspection ausgenommen; ein manueller Zertifikatsimport auf Privatgeräten ist Support-Aufwand für ein Szenario, das man architektonisch sauberer löst.

Und dann sind da die drei Sonderfälle, die nach erfolgreicher Verteilung trotzdem meckern — die Skizze listet sie: Firefox führt traditionell einen eigenen Zertifikatsspeicher und übernimmt die Windows-Roots erst, wenn die Enterprise-Roots-Richtlinie gesetzt ist; Java-Anwendungen bringen eigene Keystores mit, in die die Root separat importiert werden muss (oder die Anwendung wandert in die Ausnahmen); und Apps mit Certificate Pinning akzeptieren prinzipiell keine fremde Kette — sie sind kein Verteilungs-, sondern ein Ausnahmen-Thema und gehören auf die Bypass-Liste der Inspection. Wer diese drei von Anfang an einplant, erspart sich die klassische Woche-eins-Ticketwelle nach der Inspection-Aktivierung.

Skizze 3: GPO für die Domäne, Intune für die Cloud-Flotte, Gastnetz statt Gebastel für BYOD — und die drei Sonderfälle, die eigene Antworten brauchen.

Laufzeiten, Erneuerung und Monitoring

Zertifikate sind Verbrauchsmaterial mit Verfallsdatum, und der Unterschied zwischen einem gepflegten und einem vergessenen Bestand zeigt sich exakt einmal — am Ablauftag. Die Laufzeiten-Empfehlungen stehen im Faktenkasten; für den Betrieb zählen drei Bausteine. Erstens das Inventar: eine simple Liste aller Firewall-Zertifikate mit Ablaufdatum, Verwendungszweck und Erneuerungsweg — vier Zeilen, die im Ernstfall Stunden sparen. Zweitens die Erinnerung mit Vorlauf, und zwar außerhalb der Firewall: Kalendereinträge oder das Monitoring-System (ein TLS-Check auf das Benutzerportal prüft Erreichbarkeit und Restlaufzeit in einem Rutsch) — die Erneuerungs-Checkliste in der Tabelle nennt die Vorlaufzeiten je Typ. Drittens die Sonderbehandlung der Sub-CA: Ihr Ablauf legt nicht ein Portal lahm, sondern die komplette Inspection — flächendeckende Zertifikatsfehler auf jedem Gerät, schlagartig; deshalb bekommt sie den längsten Vorlauf und einen geplanten Tauschtermin statt eines Erinnerungsdatums. Die Praxis-Geschichte erzählt, wie sich das anfühlt, wenn man es nicht tut.

FAQ — häufige Fragen zu ADCS-Zertifikaten auf der Sophos XGS

Wie bekomme ich ein ADCS-Zertifikat auf die Sophos XGS?

Über das CSR-Verfahren in vier Schritten, bei dem der private Schlüssel die Firewall nie verlässt: Erstens auf der XGS eine Zertifikatsignieranforderung erzeugen — mit dem FQDN der Firewall und, unbedingt, denselben Namen als SAN-Einträgen. Zweitens den CSR auf der ADCS gegen eine Webserver-Vorlage einreichen (Zertifizierungsstellen-Weboberfläche oder certreq) und das Zertifikat Base64-codiert abholen. Drittens auf der XGS das signierte Zertifikat zur wartenden Anforderung hochladen und die Kette vervollständigen — ausstellende Zwischen-CA und Root als CA-Zertifikate hinterlegen. Viertens zuweisen: in den Verwaltungseinstellungen für WebAdmin und Benutzerportal, beim VPN entsprechend, und den Erfolg per Browser-Kettenprüfung verifizieren. Die zwei Stolpersteine, die fast jede erste Ausstellung betreffen: fehlende SAN-Einträge (Browser ignorieren den CN vollständig) und die nicht mitgelieferte Zwischen-CA (Fehlerbild »geht bei mir, nicht bei ihm«). Ein Sonderfall ist die Inspection: Die braucht kein Server-, sondern ein Sub-CA-Zertifikat — eigener Weg, eigenes Kapitel.

Welches Zertifikat braucht die TLS-Inspection?

Ein CA-Zertifikat — also eines mit der Befugnis, selbst Zertifikate zu signieren —, denn die Inspection funktioniert als kontrollierter Mittelsmann: Die XGS prägt für jede inspizierte Seite on-the-fly ein eigenes Zertifikat, und das muss von einer CA stammen, der die Clients vertrauen. Ab Werk erledigt das eine selbstsignierte Appliance-CA, deren Zertifikat dann auf jedes Gerät verteilt werden muss. Der bessere Weg mit vorhandener ADCS: eine untergeordnete CA aus der eigenen Hierarchie — die ADCS stellt der Firewall ein Sub-CA-Zertifikat aus (Vorlage »Untergeordnete Zertifizierungsstelle«), das samt privatem Schlüssel als PKCS#12 importiert und als signierende CA der Entschlüsselung hinterlegt wird. Der Gewinn: Die geprägten Zertifikate hängen über die Sub-CA an der Unternehmens-Root, der die Domänengeräte ohnehin vertrauen — keine separate Verteilung, und der spätere Sub-CA-Tausch bleibt clientseitig lautlos. Was ausdrücklich nicht geht: dieses CA-Zertifikat von einer öffentlichen Zertifizierungsstelle zu beziehen — warum das niemand ausstellen darf und warum genau das richtig ist, erklärt der Faktenkasten im Artikel.

Warum akzeptiert der Browser das Portal-Zertifikat nicht?

Vier Verdächtige, in absteigender Häufigkeit. Erstens der SAN-Fehler: Das Zertifikat trägt den FQDN nur im Common Name — moderne Browser werten ausschließlich die alternativen Antragstellernamen aus, ein Zertifikat ohne SAN ist für sie namenlos; die Prüfung dauert zehn Sekunden in der Zertifikatsansicht. Zweitens die Namensabweichung: Aufgerufen wird die Firewall per IP-Adresse oder Kurzname, das Zertifikat lautet aber auf den FQDN — der Aufruf muss zum Zertifikatsnamen passen, also den FQDN verwenden (und intern sauber auflösen). Drittens die unvollständige Kette: Die Zwischen-CA fehlt auf der XGS, und Clients ohne gecachte Zwischenstelle können die Kette nicht bis zur Root schließen — erkennbar daran, dass es auf manchen Geräten geht und auf anderen nicht. Viertens das fehlende Root-Vertrauen: Das Gerät kennt die Unternehmens-Root nicht — typisch bei Nicht-Domänen-Geräten oder in der Firefox-Sonderwelt mit eigenem Zertifikatsspeicher. Die Diagnose-Reihenfolge: Zertifikat im Browser öffnen, SAN prüfen, Kette ansehen, Root im Gerätespeicher suchen — in dieser Reihenfolge ist der Täter in zwei Minuten gefunden.

Wie verteile ich die Root-CA an alle Geräte?

Nach Geräteklasse, und die häufigste Antwort ist die schönste: gar nicht nötig. Domänengeräte bekommen die Root einer AD-integrierten ADCS über die Verzeichnisinfrastruktur automatisch — und wo das nicht greift, erledigt es eine Gruppenrichtlinie, die das Root-Zertifikat in den Speicher der vertrauenswürdigen Stammzertifizierungsstellen legt. Cloud-verwaltete Geräte versorgt Intune: ein Konfigurationsprofil vom Typ »Vertrauenswürdiges Zertifikat« je Plattform — einmal angelegt, gilt es für die ganze Flotte inklusive reiner Entra-Geräte. Danach bleiben die Sonderfälle: Firefox übernimmt die Windows-Roots erst mit gesetzter Enterprise-Roots-Richtlinie, Java-Anwendungen brauchen den Import in ihre eigenen Keystores, und Apps mit Certificate Pinning lassen sich gar nicht überzeugen — sie gehören in die Inspection-Ausnahmen statt in die Verteilungsliste. Wichtig für die Hygiene: Verteilt wird ausschließlich das öffentliche Root-Zertifikat (und bei Bedarf die Zwischen-CA) — niemals irgendetwas mit privatem Schlüssel; die Verteilung des Vertrauens ist harmlos, die Verteilung von Schlüsseln wäre ein Vorfall.

Was ist bei Nicht-Domänen-Geräten zu tun?

Zuerst die Architekturfrage stellen, dann erst die Zertifikatsfrage — denn die beste Antwort lautet oft: Diese Geräte sollten die Root gar nicht brauchen. Private Geräte, Besucher-Notebooks und unverwaltete Fremdgeräte gehören ins Gastnetz, und dessen Verkehr gehört von der TLS-Inspection ausgenommen — dann entstehen dort nie geprägte Zertifikate, es gibt nichts zu vertrauen, und der Support spart sich das Zertifikats-Gebastel auf Geräten, über die er keine Kontrolle hat. Für firmeneigene, aber nicht domänengebundene Geräte ist die saubere Antwort die Verwaltung: Intune-Enrollment plus das Vertrauenszertifikat-Profil — damit sind Windows-, iOS- und Android-Geräte gleichermaßen versorgt. Bleibt der schmale Rest legitimer Sonderfälle (das Messgerät mit Browser, der Laborrechner): Dort funktioniert der manuelle Import des Root-Zertifikats in den jeweiligen Systemspeicher, dokumentiert in einer kurzen Anleitung je Plattform. Die Grenze bleibt technisch bestehen: Anwendungen mit Certificate Pinning und exotische Geräte ohne pflegbaren Zertifikatsspeicher landen in den Inspection-Ausnahmen — der ehrlichere Ort als eine Bastellösung, die beim nächsten Update zerbricht.

Wie überwache ich ablaufende Firewall-Zertifikate?

Mit drei Ebenen, von denen keine allein reicht. Ebene eins ist das Inventar: eine Liste aller Zertifikate der Firewall — Portale, VPN, Sub-CA, WAF-Zertifikate — mit Ablaufdatum, Zweck und Erneuerungsweg; ohne diese Liste ist jedes Monitoring blind für das, was es prüfen müsste. Ebene zwei ist die aktive Prüfung von außen: Das vorhandene Monitoring-System kann per TLS-Check auf Portal und VPN-Endpunkt zeigen, welches Zertifikat tatsächlich ausgeliefert wird und wie lange es noch gilt — das prüft nebenbei auch die Kette und erwischt Zuweisungsfehler, die eine reine Datumsliste übersieht. Ebene drei ist der Vorlauf mit Verbindlichkeit: Kalendereinträge mit den Fristen aus der Erneuerungs-Checkliste (30 bis 45 Tage für Server-Zertifikate, sechs Monate und ein fester Projekttermin für die Sub-CA), adressiert an eine Rolle statt an eine Person — Ablaufdaten überleben Personalwechsel, Postfächer nicht. Und die Sonderregel für das gefährlichste Datum: Der Ablauf der Inspection-Sub-CA ist kein Zertifikats-, sondern ein Verfügbarkeitsereignis — flächendeckende Browserfehler auf jedem Gerät, schlagartig. Wer nur ein einziges Datum überwacht, dann dieses.

Fazit: Eine PKI, die man hat, sollte man auch benutzen

Die Rechnung ist selten so eindeutig: Die ADCS steht in den meisten Microsoft-Umgebungen ohnehin — und für einen überschaubaren Nachmittag Arbeit verschwinden dafür sämtliche Zertifikatswarnungen aus dem Firewall-Alltag: Portale und VPN weisen sich per CSR-Verfahren ordentlich aus, die Inspection prägt unter einer Sub-CA, der jedes Domänengerät automatisch glaubt, und die Belegschaft lernt wieder das Richtige — nämlich dass rote Warnungen Ausnahmen sind, die man meldet, statt Alltag, den man wegklickt. Die Disziplin-Punkte sind benannt: SANs und vollständige Ketten beim CSR, Tresor-Behandlung für den Sub-CA-Schlüssel, Gastnetz statt Gebastel für Fremdgeräte, und ein Erneuerungsprozess mit Inventar, Monitoring und Vorlauf — allen voran für das eine Datum, dessen Verpassen einen ganzen Dienstagmorgen kostet. Der Rest ist Routine, und genau das soll Zertifikatsbetrieb sein: langweilig.

Von hier aus weiter im Cluster: Das Gesamtbild der XGS in Microsoft-Umgebungen zeichnet der Pillar-Artikel [LINK: Pillar]. Wie die PKI selbst sauber entsteht — zweistufige Hierarchie, Offline-Root, Vorlagen und Betrieb — vertieft der [LINK: PKI-Track]. Welcher Verkehr durch die Inspection läuft und welche Ausnahmen Pflicht sind, regelt [LINK: A7]. Und wie die Verwaltungszugänge der Firewall an Entra ID kommen, steht in [LINK: B1].