Zertifikatsmanagement ohne Server-Stress und Effizienzverlust: Der Realitätscheck zur Microsoft Cloud PKI

Den Verwaltungsapparat dahinter nennt man Public Key Infrastructure, kurz PKI. Sie ist das System, das diese digitalen Identitätsnachweise ausstellt, verwaltet und bei Bedarf auch wieder sperrt. Eine klassische PKI gehört zu den komplexesten Bausteinen einer IT-Infrastruktur. Schon in mittelständischen Unternehmen mit einigen hundert Mitarbeitenden kommen schnell mehrere tausend Zertifikate zusammen – für Notebooks, Smartphones, User, Server und Netzwerkkomponenten, jeweils mit eigenen Laufzeiten und Erneuerungszyklen. Dabei sprechen wir noch nicht von unterschiedlichen Systemen, Identitäten und Tools. Für den Betrieb sind detailliertes Architekturwissen, aufwendige Betriebsprozesse und ein Management des gesamten Zertifikats-Lebenszyklus erforderlich.

Wer heute für seine Endgeräte eine professionelle Zertifikatsversorgung samt dem nötigen Management aufbauen will, landet schnell in einem Labyrinth aus Zertifizierungsstellen (CAs), NDES-Servern (Network Device Enrollment Service) und Intune Certificate Connectors. Hinzu kommen permanente Anforderungen an Betriebssystem-Wartung und Hochverfügbarkeit, die oft mehr Aufwand verursachen, als für den eigentlichen Zweck angemessen wäre. Ein typisches Worst-Case-Szenario: Ein NDES-Server reagiert nach einem Update nicht mehr korrekt, und plötzlich können Geräte keine neuen oder erneuerten Zertifikate mehr beziehen. Laufen dann bestehende Zertifikate ab, scheitert die WLAN-Authentifizierung auf breiter Front. In solchen Momenten wird die PKI vom Sicherheitsinstrument zum geschäftskritischen Risiko.

Genau hier setzt Microsoft Cloud PKI an: Sie verlagert die Zertifizierungsstelle in die Cloud und nimmt Unternehmen den Betrieb der Zertifizierungsstellen für Endgeräte-Zertifikate ab. Doch wie weit trägt dieses Versprechen in der Praxis?

Microsoft Cloud PKI: Die Logik hinter der Lösung

Die Grundidee ist simpel: Microsoft bringt die Zertifikatsversorgung dorthin, wo viele Unternehmen ihre Endgeräte bereits verwalten – direkt in Microsoft Intune.

Anstatt eigene Server zu betreiben, nutzen Unternehmen eine private Zertifizierungsstelle, die Microsoft als Cloud-Dienst bereitstellt. Im Überblick sieht das so aus:

Eine Stammzertifizierungsstelle (Root CA) bildet die Basis des Vertrauens. Eine untergeordnete, ausstellende Zertifizierungsstelle (Issuing CA) übernimmt die eigentliche Arbeit und stellt die Zertifikate für die Endgeräte aus. Den Betrieb beider bietet Microsoft in der Cloud an.

Die Verteilung steuert Intune: Über Konfigurationsprofile erhalten die Geräte zunächst die Vertrauenskette (die Zertifikate von Root CA und Issuing CA) und anschließend ein SCEP-Profil. Damit fordern sie ihr Zertifikat automatisch beim SCEP-Endpunkt der Cloud PKI an. SCEP steht für Simple Certificate Enrollment Protocol, ein Standardverfahren zur automatisierten Zertifikatsbeantragung.

Unterstützt werden Windows, macOS, iOS/iPadOS und Android. Wichtig: Da es sich um eine private PKI handelt, müssen alle beteiligten Geräte und Dienste die Vertrauenskette kennen, damit die Zertifikate akzeptiert werden. Das gilt auch für die Gegenseite, etwa den RADIUS-Server im WLAN oder das VPN-Gateway.

Warum die Lösung für viele attraktiv ist

Für viele Organisationen verwandelt die Cloud PKI ein schwerfälliges Infrastrukturprojekt in ein fokussiertes Konfigurationsprojekt. Die Vorteile liegen vor allem in der massiven Vereinfachung:

1. Weniger Infrastruktur-Ballast 
Für die Zertifikate, die über die Cloud PKI ausgestellt werden, sind lokale Zertifizierungsstellen, NDES-Server und Intune Certificate Connectors überflüssig. Damit entfallen Betrieb, Wartung und Absicherung eigener Server sowie aufwendige Hochverfügbarkeitskonzepte. Ausnahme: Wer weiterhin PKCS-Zertifikate oder importierte Zertifikate (z. B. für S/MIME) über Intune verteilt, benötigt dafür auch künftig den Connector. 

2. Schnellerer Start
Während eine klassische PKI oft eine monatelange Planungsphase benötigt, ist die Cloud PKI innerhalb kurzer Zeit einsatzbereit. Das spart Zeit und Ressourcen.

3. Automatisierter Lebenszyklus
Von der Ausstellung über die automatische Erneuerung bis zur Sperrung, etwa wenn ein Gerät zurückgesetzt, außer Betrieb genommen oder aus Intune entfernt wird: Das Zertifikatsmanagement ist direkt an den Lebenszyklus des Endgeräts gekoppelt.

4. Nahtlose Integration
Wer Intune bereits nutzt, findet sich sofort zurecht. Administration, Berechtigungen und Gerätegruppen werden im bekannten Intune Admin Center verwaltet.

Der Business Value ist unmittelbar spürbar: Statt Server zu betreiben, zu patchen und abzusichern, konzentriert sich das IT-Team auf die Konfiguration. Die Total Cost of Ownership kann dadurch deutlich sinken. Ob sich die Rechnung lohnt, hängt allerdings auch von der Lizenzierung ab (siehe Infobox).

Der Vergleich: Klassisch vs. Cloud

• Klassische PKI: Gerät → NDES-Server (mit Intune Certificate Connector) → interne Zertifizierungsstelle – alle Komponenten im eigenen Betrieb.
• Microsoft Cloud PKI: Gerät → SCEP-Endpunkt der Cloud PKI – Betrieb durch Microsoft. In beiden Fällen liefert Intune das Profil.

Der Realitätscheck: Wo die Grenzen liegen

Vereinfachung entsteht immer durch Standardisierung. Und genau hier liegt die Grenze: Die Cloud PKI ist ein Spezialwerkzeug für Intune-verwaltete Endgeräte, kein universeller Ersatz für jede Enterprise-PKI.

Fokus auf Intune-Geräte
Die Lösung ist auf Endgeräte zugeschnitten, die in Intune registriert sind. Für alles außerhalb von Intune ist sie nicht geeignet. Dazu zählen:

• Server-Zertifikate und Netzwerkkomponenten – inklusive des RADIUS-Servers, der im WLAN-Szenario selbst ein Server-Zertifikat benötigt
• Drucker, Appliances sowie industrielle OT- und IoT-Geräte
• Linux-Systeme und Code-Signing-Szenarien

Begrenztes Customizing
Wer individuelle Zertifikatstemplates, Approval-Workflows oder proprietäre Protokolle benötigt, wird an Grenzen stoßen. So wird beispielsweise der universelle Verwendungszweck „Any Purpose“ aus Sicherheitsgründen nicht unterstützt. Zudem stellt die Cloud PKI Zertifikate ausschließlich über SCEP aus. Das PKCS-Verfahren, das etwa für S/MIME-Verschlüsselung mit Schlüsselhinterlegung genutzt wird, steht nicht zur Verfügung.

Kontrolle vs. Komfort
Mit einer Managed-Cloud-Lösung gibt man einen Teil der technischen Kontrolle ab. Das betrifft unter anderem die Auswahl des HSM (Hardware Security Module zur sicheren Schlüsselverwaltung), die kryptografische Detailkonfiguration oder den vollständigen Zugriff auf alle CA-Logs. Auch die Sperrprüfung ist vorgegeben: Sperrinformationen stellt die Cloud PKI ausschließlich über eine Sperrliste (CRL) bereit, OCSP wird aktuell nicht unterstützt. Komponenten, die zwingend OCSP erwarten, sind damit nicht kompatibel.

Die Brücke: Hybrid statt Entweder-oder

Wer die Vorteile der Cloud nutzen möchte, aber eine bestehende Unternehmens-PKI für Server und andere Workloads behalten muss, kann auf das Bring Your Own CA (BYOCA) Modell setzen.

Dabei wird in der Cloud PKI eine Issuing CA angelegt, deren Zertifikat von der bestehenden eigenen Root CA signiert wird. Der „Trust Anchor“, also die oberste Vertrauensinstanz, bleibt im eigenen Haus, während die Zertifikatsausstellung für die Intune-Geräte über die Cloud läuft. Server-, Netzwerk- und andere Nicht-Intune-Zertifikate stellt weiterhin die bestehende PKI aus. Beide Welten teilen sich aber dieselbe Vertrauenskette. Das ermöglicht eine schrittweise Modernisierung statt einer riskanten „Big-Bang“-Migration. Zu beachten: Die eigene Root CA muss dafür weiter betrieben werden, die Einsparungen beim Serverbetrieb fallen entsprechend geringer aus.

Fazit: Die richtige PKI ist die, die passt

Microsoft Cloud PKI macht den Aufbau einer sicheren Zertifikatsinfrastruktur für Endgeräte erheblich effizienter. Besonders für Unternehmen mit Microsoft 365 E5, die standardisierte Anforderungen haben und lokalen Serverbetrieb reduzieren wollen, ist die Lösung technisch wie wirtschaftlich ein Gewinn.

Sobald jedoch Zertifikate für Server, Netzwerkgeräte oder hochindividuelle Geschäftsprozesse nötig werden, braucht es weiterhin eine Unternehmens-PKI. In diesen Fällen ist eine hybride Architektur oft der bessere Weg: Die Cloud PKI versorgt die Endgeräte, die bestehende PKI alles andere, unter einem gemeinsamen Trust Anchor.

Key Takeaways:

• Effizienz: Kein NDES-Server und kein Connector für Endgeräte-Zertifikate dank Intune-Integration.
• Zielgruppe: Ideal für standardisierte Windows-, macOS- und Mobile-Umgebungen.
• Grenzen: Nicht geeignet für Server, Netzwerkkomponenten, IoT oder hochindividuelle Templates.
• Flexibilität: BYOCA erlaubt die Kombination aus Cloud-Komfort und bestehender Trust-Hierarchie.

Kurz gesagt: Microsoft Cloud PKI ist keine PKI für jeden denkbaren Anwendungsfall – aber für den richtigen Anwendungsfall möglicherweise genau die Lösung, die ein Unternehmen tatsächlich benötigt. Die Technik ist dabei nur das Werkzeug.