Zum Hauptinhalt springen
Deutsch

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 gemeinsam genutzte Anmeldedaten eliminieren, das Zertifikats-Lebenszyklusmanagement automatisieren und PCI DSS- und GDPR-Anforderungen im großen Stil erfüllen.

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

Diesen Leitfaden anhören

Podcast-Transkript ansehen
INTRODUCTION AND CONTEXT - 0:00 to 1:00 Hello, and welcome to this technical briefing from Purple. Today we are unpacking SCEP, the Simple Certificate Enrollment Protocol, and how to implement it for automated WiFi certificate enrollment. If you are a network architect, an IT director, or managing infrastructure for large venues like retail chains, hospitals, or stadiums, this briefing is for you. We are cutting through the noise to discuss how to deploy EAP-TLS at scale, why SCEP is the right choice for device identity, and how you can practically deploy it in your environment. Let us get straight into it. TECHNICAL DEEP-DIVE - 1:00 to 6:00 So, what exactly is the challenge we are solving here? In the world of enterprise WiFi security, EAP-TLS represents the gold standard. Unlike legacy methods such as PEAP or EAP-TTLS, which rely on user passwords, EAP-TLS mandates mutual certificate-based authentication. This means the client device must verify the network identity via a server certificate, and the network must verify the client identity via a unique client certificate. Think about the vulnerability of passwords. They can be shared, phished, or stolen. In a sprawling enterprise environment, a compromised password can grant a bad actor access to your entire internal network. EAP-TLS eliminates this vector entirely. The authentication relies on X.509 certificates issued by a Public Key Infrastructure, or PKI. But the core challenge with EAP-TLS is not the protocol itself. It is the logistics of getting unique client certificates onto thousands of devices, whether they are Windows laptops, iPads, or point-of-sale tablets. You cannot manually install certificates on thousands of devices. This is where Mobile Device Management platforms like Microsoft Intune or Jamf come into play. But how do you deliver those certificates securely? You generally have two choices: PKCS or SCEP. Let me be absolutely clear on this. For WiFi authentication, you want SCEP. Here is why it matters. With SCEP, the MDM instructs the endpoint device to generate its own private key locally. That key stays locked in the device secure hardware. It never travels across the network. The device just sends a Certificate Signing Request to your Certificate Authority via a gateway, usually an NDES server. Contrast that with PKCS, where the Certificate Authority generates the private key centrally and pushes it down over the network to the device. While PKCS has its place, say, for email encryption where you need key escrow, transmitting private keys over the network is a risk you do not need to take for network authentication. Keep the keys on the device. Use SCEP. Now, let us talk implementation. If you take away one thing from this briefing, it is this rule of thumb: Trust before Authentication. You cannot just push a WiFi profile and expect it to work. There is a strict, three-step deployment sequence you must follow. Step one: Deploy the Trusted Root Certificate. Before a device can ask for a client certificate, or trust your RADIUS server, it has to trust the issuing Certificate Authority. Push this profile first. Step two: Configure and push the SCEP Certificate Profile. This tells the device how to talk to the SCEP gateway, what format to use for its subject name, and what the certificate is actually for. In this case, Client Authentication. You must link this profile to the Trusted Root you deployed in step one. Step three: Deploy the 802.1X WiFi Profile. This is where you tie it all together. You specify the SSID, select WPA3-Enterprise, set the EAP type to EAP-TLS, and point it to the SCEP certificate for client authentication. IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - 6:00 to 8:00 Here is a major pitfall we see all the time. A client calls us and says, the certificates are on the device, but the WiFi profile shows an error in Intune. Almost every single time, this is a group targeting mismatch. If you assign the SCEP profile to a Users group, but assign the WiFi profile to a Devices group, the MDM cannot resolve the dependency. Match your targets exactly across all three profiles. Let us look at a real-world scenario. Imagine a 200-room hotel. They have 150 managed iOS devices for housekeeping staff. Currently, they use a standard password network, and staff keep sharing the password with guests. It is a genuine operational headache. By migrating to WPA2-Enterprise with EAP-TLS via SCEP, the IT Director eliminates the password entirely. The iOS devices authenticate silently in the background using their certificates. But what happens if a housekeeper loses a device, or leaves the company? Disabling their Active Directory account is not enough, because the certificate on that device is still cryptographically valid. This brings us to a critical security control: strict CRL checking. You must configure your RADIUS server to check the Certificate Revocation List. If a device goes missing, you revoke the certificate at the CA. The RADIUS server sees the revocation on the CRL and immediately blocks network access. Without strict CRL checking, your security posture is incomplete. RAPID-FIRE Q&A - 8:00 to 9:00 Let us tackle a few rapid-fire questions we often hear from CTOs. Question one: Is EAP-TLS required for WPA3 Enterprise? While WPA3 Enterprise supports other methods, EAP-TLS is strongly recommended and is required if you are implementing the WPA3 Enterprise 192-bit security suite, often called Suite B. Question two: Can we use public certificates for clients? No. You must use a private internal CA for client certificates. Public CAs are for public-facing web servers. Your internal RADIUS server needs to trust your specific internal Root CA to validate your corporate devices. Question three: How does this fit with OpenRoaming? OpenRoaming relies on Passpoint and 802.1X. Purple acts as a free identity provider for services like OpenRoaming under the Connect licence, facilitating seamless, secure roaming across venues using underlying certificate and identity frameworks. SUMMARY AND NEXT STEPS - 9:00 to 10:00 To wrap up, transitioning to automated SCEP certificate deployment delivers real, measurable returns. You will see a 70 to 80 percent reduction in WiFi-related helpdesk tickets, because users are not getting locked out or typing passwords incorrectly. More importantly, you eliminate the risk of credential harvesting, ensuring you meet compliance frameworks like PCI DSS and GDPR. Automating enterprise WiFi security is not just about locking things down. It is about making the secure path the easiest path for your users. Your next steps: audit your current 802.1X deployment. If you are still relying on passwords, design your PKI and plan the migration to EAP-TLS with SCEP. Check whether your RADIUS server is enforcing strict CRL or OCSP checking. And verify that your three deployment profiles all target the same group. Thank you for listening to this technical briefing from Purple. For more detailed deployment guides and to understand how our analytics and identity platforms can integrate with your secure networks, visit purple dot ai.

header_image.png

Executive Summary

Für Standortbetreiber, die Guest WiFi in Hotels, Einzelhandelsflächen, Stadien und Konferenzzentren anbieten, ist die Nutzung von Pre-Shared Keys oder einfachen Captive Portals für den Netzwerkzugriff von Mitarbeitern ein Sicherheitsrisiko. Moderne Netzwerkarchitektur erfordert 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 für Tausende von Windows-, iOS- und Android-Geräten bereit, ohne Ihren Helpdesk zu überlasten?

Die Antwort lautet SCEP – das Simple Certificate Enrollment Protocol. Im Jahr 2020 von der IETF als RFC 8894 formalisiert, automatisiert SCEP die Zertifikatsregistrierung für verwaltete Geräteflotten. In Kombination mit einer 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 vollständigen SCEP-Implementierungs-Workflow: PKI-Architektur, NDES-Gateway-Konfiguration, die obligatorische dreistufige MDM-Bereitstellungssequenz und die betrieblichen Kontrollen – insbesondere die CRL-Prüfung und das Gruppen-Targeting –, die darüber entscheiden, ob ein Rollout erfolgreich ist oder ins Stocken gerät. Zwei Praxisbeispiele veranschaulichen diesen Ansatz in der Hotellerie und im Einzelhandel. Purple ist an über 80.000 Live-Standorten aktiv und bedient 350 Millionen eindeutige Nutzer; die hier beschriebenen Muster spiegeln wider, was in dieser Größenordnung funktioniert.

Technischer Deep-Dive

Was SCEP tatsächlich tut

SCEP befindet sich zwischen Ihrer MDM-Plattform und Ihrer Zertifizierungsstelle (Certificate Authority, CA). Es bietet einen standardisierten, HTTP-basierten Mechanismus für Geräte, um X.509-Zertifikate anzufordern, zu empfangen und zu erneuern, ohne dass domänengebundene Anmeldedaten oder ein manuelles Eingreifen des Administrators erforderlich sind. Das Protokoll wurde ursprünglich in den frühen 2000er Jahren entwickelt und fand in MDM-Umgebungen von Unternehmen breite Anwendung, bevor die IETF es offiziell als RFC 8894 veröffentlichte.

Der sechsstufige Registrierungsablauf funktioniert wie folgt. 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 (Certificate Signing Request, CSR). Drittens validiert das SCEP-Gateway die Autorisierung des Geräts mithilfe eines Challenge-Passworts oder eines in der MDM-Richtlinie eingebetteten OTP. Viertens leitet das Gateway die validierte CSR an die 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 erneut, ohne dass ein Benutzer oder Administrator eingreifen muss.

scep_architecture_overview.png

SCEP vs. PKCS: Die entscheidende Weichenstellung

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

Bei SCEP wird der private Schlüssel 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 Hardware-Ebene. 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 Key-Escrow ermöglicht – dies ist zwar für die S/MIME-E-Mail-Verschlüsselung nützlich, stellt jedoch ein unnötiges Risiko für die Netzwerkauthentifizierung dar.

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

scep_vs_pkcs_comparison.png

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

802.1X und EAP-TLS: Das Authentifizierungs-Framework

IEEE 802.1X ist der portbasierte Standard zur Netzwerkzugriffskontrolle, der die WiFi-Sicherheit in Unternehmen untermauert. 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 is die sicherste EAP-Methode für 802.1X. Beide Seiten weisen sich durch Zertifikate aus: Der RADIUS-Server präsentiert sein Zertifikat dem Client, und der Client präsentiert sein über SCEP bereitgestelltes Zertifikat dem RADIUS-Server. Keine der beiden Seiten kann sich als die andere ausgeben, ohne ein gültiges, nicht widerrufenes Zertifikat aus der vertrauenswürdigen CA-Hierarchie vorzulegen. Dieses Modell der gegenseitigen Authentifizierung eliminiert Diebstahl von Anmeldedaten, Evil-Twin-Angriffe und Risiken durch Rogue Access Points mit einer einzigen architektonischen Entscheidung.

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

Für einen tieferen Einblick in die Architektur von sicherem WiFi und wie sich die zertifikatsbasierte Authentifizierung in ein umfassenderes Sicherheitskonzept einfügt, lesen Sie unseren grundlegenden Leitfaden.

Implementierungsleitfaden

Die Bereitstellungsreihenfolge ist zwingend einzuhalten. Intune und Jamf lösen Profilabhängigkeiten der Reihe nach 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, kann das WiFi-Profil nicht angewendet werden.

Schritt 1: Entwerfen Sie Ihre PKI

Bevor Sie eine MDM-Konsole anfassen, entwerfen Sie Ihre Zertifikatshierarchie. Eine zweistufige PKI ist Standard: eine Offline-Root-CA und eine Online-Ausstellungs-CA. Der private Schlüssel der Root-CA ist der Master-Vertrauensanker für Ihre gesamte Zertifikatsinfrastruktur – bewahren Sie ihn physisch vom Netzwerk getrennt (air-gapped) auf. Die ausstellende CA übernimmt die tägliche Zertifikatsausstellung und veröffentlicht die Zertifikatssperrliste (CRL) sowie den OCSP-Responder.

Bei den meisten Bereitstellungen an Enterprise-Standorten stellt Microsoft Active Directory Certificate Services (AD CS) unter Windows Server die ausstellende CA bereit. Cloud-gehostete PKI-Dienste von Anbietern wie SCEPman oder SecureW2 machen die On-Premises-Infrastruktur vollständig überflüssig und sind eine Überlegung wert für verteilte Bereitstellungen in Hotelgruppen, Einzelhandelsketten oder behördenübergreifenden Organisationen mit mehreren Standorten.

Schritt 2: NDES-Server (oder Cloud-SCEP-Gateway) bereitstellen

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 es Remote-Geräten, sich zu registrieren, bevor sie vor Ort sind, ohne dass eingehende Firewall-Ports geöffnet werden müssen.
  • Das NDES-Dienstkonto benötigt Lese- und Registrierungsberechtigungen (Read und Enroll) für die CA-Zertifikatvorlage.
  • Konfigurieren Sie die Zertifikatvorlage mit der Schlüsselverwendung (Key Usage) "Digitale Signatur" (Digital Signature) und "Schlüsselverschlüsselung" (Key Encipherment) sowie der erweiterten Schlüsselverwendung (Extended Key Usage) "Clientauthentifizierung" (Client Authentication, OID: 1.3.6.1.5.5.7.3.2).
  • Legen Sie eine angemessene Gültigkeitsdauer für das Zertifikat fest. Ein Jahr ist der Standard für Client-Zertifikate; zwei Jahre sind für Gerätezertifikate in stabilen Gerätebeständen akzeptabel.

Wenn Sie eine On-Premises-NDES-Infrastruktur vermeiden möchten, lassen sich Cloud-SCEP-Gateways über eine API direkt in Intune und Ihre CA integrieren, wodurch die IIS-Abhängigkeit vollständig entfällt.

Schritt 3: Trusted-Root-Zertifikatsprofil bereitstellen

Erstellen Sie in Ihrer MDM-Plattform ein vertrauenswürdiges Zertifikatsprofil (Trusted Certificate) und laden Sie Ihr Root-CA-Zertifikat (und alle Zwischen-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 der ausstellenden CA bei der Anforderung ihres eigenen SCEP-Zertifikats nicht vertrauen.

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

Schritt 4: SCEP-Zertifikatsprofil konfigurieren

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 (Digital Signature), Schlüsselverschlüsselung (Key Encipherment).
  • Erweiterte Schlüsselverwendung (Extended Key Usage): Clientauthentifizierung (Client Authentication, OID: 1.3.6.1.5.5.7.3.2).
  • SCEP-Server-URL: Die extern veröffentlichte NDES-URL.
  • Root-Zertifikat: Verknüpfung zum Trusted-Root-Profil aus Schritt 3.
  • Gültigkeitsdauer des Zertifikats: Muss mit der auf der CA konfigurierten Vorlage übereinstimmen.

Schritt 5: 802.1X-WiFi-Profil bereitstellen

Erstellen Sie ein WiFi-Konfigurationsprofil:

  • SSID: Geben Sie den Netzwerknamen genau so ein, wie er von Ihren Access Points übertragen wird.
  • Sicherheitstyp: WPA2-Enterprise oder WPA3-Enterprise.
  • EAP-Typ: EAP-TLS.
  • Clientauthentifizierungszertifikat: Wählen Sie das SCEP-Zertifikatsprofil aus Schritt 4 aus.
  • Servervalidierung: Geben Sie das Trusted-Root-Zertifikat aus Schritt 3 an und tragen Sie den erwarteten RADIUS-Servernamen ein. Dies verhindert, dass sich Geräte mit betrügerischen Access Points verbinden, die gefälschte Zertifikate vorweisen.

Best Practices

Strikte CRL-Prüfung auf Ihrem RADIUS-Server erzwingen

Der Zertifikatswiderruf ist die betriebliche Kontrollmaßnahme, die die Lücke zwischen der Deaktivierung eines Kontos und der Sperrung 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 prüft. Wenn die CRL nicht verfügbar ist – weil der CDP (CRL-Verteilungspunkt) nicht erreichbar ist –, fallen die meisten RADIUS-Server standardmäßig offen aus (fail open), was ein Sicherheitsrisiko darstellt. Stellen Sie sicher, dass Ihre CDPs hochverfügbar sind und Ihr RADIUS-Server so konfiguriert ist, dass er geschlossen ausfällt (fail closed), wenn die CRL nicht abgerufen werden kann.

Für einen Widerruf in Echtzeit konfigurieren Sie zusätzlich zur CRL auch 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

Verwenden Sie für gemeinsam genutzte Geräte – wie Tablets für das Hotel-Housekeeping, POS-Terminals im Einzelhandel oder Zutrittskontroll-Lesegeräte in Stadien – Gerätezertifikate anstelle von Benutzerzertifikaten. 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 an den Gerätedatensatz statt an das Ausscheiden eines Mitarbeiters gekoppelt ist.

Bei Bereitstellungen im Einzelhandel erfüllen Gerätezertifikate auf POS-Hardware zudem die PCI-DSS-Anforderung für die Identität von Geräten auf Netzwerkebene, ohne die Komplexität von Benutzeranmeldedaten am Point-of-Sale zu erhöhen.

Zertifikatsverlängerung automatisieren

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

Abgelaufene Zertifikate, die massenhafte Authentifizierungsfehler verursachen, sind der häufigste Betriebsvorfall bei 802.1X-Bereitstellungen. Die automatisierte Erneuerung über SCEP eliminiert dieses Risiko vollständig.

Netzwerke nach Zertifikatsattributen segmentieren

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

Für Betreiber im Gastgewerbe , die neben dem Mitarbeiter-WiFi auch ein Gäste-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

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

Lösung: Ü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. Bei der Bereitstellung für Geräte müssen alle drei auf eine Gerätegruppe ausgerichtet sein.

NDES gibt HTTP 403-Fehler zurück

Ursache: 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.

Lösung: Überprüfen Sie in der CA-Konsole, ob das Connector-Konto über die Berechtigungen „Lesen“ und „Registrieren“ für die Vorlage verfügt. Suchen Sie in den Firewall-Protokollen nach blockierten Anfragen, die ?operation=GetCACaps oder ?operation=PKIOperation enthalten. Diese Abfragezeichenfolgen müssen unverändert durchgelassen werden.

Geräte können Zertifikate vor dem Ablauf nicht erneuern

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

Lösung: Setzen Sie den Erneuerungsschwellenwert auf 20 % der Zertifikatsgültigkeit. Stellen Sie sicher, dass die NDES-URL über einen hochverfügbaren Reverse-Proxy veröffentlicht wird. Überwachen Sie die NDES-IIS-Protokolle auf fehlgeschlagene Erneuerungsanfragen und richten Sie proaktive Warnmeldungen ein.

RADIUS lehnt gültige Zertifikate ab

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

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

Weitere Informationen zu Netzwerkleistung und Sicherheit finden Sie in unserem Leitfaden zum Bandbreitenmanagement .

ROI & geschäftliche Auswirkungen

Der Business Case für die SCEP-basierte Zertifikatsregistrierung ist einfach. Passwortbasiertes WiFi erzeugt ein vorhersehbares Volumen an Helpdesk-Tickets: abgelaufene Passwörter, Sperrungen, Weitergabe von Zugangsdaten durch Mitarbeiter an Gäste und 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 in Gastgewerbe- und Einzelhandelsimmobilien). 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 die Multi-Faktor-Authentifizierung auf Netzwerkebene. Für Umgebungen im Gesundheitswesen entspricht es den technischen HIPAA-Sicherheitsanforderungen für den drahtlosen Netzwerkzugriff. Für Organisationen des öffentlichen Sektors unterstützt es die Zertifizierungsanforderungen von NCSC Cyber Essentials Plus für die Netzwerkzugriffskontrolle.

Für Betreiber im Transportwesen – Eisenbahnkonzessionen, Flughafenbetreiber, Busnetze – stellt die zertifikatsbasierte Authentifizierung auf Mitarbeitergeräten sicher, dass betriebliche Netzwerke mit sicherheitskritischen Daten vom Passagier-WiFi isoliert und vor Angriffen auf Zugangsdaten geschützt sind.

Die WiFi Analytics -Plattform von Purple lässt sich in 802.1X-gesicherte Netzwerke integrieren, um First-Party-Dateneinblicke zu liefern, ohne die Sicherheitsstruktur der zugrunde liegenden Infrastruktur zu beeinträchtigen. Die 29 Milliarden Datenpunkte, die im gesamten Netzwerk von Purple gesammelt wurden, zeigen, dass Sicherheit und Analysen sich ergänzende und keine konkurrierenden Ziele sind.

Für Feedback- und Erfahrungsmanagement parallel zu Ihrer sicheren Netzwerkbereitstellung lesen Sie unser Playbook für Standort-Feedback .

Schlüsseldefinitionen

SCEP (Simple Certificate Enrollment Protocol)

An IETF-standardised protocol (RFC 8894) that automates X.509 certificate enrollment for managed devices. The device generates its own private key locally and sends only a Certificate Signing Request to the CA via a gateway. The private key never leaves the device.

IT teams encounter SCEP when configuring MDM platforms (Intune, Jamf) to deploy WiFi authentication certificates at scale. It is the recommended mechanism for 802.1X EAP-TLS deployments because the private key is hardware-protected on the endpoint.

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

The most secure 802.1X authentication method. Both the client device and the RADIUS server present X.509 certificates. Neither side can authenticate without a valid, non-revoked certificate from the trusted CA hierarchy.

EAP-TLS is the target authentication protocol that SCEP certificate deployment enables. It satisfies PCI DSS 4.0 Requirement 8.6 and is required for WPA3 Enterprise 192-bit (Suite B) deployments.

PKCS (Public Key Cryptography Standards)

A certificate delivery mechanism where the CA generates both the public and private key pair centrally and transmits them to the endpoint. The CA retains a copy of the private key, enabling key escrow.

IT teams choose between SCEP and PKCS when configuring certificate profiles in Intune. PKCS is appropriate for S/MIME email encryption where key escrow is required. It is not recommended for WiFi authentication because the private key is transmitted over the network.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as the SCEP gateway between an MDM platform and a Certificate Authority. It validates device enrollment requests and forwards CSRs to the CA.

NDES is a required infrastructure component for on-premises SCEP deployments with Microsoft Intune. It must be published externally via an application proxy to allow remote devices to enroll. Cloud SCEP gateways are an alternative that eliminates the on-premises NDES dependency.

CRL (Certificate Revocation List)

A list published by the CA containing the serial numbers of certificates that have been revoked before their expiry date. RADIUS servers check the CRL to ensure devices with revoked certificates cannot authenticate.

CRL checking is the operational control that enforces certificate revocation. IT teams must configure their RADIUS server to check the CRL on every authentication attempt and ensure the CRL Distribution Point (CDP) is highly available.

802.1X

An IEEE standard for port-based network access control. It defines the three-party authentication framework (supplicant, authenticator, authentication server) used in enterprise WiFi and wired networks.

802.1X is the framework within which EAP-TLS and SCEP operate. IT teams encounter it when configuring WPA2-Enterprise or WPA3-Enterprise SSIDs and when setting up RADIUS server policies.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised authentication, authorisation, and accounting (AAA) for network access. In 802.1X deployments, the RADIUS server validates client certificates and enforces VLAN assignment policies.

The RADIUS server is the authentication decision point in every 802.1X deployment. Common implementations include Microsoft NPS, FreeRADIUS, and Cisco ISE. It must be configured with the trusted CA chain and strict CRL or OCSP checking.

CSR (Certificate Signing Request)

A block of encoded text generated by a device that contains the device's public key and identity information. The device sends the CSR to the CA (via the SCEP gateway) to request a signed certificate. The corresponding private key is generated and retained on the device.

The CSR is the core artifact in the SCEP enrollment flow. IT teams configure the CSR format (subject name, key usage, EKU) in the SCEP certificate profile within their MDM platform.

PKI (Public Key Infrastructure)

The combination of hardware, software, policies, and procedures required to create, manage, distribute, and revoke digital certificates. A standard enterprise PKI consists of an offline root CA and an online issuing CA.

PKI is the prerequisite for any EAP-TLS deployment. IT teams must design and deploy a two-tier CA hierarchy before configuring SCEP. Cloud-hosted PKI services reduce the infrastructure burden for distributed estate deployments.

VLAN (Virtual Local Area Network)

A logical network segment that isolates traffic at Layer 2. In 802.1X deployments, RADIUS servers assign devices to VLANs dynamically based on certificate attributes, user identity, or policy.

VLAN assignment via RADIUS is the mechanism that enforces network segmentation in enterprise WiFi. IT teams use it to separate POS devices onto PCI-scoped VLANs, guest devices onto internet-only VLANs, and staff devices onto corporate VLANs - all from a single physical infrastructure.

Ausgearbeitete Beispiele

A 200-room Premier Inn property needs to deploy secure WiFi for 150 iOS housekeeping devices. Staff are currently sharing a WPA2-Personal password with guests, creating a compliance and operational risk. The IT Director needs to eliminate the shared password without disrupting daily operations.

The IT Director implements a Jamf-driven SCEP deployment in three phases. Phase one: the Root CA certificate is pushed to all 150 iOS devices via a Jamf Trusted Certificate profile, targeting the 'Housekeeping Devices' smart group. Phase two: a SCEP certificate profile is deployed, directing devices to an Azure AD App Proxy-published NDES server. The subject name uses CN={{SERIALNUMBER}} to tie the certificate to the device hardware. Phase three: a WPA2-Enterprise WiFi profile is pushed, specifying EAP-TLS and linking to the SCEP certificate. Devices authenticate silently. The shared password SSID is decommissioned. The RADIUS server is configured with strict CRL checking and VLAN assignment: housekeeping devices land on VLAN 20 (operations), guest devices on VLAN 10 (internet-only).

Kommentar des Prüfers: The key design decisions here are device certificates (not user certificates) for shared hardware, and VLAN assignment via certificate attributes rather than SSID. This means a device that somehow connects to the guest SSID still lands on the correct VLAN. The CRL checking configuration is non-negotiable: when a housekeeper leaves, the device certificate is revoked at the CA, and the RADIUS server blocks access within the CRL refresh interval - typically 15 minutes with OCSP, or up to one hour with CRL.

A retail chain with 500 locations needs to secure corporate WiFi for Windows POS tablets running payment processing software. PCI DSS 4.0 compliance requires multi-factor authentication at the network layer. The current WPA2-Personal setup fails the PCI DSS Requirement 8.6 assessment.

The network architect deploys EAP-TLS via Microsoft Intune and SCEP across all 500 locations. The deployment uses device certificates with CN={{AAD_Device_ID}} as the subject name, tying each certificate to the Intune device record. The three-profile sequence (Trusted Root, SCEP, WiFi) is deployed to the 'POS Devices' Azure AD group - the same group across all three profiles. The RADIUS server assigns POS devices to a dedicated PCI-scoped VLAN (VLAN 100) based on the certificate's issuing template. The CRL is published to a highly available CDN-hosted endpoint with a four-hour validity window. OCSP is enabled for real-time revocation checking. The deployment is validated against PCI DSS 4.0 Requirement 8.6 by the QSA.

Kommentar des Prüfers: The PCI DSS alignment is achieved by the combination of EAP-TLS (something you have - the certificate) and the device identity bound to the Intune record (something you are - the enrolled managed device). The VLAN assignment via certificate template ensures POS devices are always on the PCI-scoped network segment, regardless of physical location across the 500-site estate. The CDN-hosted CRL endpoint is a critical reliability decision: if the CRL is unreachable, authentication fails, causing a site-wide outage. High availability for the CRL is as important as high availability for the RADIUS server itself.

Übungsfragen

Q1. You have deployed Trusted Root and SCEP certificate profiles to the 'All Staff' user group in Intune. You then deploy the WiFi profile to the 'Corporate Devices' device group. Devices receive the certificates but the WiFi profile shows 'Error' in the Intune console. What is the most likely cause, and how do you fix it?

Hinweis: Consider how Intune resolves dependencies between profiles and what happens when profiles target different group types.

Musterlösung anzeigen

The root cause is a group targeting mismatch. The WiFi profile depends on the SCEP profile, which depends on the Trusted Root profile. Intune cannot resolve these dependencies when the profiles target different group types (Users vs Devices). Fix: redeploy all three profiles to the same group. If the WiFi profile targets 'Corporate Devices' (a device group), the SCEP and Trusted Root profiles must also target 'Corporate Devices'. Alternatively, move all three to a user group if user-based authentication is required.

Q2. A hotel housekeeper's iPad is reported stolen. You immediately disable the housekeeper's Active Directory account. The next morning, the stolen iPad is still connecting to the hotel's WPA2-Enterprise network. Why, and what two actions do you take to prevent this?

Hinweis: Think about what the RADIUS server actually validates during EAP-TLS authentication, and what controls govern certificate validity.

Musterlösung anzeigen

Disabling the AD account does not revoke the client certificate stored on the iPad. The RADIUS server validates the certificate, not the AD account status, during EAP-TLS authentication. The two required actions are: (1) revoke the device certificate at the CA - this adds the certificate serial number to the CRL; (2) ensure the RADIUS server is configured with strict CRL checking so it fetches the updated CRL and rejects the revoked certificate on the next authentication attempt. For faster revocation, configure OCSP on the RADIUS server for real-time certificate status checks.

Q3. A retail chain is deploying 802.1X WiFi to 500 POS locations. The security architect proposes using PKCS certificate delivery instead of SCEP to avoid deploying an NDES server. The QSA reviewing the PCI DSS 4.0 assessment raises a concern. What is the concern, and what is the correct recommendation?

Hinweis: Consider what PCI DSS says about private key handling and what PKCS does with the private key during delivery.

Musterlösung anzeigen

The QSA's concern is that PKCS transmits the private key over the network from the CA to the device. PCI DSS 4.0 Requirement 3.5 requires that private keys used for authentication are protected against disclosure. Transmitting the private key over the network - even encrypted - introduces a risk that SCEP eliminates entirely. The correct recommendation is to use SCEP, where the private key is generated on the POS device and never leaves it. To avoid on-premises NDES infrastructure, the architect should evaluate a cloud SCEP gateway service that integrates directly with Intune and the CA via API.

Q4. You are designing a WiFi network for a large conference centre that hosts 50+ events per year. Staff devices need to be on a secure 802.1X network. You want to ensure that if a contractor's device is compromised, it can be isolated from the network within 15 minutes. What certificate revocation mechanism do you configure, and why?

Hinweis: Compare CRL and OCSP in terms of revocation latency and what determines how quickly a RADIUS server acts on a revocation.

Musterlösung anzeigen

Configure OCSP (Online Certificate Status Protocol) on the RADIUS server. CRL-based revocation has a latency determined by the CRL's validity period - typically one to 24 hours - meaning a revoked certificate may still authenticate until the RADIUS server fetches the next CRL. OCSP provides real-time per-certificate status responses: when a certificate is revoked at the CA, the OCSP responder immediately returns a 'revoked' status on the next query. With OCSP configured on the RADIUS server, a revoked contractor certificate is blocked on the next authentication attempt, typically within seconds. Ensure the OCSP responder is highly available - if it is unreachable and the RADIUS server is configured to fail closed, all authentications will fail.

Weiterlesen in dieser Reihe

Der Enterprise-Leitfaden für SCEP: Bereitstellung des Simple Certificate Enrollment Protocol für automatisierte Campus-WiFi-Sicherheit

Dieser technische Referenzleitfaden bietet einen definitiven Architektur-Blueprint und eine Schritt-für-Schritt-Implementierungsstrategie für die Bereitstellung von Enterprise-WiFi-Zertifikaten mit SCEP. Er behandelt die entscheidenden Unterschiede zwischen SCEP und PKCS, die genaue Bereitstellungsreihenfolge für einen erfolgreichen Rollout sowie praxisnahe Strategien zur Risikominderung für IT-Verantwortliche.

Leitfaden lesen →

Warum verbindet sich mein Gäste-WiFi nicht? Fehlerbehebung bei Captive Portal-Problemen

Dieser maßgebliche technische Leitfaden erklärt die zugrunde liegenden Mechanismen der Captive Portal-Erkennung und beschreibt die sechs primären Fehlermodi, die verhindern, dass sich das Gäste-WiFi verbindet. Er bietet IT-Managern und Netzwerkarchitekten ein praktisches Framework zur Fehlerbehebung, um HTTP-Redirect-Probleme, DNS-Konflikte und Herausforderungen bei der MAC-Randomisierung zu lösen.

Leitfaden lesen →

GDPR und Guest WiFi: Compliance-Leitfaden für Venue-Marketer und die IT

Dieser Leitfaden bietet IT-Managern und Venue-Betreibern einen praktischen Rahmen, um sicherzustellen, dass Guest WiFi-Dienste vollständig GDPR-konform sind. Er behandelt die technische Architektur, Einwilligungsmechanismen, Datenaufbewahrung und wie Compliance in ein sicheres First-Party-Daten-Asset transformiert werden kann.

Leitfaden lesen →