Verwalten von digitalen Zertifikaten für die EAP-TLS WiFi Authentifizierung

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und konversationsorientierten Ton - wie ein leitender Berater, der einen Kunden brieft. Gemessenes Tempo, klare Aussprache, herzlich, aber direkt. Gelegentliche natürliche Pausen zur Betonung: Willkommen zur technischen Briefing-Reihe von Purple. Heute sprechen wir über das EAP-TLS-Zertifikatsmanagement - insbesondere darüber, wie man ein zertifikatsbasiertes WiFi-Authentifizierungsprogramm in großem Maßstab betreibt, ohne dass es zu einer permanenten operativen 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ätscampus oder eine Liegenschaft des öffentlichen Sektors - ist dieses Briefing genau das Richtige für Sie. Wir werden den gesamten Lebenszyklus von Zertifikaten 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 Dinge schiefgehen können, denn sie gehen schief, und wie man die häufigsten Fallen vermeidet. [medium pause] Beginnen wir mit den Grundlagen. EAP-TLS - das steht für Extensible Authentication Protocol mit Transport Layer Security - ist der Goldstandard für die 802.1X WiFi-Authentifizierung. Im Gegensatz zu PEAP, das auf einem Benutzernamen und einem 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, das per Phishing gestohlen werden kann. Keine Zugangsdaten zum Entwenden. Aus diesem Grund verweisen sowohl PCI-DSS 4.0 als auch die Zero-Trust-Richtlinien des NCSC auf die zertifikatsbasierte Authentifizierung für Mitarbeiternetzwerke. [medium pause] Nun zur Architektur. Sie benötigen drei Dinge, damit EAP-TLS funktioniert. Erstens eine Public Key Infrastructure - Ihre CA-Hierarchie. Zweitens einen Mechanismus, um Zertifikate auf Geräte zu übertragen - das ist SCEP oder Ihre MDM-Plattform. Drittens einen RADIUS-Server, der Ihrer CA vertraut und Client-Zertifikate in Echtzeit validieren kann. [medium pause] Die CA-Hierarchie ist der Bereich, in dem die meisten Unternehmen frühzeitig in Schwierigkeiten geraten. Das richtige Muster ist ein dreistufiges Modell. Sie haben eine Root CA an der Spitze - diese sollte offline und physisch isoliert sein und nur online geschaltet werden, um das Zertifikat Ihrer Intermediate CA zu signieren. Die Intermediate CA - manchmal auch als Issuing CA bezeichnet - ist diejenige, die die alltä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? Weil Sie, wenn Ihre Root CA kompromittiert wird, Ihre gesamte PKI von Grund auf neu aufbauen und jedes einzelne Gerät neu registrieren müssen. 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 Ausfallsicherheit für das dreistufige Modell. [medium pause]Sprechen wir über die Gültigkeitsdauer von Zertifikaten. Hier gab es einen bedeutenden Wandel in der Branche. Apple, Google und Mozilla haben sich alle darauf geeinigt, kürzere maximale Zertifikatslaufzeiten durchzusetzen. Für TLS Server-Zertifikate beträgt das Maximum nun 398 Tage. Für Client-Zertifikate im Enterprise WiFi haben Sie mehr Flexibilität - ein bis zwei Jahre sind üblich - aber der Trend geht zu kürzeren Laufzeiten und automatisierter Verlängerung anstelle von manuell verwalteten, langlebigen Zertifikaten. Der Grund ist einfach: Eine kürzere Laufzeit begrenzt das Zeitfenster für Missbrauch, falls ein Zertifikat kompromittiert wird. [medium pause] Dies bringt uns zur Automatisierung. Manuelle Zertifikatsverwaltung ist nicht skalierbar. Bei 500 Geräten können Sie die Verlängerungen gerade noch manuell 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 wie Microsoft Intune, Jamf Pro und VMware Workspace ONE integrieren. Das MDM überträgt ein SCEP-Konfigurationsprofil auf das Gerät. Das Gerät generiert ein Schlüsselpaar, sendet eine Zertifikatssignierungsanforderung an Ihren SCEP-Server und erhält ein signiertes Zertifikat zurück - und das alles ohne jegliche Benutzerinteraktion. [medium pause] Für Windows-Geräte in einer Active Directory-Umgebung haben Sie eine Alternative: die durch Gruppenrichtlinien gesteuerte automatische Registrierung über Active Directory Certificate Services. Das Gerät authentifiziert sich an der Domäne, die 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 stark von Windows geprägte Infrastrukturen. [medium pause] Nun zum Widerruf. Dies ist der Bereich, in den Unternehmen am seltensten investieren, und es ist der Bereich, auf den es am meisten ankommt, wenn etwas schiefgeht. Wenn ein Gerät verloren geht, gestohlen wird oder ein Mitarbeiter das Unternehmen verlässt, müssen Sie dessen Zertifikat sofort widerrufen. Es gibt zwei Mechanismen: CRL - Certificate Revocation Lists - und OCSP - Online Certificate Status Protocol. [medium pause] CRL ist der ältere Mechanismus. Ihre CA veröffentlicht eine Liste widerrufener Zertifikatsseriennummern 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ültigkeitsdauer von 24 Stunden hat, kann sich ein widerrufenes Zertifikat nach dem Widerruf noch bis zu 24 Stunden lang authentifizieren. [medium pause] OCSP ist die Echtzeit-Alternative. Der RADIUS-Server sendet bei jedem Authentifizierungsversuch eine Abfrage an den OCSP-Responder und erhält eine Live-Rückmeldung über die Gültigkeit oder den Widerruf. 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 zulassen (Fail Open) oder blockieren (Fail Closed). Für Hochsicherheitsumgebungen ist Fail Closed die richtige Antwort. Für betriebliche Umgebungen, in denen die Verfügbarkeit im Vordergrund steht, können Sie eine kurze OCSP-Toleranzzeit konfigurieren. [medium pause] Lassen Sie mich Ihnen zwei konkrete Szenarien nennen, um dies zu veranschaulichen. [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 bedeutete, dass Mitarbeiter zwei Wochen lang ausgesperrt waren oder das alte Passwort nutzten. 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 diente als Zertifizierungsstelle (CA). Das Ergebnis: keine Passwortrotationen mehr, die Zertifikatserneuerung erfolgt automatisch 30 Tage vor Ablauf, 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 die Ersparnis auf etwa 40 Stunden pro Quartal für Passwortrücksetzungen und Helpdesk-Tickets. [medium pause] Zweitens: eine Einzelhandelskette mit mehreren Standorten und 3.000 Mitarbeitergeräten in 200 Filialen. Die Herausforderung hier war die Gerätevielfalt - eine Mischung aus Windows-Laptops, Android-Handgeräten 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 von einem in der Cloud gehosteten RADIUS-Dienst verarbeitet wurde, der in Purple integriert war. Die entscheidende Designentscheidung war, Zertifikate mit einer Gültigkeit von 12 Monaten auszustellen und eine automatische Erneuerung 60 Tage vor Ablauf zu konfigurieren. Dies ermöglichte ein komfortables Erneuerungsfenster ohne zusätzlichen Betriebsaufwand. [medium pause] Nun zu den Fallstricken. Es gibt vier, die ich immer wieder sehe. [medium pause] Erstens: Der Widerruf wird nicht getestet. 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 erfasst, und stellen Sie sicher, dass dem Gerät der Zugriff verweigert wird. [medium pause] Zweitens: Klippen beim Ablaufdatum. Wenn Sie alle Zertifikate gleichzeitig mit derselben Gültigkeitsdauer ausstellen, laufen sie auch alle gleichzeitig ab. Staffeln Sie Ihre Ausstellung oder zumindest Ihre Erneuerungs-Trigger. Eine Fehlerrate bei der Erneuerung von 10 % bei 5.000 Geräten gleichzeitig ist ein schwerwiegender Vorfall. [medium pause] Drittens: Das Root-CA-Zertifikat wird nicht vor der Bereitstellung von EAP-TLS 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 Auftragnehmern 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 blockiert, funktioniert Ihr gesamtes WiFi-Netzwerk nicht mehr. Bauen Sie Redundanz in Ihre OCSP-Infrastruktur ein oder konfigurieren Sie eine kurze Übergangsfrist mit entsprechendem Monitoring. [medium pause] Und nun zu den Fragen in Schnelldurchlauf. [medium pause] Kann ich eine öffentliche Zertifizierungsstelle (CA) für EAP-TLS-Client-Zertifikate verwenden? Technisch gesehen ja, in der Praxis jedoch 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 völlig in Ordnung und vereinfacht die Vertrauensverteilung. [medium pause] Wie sieht es mit BYOD aus? BYOD ist der schwierige Fall. Sie können Zertifikate nicht über ein MDM auf nicht verwaltete Geräte pushen. Zu den Optionen gehören ein Netzwerkzugriffskontrollportal, das nach der Benutzerauthentifizierung kurzlebige Zertifikate ausstellt, oder die einfache Beibehaltung von BYOD auf einer separaten SSID mit einer anderen Authentifizierungsmethode. [medium pause] Wie verhält sich das mit WPA3? WPA3-Enterprise schreibt für sensible Umgebungen den 192-Bit-Sicherheitsmodus vor, der bestimmte 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 bewältigbar, wenn die Architektur von Anfang an stimmt. Dreistufige CA-Hierarchie. Automatische Registrierung über SCEP oder MDM. Kurze Zertifikatslebensdauern mit automatischer Verlängerung. Echtzeit-Widerruf über OCSP. Testen Sie alles, insbesondere den Widerruf. Und integrieren Sie den Lebenszyklus Ihrer Zertifikate in Ihren Identity Provider - Microsoft Entra ID, Okta oder Google Workspace - damit der Zertifikatswiderruf automatisch ausgelöst wird, wenn ein Konto deaktiviert wird. [medium pause] Wenn Sie mit Purple verbundene 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 bedeutet, dass dies mit Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und dem Rest der standardmäßigen Hardwareliste 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 das Erste, was Sie beheben müssen. Von dort aus ist der Weg zur vollständigen Automatisierung klar definiert. Vielen Dank fürs Zuhören.