How to Set Up Enterprise WiFi on Android Devices with EAP-TLS

So richten Sie Enterprise-WiFi auf Android-Geräten mit EAP-TLS ein Ein technisches Briefing von Purple — ca. 10 Minuten --- EINFÜHRUNG UND KONTEXT — ca. 1 Minute Willkommen zur technischen Briefing-Reihe von Purple. Ich bin Ihr Gastgeber, und heute befassen wir sich mit den Besonderheiten der Bereitstellung von 802.1X EAP-TLS-Authentifizierung auf Android-Geräten — egal, ob Sie ein Hotelgelände, eine Einzelhandelskette, ein Stadion oder einen Campus im öffentlichen Sektor verwalten. Wenn Sie für ein Netzwerk verantwortlich sind, das geschäftliche oder BYOD-Android-Geräte authentifizieren muss, ohne sich auf gemeinsam genutzte Passwörter zu verlassen, ist diese Episode genau das Richtige für Sie. EAP-TLS ist der Goldstandard für die Sicherheit von Enterprise-WiFi — es nutzt eine gegenseitige, zertifikatsbasierte Authentifizierung. Das bedeutet: keine Zugangsdaten, die per Phishing gestohlen werden können, keine Passwörter, die regelmäßig geändert werden müssen, und ein Compliance-Status, der PCI DSS, ISO 27001 und die meisten Sicherheitsrichtlinien des öffentlichen Sektors erfüllt. Am Ende dieses Briefings werden Sie genau verstehen, wie EAP-TLS auf Android funktioniert, welche Bereitstellungsoptionen Sie haben und welches die drei häufigsten Fehler sind, die zu fehlerhaften Rollouts führen. Legen wir los. --- TECHNISCHER DEEP-DIVE — ca. 5 Minuten Beginnen wir mit der Architektur. 802.1X ist der IEEE-Standard, der die portbasierte Netzwerkzugriffskontrolle regelt. Wenn sich ein Android-Gerät mit einem Enterprise-WiFi-Netzwerk verbindet — also einem Netzwerk, das als WPA2-Enterprise oder WPA3-Enterprise konfiguriert ist —, fungiert der Access Point als sogenannter Authentifikator. Er trifft die Authentifizierungsentscheidung nicht selbst, sondern leitet die Kommunikation zwischen dem Gerät und einem RADIUS-Server weiter, der der eigentliche Authentifizierungsserver ist. EAP-TLS — also Extensible Authentication Protocol mit Transport Layer Security — ist die Authentifizierungsmethode, die innerhalb dieses 802.1X-Frameworks ausgeführt wird. Der Unterschied zu EAP-PEAP oder EAP-TTLS, bei denen Benutzername und Passwort innerhalb eines TLS-Tunnels verwendet werden, besteht darin, dass EAP-TLS auf beiden Seiten X.509-Zertifikate nutzt. Der RADIUS-Server legt dem Gerät ein Serverzertifikat vor, und das Gerät sendet ein Clientzertifikat an den RADIUS-Server zurück. Beide Parteien validieren sich gegenseitig. Das ist eine gegenseitige Authentifizierung, und genau das macht EAP-TLS zur sichersten verfügbaren Option. Speziell bei Android müssen Sie einige Dinge beachten. Mit Android 11 und neueren Versionen wurden strengere Anforderungen an die Zertifikatsvalidierung eingeführt. Wenn Sie die Bereitstellung auf Android 11 oder höher durchführen — was zum jetzigen Zeitpunkt den Großteil Ihrer Geräte betrifft —, verweigert das Gerät die Verbindung, es sei denn, dem RADIUS-Serverzertifikat wird explizit vertraut. Sie können sich nicht allein auf den Vertrauensspeicher des Systems verlassen. Sie müssen entweder das Root-CA-Zertifikat auf das Gerät übertragen oder das WiFi-Profil so konfigurieren, dass es explizit darauf verweist. Sprechen wir über die Zertifikatskette. Sie benötigen drei Komponenten, bevor sich ein einziges Android-Gerät über EAP-TLS authentifizieren kann. Erstens eine Zertifizierungsstelle (Certificate Authority, CA) – entweder Ihre interne PKI, Microsoft Active Directory Certificate Services oder eine Cloud-PKI wie SCEP über Intune. Zweitens ein Serverzertifikat, das für Ihren RADIUS-Server ausgestellt und von dieser CA signiert wurde. Drittens ein eindeutiges Client-Zertifikat, das für jedes Gerät oder jeden Benutzer ausgestellt und ebenfalls von derselben CA signiert wurde. Das Gerät legt sein Client-Zertifikat während des TLS-Handshakes vor, und der RADIUS-Server validiert es anhand der Zertifikatssperrliste (CRL) der CA oder über OCSP – Online Certificate Status Protocol. Unter Android werden das Client-Zertifikat und der private Schlüssel normalerweise als PKCS12-Datei verpackt – das ist eine .P12- oder .PFX-Datei –, die sowohl das Zertifikat als auch den verschlüsselten privaten Schlüssel enthält. Auf einem manuell konfigurierten Gerät importiert der Benutzer diese Datei über die Einstellungen, dann Sicherheit und schließlich Zertifikat installieren. Auf einem per MDM verwalteten Gerät wird das Zertifikat im Hintergrund in den verwalteten Keystore des Geräts übertragen – es ist keine Benutzerinteraktion erforderlich. Sprechen wir nun über das WiFi-Profil selbst. Wenn Sie eine Enterprise-WiFi-Verbindung auf Android konfigurieren, müssen Sie Folgendes angeben: die SSID, den Sicherheitstyp – WPA2-Enterprise oder WPA3-Enterprise –, die EAP-Methode – also TLS –, das CA-Zertifikat für die Servervalidierung, das Client-Zertifikat für die Geräteauthentifizierung und den Identitäts-String, bei dem es sich in der Regel um den Common Name des Geräts oder den UPN des Benutzers handelt. Ab Android 11 müssen Sie außerdem den Domain-Suffix-Abgleich oder den Betreff des Serverzertifikats angeben, um Man-in-the-Middle-Angriffe zu verhindern. Bei MDM-Bereitstellungen – und hier kommt die tatsächliche Skalierbarkeit ins Spiel – übertragen Sie all dies als strukturiertes Konfigurationsprofil. In Microsoft Intune erstellen Sie ein SCEP-Zertifikatsprofil, das automatisch ein eindeutiges Client-Zertifikat auf jedem registrierten Android-Gerät anfordert und installiert. Anschließend erstellen Sie ein WiFi-Konfigurationsprofil, das auf dieses Zertifikatsprofil verweist. Wenn sich das Gerät anmeldet, empfängt es sowohl das Zertifikat als auch das WiFi-Profil und verbindet sich automatisch mit Ihrem 802.1X-Netzwerk. Keine Benutzerinteraktion, keine Support-Anrufe. Wenn Sie Intune dafür nutzen, führt Sie unser begleitender Leitfaden zur Verwendung von Microsoft Intune zur Übertragung von WiFi-Zertifikaten auf Geräte durch die genauen Konfigurationsschritte – ich empfehle, diesen parallel zu diesem Briefing zu lesen. Bei VMware Workspace ONE und Jamf Connect ist der Prozess architektonisch identisch – SCEP- oder PKCS-Zertifikatsprofil, gefolgt von einem WiFi-Profil, das darauf verweist. Die spezifische Benutzeroberfläche unterscheidet sich, aber die Anforderungen an die Zertifikatskette und die RADIUS-Konfiguration sind dieselben. Ein wichtiger Hinweis auf der RADIUS-Seite: Wenn Sie FreeRADIUS, Microsoft NPS oder Cisco ISE verwenden, stellen Sie sicher, dass Ihr Serverzertifikat die korrekten Attribute für die erweiterte Schlüsselverwendung (Extended Key Usage, EKU) enthält – insbesondere Serverauthentifizierung, OID 1.3.6.1.5.5.7.3.1. Android ist hier sehr streng. Ein Zertifikat, das mit Windows-Clients einwandfrei funktioniert, kann auf Android fehlschlagen, wenn die EKU fehlt oder falsch konfiguriert ist. --- IMPLEMENTIERUNGSEMPFEHLUNGEN UND STOLPERSTEINE — ca. 2 Minuten Lassen Sie uns darüber sprechen, was in der Praxis tatsächlich schiefgeht, denn hier treten bei den meisten Bereitstellungen die Probleme auf. Der erste und häufigste Fehler ist das Vertrauen in Zertifikate. Android 11 und höher stellen keine Verbindung her, wenn die Zertifikatskette des RADIUS-Servers nicht validiert werden kann. Die Lösung ist einfach: Verteilen Sie Ihr Root-CA-Zertifikat über das MDM in den Zertifikatsspeicher des Benutzers auf dem Gerät und verweisen Sie im CA-Zertifikatsfeld des WiFi-Profils explizit darauf. Belassen Sie dies nicht auf "Nicht validieren" – das ist eine Sicherheitslücke und wird auf einigen Android-Versionen ohnehin fehlschlagen. Der zweite Stolperstein ist der Ablauf von Zertifikaten. Client-Zertifikate haben in der Regel eine Gültigkeitsdauer von ein bis zwei Jahren. Wenn Sie keine automatische Verlängerung über SCEP oder NDES eingerichtet haben, werden Sie eines Morgens aufwachen und feststellen, dass die Hälfte Ihres Gerätebestands gleichzeitig den WiFi-Zugriff verloren hat. Integrieren Sie die Automatisierung der Zertifikatsverlängerung vom ersten Tag an in Ihren MDM-Workflow, nicht erst im Nachhinein. Das dritte Problem ist die Kapazität des RADIUS-Servers. EAP-TLS-Handshakes sind aufgrund des vollständigen gegenseitigen Zertifikatsaustauschs rechenintensiver als PEAP-Handshakes. In einem Stadion oder Konferenzzentrum mit Tausenden von gleichzeitigen Authentifizierungen wird ein unterdimensionierter RADIUS-Server zum Nadelöhr. Dimensionieren Sie Ihre RADIUS-Infrastruktur für Spitzenzeiten bei gleichzeitigen Authentifizierungen, nicht für die durchschnittliche Last. Schließlich sollten Sie auf der Android-Seite beachten, dass verschiedene Hersteller – Samsung, Google, Xiaomi – die WiFi-Konfigurations-API leicht unterschiedlich implementieren. Testen Sie Ihre per MDM verteilten Profile auf repräsentativen Geräten der einzelnen Hersteller in Ihrem Bestand, bevor Sie sie flächendeckend einführen. Insbesondere bei Samsung-Geräten musste in der Vergangenheit das Identitätsfeld explizit festgelegt werden, selbst wenn es aus dem Zertifikat abgeleitet werden konnte. --- SCHNELLE FRAGEN UND ANTWORTEN — ca. 1 Minute Ein paar kurze Fragen, die mir regelmäßig gestellt werden. Kann ich EAP-TLS für BYOD-Geräte verwenden? Ja, aber dazu muss der Benutzer ein Client-Zertifikat auf seinem persönlichen Gerät installieren. Ziehen Sie für BYOD im großen Stil in Betracht, ob EAP-TTLS mit PAP oder PEAP-MSCHAPv2 ein praktischerer Kompromiss ist, während EAP-TLS für firmeneigene Geräte reserviert bleibt. Funktioniert EAP-TLS mit WPA3-Enterprise? Ja, und WPA3-Enterprise im 192-Bit-Modus schreibt EAP-TLS sogar zwingend vor. Wenn Sie WPA3-Enterprise in Hochsicherheitsumgebungen bereitstellen, ist EAP-TLS Ihre einzige konforme Option. Was ist die Mindestversion von Android, die ich anvisieren sollte? Android 8 und höher unterstützt EAP-TLS nativ. Erzwingen Sie ab Android 11 eine explizite CA-Zertifikatsvalidierung. Ab Android 13 können Sie die verbesserten APIs zur Zertifikatsverwaltung für eine präzisere Steuerung nutzen. Kann die Plattform von Purple in EAP-TLS-Netzwerke integriert werden? Die Plattform für Gäste-WiFi und Analytics von Purple läuft auf einer separaten SSID von Ihrem 802.1X-Unternehmensnetzwerk. Ihre Unternehmensgeräte authentifizieren sich über EAP-TLS auf der sicheren SSID, während Gäste-Geräte das Captive Portal von Purple auf der Gäste-SSID nutzen. Beide koexistieren auf derselben Access-Point-Infrastruktur, wobei eine VLAN-Trennung die Sicherheitsgrenze bildet. --- ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE — ca. 1 Minute Zusammenfassend lässt sich sagen: EAP-TLS auf Android ist die sicherste verfügbare Methode zur WiFi-Authentifizierung in Unternehmen, und mit modernen MDM-Tools ist die Bereitstellung in großem Maßstab absolut praktikabel. Die drei wichtigsten Punkte sind: eine ordnungsgemäß konfigurierte PKI mit automatischer Zertifikatsverlängerung, explizites CA-Zertifikatsvertrauen ab Android 11 und eine RADIUS-Infrastruktur, die für Spitzenlasten ausgelegt ist. Wenn Sie die Bereitstellung an einem Standort mit gemischtem Unternehmens- und Gästedatenverkehr durchführen, bietet Ihnen die Plattform von Purple die Analytics- und Interaktionsschicht im Gästenetzwerk, während Ihre EAP-TLS-Infrastruktur die Unternehmensseite sichert. Beide ergänzen sich hervorragend. Für Ihre nächsten Schritte: Sehen Sie sich unser Architekturdiagramm im vollständigen Leitfaden an, arbeiten Sie die Intune-Bereitstellungsanleitung durch und führen Sie ein Pilotprojekt auf einer Teilmenge von Geräten durch, bevor Sie die Bereitstellung auf Ihren gesamten Bestand ausweiten. Beginnen Sie mit einer kontrollierten Gruppe von fünfzig Geräten, validieren Sie die Zertifikatsbereitstellung sowie die WiFi-Konnektivität und skalieren Sie dann mit Zuversicht. Vielen Dank für Ihre Aufmerksamkeit beim Purple Technical Briefing. Den vollständigen schriftlichen Leitfaden, Diagramme und Konfigurationsreferenzen finden Sie unter purple.ai. Bis zum nächsten Mal.