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

Sprechen Sie in britischem Englisch mit einem selbstbewussten, autoritären und konversationsorientierten Ton - wie ein Senior Consultant, der einen Kunden brieft. Gemessenes Tempo, klare Aussprache, herzlich, aber direkt. Gelegentliche natürliche Pausen zur Betonung: Willkommen zur Purple technischen Briefing-Serie. Heute sprechen wir über EAP-TLS Zertifikatsmanagement - genauer gesagt darüber, wie man ein zertifikatsbasiertes WiFi Authentifizierungsprogramm in großem Maßstab betreibt, ohne dass es zu einer operativen Vollzeitbelastung wird. [mittlere 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 öffentliche Einrichtung - ist dieses Briefing genau das Richtige für Sie. Wir werden den gesamten Lebenszyklus von Zertifikaten behandeln: 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, denn sie gehen schief, und wie man die häufigsten Fallen vermeidet. [mittlere 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 Benutzername und Passwort basiert, nutzt EAP-TLS eine gegenseitige, auf Zertifikaten basierende 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 Gegenseite. Kein Passwort, das per Phishing gestohlen werden kann. Keine Anmeldedaten, die entwendet werden können. Aus diesem Grund verweisen sowohl PCI-DSS 4.0 als auch die Zero-Trust-Richtlinien des NCSC auf die zertifikatsbasierte Authentifizierung für Mitarbeiternetzwerke. [mittlere 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. [mittlere Pause] Bei der CA-Hierarchie geraten die meisten Organisationen schon früh in Schwierigkeiten. Das richtige Muster ist ein dreistufiges Modell. Sie haben eine Root-CA an der Spitze - diese sollte offline sein, durch ein Air Gap geschützt und nur online gebracht 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. [mittlere 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 anzurühren. Das ist das Argument der betrieblichen Resilienz für das dreistufige Modell. [mittlere 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 alle darauf geeinigt, kürzere maximale Zertifikatslaufzeiten durchzusetzen. Für TLS-Serverzertifikate liegt das Maximum nun bei 398 Tagen. Für Client-Zertifikate in enterprise WiFi haben Sie mehr Flexibilität - üblich sind ein bis zwei Jahre - aber der Trend geht klar zu kürzeren Laufzeiten und automatischer Erneuerung statt zu manuell verwalteten Zertifikaten mit langer Lebensdauer. Der Grund dafür ist einfach: Eine kürzere Lebensdauer begrenzt das Risiko einer Kompromittierung zeitlich. [medium pause] Dies bringt uns zum Thema Automatisierung. Eine manuelle Zertifikatsverwaltung ist nicht skalierbar. Wenn Sie 500 Geräte haben, können Sie Verlängerungen gerade noch so 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 sendet ein SCEP-Konfigurationsprofil an das Gerät. Das Gerät generiert ein Schlüsselpaar, sendet eine Zertifikatssignierungsanfrage 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 die Active Directory-Zertifikatsdienste. Das Gerät authentifiziert sich an der Domäne, die Zertifizierungsstelle stellt automatisch ein Zertifikat aus, und das Zertifikat wird vor dem Ablaufdatum ohne manuelles Eingreifen erneuert. Dies ist der nahtloseste Weg für primär auf Windows basierende Infrastrukturen. [medium pause] Nun zum Widerruf. Dies ist der Bereich, in den Unternehmen am seltensten investieren, und es ist der wichtigste Teil, 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. Hierfür gibt es zwei Mechanismen: CRL - Certificate Revocation Lists - und OCSP - Online Certificate Status Protocol. [medium pause] CRL ist der ältere Mechanismus. Ihre Zertifizierungsstelle 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 ein widerrufenes Zertifikat noch bis zu 24 Stunden nach dem Widerruf 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 sofortige 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 einen offenen Zugang zulassen oder den Zugriff sperren. Für Hochsicherheitsumgebungen ist die Sperrung des Zugriffs die richtige Antwort. Für Betriebsumgebungen, in denen es auf Verfügbarkeit ankommt, können Sie eine kurze OCSP-Toleranzperiode konfigurieren. [medium pause] Lassen Sie mich Ihnen zwei konkrete Szenarien aufzeigen, um dies zu verdeutlichen. [medium pause] Erstens: Eine Hotelgruppe mit 150 Standorten. Diese nutzte PEAP mit einem gemeinsam genutzten Passwort für das Mitarbeiter-WiFi. Die Passwortänderung erfolgte vierteljährlich, was bedeutete, dass jedes Quartal ein Zeitfenster von zwei Wochen entstand, in dem Mitarbeiter ausgesperrt waren oder das alte Passwort nutzten. Sie wechselten zu EAP-TLS und nutzten Microsoft Intune für die Bereitstellung von Zertifikaten. SCEP-Profile wurden auf alle Windows - und iOS-Geräte übertragen. Active Directory Certificate Services fungierte als CA. Das Ergebnis: keine Passwortänderungen mehr, die Zertifikatsverlängerung wird 30 Tage vor Ablauf automatisch abgewickelt, und wenn ein Mitarbeiter das Unternehmen verlässt, wird sein Zertifikat im MDM innerhalb von Minuten nach Deaktivierung seines Kontos in Microsoft Entra ID 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 Geschäften. Die Herausforderung hier war die Gerätevielfalt - eine Mischung 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 bestand aus Cisco Meraki, wobei die RADIUS-Authentifizierung über einen in der Cloud gehosteten RADIUS-Dienst in Kombination mit Purple abgewickelt wurde. Die wichtigste Design-Entscheidung war die Ausstellung von Zertifikaten mit einer Gültigkeit von 12 Monaten und die Einrichtung einer automatischen Verlängerung 60 Tage vor Ablauf. Dies bot ein komfortables Verlängerungsfenster ohne zusätzlichen operativen Aufwand. [medium pause] Nun zu den Fallstricken. Es gibt vier, die ich immer wieder beobachte. [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 des erwarteten Zeitfensters erkennt, und prüfen Sie, ob dem Gerät der Zugriff verweigert wird. [medium pause] Zweitens: Massenhafter Ablauf von Zertifikaten. Wenn Sie alle Zertifikate gleichzeitig mit derselben Gültigkeitsdauer ausstellen, laufen sie auch alle zur gleichen Zeit ab. Staffeln Sie die Ausstellung oder zumindest die Auslöser für die Verlängerung. Eine Fehlerrate 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 an alle Geräte 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 externen Dienstleistern im Einsatz 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 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] Nun zu den Fragen in aller Kürze. [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 eine 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 übertragen. Zu den Optionen gehören ein Netzwerkzugriffssteuerungs-Portal, das nach der Benutzerauthentifizierung kurzlebige Zertifikate ausstellt, oder die einfache Bereitstellung von BYOD auf einer separaten SSID mit einer anderen Authentifizierungsmethode. [medium pause] Wie verhält sich dies mit WPA3? WPA3-Enterprise schreibt für sensible Umgebungen einen 192-Bit-Sicherheitsmodus vor, der bestimmte Cipher Suites erfordert. EAP-TLS ist vollständig kompatibel mit WPA3-Enterprise und wird tatsächlich als Authentifizierungsmethode empfohlen. [medium pause] Zusammenfassend lässt sich sagen: Die Verwaltung von EAP-TLS-Zertifikaten ist nicht einfach, aber sie ist machbar, wenn die Architektur von Anfang an stimmt. Eine dreistufige CA-Hierarchie. Automatische Registrierung über SCEP oder MDM. Kurze Zertifikatslaufzeiten mit automatischer Erneuerung. Echtzeit-Widerruf über OCSP. Testen Sie alles, insbesondere den Widerruf. Und integrieren Sie den Lebenszyklus Ihrer Zertifikate in Ihren Identitätsanbieter - 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 verknüpfte RADIUS-Server betreiben, sind die Integrationspunkte Ihre SCEP-Server-URL, Ihr RADIUS-Server-Zertifikat und Ihr CRL- oder OCSP-Endpunkt. Die herstellerunabhängige Architektur von Purple sorgt dafür, dass dies über Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist und den Rest der bekannten Hardware-Liste hinweg funktioniert - Sie sind nicht an die PKI-Tools eines einzelnen Anbieters 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 Punkt, den es zu beheben gilt. Von dort aus ist der Weg zur vollständigen Automatisierung klar definiert. Vielen Dank fürs Zuhören.