Microsoft Intune WiFi Zertifikatsbereitstellung über SCEP und PKCS
Dieser Leitfaden bietet eine schrittweise technische Referenz für die Bereitstellung von WiFi-Authentifizierungszertifikaten über Microsoft Intune mittels SCEP und PKCS. Er richtet sich an IT-Manager und Netzwerkarchitekten, die passwortloses 802.1X WiFi implementieren, um eine nahtlose und sichere Konnektivität in Unternehmensumgebungen zu gewährleisten.
📚 Part of our core series: Sicherheit und Authentifizierung bei Enterprise WiFi: Der vollständige Leitfaden →
- Executive Summary
- Technischer Deep-Dive: SCEP vs. PKCS
- SCEP (Simple Certificate Enrollment Protocol)
- PKCS (Public Key Cryptography Standards)
- Implementierungsleitfaden: Die Bereitstellungsreihenfolge
- Schritt 1: Bereitstellung des vertrauenswürdigen Stammzertifikat-Profils
- Schritt 2: Konfiguration des SCEP-Zertifikatprofils
- Schritt 3: Bereitstellung des 802.1X WiFi-Profils
- Best Practices & Branchenstandards
- NDES-Serverplatzierung und Sicherheit
- RADIUS und CRL-Prüfung
- Fehlerbehebung & Risikominderung
- Problem: WiFi-Profil kann nicht angewendet werden
- Problem: NDES 403 Forbidden-Fehler
- ROI & geschäftlicher Nutzen

Executive Summary
Für Unternehmensstandorte – ob in einer dynamischen Hospitality -Umgebung, einem standortübergreifenden Retail -Betrieb oder auf einem modernen Campus – ist die Nutzung von Pre-Shared Keys oder einfachen Captive Portals für das Mitarbeiter-WiFi ein Sicherheitsrisiko und ein betrieblicher Engpass. Moderne Netzwerkarchitekturen erfordern eine 802.1X-Authentifizierung mittels EAP-TLS, um sicherzustellen, dass jedes Gerät kryptografisch verifiziert wird, bevor es auf das Netzwerk zugreift.
Die Herausforderung liegt jedoch in der Verteilung: Wie stellen Sie eindeutige Client-Zertifikate auf Tausenden von Windows-, iOS- und Android-Geräten bereit, ohne Ihren Helpdesk mit Support-Tickets zu überlasten? Microsoft Intune löst dies durch automatisiertes Zertifikatslebenszyklus-Management. Durch die Nutzung von SCEP- (Simple Certificate Enrollment Protocol) oder PKCS- (Public Key Cryptography Standards) Zertifikatsprofilen können IT-Teams vertrauenswürdige Root- und Client-Zertifikate geräuschlos auf verwaltete Endpunkte übertragen.
Dieser Leitfaden bietet einen definitiven Architektur-Blueprint und eine schrittweise Implementierungsstrategie für die Bereitstellung von Intune WiFi-Zertifikaten. Wir werden die entscheidenden Unterschiede zwischen SCEP und PKCS untersuchen, die genaue Bereitstellungsreihenfolge für den Erfolg detailliert beschreiben und praxisnahe Risikominderungsstrategien skizzieren, um sicherzustellen, dass Ihr Guest WiFi und Ihre Unternehmensnetzwerke sicher und leistungsstark bleiben.
Hören Sie sich das begleitende Podcast-Briefing an:
Technischer Deep-Dive: SCEP vs. PKCS
Bei der Entwicklung Ihrer Strategie zur Bereitstellung von Intune WiFi-Zertifikaten besteht die erste architektonische Entscheidung in der Auswahl des Zertifikatsbereitstellungsmechanismus. Intune unterstützt sowohl SCEP als auch PKCS, diese funktionieren jedoch grundlegend unterschiedlich.
SCEP (Simple Certificate Enrollment Protocol)
SCEP ist der Industriestandard für die Registrierung von Unternehmensgeräten. In einem SCEP-Workflow weist der Intune-Dienst den Endpunkt an, sein eigenes privates/öffentliches Schlüsselpaar zu generieren. Das Gerät erstellt dann eine Zertifikatsignierungsanforderung (CSR) und sendet diese über einen NDES-Server (Network Device Enrollment Service) an Ihre Zertifizierungsstelle (CA). Die CA signiert die Anforderung und gibt das öffentliche Zertifikat an das Gerät zurück.
Der entscheidende Sicherheitsvorteil von SCEP besteht darin, dass der private Schlüssel das Gerät niemals verlässt. Er wird lokal generiert, im sicheren Enklavenbereich des Geräts gespeichert (z. B. im TPM unter Windows oder in der Secure Enclave unter iOS) und niemals über das Netzwerk übertragen. Dies macht SCEP zum dringend empfohlenen Ansatz für die 802.1X-Authentifizierung.
PKCS (Public Key Cryptography Standards)
Umgekehrt generiert die Zertifizierungsstelle bei PKCS sowohl den öffentlichen als auch den privaten Schlüssel zentral. Der Microsoft Intune Certificate Connector exportiert dieses Schlüsselpaar dann sicher und überträgt es auf das Zielgerät.
Obwohl PKCS die Bereitstellung und Wartung eines NDES-Servers überflüssig macht – was den Aufwand für die Infrastruktur verringert –, birgt es ein theoretisches Sicherheitsrisiko, da der private Schlüssel über das Netzwerk übertragen wird. PKCS eignet sich im Allgemeinen besser für Anwendungsfälle, in denen ein Key-Escrow erforderlich ist, wie z. B. bei der S/MIME-E-Mail-Verschlüsselung, als für die Netzwerkauthentifizierung.

Implementierungsleitfaden: Die Bereitstellungsreihenfolge
Die erfolgreiche Konfiguration eines Intune WiFi-Profils für 802.1X erfordert die strikte Einhaltung einer bestimmten Bereitstellungsreihenfolge. Die Abhängigkeiten der Intune-Profile schreiben vor, dass das Vertrauen etabliert sein muss, bevor die Authentifizierung konfiguriert werden kann.
Schritt 1: Bereitstellung des vertrauenswürdigen Stammzertifikat-Profils
Bevor ein Gerät ein Client-Zertifikat anfordern oder Ihrem RADIUS-Server vertrauen kann, muss es der ausstellenden Zertifizierungsstelle vertrauen.
- Exportieren Sie Ihr Stamm-CA-Zertifikat (und alle Zwischen-CA-Zertifikate) als
.cer-Dateien. - Navigieren Sie im Microsoft Endpoint Manager Admin Center zu Geräte > Konfigurationsprofile > Profil erstellen.
- Wählen Sie die Zielplattform (z. B. Windows 10 und höher) und den Profiltyp Vertrauenswürdiges Zertifikat.
- Laden Sie die
.cer-Datei hoch und weisen Sie dieses Profil Ihren Zielgerätegruppen zu.
Faustregel: Weisen Sie alle zusammenhängenden Profile immer denselben Gruppen (entweder Benutzern oder Geräten) zu, um Bereitstellungskonflikte zu vermeiden.
Schritt 2: Konfiguration des SCEP-Zertifikatprofils
Sobald das Vertrauen etabliert ist, konfigurieren Sie das SCEP-Profil, um den Geräten mitzuteilen, wie sie ihr Client-Zertifikat anfordern können.
- Erstellen Sie ein neues Konfigurationsprofil und wählen Sie SCEP-Zertifikat.
- Konfigurieren Sie das Format des Antragstellernamens. Für die benutzergesteuerte Authentifizierung ist
CN={{UserPrincipalName}}der Standard. Für die Geräteauthentifizierung verwenden SieCN={{AAD_Device_ID}}. - Stellen Sie die Schlüsselverwendung auf
Digitale SignaturundSchlüsselverschlüsselungein. - Geben Sie unter Erweiterte Schlüsselverwendung
Clientauthentifizierung(OID: 1.3.6.1.5.5.7.3.2) an. - Verknüpfen Sie dieses Profil mit dem in Schritt 1 erstellten vertrauenswürdigen Stammzertifikat-Profil.
- Geben Sie die externe URL Ihres NDES-Servers an.
Schritt 3: Bereitstellung des 802.1X WiFi-Profils
Der letzte Schritt ist die Bereitstellung der WiFi-Konfiguration, die die Zertifikate mit der Netzwerk-SSID verknüpft.
- Erstellen Sie ein Wi-Fi-Konfigurationsprofil.
- Geben Sie den Netzwerknamen (SSID) exakt so ein, wie er von Ihren Wireless Access Points ausgestrahlt wird.
- Wählen Sie WPA2-Enterprise oder WPA3-Enterprise als Sicherheitstyp.
- Stellen Sie den EAP-Typ auf EAP-TLS ein.
- Wählen Sie in den Authentifizierungseinstellungen das in Schritt 2 erstellte SCEP-Zertifikatsprofil als Client-Authentifizierungszertifikat aus.
- Spezifizieren Sie das Trusted Root-Zertifikat für die Servervalidierung, um sicherzustellen, dass sich das Gerät nur mit Ihrem legitimen RADIUS-Server verbindet.

Best Practices & Branchenstandards
Beachten Sie bei der Implementierung der Intune WiFi-Zertifikatsbereitstellung die folgenden herstellerneutralen Best Practices, um Compliance und Zuverlässigkeit zu gewährleisten.
NDES-Serverplatzierung und Sicherheit
Der NDES-Server muss über das Internet erreichbar sein, damit Remote-Geräte Zertifikate bereitstellen können, bevor sie vor Ort eintreffen. Die direkte Freigabe eines internen Servers im Internet stellt jedoch ein erhebliches Sicherheitsrisiko dar.
Empfehlung: Veröffentlichen Sie die NDES-URL über den Azure AD-Anwendungsproxy. Dies ermöglicht einen sicheren Remote-Zugriff, ohne eingehende Firewall-Ports zu öffnen, und erlaubt Ihnen, Richtlinien für bedingten Zugriff auf den Registrierungsdatenfluss anzuwenden.
RADIUS und CRL-Prüfung
Die Zertifikatsbereitstellung ist nur die halbe Miete für die Sicherheit; der Widerruf ist ebenso kritisch. Wenn ein Mitarbeiter das Unternehmen verlässt, führt die Deaktivierung seines Active Directory-Kontos möglicherweise nicht sofort zum Entzug des WiFi-Zugangs, wenn sein Client-Zertifikat gültig bleibt und der RADIUS-Server die Zertifikatssperrliste (CRL) nicht strikt prüft.
Empfehlung: Konfigurieren Sie Ihren Network Policy Server (NPS) oder RADIUS-Server so, dass eine strikte CRL-Prüfung erzwungen wird. Stellen Sie sicher, dass Ihre CRL-Verteilungspunkte (CDPs) hochverfügbar sind; wenn der RADIUS-Server die CRL nicht erreichen kann, schlägt die Authentifizierung fehl, was zu einem weitreichenden Ausfall führt.
Weitere Einblicke in sicheres Netzwerkdesign finden Sie unter The Core SD WAN Benefits for Modern Businesses .
Fehlerbehebung & Risikominderung
Selbst bei sorgfältiger Planung kann es bei der Zertifikatsbereitstellung zu Problemen kommen. Hier sind häufige Fehlerszenarien und Strategien zur Behebung.
Problem: WiFi-Profil kann nicht angewendet werden
Symptom: Das Gerät erhält die Trusted Root- und SCEP-Zertifikate, aber das WiFi-Profil wird in Intune als „Fehler“ oder „Nicht anwendbar“ angezeigt.
Ursache: Dies wird fast immer durch eine fehlerhafte Gruppenzuordnung verursacht. Wenn das SCEP-Profil einer Benutzergruppe, das WiFi-Profil jedoch einer Gerätegruppe zugewiesen ist, kann Intune die Abhängigkeit nicht auflösen.
Behebung: Überprüfen Sie Ihre Zuweisungen. Stellen Sie sicher, dass die Trusted Root-, SCEP- und WiFi-Profile alle genau derselben Azure AD-Gruppe zugewiesen sind.
Problem: NDES 403 Forbidden-Fehler
Symptom: Geräte können das SCEP-Zertifikat nicht abrufen, und die NDES IIS-Protokolle zeigen HTTP 403-Fehler.
Ursache: Das Dienstkonto des Intune Certificate Connectors verfügt nicht über die erforderlichen Berechtigungen für die Zertifikatsvorlage, oder die URL-Filterung auf Ihrer Firewall blockiert die spezifischen von SCEP verwendeten Abfrage-String-Parameter.
Fehlerbehebung: Überprüfen Sie, ob das Connector-Konto über die Berechtigungen „Lesen“ und „Registrieren“ für die CA-Vorlage verfügt. Überprüfen Sie die Firewall-Protokolle, um sicherzustellen, dass URLs, die ?operation=GetCACaps enthalten, nicht blockiert werden.
ROI & geschäftlicher Nutzen
Der Übergang zur Bereitstellung von Microsoft Intune 802.1X-Zertifikaten liefert messbare Erträge in den Bereichen Sicherheit und Betrieb.
- Reduzierung von Helpdesk-Tickets: Passwortbasiertes WiFi verursacht ein erhebliches Volumen an Support-Tickets (Passwortabläufe, Sperren, Tippfehler). Die zertifikatsbasierte Authentifizierung ist für den Benutzer unsichtbar und reduziert das WiFi-bezogene Helpdesk-Volumen in der Regel um 70-80 %.
- Verbesserte Sicherheitslage: EAP-TLS eliminiert das Risiko von Credential Harvesting und Man-in-the-Middle-Angriffen (MitM). Dies ist entscheidend für die Einhaltung von Richtlinien wie PCI DSS und GDPR, insbesondere im Gesundheitswesen und im Einzelhandel.
- Nahtloses Onboarding: Für Unternehmen, die neben Windows auch große Flotten von Apple-Geräten verwalten, gewährleistet die Integration von Intune in bestehende MDM-Workflows (siehe unseren Leitfaden zu Jamf und RADIUS: Zertifikatsbasierte WiFi-Authentifizierung für Apple-Geräteflotten ) vom ersten Tag an eine einheitliche, berührungslose Bereitstellung.
Schlüsseldefinitionen
SCEP (Simple Certificate Enrollment Protocol)
Ein Protokoll, das es Geräten ermöglicht, digitale Zertifikate von einer Zertifizierungsstelle anzufordern, wobei der private Schlüssel sicher auf dem Gerät selbst generiert und gespeichert wird.
Die empfohlene Methode für die Bereitstellung von WiFi-Authentifizierungszertifikaten aufgrund ihrer hohen Sicherheit und Skalierbarkeit.
PKCS (Public Key Cryptography Standards)
Eine Reihe von Standards, bei denen sowohl der öffentliche als auch der private Schlüssel von der Zertifizierungsstelle generiert und anschließend sicher an den Endpunkt übermittelt werden.
Wird häufig für die S/MIME-E-Mail-Verschlüsselung verwendet, ist jedoch aufgrund der Netzwerkübertragung des privaten Schlüssels für WiFi weniger ideal.
NDES (Network Device Enrollment Service)
Eine Microsoft Windows Server-Rolle, die als Brücke fungiert und es Geräten ohne Domänen-Anmeldeinformationen ermöglicht, Zertifikate über SCEP zu erhalten.
Eine erforderliche Infrastrukturkomponente bei der Implementierung der SCEP-Zertifikatsbereitstellung mit Microsoft Intune.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
Die sicherste 802.1X-Authentifizierungsmethode, bei der sowohl der Server als auch der Client gültige digitale Zertifikate vorlegen müssen.
Das Ziel-Authentifizierungsprotokoll, für dessen Aktivierung die Intune-WiFi- und Zertifikatsprofile konzipiert sind.
CRL (Certificate Revocation List)
Eine von der Zertifizierungsstelle veröffentlichte Liste, die die Seriennummern von Zertifikaten enthält, die vor ihrem Ablaufdatum widerrufen wurden.
Kritisch für die Sicherheit; RADIUS-Server müssen die CRL überprüfen, um sicherzustellen, dass ausgeschiedene Mitarbeiter nicht mit einem ansonsten gültigen Zertifikat auf das WiFi zugreifen können.
Intune Certificate Connector
Ein Software-Agent, der auf einem lokalen Windows Server installiert ist und Anforderungen zwischen Microsoft Intune und der internen Zertifizierungsstelle vermittelt.
Erforderlich sowohl für SCEP- (zur Validierung von Anforderungen) als auch für PKCS-Bereitstellungen (zum Exportieren von Schlüsseln).
Subject Alternative Name (SAN)
Eine Erweiterung eines digitalen Zertifikats, die es ermöglicht, dem Zertifikat mehrere Werte (wie UPN, E-Mail oder MAC-Adresse) zuzuordnen.
Im Intune-SCEP-Profil konfiguriert, um sicherzustellen, dass der RADIUS-Server den Benutzer oder das Gerät genau identifizieren kann.
Azure AD Application Proxy
Eine Funktion, die einen sicheren Remote-Zugriff auf lokale Webanwendungen ermöglicht, ohne dass ein VPN erforderlich ist oder eingehende Firewall-Ports geöffnet werden müssen.
Die Best-Practice-Methode zur sicheren Veröffentlichung der internen NDES-Server-URL im Internet für die Registrierung von Remote-Geräten.
Ausgearbeitete Beispiele
Eine nationale Einzelhandelskette mit 500 Standorten migriert von WPA2-Personal (Pre-Shared Key) zu WPA3-Enterprise für die Tablets ihrer Filialmitarbeiter (Android Enterprise Dedicated Devices). Sie nutzen Intune als MDM. Wie sollten sie die Zertifikatsbereitstellung strukturieren?
- Stellen Sie einen NDES-Server bereit, der über den Azure AD-App-Proxy veröffentlicht wird.
- Erstellen Sie ein gerätebasiertes SCEP-Zertifikatsprofil in Intune, da es sich um dedizierte (Kiosk-)Geräte handelt, die nicht an einen bestimmten Benutzer gebunden sind. Verwenden Sie
CN={{AAD_Device_ID}}für den Antragstellernamen (Subject Name). - Stellen Sie das Root-CA-Profil für die Azure AD-Gerätegruppe „Alle Filial-Tablets“ bereit.
- Stellen Sie das SCEP-Profil für dieselbe Gruppe „Alle Filial-Tablets“ bereit.
- Erstellen Sie ein Wi-Fi-Profil, das für WPA3-Enterprise und EAP-TLS konfiguriert ist, verweisen Sie auf das SCEP-Profil und stellen Sie es für dieselbe Gruppe bereit.
- Konfigurieren Sie die zentralen RADIUS-Server so, dass sie die Gerätezertifikate mit den Active Directory-Computerobjekten abgleichen.
Ein großes Konferenzzentrum nutzt Purple für seine [WiFi Analytics](/products/wifi-analytics) und das Gäste-WiFi, muss aber das interne Mitarbeiternetzwerk absichern. Die Mitarbeiter nutzen eine Mischung aus firmeneigenen Windows-Laptops und BYOD-iOS-Geräten. Wie wird die Intune-Bereitstellung für die BYOD-Geräte gehandhabt?
- Verpflichten Sie BYOD-Benutzer, ihre iOS-Geräte über die Intune-Benutzerregistrierung zu registrieren (wodurch eine sichere Arbeitspartition erstellt wird).
- Erstellen Sie ein benutzerbasiertes SCEP-Zertifikatsprofil mit
CN={{UserPrincipalName}}. - Stellen Sie die Root-CA-, SCEP- und Wi-Fi-Profile für eine Azure AD-Benutzergruppe bereit (z. B. „Alle Mitarbeiter“).
- Wenn der Benutzer sein persönliches Gerät registriert, überträgt Intune die Profile speziell auf die verwaltete Arbeitspartition.
- Das Gerät verbindet sich unter Verwendung der Identität des Benutzers mit der Mitarbeiter-SSID, sodass der RADIUS-Server eine rollenbasierte Zugriffskontrolle (VLAN-Zuweisung) basierend auf der AD-Gruppenmitgliedschaft anwenden kann.
Übungsfragen
Q1. Sie haben die Root-CA-, SCEP- und Wi-Fi-Profile auf Ihren Windows 10-Geräten bereitgestellt. Die Zertifikate werden erfolgreich installiert, aber das Wi-Fi-Profil kann nicht angewendet werden und zeigt in der Intune-Konsole "Fehler" an. Was ist die wahrscheinlichste Ursache?
Hinweis: Überprüfen Sie, wie die Profile den Azure AD-Gruppen zugewiesen sind.
Musterlösung anzeigen
Die wahrscheinlichste Ursache ist eine Diskrepanz bei der Gruppenzuweisung. Wenn das SCEP-Profil einer Benutzergruppe, das Wi-Fi-Profil jedoch einer Gerätegruppe zugewiesen wurde, kann Intune die Abhängigkeit zwischen ihnen nicht auflösen. Alle drei Profile (Root, SCEP, Wi-Fi) müssen genau demselben Gruppentyp zugewiesen werden.
Q2. Ihr Sicherheitsteam schreibt vor, dass private Schlüssel niemals über das Netzwerk übertragen werden dürfen, selbst wenn sie verschlüsselt sind. Welche Zertifikatsbereitstellungsmethode müssen Sie in Intune verwenden und welcher zusätzliche Infrastrukturserver ist erforderlich?
Hinweis: Denken Sie daran, wo das Schlüsselpaar generiert wird.
Musterlösung anzeigen
Sie müssen SCEP (Simple Certificate Enrollment Protocol) verwenden. Da SCEP das Endgerät anweist, den privaten Schlüssel lokal zu generieren, wird dieser niemals über das Netzwerk übertragen. Diese Bereitstellung erfordert einen NDES-Server (Network Device Enrollment Service), der als Brücke zur Zertifizierungsstelle fungiert.
Q3. Ein Remote-Mitarbeiter richtet zu Hause ein neues Notebook über Windows Autopilot ein. Die Intune-Profile werden erfolgreich bereitgestellt, aber das Gerät kann das SCEP-Zertifikat nicht abrufen. Welche Infrastrukturkonfiguration fehlt wahrscheinlich?
Hinweis: Wie erreicht das Gerät die interne CA aus dem Internet?
Musterlösung anzeigen
Der NDES-Server wurde wahrscheinlich nicht im Internet veröffentlicht. Damit Remote-Geräte Zertifikate anfordern können, bevor sie im Unternehmensnetzwerk angemeldet sind, muss die NDES-URL extern erreichbar sein, idealerweise sicher veröffentlicht über den Azure AD-Anwendungsproxy.
Weiterlesen in dieser Reihe
CommScope Ruckus Integration mit Purple WiFi: Einrichtungs- und Konfigurationshandbuch
Dieses technische Referenzhandbuch bietet einen maßgeblichen Konfigurationsleitfaden für die Integration von CommScope Ruckus-Architekturen mit Purple WiFi. Es beschreibt Schritt-für-Schritt-Bereitstellungen für Guest WiFi Captive Portals, sicheres Mitarbeiter-WiFi über 802.1X und mandantenfähige Netzwerkisolierung mithilfe von Ruckus Dynamic PSK.
Allied Telesis Access Points Integration mit Purple WiFi
Dieses Handbuch bietet eine umfassende Konfigurationsanleitung für die Integration von Allied Telesis Access Points der TQ-Serie mit Purple WiFi. Es behandelt die externe Captive Portal-Weiterleitung, die 802.1X-RADIUS-Authentifizierung und die dynamische VLAN-Steuerung mithilfe von Private Pre-Shared Keys (PPSK) für sichere Multi-Tenant-Bereitstellungen.
Grandstream GWN Access Points Integration mit Purple WiFi
Dieses maßgebliche technische Handbuch beschreibt die Integration von Grandstream GWN Access Points mit dem Purple Guest WiFi und der Analytics-Plattform. Es umfasst die Konfiguration des Grandstream Captive Portal, die RADIUS AAA-Einstellungen, die Einrichtung des Walled Garden, die sichere 802.1X-Authentifizierung für Mitarbeiter mit dynamischer VLAN-Steuerung sowie die Multi-Tenant-PPSK-Segmentierung – eine praxisnahe Schritt-für-Schritt-Anleitung für MSPs und IT-Teams, die WiFi für Gäste und Mitarbeiter in großem Stil bereitstellen.