Wer schon einmal Gerätezertifikate mit Microsoft Intune verteilen wollte, kennt das Problem: Bis vor Kurzem führte kein Weg an einem klassischen NDES-Server samt Connector vorbei. Seit Anfang 2024 gibt es mit Microsoft Cloud PKI endlich eine zeitgemäße Alternative, die komplett in der Cloud läuft. In vielen Tenants, die ich betreue, besteht großes Interesse an SCEP-Zertifikaten für WLAN oder VPN. NDES hat mit seinen Altservern und der Abhängigkeit von der Netzwerktopologie aber immer wieder für Ärger gesorgt. Cloud PKI macht hier vieles erheblich einfacher.

Microsoft Cloud PKI liefert Intune eine Zertifizierungsstelle aus der Cloud

Microsoft Cloud PKI ist eine CA (Certificate Authority), die Microsoft gezielt für Intune gebaut hat und als Clouddienst betreibt. Man lizenziert sie als Add-on zur Intune Suite oder einzeln, allgemein verfügbar ist sie seit Anfang 2024. Zur Auswahl stehen zwei Modelle. Im ersten laufen Root- und Issuing-CA vollständig in Azure. Im zweiten bringt man eine eigene Root-CA mit (BYOCA) und bindet sie an eine vorhandene Umgebung mit Active Directory Certificate Services an. In reinen Cloud-Umgebungen mit Intune greift man fast immer zur gehosteten Variante; BYOCA bleibt für Unternehmen mit strengen Compliance-Vorgaben eine Option.

Der eigentliche Gewinn liegt darin, dass Mobilgeräte und Windows-Clients ihre Zertifikate zentral erhalten, ganz ohne lokale Infrastruktur. Die gesamte Konfiguration erledigt man übersichtlich im Intune Admin Center unter Tenant administration → Cloud PKI. Die CAs stehen im ganzen Mandanten zur Verfügung und werden an einer Stelle verwaltet. Die Architektur sieht im Überblick so aus:

flowchart TD
    Intune["Intune" ] --> CloudPKI["Cloud PKI (CA)" ]
    CloudPKI --> Device["Gerät" ]
    CloudPKI --> CRL["CRL-Verteilerpunkt" ]
    BYOCA["BYOCA (on-prem CA)" ] -- "optional" --> CloudPKI

Abbildung: Cloud-PKI-Architektur – Intune fordert Zertifikate bei der Cloud-CA an, optional lässt sich eine BYOCA anbinden.

SCEP-Zertifikate kommen ohne lokale Server auf die Geräte

Für viele Kunden ist Cloud PKI vor allem deshalb interessant, weil es den herkömmlichen SCEP-Stack ablöst. Bisher brauchte man für SCEP-Zertifikate einen NDES-Server, musste ihn mit Intune verbinden und die komplette PKI-Infrastruktur dahinter pflegen. Das alles fällt jetzt weg: kein NDES, keine Connector-VMs, keine Firewall-Regeln. Intune spricht direkt mit Cloud PKI und verteilt die Zertifikate über ein SCEP-Profil an die Geräte. Am WLAN (meist 802.1X mit RADIUS) oder am VPN melden sich die Geräte an wie bisher, nur stammt die Zertifikatskette jetzt vollständig aus der Cloud.

Wer schnell loslegen möchte, sollte sich an die offizielle Anleitung halten, die Bereitstellung und Konfiguration Schritt für Schritt beschreibt:

Ein Tipp aus der Praxis: Wer schon SCEP-Profile im Einsatz hat und auf Cloud PKI umsteigen will, sollte vorher alle abhängigen Konfigurationen wie WLAN-Profile prüfen und die Root-CA-Zertifikate sauber verteilen. Sonst brechen Verbindungen ab.

Die einzelnen Schritte findet ihr unter Microsoft Cloud PKI Deployment, die Einrichtung der CA unter Cloud PKI konfigurieren.

Cloud PKI deckt vor allem WLAN und VPN ab und hat klare Grenzen

In meinen Projekten dient Cloud PKI fast immer zwei Zwecken: der Geräteauthentifizierung am WLAN (RADIUS, 802.1X) und dem VPN-Zugang. Das Prinzip ist bekannt. Über SCEP erhält das Gerät ein vertrauenswürdiges Zertifikat und meldet sich damit beim jeweiligen Netzwerkdienst an. Zusätzlich zu den SCEP-Profilen kann Cloud PKI auch Trusted Certificate Profiles verteilen, damit die CA-Zertifikate auf den Clients landen.

Gut zu wissen ist, dass Cloud PKI alle ausgestellten Zertifikate zentral verwaltet und man sie über Intune auch widerrufen kann. Die CRL (Certificate Revocation List) veröffentlicht der Dienst automatisch im Internet, sodass etwa RADIUS-Server sie zur Prüfung abrufen können. An Grenzen stößt man bei sehr speziellen Setups. Designs mit mehreren CAs, ungewöhnliche Zertifikatsvorlagen oder komplexe Anforderungen wie Smartcards oder benutzerbezogene Szenarien lassen sich derzeit gar nicht oder nur eingeschränkt abbilden. Für die übliche moderne Geräteverwaltung genügt der Funktionsumfang aber vollauf.

Sperrliste und Widerruf erledigt Cloud PKI weitgehend selbst

Um die Erreichbarkeit der CRL musste man sich früher ständig sorgen, denn ohne abrufbare Sperrliste ist auf die Zertifikatsprüfung kein Verlass. Diese Sorge nimmt Cloud PKI einem ab. Microsoft stellt die CRL automatisch über einen eigenen, verwalteten Endpunkt bereit und trägt den Verweis darauf in jedes ausgestellte Zertifikat ein. Wird ein Gerät kompromittiert oder geht verloren, widerruft man im Intune Admin Center gezielt das betreffende Zertifikat. Auch das Auditing lässt sich bequem über Intune erledigen.

Für einige Sonderfälle bleibt der klassische NDES/SCEP-Stack nötig

So viele Probleme Cloud PKI auch löst, ganz verschwinden lokale NDES-Server nicht. Brauchen On-Premises-Dienste Zertifikate, die nur eine lokale PKI akzeptieren, etwa für die Smartcard-Anmeldung in einer klassischen AD-Umgebung, führt an NDES und der herkömmlichen SCEP-Anbindung kein Weg vorbei. Dasselbe gilt, wenn spezielle Zertifikatserweiterungen oder Vorlagen gefordert sind, die Cloud PKI (noch) nicht beherrscht. In diesen Fällen bleibt es vorerst beim bewährten Aufbau.

Cloud PKI hat sich in meinem Alltag als deutlicher Fortschritt erwiesen

Nach einigen Monaten mit Microsoft Cloud PKI ziehe ich eine klare Bilanz. Für den Großteil der Intune-Umgebungen ist es der lange erwartete Schritt zu einer Verwaltung, die vollständig in der Cloud stattfindet. Ich muss keine NDES-Server mehr in endlosen Runden patchen, mir keine Gedanken um die Erreichbarkeit der CRL machen und keine Connector-Fehler mehr suchen. Besonders in Projekten, in denen am Ende alles „einfach funktionieren“ soll, ist Cloud PKI schnell zur Standardlösung geworden. Wer auf komplexe hybride PKI-Szenarien angewiesen ist, fährt vorerst weiter mit dem klassischen Ansatz. Alle anderen sollten heute zu Cloud PKI greifen.