The Enterprise Guide to SCEP: Deploying Simple Certificate Enrollment Protocol for Automated Campus WiFi Security

Guten Morgen. Wenn Sie die WiFi-Infrastruktur einer Hotelgruppe, eines Einzelhandelsunternehmens, eines Stadions oder eines Universitätsgeländes verwalten, ist dieses Briefing genau das Richtige für Sie. Wir werden uns mit SCEP – Simple Certificate Enrollment Protocol – befassen und insbesondere damit, wie es eines der hartnäckigsten Probleme im Enterprise-WiFi löst: die automatische Bereitstellung von Zertifikaten auf Tausenden von Geräten, ohne dass Ihr Helpdesk in Tickets ertrinkt. [short pause] Lassen Sie mich die Ausgangslage beschreiben. Sie haben – völlig zu Recht – entschieden, dass Pre-Shared Keys für das Mitarbeiter-WiFi nicht mehr akzeptabel sind. Ein einziges kompromittiertes Passwort gefährdet Ihr gesamtes Netzwerksegment. Sie sind auf die 802.1X-Authentifizierung umgestiegen oder befinden sich gerade im Übergang. Das ist der IEEE-Standard, der vorschreibt, dass jedes Gerät seine Identität nachweisen muss, bevor es Netzwerkzugriff erhält. Die sicherste Variante von 802.1X ist EAP-TLS – Extensible Authentication Protocol mit Transport Layer Security –, das digitale Zertifikate anstelle von Passwörtern verwendet. Zertifikate sind kryptografisch eindeutig pro Gerät, sie können nicht geteilt werden und sie können sofort widerrufen werden, wenn ein Gerät verloren geht oder ein Mitarbeiter das Unternehmen verlässt. [short pause] So weit, so gut. Das Problem ist die Verteilung. Wie bekommen Sie ein eindeutiges Zertifikat auf jeden Laptop, jedes Telefon, jedes Tablet in Ihrem Bestand – über Windows, iOS, Android und macOS hinweg –, ohne dass ein Techniker jedes einzelne Gerät anfassen muss? Genau dieses Problem löst SCEP. [medium pause] SCEP wurde 2020 von der Internet Engineering Task Force im RFC 8894 formalisiert, obwohl es in Enterprise-Umgebungen bereits seit den frühen 2000er Jahren im Einsatz ist. Es ist ein Protokoll, mit dem ein verwaltetes Gerät sein eigenes Zertifikat direkt von Ihrer Certificate Authority anfordern kann, und zwar über eine vorkonfigurierte URL und ein Challenge-Passwort. Der entscheidende Sicherheitspunkt dabei: Der private Schlüssel wird auf dem Gerät selbst generiert, im sicheren Bereich des Geräts gespeichert – das ist der TPM-Chip auf Windows-Geräten oder die Secure Enclave auf Apple-Hardware – und wird niemals über das Netzwerk übertragen. Das Gerät generiert einen Certificate Signing Request, sendet diesen an das SCEP-Gateway, das Gateway validiert die Challenge, leitet die Anfrage an Ihre Certificate Authority weiter, die CA signiert sie und das signierte Zertifikat geht zurück an das Gerät. Der gesamte Prozess ist für den Endbenutzer unsichtbar. [short pause] In einer Microsoft-Umgebung ist das SCEP-Gateway in der Regel NDES – Network Device Enrollment Service –, eine Windows-Server-Rolle, die als Vermittler zwischen Ihrer MDM-Plattform und Ihrer CA fungiert. Microsoft Intune pusht das SCEP-Profil auf die verwalteten Geräte, wodurch ihnen die NDES-URL und das Challenge-Passwort mitgeteilt werden. Die Geräte erledigen den Rest automatisch. [medium pause] Lassen Sie mich Ihnen zeigen, wie eine echte Bereitstellung aussieht. Nehmen wir eine Hotelgruppe mit 150 Standorten – denken Sie an die Größenordnung von Premier Inn. Sie haben eine Mischung aus Windows-Laptops für das Personal an der Rezeption, iOS-Geräten für die Hauswirtschaftsleitung und Android-Tablets an den Kassen im Restaurant. Vor SCEP nutzten sie WPA2-Personal mit einem gemeinsamen Passwort, das vierteljährlich geändert wurde. Jede Änderung löste eine Welle von Helpdesk-Anrufen aus. Mit SCEP und Intune stellen sie drei Profile nacheinander bereit. Erstens das Profil „Vertrauenswürdiges Stammzertifikat“ – dieses weist jedes Gerät an, der Zertifizierungsstelle des Unternehmens zu vertrauen. Zweitens das SCEP-Zertifikatsprofil – dieses weist die Geräte an, ihr individuelles Client-Zertifikat abzurufen. Drittens das WiFi-Profil – dieses konfiguriert die SSID, legt den Sicherheitstyp auf WPA2-Enterprise oder WPA3-Enterprise fest und verweist für die Authentifizierung auf das SCEP-Zertifikat. Wenn Sie diese drei Profile derselben Gerätegruppe in Intune zuweisen, verbindet sich jedes verwaltete Gerät automatisch mit der Unternehmens-SSID – mit einem individuellen Zertifikat und ohne dass eine Benutzerinteraktion erforderlich ist. [short pause] Der RADIUS-Server – in der Regel Microsoft NPS oder ein Cloud-RADIUS-Dienst – empfängt die EAP-TLS-Authentifizierungsanfrage, validiert das Zertifikat gegenüber der Zertifizierungsstelle, prüft die Zertifikatssperrliste und gewährt oder verweigert den Zugriff. Wenn ein Mitarbeiter ausscheidet, sperren Sie sein Zertifikat in der Zertifizierungsstelle. Sein Gerät verliert beim nächsten Authentifizierungszyklus den WiFi-Zugriff. Kein Zurücksetzen des Passworts erforderlich. Kein Warten auf die vierteljährliche Änderung. [medium pause] Nun wird oft nach dem Unterschied zwischen SCEP und PKCS (Public Key Cryptography Standards) gefragt. Beide funktionieren mit Intune. Der Hauptunterschied liegt darin, wo der private Schlüssel generiert wird. Bei SCEP wird er auf dem Gerät generiert. Bei PKCS generiert die Zertifizierungsstelle beide Schlüssel zentral und überträgt den privaten Schlüssel auf das Gerät. Das bedeutet, dass der private Schlüssel über das Netzwerk übertragen wird, was ein theoretisches Abfangrisiko birgt. PKCS hat seine Berechtigung – es eignet sich besser für die S/MIME-E-Mail-Verschlüsselung, bei der die Hinterlegung von Schlüsseln eine Rolle spielt. Für die WiFi-Authentifizierung ist SCEP die richtige Wahl. Jedes Mal. [short pause] Lassen Sie mich Ihnen ein zweites Szenario vorstellen – ein Filialnetz im Einzelhandel. Stellen Sie sich einen Modehändler mit 200 Geschäften in ganz Großbritannien vor, in denen jeweils Cisco Meraki Access Points im Einsatz sind. Ihre Kassensysteme basieren auf Windows und werden über Intune verwaltet. Sie benötigen PCI-DSS-Konformität, was eine Netzwerksegmentierung und eine starke Authentifizierung für jedes Gerät erfordert, das Karteninhaberdaten verarbeitet. SCEP-basiertes EAP-TLS bietet ihnen eine Authentifizierung auf Geräteebene in der Mitarbeiter-SSID, wobei die VLAN-Zuweisung durch die RADIUS-Richtlinie gesteuert wird. Die Kassenterminals landen automatisch im VLAN für den PCI-Bereich. Das Gäste-WiFi – das separat über eine Plattform wie Purple abgewickelt wird – läuft auf einer völlig isolierten SSID mit eigenem Authentifizierungsfluss. Die beiden Netzwerke berühren sich nie. Die Auditoren sind zufrieden. Das Sicherheitsteam schläft ruhiger. [medium pause] Gut, lassen Sie uns über die Fallstricke sprechen, denn es gibt einige, die Teams immer wieder unvorbereitet treffen. [short pause] Der häufigste Fehlergrund sind Abweichungen bei der Gruppenzuweisung in Intune. Ihr Trusted Root-Profil, Ihr SCEP-Profil und Ihr WiFi-Profil müssen alle derselben Azure AD-Gruppe zugewiesen sein. Wenn das SCEP-Profil einer Benutzergruppe und das WiFi-Profil einer Gerätegruppe zugewiesen ist, kann Intune die Abhängigkeit nicht auflösen und das WiFi-Profil wird als Fehler angezeigt. Überprüfen Sie zuerst Ihre Zuweisungen – das ist fast immer die Ursache. [short pause] Zweite Fehlerquelle: Verfügbarkeit des NDES-Servers. Ihr NDES-Server muss aus dem Internet erreichbar sein, damit sich Remote-Geräte registrieren können, bevor sie vor Ort eintreffen. Der sichere Weg dorthin führt über den Azure AD-Anwendungsproxy, der Ihnen Remote-Zugriff ermöglicht, ohne eingehende Firewall-Ports zu öffnen. Geben Sie NDES nicht direkt für das Internet frei. [short pause] Drittens: CRL-Verfügbarkeit. Ihr RADIUS-Server überprüft bei jeder Geräteauthentifizierung die Zertifikatssperrliste (Certificate Revocation List). Wenn der CRL-Verteilungspunkt nicht erreichbar ist – weil vielleicht ein Server offline ist oder eine Firewall-Regel geändert wurde –, schlägt die Authentifizierung für alle fehl. Machen Sie Ihre CRL-Endpunkte hochverfügbar und testen Sie sie regelmäßig. [short pause] Viertens: Berechtigungen für Zertifikatsvorlagen. Wenn das Dienstkonto Ihres NDES-Connectors keine Berechtigungen zum Lesen und Registrieren für die Zertifikatsvorlage besitzt, erhalten Geräte HTTP 403-Fehler, wenn sie versuchen, ihr Zertifikat abzurufen. Das ist eine einfache Berechtigungskorrektur, die man bei der Ersteinrichtung jedoch leicht übersieht. [medium pause] Und nun zu einer kurzen Fragerunde. [short pause] Kann SCEP mit Nicht-Microsoft-MDMs verwendet werden? Ja – Jamf für Apple-Geräteflotten, VMware Workspace ONE und die meisten Enterprise-MDM-Plattformen unterstützen SCEP-Profile. Das Protokoll ist herstellerneutral. [short pause] Funktioniert SCEP mit Cloud-PKI? Ja. Die Microsoft-eigene Cloud-PKI in der Intune Suite macht einen lokalen NDES-Server komplett überflüssig. Drittanbieter von Cloud-PKI wie SecureW2 und Keyfactor bieten ebenfalls Cloud-SCEP-Endpunkte an. [short pause] Wie sieht es mit WPA3-Enterprise aus? WPA3-Enterprise nutzt denselben 802.1X- und EAP-TLS-Authentifizierungs-Stack. Über SCEP ausgestellte Zertifikate funktionieren exakt genauso. Das Upgrade erfolgt auf der Ebene des Wireless-Protokolls, nicht auf der Zertifikatsebene. [short pause] Wie lange sind Zertifikate gültig? In der Regel ein Jahr, obwohl Sie auch kürzere Gültigkeitsdauern konfigurieren können. Intune übernimmt die automatische Verlängerung vor dem Ablauf, sodass für die Benutzer keinerlei Unterbrechung entsteht. [medium pause] Zusammenfassend lässt sich sagen: SCEP automatisiert die Zertifikatsverteilung in großem Umfang und eliminiert den manuellen Aufwand für die PKI-Bereitstellung auf großen Geräteflotten. Der private Schlüssel verbleibt auf dem Gerät – das ist das Sicherheitsfundament von EAP-TLS. Führen Sie die Bereitstellung nacheinander durch: Zuerst das Trusted Root-Profil, dann das SCEP-Profil, danach das WiFi-Profil, alle zugewiesen an dieselbe Gruppe. Veröffentlichen Sie Ihren NDES-Endpunkt sicher über den Anwendungsproxy. Halten Sie Ihre CRL-Endpunkte hochverfügbar. Und wenn Sie ganz neu anfangen, evaluieren Sie eine Cloud-PKI, um die Abhängigkeit von einem lokalen NDES-Server vollständig zu beseitigen. [short pause] Für das Gäste-WiFi – das separate, auf Besucher ausgerichtete Netzwerk – ist die zertifikatsbasierte Authentifizierung nicht das richtige Modell. Gäste verfügen nicht über verwaltete Geräte. Hier übernimmt eine Plattform wie Purple den Authentifizierungsfluss: Captive Portal, Social Login, E-Mail-Erfassung oder SMS-Verifizierung – alles fließt in eine First-Party-Datenebene ein, die Ihr Marketingteam tatsächlich nutzen kann. Beide Ansätze ergänzen sich gegenseitig: SCEP für Ihre verwalteten Mitarbeitergeräte, Purple für Ihr Gästenetzwerk. Beide laufen auf derselben Hardware, sauber segmentiert durch VLAN. [short pause] Das war Ihr Briefing zum SCEP-Enterprise-WiFi-Onboarding. Der vollständige schriftliche Leitfaden mit Architekturdiagrammen, Schritt-für-Schritt-Konfiguration für Intune und praktischen Beispielen ist auf der Purple-Website verfügbar. Vielen Dank fürs Zuhören.