So implementieren Sie SCEP für die automatisierte WiFi-Zertifikatsregistrierung

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte WiFi-Zertifikatsregistrierung in Unternehmensstandorten implementieren. Er deckt den gesamten architektonischen Entwurf ab – vom PKI-Design und der MDM-Integration bis hin zur obligatorischen dreistufigen Bereitstellungssequenz – und zeigt IT-Managern und Netzwerkarchitekten, wie sie gemeinsame Anmeldeinformationen eliminieren, das Lebenszyklusmanagement von Zertifikaten automatisieren und PCI DSS- und GDPR-Anforderungen in großem Maßstab erfüllen.

📖 10 Min. Lesezeit📝 2,383 Wörter🔧 2 ausgearbeitete Beispiele❓ 4 Übungsfragen📚 10 Schlüsseldefinitionen

Diesen Leitfaden anhören

Podcast-Transkript ansehen

EINFÜHRUNG UND KONTEXT - 0:00 bis 1:00

Hallo und herzlich willkommen zu diesem technischen Briefing von Purple. Heute befassen wir sich mit SCEP, dem Simple Certificate Enrollment Protocol, und wie Sie es für die automatisierte Registrierung von WiFi-Zertifikaten implementieren. Wenn Sie Netzwerkarchitekt, IT-Leiter oder Infrastrukturmanager für große Standorte wie Einzelhandelsketten, Krankenhäuser oder Stadien sind, ist dieses Briefing genau das Richtige für Sie. Wir bringen die Dinge auf den Punkt und besprechen, wie Sie EAP-TLS in großem Maßstab bereitstellen, warum SCEP die richtige Wahl für die Geräteidentität ist und wie Sie es praktisch in Ihrer Umgebung implementieren können. Lassen Sie uns direkt einsteigen.

TECHNISCHE TIEFENANALYSE - 1:00 bis 6:00

Welche Herausforderung lösen wir hier also genau? In der Welt der Enterprise-WiFi-Sicherheit gilt EAP-TLS als Goldstandard. Im Gegensatz zu älteren Methoden wie PEAP oder EAP-TTLS, die auf Benutzerpasswörtern basieren, erfordert EAP-TLS eine gegenseitige zertifikatsbasierte Authentifizierung. Das bedeutet, dass das Client-Gerät die Netzwerkidentität über ein Serverzertifikat und das Netzwerk die Client-Identität über ein eindeutiges Client-Zertifikat überprüfen muss.

Denken Sie an das Sicherheitsrisiko von Passwörtern. Sie können weitergegeben, per Phishing abgefangen oder gestohlen werden. In einer weitläufigen Unternehmensumgebung kann ein kompromittiertes Passwort einem böswilligen Akteur Zugriff auf Ihr gesamtes internes Netzwerk gewähren. EAP-TLS eliminiert diesen Angriffsvektor vollständig. Die Authentifizierung basiert auf X.509-Zertifikaten, die von einer Public Key Infrastructure (PKI) ausgestellt wurden.

Die eigentliche Herausforderung bei EAP-TLS ist jedoch nicht das Protokoll selbst. Es ist die Logistik, eindeutige Client-Zertifikate auf Tausende von Geräten zu übertragen – seien es Windows-Laptops, iPads oder Point-of-Sale-Tablets. Sie können Zertifikate nicht manuell auf Tausenden von Geräten installieren. Hier kommen Mobile Device Management-Plattformen wie Microsoft Intune oder Jamf ins Spiel. Aber wie übertragen Sie diese Zertifikate sicher?

Im Allgemeinen haben Sie zwei Optionen: PKCS oder SCEP. Lassen Sie mich hierbei absolut unmissverständlich sein. Für die WiFi-Authentifizierung sollten Sie SCEP wählen. Hier ist der Grund, warum das so wichtig ist: Bei SCEP weist das MDM das Endgerät an, seinen eigenen privaten Schlüssel lokal zu generieren. Dieser Schlüssel bleibt in der sicheren Hardware des Geräts gesperrt. Er wird niemals über das Netzwerk übertragen. Das Gerät sendet lediglich eine Zertifikatsignierungsanforderung über ein Gateway, in der Regel einen NDES-Server, an Ihre Zertifizierungsstelle.

Vergleichen Sie das mit PKCS, bei dem die Zertifizierungsstelle den privaten Schlüssel zentral generiert und über das Netzwerk an das Gerät überträgt. PKCS hat zwar seine Berechtigung, beispielsweise für die E-Mail-Verschlüsselung, bei der Sie eine Schlüsselhinterlegung benötigen, aber die Übertragung privater Schlüssel über das Netzwerk ist ein Risiko, das Sie für die Netzwerkauthentifizierung nicht eingehen müssen. Lassen Sie die Schlüssel auf dem Gerät. Nutzen Sie SCEP.

Lassen Sie uns nun über die Implementierung sprechen. Wenn Sie eine einzige Erkenntnis aus diesem Briefing mitnehmen, dann diese Faustregel: Vertrauen vor Authentifizierung. Sie können nicht einfach ein WiFi-Profil per Push übertragen und erwarten, dass es funktioniert. Es gibt eine strikte, dreistufige Bereitstellungsreihenfolge, die Sie befolgen müssen.

Schritt 1: Bereitstellung des Trusted Root Certificate. Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Zertifizierungsstelle (Certificate Authority) vertrauen. Pushen Sie dieses Profil zuerst.

Schritt 2: Konfigurieren und Pushen des SCEP-Zertifikatsprofils. Dies teilt dem Gerät mit, wie es mit dem SCEP-Gateway kommunizieren soll, welches Format für den Subject Name verwendet werden soll und wofür das Zertifikat eigentlich gedacht ist. In diesem Fall: Client-Authentifizierung. Sie müssen dieses Profil mit dem in Schritt 1 bereitgestellten Trusted Root verknüpfen.

Schritt 3: Bereitstellung des 802.1X WiFi-Profils. Hier führen Sie alles zusammen. Sie geben die SSID an, wählen WPA3-Enterprise, stellen den EAP-Typ auf EAP-TLS ein und verweisen auf das SCEP-Zertifikat für die Client-Authentifizierung.

EMPFEHLUNGEN FÜR DIE IMPLEMENTIERUNG UND STOLPERSTEINE - 6:00 bis 8:00

Hier ist ein großer Stolperstein, den wir ständig sehen. Ein Kunde ruft uns an und sagt: Die Zertifikate sind auf dem Gerät, aber das WiFi-Profil zeigt in Intune einen Fehler an. Fast jedes Mal liegt dies an einer fehlerhaften Gruppenzuweisung (Targeting Mismatch). Wenn Sie das SCEP-Profil einer Benutzergruppe (Users) zuweisen, das WiFi-Profil jedoch einer Gerätegruppe (Devices), kann das MDM die Abhängigkeit nicht auflösen. Passen Sie Ihre Zielgruppen über alle drei Profile hinweg exakt an.

Betrachten wir ein reales Szenario. Stellen Sie sich ein Hotel mit 200 Zimmern vor. Sie verfügen über 150 verwaltete iOS-Geräte für das Housekeeping-Personal. Derzeit nutzen sie ein Standard-Passwortnetzwerk, und die Mitarbeiter teilen das Passwort ständig mit Gästen. Das ist ein echtes betriebliches Problem. Durch die Migration auf WPA2-Enterprise mit EAP-TLS via SCEP eliminiert der IT-Leiter das Passwort vollständig. Die iOS-Geräte authentifizieren sich geräuschlos im Hintergrund mithilfe ihrer Zertifikate.

Aber was passiert, wenn eine Reinigungskraft ein Gerät verliert oder das Unternehmen verlässt? Das Deaktivieren ihres Active Directory-Kontos reicht nicht aus, da das Zertifikat auf diesem Gerät kryptografisch immer noch gültig ist. Dies bringt uns zu einer entscheidenden Sicherheitsmaßnahme: der strengen CRL-Prüfung. Sie müssen Ihren RADIUS-Server so konfigurieren, dass er die Zertifikatssperrliste (Certificate Revocation List) prüft. Wenn ein Gerät verloren geht, sperren Sie das Zertifikat bei der CA. Der RADIUS-Server erkennt die Sperrung auf der CRL und blockiert sofort den Netzwerkzugriff. Ohne strenge CRL-Prüfung ist Ihre Sicherheitsarchitektur unvollständig.

SCHNELLE FRAGEN & ANTWORTEN (RAPID-FIRE Q&A) - 8:00 bis 9:00

Beantworten wir ein paar schnelle Fragen, die wir oft von CTOs hören.

Frage 1: Ist EAP-TLS für WPA3 Enterprise erforderlich? Obwohl WPA3 Enterprise andere Methoden unterstützt, wird EAP-TLS dringend empfohlen und ist erforderlich, wenn Sie die WPA3 Enterprise 192-Bit-Sicherheits-Suite (oft als Suite B bezeichnet) implementieren.

Frage 2: Können wir öffentliche Zertifikate für Clients verwenden? Nein. Sie müssen eine private, interne CA für Client-Zertifikate verwenden. Öffentliche CAs sind für öffentlich zugängliche Webserver gedacht. Ihr interner RADIUS-Server muss Ihrer spezifischen internen Root-CA vertrauen, um Ihre Unternehmensgeräte zu validieren.

Frage drei: Wie fügt sich das in OpenRoaming ein? OpenRoaming basiert auf Passpoint und 802.1X. Purple agiert unter der Connect-Lizenz als kostenloser Identity-Provider für Dienste wie OpenRoaming und ermöglicht so ein nahtloses, sicheres Roaming über verschiedene Standorte hinweg unter Nutzung der zugrunde liegenden Zertifikats- und Identitäts-Frameworks.

ZUSAMMENFASSUNG UND NÄCHSTE SCHRITTE - 9:00 bis 10:00

Zusammenfassend lässt sich sagen, dass die Umstellung auf eine automatisierte SCEP-Zertifikatsbereitstellung echte, messbare Erfolge bringt. Sie werden eine Reduzierung der WiFi-bezogenen Helpdesk-Tickets um 70 bis 80 Prozent feststellen, da sich die Benutzer nicht mehr ausschließen oder Passwörter falsch eingeben. Vor allem aber eliminieren Sie das Risiko des Abgreifens von Anmeldedaten (Credential Harvesting) und stellen sicher, dass Sie Compliance-Frameworks wie PCI DSS und GDPR einhalten.

Bei der Automatisierung der WiFi-Sicherheit im Unternehmen geht es nicht nur darum, Systeme abzuriegeln. Es geht darum, den sicheren Weg zum einfachsten Weg für Ihre Benutzer zu machen. Ihre nächsten Schritte: Überprüfen Sie Ihre aktuelle 802.1X-Bereitstellung. Wenn Sie immer noch auf Passwörter setzen, entwerfen Sie Ihre PKI und planen Sie die Migration zu EAP-TLS mit SCEP. Prüfen Sie, ob Ihr RADIUS-Server eine strikte CRL- oder OCSP-Prüfung erzwingt. Und stellen Sie sicher, dass Ihre drei Bereitstellungsprofile alle auf dieselbe Gruppe ausgerichtet sind.

Vielen Dank, dass Sie sich dieses technische Briefing von Purple angehört haben. Für detailliertere Bereitstellungshandbücher und um zu erfahren, wie sich unsere Analytics- und Identitätsplattformen in Ihre sicheren Netzwerke integrieren lassen, besuchen Sie purple dot ai.

Wichtigste Erkenntnisse

✓SCEP (RFC 8894) automatisiert die X.509-Zertifikatsregistrierung für verwaltete Geräte. Der private Schlüssel wird lokal auf dem Gerät generiert und niemals über das Netzwerk übertragen – dies ist der zentrale Sicherheitsvorteil gegenüber PKCS.
✓Verwenden Sie für die 802.1X EAP-TLS WiFi-Authentifizierung immer SCEP. Reservieren Sie PKCS für Anwendungsfälle, die ein Key Escrow erfordern, wie z. B. die S/MIME-E-Mail-Verschlüsselung.
✓Die Bereitstellungsreihenfolge ist nicht verhandelbar: Zuerst das vertrauenswürdige Stammzertifikat, dann das SCEP-Zertifikatsprofil, danach das 802.1X WiFi-Profil. Alle drei Profile müssen auf genau dieselbe Azure AD-Gruppe ausgerichtet sein.
✓Eine strikte CRL- oder OCSP-Prüfung auf dem RADIUS-Server ist zwingend erforderlich. Das Deaktivieren eines AD-Kontos sperrt kein Zertifikat. Führen Sie den Widerruf an der CA durch und stellen Sie sicher, dass der RADIUS-Server darauf reagiert.
✓EAP-TLS erfüllt die Anforderung 8.6 des PCI DSS 4.0 für Multi-Faktor-Authentifizierung auf der Netzwerkebene und ist für WPA3 Enterprise 192-Bit (Suite B) Bereitstellungen erforderlich.
✓Organisationen, die von passwortbasiertem WiFi auf EAP-TLS mit SCEP migrieren, berichten in der Regel von einer Reduzierung der WiFi-bezogenen Helpdesk-Tickets um 70-80 % (interne Purple-Daten, 2024).
✓Für verteilte Standorte (Hotelgruppen, Einzelhandelsketten, standortübergreifender öffentlicher Sektor) erübrigen cloudbasierte SCEP-Gateways und verwaltete PKI-Dienste die Notwendigkeit einer lokalen NDES-Infrastruktur, ohne die Sicherheit zu beeinträchtigen.

Executive Summary

Für Betreiber von Veranstaltungsorten, die Guest WiFi in Hotels, Einzelhandelsgeschäften, Stadien und Konferenzzentren anbieten, ist die Nutzung von Pre-Shared Keys oder einfachen Captive Portals für den Netzwerkzugriff von Mitarbeitern ein Sicherheitsrisiko. Moderne Netzwerkarchitekturen erfordern eine 802.1X-Authentifizierung mittels EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), um sicherzustellen, dass jedes Gerät kryptografisch verifiziert wird, bevor es eine Verbindung zum Netzwerk herstellt. Die Herausforderung liegt in der Verteilung: Wie stellen Sie eindeutige Client-Zertifikate auf Tausenden von Windows-, iOS- und Android-Geräten bereit, ohne Ihren Helpdesk zu überlasten?

Die Antwort lautet SCEP – das Simple Certificate Enrollment Protocol. SCEP wurde 2020 von der IETF als RFC 8894 formalisiert und automatisiert die Registrierung von Zertifikaten auf verwalteten Geräteflotten. Bei der Integration in eine MDM-Plattform wie Microsoft Intune oder Jamf ermöglicht SCEP eine Zero-Touch-Zertifikatsbereitstellung: Geräte fordern ihre eigenen Zertifikate an, empfangen und erneuern sie ohne jegliches Eingreifen der IT. Der private Schlüssel wird lokal auf dem Gerät generiert und niemals über das Netzwerk übertragen – ein grundlegender Sicherheitsvorteil gegenüber der PKCS-basierten Bereitstellung.

Dieser Leitfaden führt Sie durch den gesamten SCEP-Implementierungs-Workflow: PKI-Architektur, NDES-Gateway-Konfiguration, die obligatorische dreistufige MDM-Bereitstellungssequenz und die betrieblichen Kontrollen – insbesondere die Überprüfung von CRLs und die Gruppenzielausrichtung –, die über den Erfolg oder das Scheitern eines Rollouts entscheiden. Zwei Praxisbeispiele veranschaulichen diesen Ansatz in der Hotellerie und im Einzelhandel. Purple ist in über 80.000 Live-Locations aktiv und zählt mehr als 350 Millionen Unique User. Die hier beschriebenen Muster spiegeln wider, was in dieser Größenordnung funktioniert.

Technische Vertiefung

Was SCEP tatsächlich tut

SCEP fungiert als Schnittstelle zwischen Ihrer MDM-Plattform und Ihrer Certificate Authority (CA). Es bietet einen standardisierten HTTP-basierten Mechanismus, über den Geräte X.509-Zertifikate anfordern, empfangen und erneuern können, ohne dass domänengebundene Anmeldedaten oder ein manueller Eingriff des Administrators erforderlich sind. Das Protokoll wurde ursprünglich in den frühen 2000er Jahren entwickelt und fand in MDM-Umgebungen von Unternehmen breite Akzeptanz, bevor die IETF es offiziell als RFC 8894 veröffentlichte.

Der sechsstufige Registrierungsprozess läuft wie folgt ab. Erstens verbindet sich das verwaltete Gerät mit der im MDM-Profil vorkonfigurierten SCEP-Gateway-URL. Zweitens generiert das Gerät lokal ein privates/öffentliches Schlüsselpaar und erstellt eine Zertifikatsignierungsanforderung (CSR). Drittens validiert das SCEP-Gateway die Autorisierung des Geräts anhand eines Challenge-Passworts oder eines in der MDM-Richtlinie eingebetteten OTP. Viertens leitet das Gateway die validierte CSR an die Zertifizierungsstelle (CA) weiter. Fünftens signiert die CA das Zertifikat und sendet es an das Gateway zurück. Sechstens stellt das Gateway das signierte Zertifikat dem Gerät bereit. Zukünftige Erneuerungen folgen demselben automatisierten Pfad – das Gerät registriert sich vor dem Ablaufdatum ohne Eingreifen des Benutzers oder Administrators erneut.

SCEP vs. PKCS: Die entscheidende Weichenstellung

Microsoft Intune und die meisten MDM-Plattformen unterstützen zwei Mechanismen zur Bereitstellung von Zertifikaten: SCEP und PKCS. Der Unterschied ist architektonischer Natur, nicht kosmetischer.

Bei SCEP wird der private Schlüssel direkt auf dem Gerät generiert und verbleibt dort. Die CA sieht ihn nie. Das TPM des Geräts (unter Windows) oder die Secure Enclave (unter iOS/macOS) schützt den Schlüssel auf Hardwareebene. Bei PKCS generiert die CA das Schlüsselpaar zentral und überträgt es über das Netzwerk an das Gerät. Die CA behält eine Kopie, was ein Schlüssel-Escrow ermöglicht – was für die S/MIME-E-Mail-Verschlüsselung nützlich ist, aber ein unnötiges Risiko für die Netzwerkauthentifizierung darstellt.

Verwenden Sie für die 802.1X WiFi-Authentifizierung SCEP. Der private Schlüssel verlässt das Gerät niemals. Das ist die feste Regel.

Kriterium	SCEP	PKCS
Privater Schlüssel generiert auf	Gerät	CA (zentral)
Privater Schlüssel über Netzwerk übertragen	Niemals	Ja
Unterstützt TPM / Secure Enclave	Ja	Nein
Empfohlen für WiFi-Auth	Ja	Nein
Empfohlen für E-Mail-Verschlüsselung (S/MIME)	Nein	Ja
Schlüssel-Escrow möglich	Nein	Ja

802.1X und EAP-TLS: Das Authentifizierungs-Framework

IEEE 802.1X ist der portbasierte Netzwerkzugriffskontrollstandard, der die Sicherheit von Unternehmens-WiFi gewährleistet. Er definiert drei Rollen: den Supplicant (das Client-Gerät), den Authenticator (den Access Point – Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme oder Fortinet) und den Authentifizierungsserver (einen RADIUS-Server wie Microsoft NPS, FreeRADIUS oder Cisco ISE).

EAP-TLS ist die sicherste EAP-Methode für 802.1X. Beide Seiten weisen Zertifikate vor: Der RADIUS-Server präsentiert dem Client sein Zertifikat, und der Client präsentiert dem RADIUS-Server sein über SCEP bereitgestelltes Zertifikat. Keine Seite kann sich als die andere ausgeben, ohne ein gültiges, nicht widerrufenes Zertifikat der vertrauenswürdigen CA-Hierarchie vorzuweisen. Dieses Modell der gegenseitigen Authentifizierung eliminiert den Diebstahl von Anmeldedaten, Evil-Twin-Angriffe und Risiken durch Rogue Access Points in einer einzigen architektonischen Entscheidung.

EAP-TLS erfüllt die PCI DSS 4.0 Anforderung 8.6 für Multi-Faktor-Authentifizierung auf der Netzwerkebene. Es ist für WPA3-Enterprise-192-Bit-Bereitstellungen (Suite B) erforderlich. Für jedes drahtlose Netzwerk im Rahmen der Karteninhaberdaten-Verarbeitung – Point-of-Sale im Einzelhandel, Hotelrezeption, Ticketverkauf im Stadion – ist EAP-TLS die richtige Wahl.

Für einen tieferen Einblick in die Architektur von secure WiFi und die Integration zertifikatsbasierter Authentifizierung in ein breiteres Sicherheitskonzept lesen Sie unseren Leitfaden.

Implementierungshandbuch

Die Bereitstellungsreihenfolge ist nicht verhandelbar. Intune und Jamf lösen Profilabhängigkeiten nacheinander auf: Das WiFi-Profil hängt vom SCEP-Profil ab, welches wiederum vom Trusted-Root-Profil abhängt. Wenn Sie diese außerhalb der Reihenfolge bereitstellen, schlägt die Anwendung des WiFi-Profils fehl.

Schritt 1: Entwerfen Sie Ihre PKI

Bevor Sie eine MDM-Konsole anfassen, entwerfen Sie Ihre Zertifikatshierarchie. Standard ist eine zweistufige PKI: eine Offline-Root-CA und eine Online-Aussteller-CA. Der private Schlüssel der Root-CA ist der Master-Vertrauensanker für Ihre gesamte Zertifikatsinfrastruktur – halten Sie ihn offline (Air-Gapped). Die Aussteller-CA übernimmt die tägliche Zertifikatsausstellung und veröffentlicht die Zertifikatswiderrufsliste (CRL) sowie den OCSP-Responder.

Für die meisten Enterprise-Standorte stellt Microsoft Active Directory Certificate Services (AD CS) auf Windows Server die ausstellende CA bereit. Cloud-basierte PKI-Dienste von Anbietern wie SCEPman oder SecureW2 machen die On-Premises-Infrastruktur komplett überflüssig und sind eine Evaluierung wert für verteilte Bereitstellungen über Hotelgruppen, Einzelhandelsketten oder standortübergreifende Organisationen des öffentlichen Sektors.

Schritt 2: Stellen Sie den NDES-Server (oder das Cloud SCEP Gateway) bereit

NDES (Network Device Enrollment Service) ist die Microsoft Windows Server-Rolle, die als SCEP-Gateway zwischen Ihrem MDM und Ihrer CA fungiert. Wichtige Konfigurationsanforderungen:

Veröffentlichen Sie die NDES-URL extern über den Azure AD Anwendungsproxy (oder einen gleichwertigen Reverse-Proxy). Dies ermöglicht Remote-Geräten die Registrierung, bevor sie vor Ort sind, ohne dass eingehende Firewall-Ports geöffnet werden müssen.
Das NDES-Dienstkonto benötigt Lese- und Registrierungsberechtigungen für die CA-Zertifikatsvorlage.
Konfigurieren Sie die Zertifikatsvorlage mit der Schlüsselverwendung (Key Usage) Digitale Signatur und Schlüsselverschlüsselung sowie der erweiterten Schlüsselverwendung (Extended Key Usage) Client-Authentifizierung (OID: 1.3.6.1.5.5.7.3.2).
Legen Sie eine angemessene Gültigkeitsdauer für Zertifikate fest. Ein Jahr ist Standard für Client-Zertifikate; zwei Jahre sind für Geräte-Zertifikate in stabilen Geräteparks akzeptabel. Wenn Sie lokale NDES-Infrastrukturen vermeiden möchten, integrieren sich Cloud-SCEP-Gateways direkt über eine API in Intune und Ihre CA, wodurch die IIS-Abhängigkeit vollständig entfällt.

Schritt 3: Bereitstellen des Profils für vertrauenswürdige Stammzertifikate

Erstellen Sie in Ihrer MDM-Plattform ein Profil für vertrauenswürdige Zertifikate und laden Sie Ihr Root-CA-Zertifikat (und alle Intermediate-CA-Zertifikate) als .cer-Dateien hoch. Stellen Sie dieses Profil vor allen anderen Zertifikats- oder WiFi-Profilen für Ihre Zielgerätegruppen bereit. Ohne diesen Schritt können Geräte das Zertifikat des RADIUS-Servers während des EAP-TLS-Handshakes nicht validieren und sie können der ausstellenden CA nicht vertrauen, wenn sie ihr eigenes SCEP-Zertifikat anfordern.

Faustregel: Verwenden Sie immer dieselbe Azure AD-Gruppe (entweder Benutzer oder Geräte) für alle drei zusammenhängenden Profile. Eine Diskrepanz an dieser Stelle ist die häufigste Ursache für Fehlschläge bei der Bereitstellung von WiFi-Profilen.

Schritt 4: Konfigurieren des SCEP-Zertifikatprofils

Erstellen Sie ein SCEP-Zertifikatskonfigurationsprofil in Ihrem MDM:

Format des Antragstellernamens (Subject Name): Verwenden Sie für die benutzergesteuerte Authentifizierung CN={{UserPrincipalName}}. Verwenden Sie für die Geräteauthentifizierung (empfohlen für gemeinsam genutzte Geräte und IoT) CN={{AAD_Device_ID}}.
Schlüsselverwendung (Key Usage): Digitale Signatur, Schlüsselverschlüsselung.
Erweiterte Schlüsselverwendung (Extended Key Usage): Client-Authentifizierung (OID: 1.3.6.1.5.5.7.3.2).
SCEP-Server-URL: Die extern veröffentlichte NDES-URL.
Stammzertifikat: Verknüpfen Sie das Profil für vertrauenswürdige Stammzertifikate aus Schritt 3.
Gültigkeitsdauer des Zertifikats: Muss mit der auf der CA konfigurierten Vorlage übereinstimmen.

Schritt 5: Bereitstellen des 802.1X-WiFi-Profils

Erstellen Sie ein WiFi-Konfigurationsprofil:

SSID: Geben Sie den Netzwerknamen exakt so ein, wie er von Ihren Access Points ausgestrahlt wird.
Sicherheitstyp: WPA2-Enterprise oder WPA3-Enterprise.
EAP-Typ: EAP-TLS.
Client-Authentifizierungszertifikat: Wählen Sie das SCEP-Zertifikatprofil aus Schritt 4.
Server-Validierung: Geben Sie das vertrauenswürdige Stammzertifikat aus Schritt 3 an und tragen Sie den erwarteten RADIUS-Servernamen ein. Dies verhindert, dass sich Geräte mit gefälschten Access Points verbinden, die betrügerische Zertifikate vorweisen.

Best Practices

Erzwingen Sie eine strenge CRL-Prüfung auf Ihrem RADIUS-Server

Der Zertifikatswiderruf ist die betriebliche Kontrollmaßnahme, die die Lücke zwischen der Deaktivierung eines Kontos und dem Sperren des Netzwerkzugriffs schließt. Wenn ein Gerät verloren geht, gestohlen wird oder ein Mitarbeiter das Unternehmen verlässt, deaktivieren Sie das AD-Konto und widerrufen Sie das Zertifikat bei der CA. Ihr RADIUS-Server muss so konfiguriert sein, dass er bei jedem Authentifizierungsversuch die CRL überprüft. Wenn die CRL nicht verfügbar ist – weil der CDP (CRL Distribution Point) nicht erreichbar ist –, schalten die meisten RADIUS-Server standardmäßig auf "Fail-Open" (Sicherheitsrisiko). Stellen Sie sicher, dass Ihre CDPs hochverfügbar sind und Ihr RADIUS-Server so konfiguriert ist, dass er auf "Fail-Closed" schaltet, wenn die CRL nicht abgerufen werden kann.

Konfigurieren Sie für den Widerruf in Echtzeit zusätzlich zur CRL das OCSP (Online Certificate Status Protocol). OCSP liefert Statusantworten pro Zertifikat, ohne dass der RADIUS-Server die gesamte CRL herunterladen und analysieren muss.

Gerätezertifikate für gemeinsam genutzte und IoT-Geräte verwenden

Für gemeinsam genutzte Geräte – wie Tablets des Hotel-Housekeeping, POS-Terminals im Einzelhandel oder Zutrittskontroll-Leser im Stadion – sollten Sie Gerätezertifikate anstelle von Benutzerzertifikaten verwenden. Gerätezertifikate sind an die Identität des Geräts und nicht an ein Benutzerkonto gebunden. Das bedeutet, dass sich das Gerät unabhängig vom angemeldeten Benutzer authentifiziert, und ein Widerruf ist an den Datensatz des Geräts gebunden, anstatt an das Ausscheiden eines Mitarbeiters.

Bei Bereitstellungen im Einzelhandel erfüllen Gerätezertifikate auf POS-Hardware zudem die PCI-DSS-Anforderungen an die Identität von Geräten auf Netzwerkebene, ohne dass am Point of Sale komplexe Benutzeranmeldedaten erforderlich sind.

Zertifikatsverlängerung automatisieren

SCEP unterstützt die automatische Verlängerung: Das MDM weist das Gerät an, sich erneut anzumelden, bevor das Zertifikat abläuft. Konfigurieren Sie Ihr SCEP-Profil so, dass die Verlängerung bei 20 % der verbleibenden Gültigkeitsdauer des Zertifikats ausgelöst wird. Bei einem einjährigen Zertifikat beginnt die Verlängerung ca. 73 Tage vor Ablauf. Dieses Zeitfenster bietet genügend Zeit, um eventuelle Fehler bei der Verlängerung zu beheben, bevor das Zertifikat abläuft und Geräte den Netzwerkzugriff verlieren.

Abgelaufene Zertifikate, die zu massenhaften Authentifizierungsfehlern führen, sind der häufigste Betriebsvorfall bei 802.1X-Bereitstellungen. Die automatische Verlängerung via SCEP eliminiert dieses Risiko vollständig.

Netzwerke nach Zertifikatsattributen segmentieren

RADIUS-Server können Zertifikatsattribute wie Subject, SAN oder benutzerdefinierte OIDs auslesen und diese verwenden, um Geräte dynamisch VLANs zuzuweisen. Ein Housekeeping-Tablet mit einem Zertifikat, das aus der Vorlage HousekeepingDevices ausgestellt wurde, landet im Housekeeping-VLAN. Ein POS-Terminal mit einem Zertifikat aus der Vorlage RetailPOS landet im PCI-konformen VLAN. Dies ist eine kryptografisch erzwungene Netzwerksegmentierung – weitaus zuverlässiger als SSID-basierte oder MAC-basierte Ansätze.

Für Betreiber im Gastgewerbe , die Guest WiFi und Staff WiFi auf derselben physischen Infrastruktur betreiben, stellt die VLAN-Zuweisung über Zertifikatsattribute sicher, dass Gäste und Mitarbeiter immer auf separaten Netzwerksegmenten sind, unabhängig davon, mit welcher SSID sich ein Gerät verbindet.

Fehlerbehebung & Risikominderung

WiFi-Profil zeigt in Intune „Fehler“ oder „Nicht anwendbar“ an

Fehlerursache: Abweichung bei der Gruppenzuweisung. Das SCEP-Profil ist einer anderen Gruppe zugewiesen als das WiFi-Profil. Intune kann die Zertifikatsabhängigkeit nicht auflösen.

Behebung: Überprüfen Sie alle drei Profile (Trusted Root, SCEP, WiFi). Stellen Sie sicher, dass sie alle genau derselben Azure AD-Gruppe zugewiesen sind. Wenn Sie die Bereitstellung für Benutzer durchführen, müssen alle drei Profile auf eine Benutzergruppe ausgerichtet sein. Wenn Sie für Geräte bereitstellen, müssen alle drei Profile auf eine Gerätegruppe ausgerichtet sein.

NDES gibt HTTP 403-Fehler zurück

Fehlerursache: Dem Dienstkonto des Intune Certificate Connector fehlen die Berechtigungen „Lesen“ oder „Registrieren“ für die CA-Zertifikatvorlage, oder die URL-Filterung der Firewall blockiert SCEP-Abfragezeichenfolgen. Fix: Stellen Sie sicher, dass das Connector-Konto über Lese- und Registrierungsberechtigungen (Read and Enroll) für die Vorlage in der CA-Konsole verfügt. Überprüfen Sie die Firewall-Protokolle auf blockierte Anfragen, die ?operation=GetCACaps oder ?operation=PKIOperation enthalten. Diese Query-Strings müssen ohne Modifikation durchgelassen werden.

Geräte erneuern Zertifikate nicht vor dem Ablauf

Fehlerursache: Das SCEP-Erneuerungsfenster ist zu kurz oder der NDES-Server ist zum Zeitpunkt der Erneuerung nicht erreichbar.

Fix: Setzen Sie den Erneuerungsschwellenwert auf 20 % der Zertifikatsgültigkeit. Stellen Sie sicher, dass die NDES-URL über einen hochverfügbaren Reverse-Proxy bereitgestellt wird. Überwachen Sie die NDES-IIS-Protokolle auf Fehler bei Erneuerungsanfragen und richten Sie proaktive Warnmeldungen ein.

RADIUS lehnt gültige Zertifikate ab

Fehlerursache: Der Speicher für vertrauenswürdige CAs des RADIUS-Servers enthält das Zertifikat der ausstellenden CA nicht oder die CRL ist veraltet.

Fix: Importieren Sie die vollständige CA-Kette (Root CA + ausstellende CA) in den vertrauenswürdigen Speicher des RADIUS-Servers. Überprüfen Sie, ob die CRL erfolgreich abgerufen wird und die CDP-URL vom RADIUS-Server aus erreichbar ist. Kontrollieren Sie den Zeitstempel für das nächste Update der CRL – wenn dieser überschritten ist, muss die CA eine neue CRL veröffentlichen.

Für umfassendere Überlegungen zur Netzwerkleistung neben der Sicherheit lesen Sie unseren Leitfaden zum Bandbreitenmanagement .

ROI & geschäftliche Auswirkungen

Das Business Case für die SCEP-basierte Zertifikatsregistrierung ist eindeutig. Passwortbasiertes WiFi verursacht ein vorhersehbares Aufkommen an Helpdesk-Tickets: abgelaufene Passwörter, Kontosperrungen, die Weitergabe von Zugangsdaten durch Mitarbeiter an Gäste sowie Reibungsverluste beim Onboarding neuer Mitarbeiter. Die zertifikatsbasierte Authentifizierung ist für den Endbenutzer unsichtbar. Geräte verbinden sich automatisch. Es gibt keine Passwörter, die ablaufen, geteilt oder vergessen werden können.

Unternehmen, die von passwortbasiertem WiFi auf EAP-TLS mit SCEP umstellen, berichten in der Regel von einer Reduzierung der WiFi-bezogenen Helpdesk-Tickets um 70–80 % (interne Daten von Purple, 2024, basierend auf Bereitstellungen im Gastgewerbe und im Einzelhandel). Die Einsparungen im Helpdesk rechtfertigen oft schon im ersten Jahr die Implementierungskosten.

Die Auswirkungen auf die Compliance sind ebenso konkret. EAP-TLS erfüllt die Anforderung 8.6 von PCI DSS 4.0 für Multi-Faktor-Authentifizierung auf der Netzwerkschicht. Für Gesundheitswesen -Umgebungen entspricht es den technischen HIPAA-Sicherheitsanforderungen für den drahtlosen Netzwerkzugriff. Für Organisationen des öffentlichen Sektors unterstützt es die Anforderungen der NCSC Cyber Essentials Plus-Zertifizierung für die Netzwerkzugriffskontrolle.

Für Transport -Betreiber – Bahngesellschaften, Flughafenbetreiber, Busnetze – stellt die zertifikatsbasierte Authentifizierung auf Mitarbeitergeräten sicher, dass betriebliche Netzwerke, die sicherheitskritische Daten übertragen, vom Passagier-WiFi isoliert und vor angriffen auf Zugangsdaten geschützt sind.

Die WiFi Analytics -Plattform von Purple lässt sich nahtlos in 802.1X-gesicherte Netzwerke integrieren, um First-Party-Dateneinblicke zu liefern, ohne die Sicherheitsarchitektur der zugrunde liegenden Infrastruktur zu beeinträchtigen. Die 29 Milliarden Datenpunkte, die über das Netzwerk von Purple erfasst wurden, beweisen, dass Sicherheit und Analytics sich ergänzende und keine konkurrierenden Ziele sind.

Für das Feedback- und Experience-Management parallel zu Ihrer sicheren Netzwerkbereitstellung lesen Sie unser Venue Feedback Playbook .

Schlüsseldefinitionen

SCEP (Simple Certificate Enrollment Protocol)

Ein IETF-standardisiertes Protokoll (RFC 8894), das die Registrierung von X.509-Zertifikaten für verwaltete Geräte automatisiert. Das Gerät generiert seinen eigenen privaten Schlüssel lokal und sendet über ein Gateway nur eine Zertifikatsignierungsanforderung (CSR) an die Zertifizierungsstelle (CA). Der private Schlüssel verlässt das Gerät nie.

IT-Teams stoßen auf SCEP bei der Konfiguration von MDM-Plattformen (Intune, Jamf), um WiFi-Authentifizierungszertifikate in großem Umfang bereitzustellen. Es ist der empfohlene Mechanismus für 802.1X EAP-TLS-Bereitstellungen, da der private Schlüssel auf dem Endgerät hardwaregeschützt ist.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

Die sicherste 802.1X-Authentifizierungsmethode. Sowohl das Client-Gerät als auch der RADIUS-Server weisen sich mit X.509-Zertifikaten aus. Keine der beiden Seiten kann sich ohne ein gültiges, nicht widerrufenes Zertifikat aus der vertrauenswürdigen CA-Hierarchie authentifizieren.

EAP-TLS ist das Ziel-Authentifizierungsprotokoll, das durch die SCEP-Zertifikatsbereitstellung ermöglicht wird. Es erfüllt die PCI DSS 4.0-Anforderung 8.6 und ist für WPA3-Enterprise-192-Bit-Bereitstellungen (Suite B) erforderlich.

PKCS (Public Key Cryptography Standards)

Ein Zertifikatsbereitstellungsmechanismus, bei dem die CA sowohl das öffentliche als auch das private Schlüsselpaar zentral generiert und an das Endgerät überträgt. Die CA behält eine Kopie des privaten Schlüssels, was ein Key Escrow ermöglicht.

IT-Teams wählen bei der Konfiguration von Zertifikatsprofilen in Intune zwischen SCEP und PKCS. PKCS eignet sich für die S/MIME-E-Mail-Verschlüsselung, bei der eine Hinterlegung von Schlüsseln (Key Escrow) erforderlich ist. Für die WiFi-Authentifizierung wird es nicht empfohlen, da der private Schlüssel über das Netzwerk übertragen wird.

NDES (Network Device Enrollment Service)

Eine Microsoft Windows Server-Rolle, die als SCEP-Gateway zwischen einer MDM-Plattform und einer Zertifizierungsstelle (CA) fungiert. Sie validiert Registrierungsanfragen von Geräten und leitet CSRs an die CA weiter.

NDES ist eine erforderliche Infrastrukturkomponente für On-Premises-SCEP-Bereitstellungen mit Microsoft Intune. Es muss extern über einen Anwendungsproxy veröffentlicht werden, um Remote-Geräten die Registrierung zu ermöglichen. Cloud-SCEP-Gateways sind eine Alternative, welche die Abhängigkeit von On-Premises-NDES aufhebt.

CRL (Certificate Revocation List)

Eine von der CA veröffentlichte Liste, die die Seriennummern von Zertifikaten enthält, die vor ihrem Ablaufdatum widerrufen wurden. RADIUS-Server überprüfen die CRL, um sicherzustellen, dass sich Geräte mit widerrufenen Zertifikaten nicht authentifizieren können.

Die CRL-Überprüfung ist die betriebliche Kontrollmaßnahme, die den Zertifikatswiderruf erzwingt. IT-Teams müssen ihren RADIUS-Server so konfigurieren, dass er die CRL bei jedem Authentifizierungsversuch überprüft und sicherstellt, dass der CRL-Verteilungspunkt (CDP) hochverfügbar ist.

802.1X

Ein IEEE-Standard für die portbasierte Netzwerkzugriffskontrolle. Er definiert das dreiteilige Authentifizierungs-Framework (Supplicant, Authenticator, Authentication Server), das in Enterprise-WiFi und kabelgebundenen Netzwerken verwendet wird.

802.1X ist das Framework, innerhalb dessen EAP-TLS und SCEP betrieben werden. IT-Teams stoßen darauf bei der Konfiguration von WPA2-Enterprise oder WPA3-Enterprise SSIDs und bei der Einrichtung von RADIUS-Server-Richtlinien.

RADIUS (Remote Authentication Dial-In User Service)

Ein Netzwerkprotokoll, das eine zentrale Authentifizierung, Autorisierung und Benutzerabrechnung (AAA) für den Netzwerkzugriff bereitstellt. Bei 802.1X-Bereitstellungen validiert der RADIUS-Server Client-Zertifikate und setzt VLAN-Zuweisungsrichtlinien durch.

Der RADIUS-Server ist der Entscheidungspunkt für die Authentifizierung in jeder 802.1X-Bereitstellung. Typische Implementierungen sind Microsoft NPS, FreeRADIUS und Cisco ISE. Er muss mit der vertrauenswürdigen CA-Kette und einer strengen CRL- oder OCSP-Überprüfung konfiguriert werden.

CSR (Certificate Signing Request)

Ein Block aus codiertem Text, der von einem Gerät generiert wird und den öffentlichen Schlüssel sowie die Identitätsinformationen des Geräts enthält. Das Gerät sendet die CSR (über das SCEP-Gateway) an die CA, um ein signiertes Zertifikat anzufordern. Der zugehörige private Schlüssel wird auf dem Gerät generiert und dort behalten.

Die CSR ist das zentrale Element im SCEP-Registrierungsfluss. IT-Teams konfigurieren das CSR-Format (Subjektname, Schlüsselverwendung, EKU) im SCEP-Zertifikatsprofil innerhalb ihrer MDM-Plattform.

PKI (Public Key Infrastructure)

Die Kombination aus Hardware, Software, Richtlinien und Verfahren, die zum Erstellen, Verwalten, Verteilen und Widerrufen digitaler Zertifikate erforderlich ist. Eine standardmäßige Enterprise-PKI besteht aus einer Offline-Root-CA und einer Online-Issuing-CA.

Eine PKI ist die Voraussetzung für jede EAP-TLS-Bereitstellung. IT-Teams müssen eine zweistufige CA-Hierarchie entwerfen und bereitstellen, bevor sie SCEP konfigurieren. Cloud-gehostete PKI-Dienste reduzieren den Infrastrukturaufwand für verteilte Standorte.

VLAN (Virtual Local Area Network)

Ein logisches Netzwerksegment, das den Datenverkehr auf Layer 2 isoliert. Bei 802.1X-Bereitstellungen weisen RADIUS-Server Geräte basierend auf Zertifikatsattributen, Benutzeridentität oder Richtlinien dynamisch VLANs zu.

Die VLAN-Zuweisung über RADIUS ist der Mechanismus, der die Netzwerksegmentierung in Enterprise-WiFi erzwingt. IT-Teams nutzen sie, um POS-Geräte in VLANs im PCI-Bereich, Gastgeräte in reine Internet-VLANs und Mitarbeitergeräte in Unternehmens-VLANs aufzuteilen – alles über eine einzige physische Infrastruktur.

Ausgearbeitete Beispiele

Ein Premier Inn-Hotel mit 200 Zimmern muss sicheres WiFi für 150 iOS-Geräte des Housekeepings bereitstellen. Die Mitarbeiter teilen sich derzeit ein WPA2-Personal-Passwort mit den Gästen, was ein Compliance- und Betriebsrisiko darstellt. Der IT-Leiter muss das geteilte Passwort ohne Unterbrechung des täglichen Betriebs eliminieren.

Der IT-Leiter implementiert eine Jamf-gesteuerte SCEP-Bereitstellung in drei Phasen. Phase eins: Das Root-CA-Zertifikat wird über ein Jamf-Profil für vertrauenswürdige Zertifikate auf alle 150 iOS-Geräte übertragen, wobei die Smart Group „Housekeeping Devices“ als Ziel dient. Phase zwei: Ein SCEP-Zertifikatsprofil wird bereitgestellt, das die Geräte an einen über Azure AD App Proxy veröffentlichten NDES-Server verweist. Der Subject Name verwendet CN={{SERIALNUMBER}}, um das Zertifikat an die Gerätehardware zu binden. Phase drei: Ein WPA2-Enterprise WiFi-Profil wird übertragen, das EAP-TLS spezifiziert und mit dem SCEP-Zertifikat verknüpft. Die Geräte authentifizieren sich lautlos. Die SSID mit dem geteilten Passwort wird stillgelegt. Der RADIUS-Server wird mit strenger CRL-Prüfung und VLAN-Zuweisung konfiguriert: Housekeeping-Geräte landen im VLAN 20 (Betrieb), Gäste-Geräte im VLAN 10 (nur Internet).

Kommentar des Prüfers: Die wichtigsten Designentscheidungen sind hier Gerätezertifikate (keine Benutzerzertifikate) für gemeinsam genutzte Hardware und die VLAN-Zuweisung über Zertifikatsattribute anstelle der SSID. Das bedeutet, dass ein Gerät, das sich irgendwie mit der Gäste-SSID verbindet, dennoch im richtigen VLAN landet. Die Konfiguration der CRL-Prüfung ist nicht verhandelbar: Wenn ein Housekeeper das Unternehmen verlässt, wird das Gerätezertifikat bei der CA widerrufen, und der RADIUS-Server blockiert den Zugriff innerhalb des CRL-Aktualisierungsintervalls – in der Regel 15 Minuten mit OCSP oder bis zu einer Stunde mit CRL.

Eine Einzelhandelskette mit 500 Standorten muss das Corporate-WiFi für Windows-POS-Tablets sichern, auf denen Zahlungsabwicklungssoftware läuft. Die Konformität mit PCI DSS 4.0 erfordert eine Multi-Faktor-Authentifizierung auf der Netzwerkschicht. Das aktuelle WPA2-Personal-Setup besteht die Bewertung der PCI DSS-Anforderung 8.6 nicht.

Der Netzwerkarchitekt stellt EAP-TLS über Microsoft Intune und SCEP an allen 500 Standorten bereit. Die Bereitstellung verwendet Gerätezertifikate mit CN={{AAD_Device_ID}} als Subject Name, wodurch jedes Zertifikat mit dem Intune-Gerätedatensatz verknüpft wird. Die Sequenz aus drei Profilen (Trusted Root, SCEP, WiFi) wird für die Azure AD-Gruppe „POS Devices“ bereitgestellt – dieselbe Gruppe über alle drei Profile hinweg. Der RADIUS-Server weist die POS-Geräte basierend auf der Ausstellungsvorlage des Zertifikats einem dedizierten VLAN für den PCI-Bereich (VLAN 100) zu. Die CRL wird auf einem hochverfügbaren, über ein CDN gehosteten Endpunkt mit einem Gültigkeitsfenster von vier Stunden veröffentlicht. OCSP ist für die Echtzeit-Sperrungsprüfung aktiviert. Die Bereitstellung wird vom QSA anhand der PCI DSS 4.0-Anforderung 8.6 validiert.

Kommentar des Prüfers: Die PCI DSS-Konformität wird durch die Kombination aus EAP-TLS (etwas, das Sie haben – das Zertifikat) und der an den Intune-Datensatz gebundenen Geräteidentität (etwas, das Sie sind – das registrierte, verwaltete Gerät) erreicht. Die VLAN-Zuweisung über die Zertifikatsvorlage stellt sicher, dass sich POS-Geräte immer im PCI-Netzwerksegment befinden, unabhängig vom physischen Standort im gesamten 500-Standorte-Netzwerk. Der CDN-gehostete CRL-Endpunkt ist eine kritische Entscheidung für die Zuverlässigkeit: Wenn die CRL nicht erreichbar ist, schlägt die Authentifizierung fehl, was zu einem standortweiten Ausfall führt. Die Hochverfügbarkeit der CRL ist ebenso wichtig wie die Hochverfügbarkeit des RADIUS-Servers selbst.

Übungsfragen

Q1. Sie haben Trusted Root- und SCEP-Zertifikatsprofile für die Benutzergruppe "All Staff" in Intune bereitgestellt. Anschließend stellen Sie das WiFi-Profil für die Gerätegruppe "Corporate Devices" bereit. Die Geräte erhalten die Zertifikate, aber das WiFi-Profil zeigt in der Intune-Konsole "Fehler" an. Was ist die wahrscheinlichste Ursache und wie beheben Sie das Problem?

Hinweis: Überlegen Sie, wie Intune Abhängigkeiten zwischen Profilen auflöst und was passiert, wenn Profile auf unterschiedliche Gruppentypen verweisen.

Musterlösung anzeigen

Die Ursache ist eine Diskrepanz bei der Gruppenzuweisung. Das WiFi-Profil hängt vom SCEP-Profil ab, welches wiederum vom Trusted Root-Profil abhängt. Intune kann diese Abhängigkeiten nicht auflösen, wenn die Profile auf unterschiedliche Gruppentypen (Benutzer vs. Geräte) verweisen. Lösung: Stellen Sie alle drei Profile für dieselbe Gruppe bereit. Wenn das WiFi-Profil auf "Corporate Devices" (eine Gerätegruppe) verweist, müssen die SCEP- und Trusted Root-Profile ebenfalls auf "Corporate Devices" verweisen. Alternativ können Sie alle drei in eine Benutzergruppe verschieben, falls eine benutzerbasierte Authentifizierung erforderlich ist.

Q2. Das iPad einer Hotel-Reinigungskraft wird als gestohlen gemeldet. Sie deaktivieren sofort das Active Directory-Konto der Reinigungskraft. Am nächsten Morgen verbindet sich das gestohlene iPad immer noch mit dem WPA2-Enterprise-Netzwerk des Hotels. Warum ist das so und welche zwei Maßnahmen ergreifen Sie, um dies zu verhindern?

Hinweis: Denken Sie darüber nach, was der RADIUS-Server während der EAP-TLS-Authentifizierung tatsächlich validiert und welche Kontrollen die Gültigkeit von Zertifikaten regeln.

Musterlösung anzeigen

Das Deaktivieren des AD-Kontos widerruft nicht das auf dem iPad gespeicherte Client-Zertifikat. Der RADIUS-Server validiert während der EAP-TLS-Authentifizierung das Zertifikat, nicht den Status des AD-Kontos. Die zwei erforderlichen Maßnahmen sind: (1) Widerrufen des Gerätezertifikats bei der CA – dadurch wird die Seriennummer des Zertifikats zur CRL hinzugefügt; (2) Sicherstellen, dass der RADIUS-Server mit einer strikten CRL-Prüfung konfiguriert ist, damit er die aktualisierte CRL abruft und das widerrufene Zertifikat beim nächsten Authentifizierungsversuch ablehnt. Für einen schnelleren Widerruf konfigurieren Sie OCSP auf dem RADIUS-Server für Statusprüfungen des Zertifikats in Echtzeit.

Q3. Eine Einzelhandelskette stellt 802.1X WiFi an 500 POS-Standorten bereit. Der Sicherheitsarchitekt schlägt vor, die PKCS-Zertifikatsbereitstellung anstelle von SCEP zu verwenden, um die Bereitstellung eines NDES-Servers zu vermeiden. Der QSA, der das PCI DSS 4.0-Assessment prüft, äußert Bedenken. Was ist das Bedenken und was ist die richtige Empfehlung?

Hinweis: Berücksichtigen Sie, was PCI DSS über die Handhabung privater Schlüssel aussagt und was PKCS bei der Bereitstellung mit dem privaten Schlüssel macht.

Musterlösung anzeigen

Das Bedenken des QSA besteht darin, dass PKCS den privaten Schlüssel über das Netzwerk von der CA an das Gerät überträgt. PCI DSS 4.0 Anforderung 3.5 verlangt, dass private Schlüssel, die für die Authentifizierung verwendet werden, vor Offenlegung geschützt sind. Die Übertragung des privaten Schlüssels über das Netzwerk – selbst verschlüsselt – birgt ein Risiko, das SCEP vollständig eliminiert. Die richtige Empfehlung lautet, SCEP zu verwenden, bei dem der private Schlüssel auf dem POS-Gerät generiert wird und dieses nie verlässt. Um die lokale NDES-Infrastruktur zu vermeiden, sollte der Architekt einen Cloud-SCEP-Gateway-Service evaluieren, der über eine API direkt in Intune und die CA integriert ist.

Q4. Sie entwerfen ein WiFi-Netzwerk für ein großes Konferenzzentrum, in dem jährlich mehr als 50 Veranstaltungen stattfinden. Die Geräte der Mitarbeiter müssen sich in einem sicheren 802.1X-Netzwerk befinden. Sie möchten sicherstellen, dass das Gerät eines Dienstleisters im Falle einer Kompromittierung innerhalb von 15 Minuten vom Netzwerk isoliert werden kann. Welchen Mechanismus zum Zertifikatswiderruf konfigurieren Sie und warum?

Hinweis: Vergleichen Sie CRL und OCSP im Hinblick auf die Latenz beim Widerruf und was bestimmt, wie schnell ein RADIUS-Server auf einen Widerruf reagiert.

Musterlösung anzeigen

Konfigurieren Sie OCSP (Online Certificate Status Protocol) auf dem RADIUS-Server. Ein CRL-basierter Widerruf weist eine Latenz auf, die durch die Gültigkeitsdauer der CRL bestimmt wird – typischerweise eine bis 24 Stunden. Dies bedeutet, dass ein widerrufenes Zertifikat möglicherweise immer noch authentifiziert wird, bis der RADIUS-Server die nächste CRL abruft. OCSP bietet Echtzeit-Statusantworten pro Zertifikat: Wenn ein Zertifikat bei der CA widerrufen wird, gibt der OCSP-Responder bei der nächsten Abfrage sofort den Status "widerrufen" zurück. Wenn OCSP auf dem RADIUS-Server konfiguriert ist, wird ein widerrufenes Zertifikat des Dienstleisters beim nächsten Authentifizierungsversuch blockiert, in der Regel innerhalb von Sekunden. Stellen Sie sicher, dass der OCSP-Responder hochverfügbar ist – wenn er nicht erreichbar ist und der RADIUS-Server so konfiguriert ist, dass er bei Fehlern schließt (fail closed), schlagen alle Authentifizierungen fehl.

Weiterlesen in dieser Reihe

So konfigurieren Sie SCEP für die automatisierte Zertifikatsregistrierung für Enterprise WiFi

Dieser Leitfaden erklärt, wie Sie SCEP (Simple Certificate Enrollment Protocol) für die automatisierte Zertifikatsregistrierung für Enterprise WiFi konfigurieren. Er deckt die gesamte Architektur von PKI und NDES bis hin zur MDM-Profilbereitstellung und RADIUS-Validierung ab. Er richtet sich an IT-Manager, Netzwerkarchitekten und CTOs in Hotels, Einzelhandelsketten, Stadien, Konferenzzentren und Organisationen des öffentlichen Sektors, die über Pre-Shared Keys hinausgehen und eine skalierbare, identitätsbasierte 802.1X EAP-TLS-Authentifizierung implementieren müssen. Die hardwareunabhängige Cloud-Overlay-Plattform von Purple lässt sich direkt in diese Architektur integrieren und bietet die Guest- und BYOD-WiFi-Ebene, die parallel zu Ihrem zertifikatsauthentifizierten Mitarbeiternetzwerk läuft.

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

Dieser technische Leitfaden bietet einen definitiven Architektur-Entwurf und eine schrittweise Implementierungsstrategie für die Bereitstellung von WiFi-Zertifikaten in Unternehmen mittels SCEP. Er behandelt die entscheidenden Unterschiede zwischen SCEP und PKCS, die für den Erfolg erforderliche genaue Bereitstellungsreihenfolge sowie praxiserprobte Strategien zur Risikominderung für IT-Verantwortliche.

Cisco SUDI verstehen: Hardware-basierte Geräteidentität in der Netzwerk-Zugriffskontrolle

Dieser Leitfaden beschreibt die technische Architektur von Cisco SUDI und erklärt, wie eine hardwareverankerte Identität die Netzwerk-Zugriffskontrolle sichert. Er bietet IT-Verantwortlichen konkrete Implementierungsschritte zur Bereitstellung der 802.1X EAP-TLS-Authentifizierung und zur Automatisierung des Zero Touch Provisioning an Unternehmensstandorten.