Verwaltung digitaler Zertifikate für die EAP-TLS WiFi-Authentifizierung

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und konversationellen Ton – wie ein Senior Consultant, der einen Kunden brieft. Gemessenes Tempo, klare Artikulation, herzlich, aber direkt. Gelegentliche natürliche Pausen zur Betonung: Willkommen bei der technischen Briefing-Reihe von Purple. Heute sprechen wir über das EAP-TLS-Zertifikatsmanagement – insbesondere darüber, wie Sie ein zertifikatsbasiertes WiFi-Authentifizierungsprogramm in großem Maßstab betreiben können, ohne dass es zu einer permanenten betrieblichen Belastung wird. [medium pause] Wenn Sie für das WiFi von Unternehmen oder Mitarbeitern an mehreren Standorten verantwortlich sind – sei es eine Hotelgruppe, ein Einzelhandelsunternehmen, ein Universitätsgcampus oder ein öffentlicher Sektor –, ist dieses Briefing genau das Richtige für Sie. Wir werden den gesamten Zertifikatslebenszyklus abdecken: von der Einrichtung Ihrer CA-Hierarchie über die automatisierte Bereitstellung via SCEP und MDM bis hin zur Erneuerung und dem Widerruf. Und wir werden darüber sprechen, wo Probleme auftreten – denn sie treten auf – und wie Sie die häufigsten Stolpersteine vermeiden. [medium pause] Beginnen wir mit den Grundlagen. EAP-TLS – das ist Extensible Authentication Protocol mit Transport Layer Security – ist der Goldstandard für die 802.1X-WiFi-Authentifizierung. Im Gegensatz zu PEAP, das auf Benutzername und Passwort basiert, nutzt EAP-TLS eine gegenseitige, zertifikatsbasierte Authentifizierung. Das Gerät weist seine Identität mit einem Client-Zertifikat nach. Der RADIUS-Server weist seine Identität mit einem Server-Zertifikat nach. Beide Seiten verifizieren die andere. Kein Passwort zum Phishen. Keine Zugangsdaten zum Stehlen. Deshalb weisen sowohl PCI DSS 4.0 als auch die Zero-Trust-Richtlinien des NCSC auf eine zertifikatsbasierte Authentifizierung für Mitarbeiternetzwerke hin. [medium pause] Nun zur Architektur. Sie benötigen drei Dinge, damit EAP-TLS funktioniert. Erstens eine Public-Key-Infrastruktur – Ihre CA-Hierarchie. Zweitens einen Mechanismus, um Zertifikate auf Geräte zu bringen – das ist SCEP oder Ihre MDM-Plattform. Drittens einen RADIUS-Server, der Ihrer CA vertraut und Client-Zertifikate in Echtzeit validieren kann. [medium pause] Bei der CA-Hierarchie geraten die meisten Unternehmen frühzeitig in Schwierigkeiten. Das richtige Muster ist ein dreistufiges Modell. Sie haben eine Root-CA an der Spitze – diese sollte offline und physisch vom Netz getrennt (air-gapped) sein und nur online geschaltet werden, um Ihr Intermediate-CA-Zertifikat zu signieren. Die Intermediate-CA – manchmal auch als Issuing-CA bezeichnet – ist diejenige, die die täglichen Zertifikate tatsächlich signiert. Sie ist online, aber ihr privater Schlüssel ist gut geschützt. Darunter stellen Sie zwei Arten von Zertifikaten aus: Server-Zertifikate für Ihre RADIUS-Infrastruktur und Client-Zertifikate für Ihre Geräte und Benutzer. [medium pause] Warum ist das wichtig? Denn wenn Ihre Root-CA kompromittiert wird, müssen Sie Ihre gesamte PKI von Grund auf neu aufbauen und jedes Gerät neu registrieren. Sie offline zu halten, eliminiert dieses Risiko. Die Intermediate-CA kann ausgetauscht werden, ohne die Root-CA zu berühren. Das ist das Argument der betrieblichen Resilienz für das dreistufige Modell. [medium pause] Sprechen wir über die Gültigkeitsdauer von Zertifikaten. Hier hat sich in der Branche ein bedeutender Wandel vollzogen. Apple, Google und Mozilla haben sich darauf geeinigt, kürzere maximale Zertifikatslaufzeiten durchzusetzen. Für TLS-Serverzertifikate beträgt das Maximum nun 398 Tage. Bei Client-Zertifikaten im Enterprise-WiFi haben Sie mehr Flexibilität – üblich sind ein bis zwei Jahre –, aber der Trend geht zu kürzeren Laufzeiten und automatisierter Verlängerung statt manuell verwalteter, langlebiger Zertifikate. Der Grund ist einfach: Eine kürzere Laufzeit begrenzt das Risiko im Falle einer Kompromittierung des Zertifikats. [medium pause] Dies bringt uns zur Automatisierung. Manuelle Zertifikatsverwaltung lässt sich nicht skalieren. Wenn Sie 500 Geräte haben, können Sie Verlängerungen gerade noch von Hand verwalten. Bei 5.000 Geräten an 50 Standorten ist das unmöglich. Sie benötigen SCEP – das Simple Certificate Enrolment Protocol – oder dessen modernen Nachfolger, EST. SCEP lässt sich direkt in MDM-Plattformen integrieren, darunter Microsoft Intune, Jamf Pro und VMware Workspace ONE. Das MDM überträgt ein SCEP-Konfigurationsprofil an das Gerät. Das Gerät generiert ein Schlüsselpaar, sendet eine Zertifikatsignierungsanfrage an Ihren SCEP-Server und erhält ein signiertes Zertifikat zurück – ganz ohne Benutzerinteraktion. [medium pause] Für Windows-Geräte in einer Active Directory-Umgebung gibt es eine Alternative: Die über Gruppenrichtlinien gesteuerte automatische Registrierung (Auto-Enrolment) über Active Directory-Zertifikatsdienste. Das Gerät authentifiziert sich an der Domäne, die Zertifizierungsstelle (CA) stellt automatisch ein Zertifikat aus, und das Zertifikat wird vor dem Ablauf ohne manuelles Eingreifen verlängert. Dies ist der nahtloseste Weg für primär auf Windows basierende Infrastrukturen. [medium pause] Nun zur Sperrung. Dies ist der Bereich, in den Unternehmen am seltensten investieren, und doch ist er der wichtigste, wenn etwas schiefgeht. Wenn ein Gerät verloren geht, gestohlen wird oder ein Mitarbeiter das Unternehmen verlässt, müssen Sie das entsprechende Zertifikat sofort sperren. Es gibt zwei Mechanismen: CRL – Certificate Revocation Lists – und OCSP – Online Certificate Status Protocol. [medium pause] CRL ist der ältere Mechanismen. Ihre CA veröffentlicht eine Liste gesperrter Zertifikatseriennummern unter einer bekannten URL. Der RADIUS-Server lädt diese Liste regelmäßig herunter und gleicht sie ab. Das Problem bei CRL ist die Latenz: Wenn Ihre CRL eine Gültigkeit von 24 Stunden hat, kann ein gesperrtes Zertifikat nach der Sperrung noch bis zu 24 Stunden lang authentifiziert werden. [medium pause] OCSP ist die Echtzeit-Alternative. Der RADIUS-Server sendet bei jedem Authentifizierungsversuch eine Abfrage an den OCSP-Responder und erhält eine direkte Antwort über den Status („gültig“ oder „gesperrt“). Der Nachteil ist, dass Ihr OCSP-Responder zu einer kritischen Abhängigkeit wird – wenn er nicht verfügbar ist, müssen Sie entscheiden, ob Sie die Authentifizierung standardmäßig zulassen (fail open) oder verweigern (fail closed). Für Hochsicherheitsumgebungen ist „fail closed“ die richtige Wahl. Für produktive Umgebungen, in denen die Verfügbarkeit im Vordergrund steht, können Sie eine kurze OCSP-Toleranzperiode konfigurieren. [medium pause] Lassen Sie mich Ihnen zwei konkrete Szenarien nennen, um dies zu verdeutlichen. [medium pause] Erstens: Eine Hotelgruppe mit 150 Standorten. Sie nutzten PEAP mit einem gemeinsamen Passwort für das Mitarbeiter-WiFi. Die Passwortrotation erfolgte vierteljährlich, was in jedem Quartal ein zweiwöchiges Zeitfenster bedeutete, in dem Mitarbeiter ausgesperrt waren oder das alte Passwort verwendeten. Sie wechselten zu EAP-TLS und nutzten Microsoft Intune für die Zertifikatsbereitstellung. SCEP-Profile wurden auf alle Windows- und iOS-Geräte übertragen. Active Directory Certificate Services fungierte als CA. Das Ergebnis: keine Passwortrotationen mehr, die Zertifikatsverlängerung wird 30 Tage vor Ablauf automatisch abgewickelt, und wenn ein Mitarbeiter das Unternehmen verlässt, wird sein Zertifikat innerhalb von Minuten nach Deaktivierung seines Kontos in Microsoft Entra ID im MDM widerrufen. Das IT-Team schätzte, dass es pro Quartal etwa 40 Stunden für Passwort-Resets und Helpdesk-Tickets einsparen konnte. [medium pause] Zweitens: Eine Einzelhandelskette mit mehreren Standorten und 3.000 Mitarbeitergeräten in 200 Filialen. Die Herausforderung war hier die Gerätevielfalt – ein Mix aus Windows-Laptops, Android-Handhelds und iOS-Geräten. Sie nutzten Jamf Pro für Apple-Geräte und Microsoft Intune für Windows und Android, wobei beide auf denselben SCEP-Server verwiesen, der durch eine Microsoft ADCS Intermediate CA unterstützt wurde. Die WiFi-Infrastruktur war Cisco Meraki, wobei die RADIUS-Authentifizierung über einen in der Cloud gehosteten, in Purple integrierten RADIUS-Dienst abgewickelt wurde. Die wichtigste Designentscheidung bestand darin, Zertifikate mit einer Gültigkeit von 12 Monaten auszustellen und die automatische Verlängerung auf 60 Tage vor Ablauf zu konfigurieren. Dies ermöglichte ein komfortables Verlängerungsfenster ohne betrieblichen Mehraufwand. [medium pause] Nun zu den Fallstricken. Es gibt vier, die ich immer wieder sehe. [medium pause] Erstens: Das Testen des Widerrufs wird vernachlässigt. Organisationen richten ihre PKI ein, stellen Zertifikate bereit und testen nie wirklich, ob der Widerruf durchgängig funktioniert. Testen Sie es. Widerrufen Sie ein Testzertifikat, bestätigen Sie, dass der RADIUS-Server den Widerruf innerhalb Ihres erwarteten Zeitfensters erkennt, und stellen Sie sicher, dass dem Gerät der Zugriff verweigert wird. [medium pause] Zweitens: Klippen beim Zertifikatsablauf. Wenn Sie alle Zertifikate gleichzeitig mit derselben Gültigkeitsdauer ausstellen, laufen sie auch alle zur gleichen Zeit ab. Staffeln Sie Ihre Ausstellung oder zumindest Ihre Verlängerungs-Trigger. Eine Ausfallrate bei der Verlängerung von 10 % bei 5.000 Geräten gleichzeitig ist ein schwerwiegender Vorfall. [medium pause] Drittens: Das Root-CA-Zertifikat wird vor der Bereitstellung von EAP-TLS nicht auf allen Geräten verteilt. Wenn das Gerät Ihrer Root-CA nicht vertraut, lehnt es das Zertifikat des RADIUS-Servers ab, und die Authentifizierung schlägt fehl. Das klingt offensichtlich, wird aber von Organisationen oft übersehen, wenn sie BYOD-Geräte oder Laptops von Subunternehmern haben, die nicht im MDM registriert sind. [medium pause] Viertens: Verfügbarkeit des OCSP-Responders. Wenn Ihr OCSP-Responder ausfällt und Ihr RADIUS-Server so konfiguriert ist, dass er bei OCSP-Fehlern den Zugriff standardmäßig sperrt (Fail Closed), funktioniert Ihre gesamte WiFi-Infrastruktur nicht mehr. Sorgen Sie für Redundanz in Ihrer OCSP-Infrastruktur oder konfigurieren Sie eine kurze Übergangsfrist mit entsprechendem Monitoring. [medium pause] Gut, nun zu den schnellen Fragerunden. [medium pause] Kann ich eine öffentliche CA für EAP-TLS-Client-Zertifikate verwenden? Technisch gesehen ja, aber in der Praxis nein. Öffentliche CAs stellen keine Client-Zertifikate für beliebige Geräte aus. Sie benötigen Ihre eigene CA für Client-Zertifikate. Für das RADIUS-Server-Zertifikat ist eine öffentliche CA in Ordnung und vereinfacht die Vertrauensverteilung. [medium pause] Was ist mit BYOD? BYOD ist der schwierige Fall. Sie können Zertifikate nicht über MDM auf unmanaged Geräte pushen. Zu den Optionen gehören ein Network Access Control Portal, das nach der Benutzerauthentifizierung kurzlebige Zertifikate ausstellt, oder einfach die Beibehaltung von BYOD auf einer separaten SSID mit einer anderen Authentifizierungsmethode. [medium pause] Wie verhält sich das im Zusammenspiel mit WPA3? WPA3-Enterprise schreibt für sensible Umgebungen einen 192-Bit-Sicherheitsmodus vor, der spezifische Cipher Suites erfordert. EAP-TLS ist vollständig kompatibel mit WPA3-Enterprise und ist tatsächlich die empfohlene Authentifizierungsmethode. [medium pause] Zusammenfassend lässt sich sagen: Das EAP-TLS-Zertifikatsmanagement ist nicht einfach, aber es ist machbar, wenn Sie die Architektur von Anfang an richtig aufbauen. Eine dreistufige CA-Hierarchie. Automatische Registrierung über SCEP oder MDM. Kurze Zertifikatslaufzeiten mit automatischer Verlängerung. Echtzeit-Sperrung via OCSP. Testen Sie alles, insbesondere die Sperrung. Und integrieren Sie den Lebenszyklus Ihrer Zertifikate in Ihren Identity Provider – Microsoft Entra ID, Okta oder Google Workspace –, sodass die Zertifikatssperrung automatisch ausgelöst wird, wenn ein Konto deprovisioniert wird. [medium pause] Wenn Sie mit Purple verknüpfte RADIUS-Server betreiben, sind die Integrationspunkte Ihre SCEP-Server-URL, Ihr RADIUS-Server-Zertifikat und Ihr CRL- oder OCSP-Endpunkt. Die hardwareunabhängige Architektur von Purple sorgt dafür, dass dies über Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und den Rest der kanonischen Hardware-Liste hinweg funktioniert – Sie sind nicht an die PKI-Tools eines einzelnen Herstellers gebunden. [medium pause] Nächste Schritte: Überprüfen Sie Ihren aktuellen Zertifikatsbestand. Wenn Sie nicht wissen, wie viele Zertifikate Sie haben, wann sie ablaufen und wer sie ausgestellt hat, ist das der erste Schritt zur Besserung. Von dort aus ist der Weg zur vollständigen Automatisierung klar definiert. Vielen Dank fürs Zuhören.