Microsoft Active Directory Certificate Services (ADCS) – Grundlagen, Architektur und Best Practices

von adminub | Sep. 27, 2025 | Compliance, Fachartikel, Security, Zertifikate | 0 Kommentare

Table of Contents

Consulting, Beratung

Management Summary

Microsoft Active Directory Certificate Services (ADCS) sind das Herzstück der unternehmensinternen Public-Key-Infrastruktur (PKI). Sie ermöglichen die Ausstellung und Verwaltung digitaler Zertifikate für eine Vielzahl geschäftskritischer Anwendungsfälle – von der Server- und Client-Authentifizierung über E-Mail-Verschlüsselung bis zur Code-Signierung. Eine solide PKI sorgt dafür, dass nur vertrauenswürdige Geräte, Benutzer und Dienste miteinander kommunizieren, und bildet somit eine essentielle Sicherheitsgrundlage. Dieser Artikel gibt einen praxisnahen Überblick, wie man ADCS richtig aufbaut und betreibt, welche Architekturen sich bewährt haben und welche Fallstricke es zu vermeiden gilt.

Wichtigste Empfehlungen auf einen Blick:

PKI-Design mit Sicherheitsfokus: Setzen Sie auf eine mehrstufige CA-Hierarchie (zwei Ebenen genügen meist) mit einer Offline-Stammzertifizierungsstelle für maximalen Schutz des Vertrauensankers.
Standardisierte Prozesse und Templates: Definieren Sie klare Zertifikatvorlagen und automatisieren Sie die Zertifikatsbeantragung (z.B. über Autoenrollment) zur Fehlerreduktion und konsistenten Umsetzung von Richtlinien.
Lebenszyklus im Blick behalten: Etablieren Sie ein striktes Lebenszyklus-Management für Zertifikate – von der Ausstellung über die Erneuerung bis zum Widerruf – und setzen Sie kurze Aktualisierungsintervalle für Sperrlisten (CRLs) bzw. nutzen Sie OCSP für aktuelle Sperrprüfungen.
Betrieb und Überwachung: Härten und patchen Sie die CA-Server nach Best Practices (Minimalprinzip, aktuelle Updates, HSM für private Schlüssel) und überwachen Sie wichtige Kennzahlen wie Zertifikatsausstellungen, CRL-Alter und OCSP-Antwortzeiten.
Klare Zuständigkeiten und Notfallpläne: Definieren Sie Verantwortlichkeiten für die PKI-Administration, implementieren Sie ein Vier-Augen-Prinzip für kritische Aktionen und halten Sie einen erprobten Notfallplan für Kompromittierungen oder Ausfälle bereit.

Grundlagen: Zertifikate und PKI

Anwendungsfälle für digitale Zertifikate

Unternehmenszertifikate kommen in vielen Bereichen zum Einsatz, um Identitäten zu bestätigen, Daten zu verschlüsseln oder Integrität sicherzustellen. Typische Use Cases sind:

TLS/HTTPS für Server und Dienste: Web-Server, APIs und interne Dienste nutzen Zertifikate, um gegenüber Clients ihre Identität nachzuweisen und den Datenverkehr per TLS zu verschlüsseln.
Client-Authentifizierung: Benutzer- und Geräte-Zertifikate ermöglichen die sichere Anmeldung gegenüber Diensten (z.B. Client-Zertifikate für VPN oder Web-Services bei mTLS).
Code-Signierung und Treiber-Signierung: Entwickler oder Build-Systeme signieren Programmcode und Treiber digital, damit Clients die Vertrauenswürdigkeit und Unversehrtheit von Software prüfen können.
E-Mail-Verschlüsselung und -Signatur (S/MIME): Nutzerzertifikate verschlüsseln E-Mails Ende-zu-Ende und fügen digitale Signaturen hinzu, um Absender zu authentifizieren und Manipulation auszuschließen.
Netzwerkzugang (VPN, WLAN): In 802.1X-basierten WLAN- oder VPN-Szenarien dienen Zertifikate der gegenseitigen Authentifizierung von Client und Server (z.B. EAP-TLS mit RADIUS/NPS).
IoT und Maschinenidentitäten: Zertifikate sichern die Kommunikation von Geräten, Sensoren oder Container-Diensten ab (z.B. gegenseitige TLS-Authentifizierung zwischen Microservices in einer Zero-Trust-Architektur).

Technische Funktionsweise einer PKI

Ein digitales Zertifikat bindet einen öffentlichen kryptographischen Schlüssel an eine Identität (z.B. einen Servernamen oder Benutzer). Dies basiert auf asymmetrischer Kryptografie: Jedes Zertifikat gehört zu einem Schlüsselpaar (Key Pair), bestehend aus einem privaten Schlüssel (geheim, bleibt auf dem System) und einem öffentlichen Schlüssel (wird im Zertifikat veröffentlicht). Die Certification Authority (CA) bestätigt mit ihrer digitalen Signatur, dass der öffentliche Schlüssel zum genannten Subjekt gehört und vertrauenswürdig ist.

Ein X.509-Zertifikat enthält standardisierte Felder und Erweiterungen:

Subject Name – Name des Zertifikatsinhabers (z.B. „CN=server1.intern.example.com“). Heutige Anwendungen prüfen primär die Subject Alternative Names (SAN, Subject Alternative Name), die zusätzliche Identifikatoren wie DNS-Namen, E-Mail-Adressen oder UPNs enthalten.
Key Usage (Schlüsselverwendung) – Einschränkungen, wofür der zugehörige Schlüssel verwendet werden darf (z.B. digitale Signatur, Schlüsselverschlüsselung).
Extended Key Usage (EKU, Erweiterte Schlüsselverwendung) – spezifische Einsatzbereiche des Zertifikats, etwa Serverauthentifizierung, Code Signing etc. (siehe Tabelle unten).
Validity (Gültigkeitsdauer) – Start- und Enddatum, zwischen denen das Zertifikat als gültig angesehen wird.
Authority Information Access (AIA, Stelleninformationszugriff) – Verweise, wo das Zertifikat der ausstellenden CA und ggf. ein OCSP-Responder zu finden sind.
CRL Distribution Point (CDP, Sperrlistenverteilungspunkt) – URL(s), unter denen die Sperrliste (CRL, Certificate Revocation List) der CA verfügbar ist.
Signature Algorithm – der von der CA verwendete Signaturalgorithmus (z.B. SHA-256 mit RSA).

Vertrauensstellung und Kette: CAs können hierarchisch organisiert sein. Eine PKI-Vertrauenskette beginnt bei einer Stamm-CA (Root CA), die selbstsigniert ist und als oberste Vertrauensinstanz dient. Darunter können eine oder mehrere Zwischenzertifizierungsstellen (Intermediate CAs) liegen, die von der Root CA zertifiziert sind, sowie ausstellende CAs (Issuing CAs), die die Endzertifikate an Benutzer oder Geräte ausstellen. Ein Endentity-Zertifikat wird nur dann als vertrauenswürdig anerkannt, wenn alle CA-Zertifikate in seiner Kette bis zur Root CA gültig sind und die Root CA als Vertrauensanker im System hinterlegt ist.

Lebenszyklus eines Zertifikats: Der Zertifikatsprozess beginnt mit der Schlüsselerzeugung und einer Zertifikatanfrage (CSR). Die CA prüft den Antragsteller und signiert das Zertifikat. Anschließend wird das neue Zertifikat veröffentlicht (z.B. im Verzeichnis oder Web) und dem Antragsteller bereitgestellt. Während der Nutzungsdauer muss regelmäßig der Sperrstatus geprüft werden – entweder über heruntergeladene Sperrlisten (CRLs) oder über einen Online-Abfrage-Dienst per OCSP (Online Certificate Status Protocol). Vor Ablauf der Gültigkeit sollte ein Zertifikat erneuert oder ersetzt werden. Wird ein Zertifikat kompromittiert oder vorzeitig ungültig, kann die CA es widerrufen und auf die Sperrliste setzen. Clients erkennen dann bei der nächsten Prüfung, dass diesem Zertifikat nicht mehr zu trauen ist.

Automatisierung: In Windows-Umgebungen werden viele Schritte automatisiert. Über Autoenrollment (automatische Zertifikatregistrierung) können Domänenmitglieder Zertifikate basierend auf vordefinierten Vorlagen ohne manuellen Antrag erhalten – gesteuert durch Gruppenrichtlinien und ADCS-Zertifikatvorlagen. Für Geräte oder Systeme außerhalb der Domäne bietet ADCS den Network Device Enrollment Service (NDES), der das Simple Certificate Enrollment Protocol (SCEP) bereitstellt. Darüber können z.B. Router, Drucker oder mobile Geräte (via MDM/Intune) automatisiert Zertifikate anfordern. ACME (Automated Certificate Management Environment) wiederum ist ein Protokollstandard aus dem Webumfeld (bekannt durch Let’s Encrypt) zur automatischen Zertifikatsbeantragung. ADCS unterstützt ACME nicht nativ, doch es existieren optionale Lösungen und Plugins, um ACME-Workflows mit einer Windows-PKI zu integrieren. In vielen Enterprise-Szenarien übernehmen Autoenrollment oder SCEP jedoch bereits die automatisierte Verteilung der Zertifikate.

Typische Extended Key Usages (EKUs) und ihre Verwendung:
Die folgende Tabelle zeigt einige häufige EKUs und wofür diese Zertifikate typischerweise eingesetzt werden:

EKU-Bezeichnung (Deutsch/Englisch)	Typische Verwendung
Serverauthentifizierung (Server Authentication)	TLS-Serverzertifikate für HTTPS/Webserver und andere Dienste, damit Clients die Serveridentität überprüfen können.
Clientauthentifizierung (Client Authentication)	Zertifikate für Benutzer oder Geräte zur Anmeldung gegenüber Servern (z.B. VPN-Clients, 802.1X Netzwerkzugang).
Code-Signierung (Code Signing)	Signieren von Software und Skripten, um Herausgeber-Authentizität und Integrität sicherzustellen.
E-Mail-Schutz (Email Protection)	S/MIME-Zertifikate zum Verschlüsseln und Signieren von E-Mails.
OCSP-Antwortsignierung (OCSP Signing)	Spezielles Zertifikat für OCSP-Responder, um Online-Sperrstatusantworten digital zu signieren.
Dokumentensignatur (Document Signing)	Signieren von Dokumenten (z.B. PDF, Office-Dateien) im Rahmen elektronischer Unterschriften.
IPSec-Endsystem (IP security end system)	Geräte- oder Benutzerzertifikat zur Authentifizierung in IPsec-Verbindungen (End-to-End-Sicherheit).
Smartcard-Logon (Smartcard Logon)	Benutzerzertifikat auf Smartcards für die Anmeldung an Windows-Domänen (enthält z.B. den Anmeldenamen als SAN).

ADCS im Überblick

Microsoft ADCS stellt die Komponenten bereit, um eine PKI innerhalb einer Active-Directory-Umgebung aufzubauen. Die wichtigsten Rollen und Dienste dabei sind:

Stammzertifizierungsstelle (Root CA): Oberste Vertrauensinstanz der Hierarchie. Wird idealerweise offline (nicht mit dem Netzwerk verbunden) betrieben und signiert nur die Zertifikate untergeordneter CAs.
Untergeordnete CA / ausstellende CA (Subordinate/Issuing CA): Domain-Mitglied (Enterprise CA), online und für das Ausstellen der Endentity-Zertifikate zuständig. Nutzt Active Directory zur Veröffentlichung und Zertifikatvorlagen für standardisierte Anträge.
Zwischen- oder Richtlinien-CA (Policy CA): Optionale zweite Hierarchie-Ebene in einer dreistufigen PKI. Dient in großen Umgebungen der organisatorischen Trennung von Zertifikatsrichtlinien – sie zertifiziert die ausstellenden CAs, wird aber selbst meist offline gehalten.
Zertifizierungsstellen-Webregistrierung (Web Enrollment): Optionales Web-Interface zur manuellen Zertifikatsbeantragung und -abholung (URL meist http://<CA-Server>/certsrv). Aufgrund begrenzter Sicherheit und Automatisierung wird es in modernen Umgebungen selten benötigt.
Online Responder (OCSP-Responder): Dienst für Echtzeit-Sperrstatusabfragen via OCSP. Er beantwortet OCSP-Anfragen signiert mit einem speziellen OCSP-Signer-Zertifikat, damit Clients einzelne Zertifikate schnell auf Gültigkeit prüfen können (anstatt ganze CRLs zu laden).
Network Device Enrollment Service (NDES): Implementiert SCEP, sodass Netzwerkgeräte und MDM-verwaltete Mobilgeräte Zertifikatsanträge stellen können. Läuft auf einem IIS-Webserver und fungiert als Registrierungs-Proxy zwischen Geräten und der CA.
Zertifikatvorlagen (Certificate Templates): In AD gespeicherte Objekte, die Aufbau und Eigenschaften von Zertifikaten vordefinieren (z.B. Felder wie Subject/SAN, erlaubte Key Usage/EKU, Gültigkeitsdauer, Schlüssellänge) und festlegen, wer sie beantragen darf. Erlauben Autoenrollment und konsistente Ausstellung.
Certificate Enrollment Web Services (CEP/CES): Optionale Webdienste (ab Server 2008 R2) zur Zertifikatregistrierung über HTTPS. Ermöglichen Domänenmitgliedern auch ohne direkte AD-Anbindung Zertifikate zu beantragen (z.B. übers Internet oder in Cross-Forest-Szenarien). In vielen Fällen ersetzen jedoch Group Policies und MDM-Lösungen diese Komponenten.

Veröffentlichung von Zertifikatsdaten (AIA/CDP): Damit Zertifikate validiert werden können, müssen CA-Zertifikate und Sperrlisten leicht auffindbar sein. ADCS veröffentlicht diese an typischen Pfaden:

Active Directory (LDAP): Enterprise CAs integrieren sich ins AD. Root- und CA-Zertifikate sowie CRLs können im AD gespeichert werden (Configuration Partition) und sind über LDAP-URLs abrufbar. Domänenrechner finden so automatisch die Zertifikatskette und Sperrinformationen. Voraussetzung ist jedoch AD-Konnektivität.
HTTP-URLs: Üblich ist die Publikation von AIA und CDP über Webserver (z.B. http://pki.firma.de/…). HTTP ist auch für nicht-AD-verbundene Clients erreichbar und leichter redundant auslegbar (Load Balancer, geografische Spiegelung). Clients und Geräte können die CA-Zertifikate und CRLs per HTTP herunterladen; zudem lassen sich HTTP-Downloads einfacher cachen, was die Latenz reduziert.

Best Practice ist, mehrere redundante Pfade anzubieten – etwa LDAP für interne Szenarien und HTTP für alles, was LDAP nicht nutzen kann. Wichtig sind auch kurze Zugriffszeiten: Eine CRL-Abfrage sollte Anwendungen nicht merklich verzögern. Bei sehr großen CRLs empfiehlt sich der Einsatz von Delta-CRLs (für Änderungen zwischen Base-CRLs) oder primär OCSP, um die Datenmengen klein und aktuell zu halten.

ADCS-Komponenten und ihr Zweck:
Die Tabelle gibt einen Überblick über die Hauptkomponenten von ADCS und wofür sie eingesetzt werden:

ADCS-Komponente	Zweck / Beschreibung
Stamm-CA (Root CA)	Oberste Vertrauensinstanz, signiert nur CA-Zertifikate. Sollte offline betrieben werden, um den privaten Schlüssel maximal zu schützen.
Untergeordnete CA (Issuing CA)	Online-CA (Enterprise), stellt Endzertifikate für Nutzer, Computer, Dienste aus. Integriert in AD, nutzt Zertifikatvorlagen und veröffentlicht CRLs/AIA.
Richtlinien-CA (Policy CA)	Optionale Zwischenebene in dreistufiger Hierarchie. Zertifiziert die Issuing CAs, dient der organisatorischen Trennung (unterschiedliche Richtlinien pro Bereich). Wird meist offline gehalten.
Web Enrollment Service	Webportal zur manuellen Zertifikatsanforderung/-ausgabe. In produktiven Umgebungen aus Sicherheitsgründen oft deaktiviert (Automatisierung statt manueller Web-Anträge).
Online Responder (OCSP)	Antwortdienst für Echtzeit-Sperrstatus. Verbessert die Prüfgeschwindigkeit, indem er den Status einzelner Zertifikate auf Anfrage signiert bestätigt.
NDES (SCEP-Dienst)	Serverrolle zur automatisierten Zertifikatsregistrierung von Geräten über SCEP. Wird für Netzwerkhardware und Mobile-Device-Management (Intune usw.) eingesetzt, um Geräten Zertifikate von der ADCS zu beschaffen.
Zertifikatvorlagen	Definitionen in AD für Zertifikatstypen: Legen Felder (Subject/SAN), Erweiterungen (Key Usage/EKU), Gültigkeitsdauer, Schlüsselstärke und Berechtigungen fest. Ermöglichen Autoenrollment und standardisieren die Ausstellung.
CEP/CES Webdienste	Web Services für Zertifikatregistrierung über HTTP, auch außerhalb direkter Domänenanbindung. Ermöglichen z.B. Cross-Forest-Enrollment oder die Anbindung extern befindlicher Clients an die PKI.

Referenzarchitekturen

Je nach Unternehmensgröße, Sicherheitsanforderungen und Anwendungsfällen gibt es verschiedene PKI-Architekturen. Im Folgenden einige gängige Designmuster mit ihren Einsatzbereichen, Vor- und Nachteilen:

Zweistufige PKI (Offline-Root + Issuing CAs)

Eine zweistufige Hierarchie (Offline-Stamm und eine oder mehrere untergeordnete ausstellende CAs) ist der bewährte Standard. Die Root-CA bleibt vom Netz getrennt, signiert nur CA-Zertifikate und gelegentlich CRLs; die Issuing CAs sind online und stellen Endzertifikate aus. Vorteile: Sehr hoher Schutz des Root-Schlüssels und flexible Erweiterbarkeit (mehrere Issuing CAs in verschiedenen Bereichen oder Standorten möglich). Nachteile: Etwas zusätzlicher Aufwand, da die Root-CA für gewisse Aktionen (neue Sub-CA, CRL-Publikation) temporär aktiviert werden muss. Insgesamt bietet dieses Design die beste Balance zwischen Sicherheit und Betriebsaufwand und wird in den meisten Fällen empfohlen.

Dreistufige PKI (Offline-Root + Policy CA + Issuing CAs)

Eine dreistufige PKI fügt als zweite Ebene eine Richtlinien-CA ein, die zwischen Root und Issuing CAs geschaltet ist. Vorteile: Ermöglicht streng getrennte Ausstellungsrichtlinien – die Policy-CA kann z.B. Zertifikate für unterschiedliche Bereiche an verschiedene Issuing CAs delegieren und so Kompromittierungen eingrenzen (man könnte eine ganze Teil-PKI sperren, ohne alle zu beeinflussen). Nachteile: Deutlich komplexer (zwei Offline-CAs zu betreuen, längere Kettenvalidierung) und nur in Spezialfällen wirklich nötig. Ohne klare Anforderungen an eine separate Policy-Ebene bringt eine Dreistufigkeit meist mehr Aufwand als Nutzen.

Mehrstandort-Design (AIA/CDP-Verteilung, Geo-Redundanz)

In global verteilten Organisationen wird oft eine zweistufige PKI mit mehreren Issuing CAs an verschiedenen Standorten betrieben. Vorteile: Redundanz und geringe Latenz – jeder Standort hat eine eigene CA, wodurch ein Ausfall lokal begrenzt bleibt und Zertifikatsanfragen oder Sperrlistenabfragen schneller gehen. Nachteile: Höherer Koordinationsaufwand – alle CAs müssen identische Richtlinien/Vorlagen nutzen, und die Verteilung der CRLs sowie OCSP-Responder muss weltweit verfügbar und konsistent sein (z.B. über replizierte Webserver oder Content Delivery Networks). Die gemeinsame Root ist ein Single Point of Trust; deren Schutz bleibt zentral kritisch.

Spezialarchitektur für Gerätezertifikate (NDES/SCEP, Intune/MDM, 802.1X)

Für Geräte, die nicht direkt in AD integriert sind (z.B. mobile BYOD, Netzwerktechnik), wird ADCS oft mit dem Network Device Enrollment Service (NDES) und einer MDM-Lösung kombiniert. Vorteile: Auch nicht-domänengebundene Geräte erhalten automatisiert Zertifikate (für WLAN, VPN etc.), was die Sicherheit z.B. gegenüber Pre-Shared-Keys deutlich erhöht. Nachteile: Zusätzliche Infrastruktur (NDES-Server) und potenzielle Angriffsvektoren – der NDES-Dienst muss gut abgesichert werden, damit er nicht missbraucht werden kann (z.B. nur bestimmte Templates, starkes Passwort für SCEP-Challenge). Ebenso erfordert die Einrichtung von Intune/MDM-Profilen sorgfältiges Testen, damit alle Komponenten reibungslos zusammenspielen.

Isolierte/Partner-PKI und Cross-Forest-Szenarien

In manchen Fällen existieren mehrere PKIs, die zueinander in Beziehung stehen (z.B. zwischen Unternehmen oder in getrennten AD-Forests). Vorgehen: Entweder vollständig getrennt halten (jede Umgebung vertraut nur ihrer eigenen Root), oder gezielt Vertrauensanker austauschen. Man kann z.B. das Root-Zertifikat der Partner-PKI als vertrauenswürdige Stammzertifizierungsstelle importieren, damit deren Zertifikate akzeptiert werden. Seltener wird eine wechselseitige Cross-Zertifizierung eingerichtet oder eine Bridge-CA genutzt – diese Ansätze sind komplex und werden nur bei striktem Bedarf eingesetzt. Best Practice: So wenig gegenseitiges Vertrauen wie möglich, nur so viel wie nötig. Einzelne Dienste kann man alternativ durch gezielt ausgegebene Partner-Zertifikate ermöglichen, statt beide PKIs global zu koppeln. Dadurch bleibt ein Kompromiss in einer PKI auf diese begrenzt.

Fünf praxisnahe Anwendungsbeispiele

TLS-Zertifikate für interne Server und Dienste

Szenario: Interne Webserver, Anwendungsserver oder Datenbankdienste sollen über HTTPS bzw. TLS abgesichert werden. Dazu benötigt jeder Server ein Zertifikat, dem die Clients (Browser, Anwendungen) vertrauen.

Umsetzung: Erstellen Sie in ADCS eine Zertifikatvorlage basierend auf der vordefinierten „Webserver“-Vorlage. Stellen Sie sicher, dass Serverauthentifizierung (Server Authentication) als EKU gesetzt ist und die Vorlage im Bereich Erweiterungen ein Subject Alternative Name einschließt (für DNS-Namen). In der Regel konfiguriert man die Vorlage so, dass der DNS-Name des Computers automatisch als SAN ins Zertifikat übernommen wird. Setzen Sie die Schlüssellänge z.B. auf mindestens 2.048 Bit RSA und markieren Sie den privaten Schlüssel als nicht exportierbar. Die Gültigkeitsdauer interner Serverzertifikate liegt typischerweise bei 1–3 Jahren – mit Autoenrollment kann man auch kürzere Intervalle (z.B. 1 Jahr) wählen, da die Erneuerung automatisch erfolgt.

Die betreffenden Server werden in eine AD-Gruppe aufgenommen, der über die Vorlage Registrieren– und Autoenroll-Berechtigung erteilt wird. Per Gruppenrichtlinie (GPO) aktivieren Sie für diese Gruppe die automatische Zertifikatregistrierung. Damit holen sich die Server eigenständig beim Start oder in regelmäßigen Abständen ihr Zertifikat ab. Alternativ kann ein Zertifikat auch manuell über die MMC-Konsole oder via Kommandozeile beantragt werden:

certutil -pulse # Autoenrollment sofort anstoßen

Nach erfolgreicher Ausstellung findet sich das Zertifikat im lokalen Computerspeicher (Zertifikatsspeicher „Eigener Computer“) des Servers. Es sollte nun in der jeweiligen Serveranwendung (z.B. im IIS für HTTPS oder im SQL Server für TLS) hinterlegt bzw. gebunden werden. Wichtig: Prüfen Sie auf Clientseite, ob die Zertifikatskette vertrauenswürdig ist (alle Zwischenzertifikate installiert, Root-CA vertraut) und ob die CRL/OCSP-URLs vom Client erreicht werden können.

Typische Stolpersteine: Häufig passen die eingetragenen Namen nicht exakt (wenn CN/SAN nicht mit dem DNS-Namen des Dienstes übereinstimmt), oder Zertifikate werden mit überlanger Gültigkeit ausgestellt (und dann die rechtzeitige Erneuerung versäumt). Achten Sie darauf, dass wirklich alle benötigten DNS-Namen im Zertifikat enthalten sind (ggf. mehrere SAN-Einträge). Auf Wildcard-Zertifikate („*.example.com“) sollte man verzichten – sie decken zwar viele Namen ab, stellen aber im Kompromittierungsfall ein unnötig hohes Risiko dar.

Checkliste Inbetriebnahme:

Zertifikatvorlage „Webserver intern“ erstellt (basierend auf Web Server, mit DNS-SAN, EKU Server Authentication, privater Schlüssel nicht exportierbar).
Server/Systemgruppe hat Enroll- und Autoenroll-Rechte auf die Vorlage; GPO für Autoenrollment verknüpft.
Prüfung: Server hat Zertifikat im lokalen Zertifikatstore erhalten (certlm.msc).
Zertifikat in Serverdienst eingebunden (z.B. HTTPS-Bindung im IIS gesetzt, Dienst neu gestartet).
Vertrauensstellung getestet: Client kann über HTTPS verbinden, Zertifikatpfad zeigt keine Fehler (Kette vollständig, Zertifikat gültig, nicht widerrufen).
Monitoring eingerichtet: Ablaufdaten der Zertifikate überwachen (bei Autoenrollment erfolgt Erneuerung i.d.R. rechtzeitig, z.B. 4 Wochen vor Ablauf).

802.1X WLAN und VPN (EAP-TLS)

Szenario: Unternehmens-WLAN nach 802.1X-Standard soll anstelle von Pre-Shared-Keys mit individuellen Zertifikaten je Gerät (oder Benutzer) abgesichert werden. Auch VPN-Zugänge (z.B. via RADIUS/NPS) sollen mit Zertifikat-Authentifizierung (EAP-TLS) arbeiten, um die Sicherheit zu erhöhen.

Umsetzung: Für die 802.1X-Authentifizierung legt man separate Zertifikatvorlagen für Computer (und falls nötig für Benutzer) an, jeweils mit der EKU Client Authentication. Die Vorlage für Geräte kann z.B. von „Workstation Authentication“ abgeleitet werden (Subject=Computername, Schlüssel nicht exportierbar). Per GPO wird Autoenrollment aktiviert, damit alle Domänenrechner automatisch ein entsprechendes Zertifikat erhalten. Auf dem RADIUS-Server (NPS) wird EAP-TLS als Methode eingerichtet und das Root-Zertifikat der internen CA als vertrauenswürdig hinterlegt. Die NPS-Richtlinie sollte prüfen, ob präsentierte Zertifikate von der richtigen CA stammen und ggf. ob der Kontoinhaber berechtigt ist (z.B. Mitglied einer bestimmten AD-Gruppe).

Typische Stolpersteine: Häufig fehlt anfangs das gegenseitige Vertrauen: Der NPS/RADIUS-Server muss der ausstellenden CA vertrauen, und die Clients müssen dem NPS-Serverzertifikat vertrauen (dieses sollte idealerweise von derselben internen CA stammen). Wichtig ist außerdem, dass Geräte-Zertifikate nicht ablaufen – daher Autoenrollment bzw. MDM-gestützte Erneuerung einplanen. In MDM-Szenarien sollte man eindeutige Namen/Kennungen im Zertifikat verwenden (z.B. Geräte-ID im SAN), um Verwechslungen zwischen Geräten zu vermeiden.

Checkliste Inbetriebnahme:

Template „Computer-Authentifizierung“ erstellt (EKU Client Auth, Subject = Computerkonto, automatische Subject-Namensgebung).
Autoenrollment-GPO für Computerzertifikate aktiviert; alle relevanten Geräte haben ein Zertifikat erhalten.
NPS/RADIUS-Server mit eigenem Serverzertifikat ausgestattet (von interner CA) und Root/Zwischenzertifikat der CA importiert.
NPS-Netzwerkrichtlinie definiert: EAP-TLS aktiviert, Bedingung „Zertifikat von interner CA“ gesetzt; ggf. Benutzer-/Computergruppen als weitere Voraussetzung.
Test: Domänen-Laptop meldet sich im WLAN an, NPS-Log zeigt erfolgreiche Zertifikat-Authentifizierung. Ebenso VPN-Client mit Zertifikat geprüft.
Dokumentation/Monitoring: Gültigkeitsdauer der ausgegebenen Zertifikate notiert; Prozesse für Erneuerung (via GPO oder Intune) etabliert.

Client-Authentifizierung für mTLS-APIs

Szenario: Interne Web-APIs und Microservices sollen nur miteinander kommunizieren, wenn sich beide Seiten mit Zertifikat ausweisen (mutual TLS). Jeder Dienst bzw. Server tritt also zugleich als TLS-Client und -Server auf und benötigt ein entsprechendes Zertifikat. Ebenso sollen ggf. Entwickler oder Administratoren-Tools sich per Zertifikat an internen APIs authentisieren können, anstatt Passwörter zu verwenden.

Umsetzung: Hier kommen Maschinenzertifikate mit der EKU Client Authentication (und ggf. zusätzlich Server Authentication, falls der Dienst auch als Server agiert) zum Einsatz. Für reine Clientrollen reicht die EKU Client Auth. Erstellen Sie z.B. ein Template „Service-mTLS“ mit folgenden Parametern: Subject sollte eine eindeutige Dienstkennung sein (etwa der Dienst-Name oder ein Dienstkonto); als SAN kann man einen sprechenden DNS-Namen oder eine UID eintragen. Wenn DevOps-Prozesse eingebunden werden sollen, lässt sich die Zertifikatsanforderung skripten (z.B. mittels certreq und INF-Datei oder via REST-Schnittstellen, falls vorhanden). Der private Schlüssel solcher Zertifikate muss auf dem System sicher hinterlegt werden – bei Windows-Diensten im lokalen Computerschlüssel-Speicher (ggf. geschützt durch DPAPI oder ein TPM), bei Containern oder Linux-Services in einem sicheren Vault oder Secret-Store.

Auf Serverseite (der API) wird Client-Zertifikatprüfung aktiviert und die interne Root-CA als vertrauenswürdige Stamminstanz für Clientzertifikate konfiguriert. Die API-Logik entzieht Berechtigungen basierend auf dem präsentierten Zertifikat – z.B. anhand des Zertifikats-SAN oder spezieller OIDs in einem Attribut. In .NET oder Java kann man nach dem TLS-Handshake auf das Clientzertifikat im Request-Context zugreifen und dessen Eigenschaften auswerten.

Automatisierung: In DevOps-Umgebungen kann die Zertifikatsanforderung direkt in Deploymentskripte integriert oder über ACME-Clients automatisiert werden, sofern die PKI entsprechende Schnittstellen bietet. Andernfalls sind regelmäßige Abstimmungen zwischen Entwicklern und dem PKI-Team nötig, um sicherzustellen, dass neue Dienste rechtzeitig Zertifikate erhalten.

Stolpersteine: Keine Wildcards für Clientzertifikate verwenden! Jeder Dienst braucht ein eigenes, individuelles Zertifikat, sonst könnte ein kompromittiertes Wildcard-Zertifikat auf andere Dienste zugreifen. Außerdem müssen die Zertifikate aussagekräftige Identitäten enthalten (damit die API z.B. „Service A“ von „Service B“ unterscheiden kann). Die Revocation-Prüfung kann bei mTLS die Performance beeinflussen: Viele parallele Verbindungen dürfen nicht an CRL-Downloads hängen. Hier bietet sich an, OCSP im Intranet zu nutzen oder die Zertifikatslaufzeiten relativ kurz zu halten (und dafür häufiger zu erneuern), um im Zweifel auf Sperrlisten verzichten zu können.

Checkliste Inbetriebnahme:

Template „Service-ClientAuth“ erstellt (EKU Client Auth ± Server Auth, Subject enthält Dienstkennung oder Service-Account).
Prozesse/Skripte etabliert, wie Zertifikate beantragt werden (Domain-Maschinen via Autoenrollment; externe Dienste via SCEP/CEP oder manuell durch PKI-Team).
Dienste/API-Server konfiguriert: Client-Zertifikatsauthentifizierung aktiviert; CA-Root-Zertifikat in den Trust Store für Clientauth importiert.
Test: Service A ruft API B auf – beidseitig präsentieren sie gültige Zertifikate, die jeweils akzeptiert werden. Ein abgelaufenes oder falsches Zertifikat wird abgewiesen.
Sicherer Umgang mit Private Keys gewährleistet (Schlüssel liegen nur in geschütztem Store oder Hardware, nicht in Code-Repositories).
Monitoring: Regelmäßige Prüfung der Zertifikatsgültigkeit und Sperrstatus der verwendeten Service-Zertifikate; Logging fehlgeschlagener Verbindungsversuche.

S/MIME: E-Mail-Signatur und -Verschlüsselung

Szenario: Mitarbeiter sollen ihre E-Mails digital signieren können, um Phishing zu erschweren, und vertrauliche Inhalte bei Bedarf verschlüsseln (S/MIME). Hierfür benötigt jeder Nutzer ein persönliches E-Mail-Zertifikat.

Umsetzung: Die ADCS-Zertifikatvorlage „User“ oder eine spezielle „S/MIME-Benutzer“-Vorlage kann als Basis dienen. Diese beinhaltet typischerweise die EKUs Email Protection sowie Client Authentication (letzteres, falls das Zertifikat z.B. auch für VPN-Login genutzt werden dürfte). Das Zertifikat sollte den Namen des Mitarbeiters im Subject und seine E-Mail-Adresse im SAN enthalten. Aktivieren Sie in der Vorlage die Schlüsselarchivierung, damit der private Schlüssel vom CA-Server gesichert wird (Key Recovery). Dies ist wichtig für den Fall, dass ein Mitarbeiter z.B. verschlüsselte E-Mails verliert oder ausscheidet – ein berechtigter Sicherheitsbeauftragter kann dann den Schlüssel aus dem Archiv bergen, um die Daten zu entschlüsseln. Für die Schlüsselarchivierung muss auf der CA ein Key Recovery Agent (KRA) eingerichtet sein.

Die Verteilung solcher Benutzerzertifikate erfolgt entweder per Autoenrollment (für Domänennutzer an Windows-Arbeitsplätzen) oder manuell per Zertifikatexport/-import (für einzelne Fälle oder externe Mitarbeiter). Nach Erhalt muss der Nutzer das Zertifikat in seinem Mailprogramm installieren. In einer Exchange/Outlook-Umgebung können die öffentlichen Schlüssel aller Mitarbeiter im Active Directory veröffentlicht werden, sodass Kollegen sie zum Verschlüsseln verwenden können (Outlook/Exchange liest dazu das Attribut userSMIMECertificate des AD-Benutzerobjekts aus).

Wichtig: Legen Sie interne Richtlinien fest, wie mit den E-Mail-Zertifikaten umzugehen ist – z.B. Gültigkeitsdauer (oft 1–2 Jahre), Vorgehen bei Widerruf (sofort widerrufen bei Austritt eines Mitarbeiters oder Geräteverlust) und Prozesse zur Schlüsselwiederherstellung. Letzteres darf nur berechtigten Personen vorbehalten sein und sollte protokolliert werden (Stichwort Revisionssicherheit).

Stolpersteine: Der Austausch der öffentlichen Schlüssel muss gewährleistet sein (z.B. automatische Veröffentlichung im globalen Adressbuch), sonst können Kollegen keine verschlüsselten E-Mails senden. Außerdem braucht es ein Konzept zur Wiederherstellung verschlüsselter Mails (etwa zentrale Schlüsselhinterlegung oder Journaling), falls Nutzerzertifikate verloren gehen oder Mitarbeiter ausscheiden. Schließlich ist Nutzertraining wichtig, damit Signaturen und Verschlüsselung korrekt angewendet und erkannt werden.

Checkliste Inbetriebnahme:

Template „Benutzer S/MIME“ mit EKU Email Protection erstellt; Key Recovery (Archivierung) aktiviert und KRA-Zertifikat auf CA eingerichtet.
Ggf. Enrollment-Agent bestimmt, falls Zertifikate zentral vom IT-Team beantragt/ausgegeben werden sollen (statt Autoenrollment).
Testnutzer hat Zertifikat erhalten (Autoenrollment oder manuell); privater Schlüssel im Benutzerzertifikatstore vorhanden; Zertifikat enthält korrekte E-Mail-Adresse im SAN.
Öffentlichen Schlüssel des Nutzers im AD-Benutzerobjekt veröffentlicht (z.B. certutil -f -dspublish usercert.cer user).
Outlook/Exchange-Funktion geprüft: Globale Adressliste zeigt Zertifikatsinfo; Test-E-Mail erfolgreich signiert und vom Empfänger auf Integrität geprüft; Test-Mail verschlüsselt versendet und vom Empfänger geöffnet.
Prozess zur Schlüsselwiederherstellung getestet (mit KRA ein testverschlüsseltes Dokument entschlüsselt) und dokumentiert.

Code-Signierung in der Build-Pipeline

Szenario: Eine Entwicklungsabteilung möchte Softwarepakete, Skripte oder ausführbare Dateien signieren, bevor sie ausgeliefert oder intern verteilt werden. Dadurch kann jedes System prüfen, ob das Paket vom vertrauenswürdigen Herausgeber stammt und ob es unverändert ist.

Umsetzung: Für Code Signing empfiehlt sich eine eigene Zertifikatvorlage „Code Signing“, die ausschließlich die EKU Code Signing trägt. Der private Schlüssel kann entweder Benutzern (Entwickler) zugeordnet sein oder – besser – in einem zentralen Dienstkonto bzw. auf einem Build-Server generiert werden. In hochsicheren Umgebungen setzt man dafür ein Hardware Security Module (HSM) ein oder zumindest die Windows Data Protection API (DPAPI) mit einem spezialisierten Key Storage Provider (KSP), um den Signaturschlüssel vor Diebstahl zu schützen.

Das ausgestellte Code-Signing-Zertifikat wird auf dem Build-Server oder dem Signiersystem installiert. Entwickler können damit ausführbare Dateien und Skripte signieren, etwa mit Tools wie signtool.exe (für EXE/MSI) oder PowerShells Set-AuthenticodeSignature (für PS1/Module). Wichtig ist die Verwendung eines Zeitstempel-Servers bei jeder Signatur – so bleibt die Signatur auch nach Ablauf des Zertifikats gültig (die Signatur erhält einen Vertrauenszeitpunkt).

Policies: Legen Sie fest, wer das Recht hat, Code-Signing-Zertifikate zu erhalten (z.B. nur Nutzer der AD-Gruppe „CodeSignierer“ oder nur definierte Build-Accounts). Aktivieren Sie auf der Vorlage ggf. die Option „Zertifikatsantrag muss vom Administrator genehmigt werden“, um ein Vier-Augen-Prinzip einzuhalten. Protokollieren Sie alle Signiervorgänge soweit möglich – z.B. durch Skripte, die Logs schreiben, oder HSM-Auditfunktionen.

Stolpersteine: Oft speichern Entwickler aus Bequemlichkeit den privaten Schlüssel auf ihrer Workstation – das birgt große Risiken. Private Keys niemals ungeschützt ablegen! Idealerweise verbleibt der Signierschlüssel auf einem zentralen, gut gesicherten System oder Hardware-Token. Außerdem muss man den Umgang mit ablaufenden Zertifikaten planen: Signierter Code ist mit Zeitstempel zwar auch nach Ablauf des Zertifikats noch verifizierbar, aber neue Signaturen benötigen rechtzeitig ein aktualisiertes Zertifikat. Eine Übergangszeit mit parallel gültigem altem und neuem CodeSigning-Zertifikat ist ratsam, um Builds nicht zu blockieren.

Checkliste Inbetriebnahme:

Template „Code Signing“ eingerichtet (nur EKU Code Signing, starke Krypto-Einstellungen; Ausgabe nur an definierten Personenkreis oder Dienstkonto).
Privater Schlüssel auf HSM oder Systemschlüsselbund erzeugt, als nicht exportierbar markiert.
Signaturprozess in CI/CD-Pipeline integriert (z.B. Post-Build-Schritt ruft signtool oder PowerShell-Signierung mit dem Zertifikat auf).
Entwickler-Dokumentation: Ablauf zum lokalen Testsignieren vs. Signieren im Release-Prozess; Hinweis auf Verwendung eines Zeitstempel-Servers.
Überprüfung: Signiertes Programm/Skript auf einem Testsystem ausgeführt – digitale Signatur wird als gültig und vom richtigen Herausgeber angezeigt.
Ablaufmanagement: Gültigkeitsdauer des CodeSigning-Zertifikats bekannt (z.B. 3 Jahre); Reminder für rechtzeitige Erneuerung und Verteilung des neuen Zertifikats in die Pipeline eingerichtet.

Betrieb, Sicherheit und Governance einer PKI

Der langfristige Erfolg einer PKI hängt von solider Betriebsführung und kontinuierlicher Überwachung ab. Hier einige Schlüsselfelder:

Lebenszyklus-Management: Legen Sie klare Prozesse für Enrollment, Erneuerung und Sperrung fest. Automatisierte Enrollment-Mechanismen (Autoenrollment, SCEP) sollten so konfiguriert sein, dass Zertifikate rechtzeitig vor Ablauf erneuert werden. Ein gängiges Vorgehen ist, Zertifikate bei ~80% der Ablaufzeit erneuern zu lassen. Für Widerrufe definieren Sie interne SLAs: Wie schnell nach Meldung eines kompromittierten Schlüssels muss das Zertifikat gesperrt sein (idealerweise binnen Stunden). Publizieren Sie CRLs in kurzen Abständen – z.B. eine Base-CRL alle paar Tage und ggf. Delta-CRLs sogar täglich oder häufiger. Wo hohe Anforderungen bestehen, setzen Sie auf OCSP für nahezu echtzeitnahe Statusauskünfte.

Zertifikatvorlagen und Zugriffssteuerung: Behandeln Sie Template-Änderungen ähnlich sensibel wie GPO-Änderungen. Nur PKI-Admins sollten Schreibrechte auf Vorlagen haben. Nutzen Sie Enrollment-Berechtigungen: Nicht jeder Domänenbenutzer darf jede Vorlage nutzen. Beispielsweise die CodeSigning-Vorlage nur für Build-Accounts, die Smartcard-Logon-Vorlage nur für definierte Benutzergruppen freigeben. Bei sensiblen Zertifikaten können Sie einstellen, dass eine manuelle Genehmigung durch einen Zertifikatsmanager erforderlich ist (Vier-Augen-Prinzip). Das verhindert unautorisierte Ausstellung z.B. eines Administratorzertifikats, erhöht aber den Verwaltungsaufwand.

Protokollierung und Auditierung: Aktivieren Sie auf den CAs die Sicherheitsüberwachung (Audit Logging) für Vorgänge wie Zertifikat-Ausstellung, -Ablehnung, Sperrungen und Änderungen an den Einstellungen. Die Windows-Ereignisprotokolle („Sicherheit“ und „Anwendungs- und Dienstprotokolle → Microsoft → Windows → CertificateServices–…“) sollten regelmäßig auf auffällige Muster geprüft werden (z.B. wiederholte Fehlversuche). Führen Sie Buch über ausgegebene Administrator- oder Zwischenzertifikate, um im Notfall nachvollziehen zu können, wer wann welches kritische Zertifikat erhalten hat. Für Compliance-Zwecke (z.B. TISAX, ISO 27001) sind regelmäßige Audits der PKI-Konfiguration und Nachweise über den korrekten Betrieb ratsam.

Backup und Recovery: Eine PKI muss gegen Datenverlust abgesichert sein, da ein Ausfall insbesondere der Root oder Issuing CA schwerwiegende Folgen hätte. Wichtige Backup-Objekte sind der CA-Schlüssel und das CA-Zertifikat, die CA-Datenbank (mit allen ausgestellten Zertifikaten und Sperrlisten) sowie die CA-Konfiguration. Die folgende Tabelle zeigt, was gesichert werden sollte und in welchem Intervall:

Backup-Objekt	Empfohlenes Intervall/Anlass	Hinweise zur Wiederherstellung
Root-CA privater Schlüssel & Zertifikat	Einmalig bei Einrichtung, danach bei jeder Erneuerung des Root-Zertifikats.	Sicher offline verwahren (z.B. auf Smartcard/HSM und verschlüsseltem Backup-Medium). Wiederherstellung auf einem separaten System; neues Root-Zertifikat ggf. an alle Clients verteilen.
Issuing-CA Schlüssel & Zertifikat	Bei CA-Installation und bei Zertifikat-/Schlüsselerneuerung.	In den PKI-Notfallplan aufnehmen, wie eine neue CA aufgebaut oder der Backup-Key importiert wird.
CA-Datenbank (CA-DB)	Regelmäßig (z.B. täglich oder wöchentlich, abhängig vom Volumen).	Transaktionslogs mit sichern. Wiederherstellung erfordert identische CA-Namen und -Konfiguration, dann DB einspielen.
CA-Konfiguration (Registry, CAPolicy.inf, Templates)	Nach jeder relevanten Änderung exportieren.	Mit certutil -backupRegistry die CA-Einstellungen sichern; Zertifikatvorlagen liegen in AD (daher regelmäßiges AD-Backup oder Export der Vorlagen mit certutil -catemplates).
CRLs (Sperrlisten)	Bei jeder Veröffentlichung automatisch erzeugt – separates Backup optional.	CRLs lassen sich aus der CA-DB neu erzeugen. Optional letzte veröffentlichte CRL aufbewahren (Offline-Nachweis).
Key-Archiv (archivierte Nutzerschlüssel)	Regelmäßig, z.B. synchron zum CA-DB-Backup.	KRA-Zertifikate ebenfalls sichern. Wiederherstellung: archivierte Keys können auf neuer CA importiert werden, sofern der KRA-Schlüssel verfügbar ist.

Notfallübungen: Testen Sie mindestens jährlich die Desaster-Wiederherstellung: Stellen Sie aus den Backups eine CA in einer isolierten Umgebung wieder her und prüfen Sie, ob alle Schritte dokumentiert sind (z.B. sind Passwörter für Backup-Schlüssel verfügbar, Installationsparameter bekannt?). Planen Sie auch die Neuverteilung von Trust Anchors (Root-Zertifikate) mit ein, falls der Worst Case eintritt und eine neue Root-CA etabliert werden muss.

AIA/CDP-Verfügbarkeit: Überwachen Sie die Erreichbarkeit und Aktualität der veröffentlichten CRLs und OCSP-Dienste. Eine PKI verliert an Wirkung, wenn z.B. eine abgelaufene CRL auf Clients im Cache bleibt, weil keine neue verfügbar ist. Setzen Sie daher auf redundante CDP-URLs (mehrere HTTP-Server, ggf. DFS-Replikation oder CDN) und planen Sie OCSP-Responder mit Loadbalancing ein. Mehrere OCSP-Server können als Array betrieben werden, sodass sie unter einem gemeinsamen Namen identische Antworten liefern.

Härtung und Patchen der CA-Server: PKI-Systeme sollten nach bewährten Sicherheitsrichtlinien konfiguriert werden. Entfernen Sie unnötige Dienste, erlauben Sie nur befugten Administratoren den Zugriff und nutzen Sie aktuelle Kryptografie-Einstellungen (keine veralteten Protokolle oder Hashalgorithmen, mind. RSA 2048 oder ECC P-256). Planen Sie regelmäßige Windows-Updates ein – idealerweise in Wartungsfenstern – und testen Sie danach die Kernfunktionen (z.B. Zertifikat ausstellen, CRL publizieren). Für Offline-Root-CAs sollten Updates gesammelt und vor dem nächsten geplanten Einsatz eingespielt werden, um Sicherheitslücken zu schließen, ohne den isolierten Betrieb zu gefährden.

Monitoring und Kennzahlen: Definieren Sie messbare Indikatoren, um den PKI-Zustand zu überwachen. Beispiele: die Anzahl ausgestellter Zertifikate pro Woche (ungewöhnliche Peaks können auf Missbrauch oder neue Anforderungen hinweisen), das Alter der CRLs (Alarm, wenn eine Sperrliste kurz vor Ablauf steht) und die Antwortzeiten der OCSP-Responder (zu hohe Latenz deutet auf Leistungsprobleme hin). Auch die regelmäßige Überprüfung der Template-Konfigurationen (keine ungewollten Änderungen) gehört zum Monitoring.

Best Practices

Root-CA offline halten: Die Stammzertifizierungsstelle niemals ans Netzwerk anschließen, außer zu definierten Wartungszwecken. So bleibt der wichtigste Schlüssel maximal geschützt.
HSM für CA-Schlüssel verwenden: Private Keys von CAs nach Möglichkeit in Hardware sichern. Ein HSM bietet physischen Diebstahlschutz und rollenbasierten Zugriff – besonders für Root- und wichtige Issuing CAs empfehlenswert.
Kurze Sperrlistenintervalle: CRLs häufig aktualisieren (z.B. wöchentlich oder öfter) und bei wichtigen Widerrufen sofort neu veröffentlichen. Alternativ bzw. ergänzend OCSP-Responder einsetzen, um Sperrinformationen in Echtzeit bereitzustellen.
HTTP als Verteilungskanal: AIA-/CDP-Pfade bevorzugt über HTTP(S) anbieten statt ausschließlich LDAP. Web-URLs sind flexibler erreichbar (auch für externe/ mobile Clients) und lassen sich leichter redundant auslegen.
Klare Trennung pro Vorlage: Für jeden Zweck eigene Zertifikatvorlagen einsetzen. Keine Mehrzweck-Zertifikate definieren, die z.B. sowohl als Server- als auch als Clientzertifikat dienen – so minimieren Sie Missbrauchsmöglichkeiten.
Strikte Rechtevergabe: Enrollment-Berechtigungen restriktiv handhaben. Nur definierte Gruppen oder Dienste dürfen bestimmte Templates nutzen. Vergeben Sie keine weitreichenden Rechte an „Domain Users“ auf sicherheitskritische Vorlagen.
Dokumentation und Richtlinien: Pflegen Sie ein PKI-Betriebshandbuch, in dem Hierarchie, Gültigkeiten, Verantwortlichkeiten und Prozesse (z.B. bei Schlüsselkompromittierung) festgehalten sind. Schriftliche Policies stellen sicher, dass alle Beteiligten nach gleichen Regeln handeln.
Automatisierung nutzen: Setzen Sie Autoenrollment, SCEP/NDES und Skripte ein, um manuelle Schritte zu vermeiden. Automatisierte Zertifikatsverteilung reduziert menschliche Fehler und stellt die rechtzeitige Erneuerung sicher.
Notfallplan bereit halten: Für Szenarien wie CA-Ausfall oder kompromittierten CA-Key vorab einen Maßnahmenplan erstellen. Zuständigkeiten und Schritte (z.B. CA sperren, neue CA bereitstellen, Bekanntmachung an Benutzer) sollten definiert und geübt sein.
Regelmäßige PKI-Audits: Überprüfen Sie die PKI mindestens jährlich oder bei wichtigen Änderungen. Dabei Sicherheitsparameter (z.B. Schlüsselstärken, Algorithmen), Berechtigungen und Abläufe kontrollieren. So werden schleichende Fehlkonfigurationen oder unsichere Praktiken rechtzeitig erkannt.

Dos and Don’ts in der PKI-Praxis

10 Dos (unbedingt tun)

Offline-Root etablieren: Die Root-CA stets offline betreiben und physisch sichern – das schützt den wichtigsten Schlüssel.
CA-Schlüssel bestmöglich schützen: Private Keys von CAs in HSMs oder wenigstens abgesichert im Systemschlüsselbund speichern; Zugriffe darauf auditieren.
AIA/CDP hochverfügbar machen: CRLs und CA-Zertifikate auf redundanten, schnellen HTTP-Servern bereitstellen; Erreichbarkeit kontinuierlich prüfen.
Sperrlisten häufig aktualisieren: CRLs regelmäßig neu herausgeben (z.B. wöchentlich) und bei kritischen Zwischenfällen sofort eine aktuelle CRL erzeugen; für schnelle Prüfungen OCSP anbieten.
Einschränkende Templates nutzen: Für jeden Zertifikatstyp separate Vorlagen mit minimal notwendigen Rechten/EKUs erstellen; so begrenzen Sie den Impact eines kompromittierten Zertifikats.
Autoenrollment einsetzen: Wo möglich, Zertifikate via Gruppenrichtlinie automatisch anfordern und verteilen lassen (für Computer- und Benutzerzertifikate). Das stellt konsistente Versorgung sicher.
Dokumentation aktuell halten: Alle PKI-Komponenten, -Einstellungen und -Zertifikate dokumentieren. Das erleichtert Fehleranalyse und stellt Wissen bei Personalwechsel sicher.
PKI-spezifisches Monitoring einführen: Kennzahlen wie Zertifikatsausstellungen, ausstehende Anträge, CRL-Validität und OCSP-Status überwachen; bei Auffälligkeiten sofort reagieren.
Änderungen erst testen: Neue Templates, CA-Konfigurationsänderungen oder Updates erst in einer Test-PKI probieren. So vermeiden Sie Betriebsstörungen durch unerwartete Nebeneffekte.
Schlüssel regelmäßig erneuern: Planen Sie Key-Rollover für CAs und wichtige Zertifikatstypen ein (z.B. alle paar Jahre neue Schlüssel mit moderner Kryptografie), um stets den aktuellen Sicherheitsstand zu wahren.

10 Don’ts (unbedingt vermeiden)

Root-CA online betreiben: Einen Stammzertifikatsserver nie dauerhaft ans Netzwerk anschließen oder als Domänenmitglied betreiben – bei Kompromittierung ist die ganze PKI gefährdet.
Einstufige PKI in Produktion: Eine einzige CA ohne Offline-Root nur in Testumgebungen verwenden. In Produktion fehlt sonst die Sicherheitsreserve und Möglichkeit, eine kompromittierte CA zu ersetzen.
Standardvorlagen ungeprüft nutzen: Vordefinierte Templates nicht blind übernehmen – einige älteren Standardvorlagen nutzen z.B. unsichere Kryptografie (SHA-1) oder zu breite Rechte.
Wildcard-Zertifikate für Authentifizierung: Keine Wildcards („*.domain.com“) für mTLS oder individuelle Authentifizierungen einsetzen. Jeder Dienst und Benutzer sollte ein eigenes Zertifikat haben, um nachvollziehbar und einschränkbar zu bleiben.
Überlange Laufzeiten: Keine übermäßig langen Zertifikatsgültigkeiten (z.B. 10+ Jahre) vergeben. Lieber kürzere Intervalle und dafür automatisierte Erneuerung – das reduziert Risiken durch veraltete Algorithmen oder vergessene Sperrungen.
CRL-Publikation vernachlässigen: Auf keinen Fall CRLs so konfigurieren, dass sie selten oder gar manuell veröffentlicht werden. Eine vergessene CRL-Aktualisierung kann die gesamte Zertifikatsprüfung zum Stillstand bringen.
Statisches SCEP-Passwort ewig nutzen: Das Challenge Password für NDES/SCEP regelmäßig ändern und sicher verteilen. Ein geleaktes oder dauerhaft gleiches SCEP-Secret könnte fremden Geräten Zertifikatsanträge erlauben.
„Jeder darf alles“-Administration: Keine unkontrollierte PKI-Administration durch zu viele Personen. Begrenzen Sie die Zahl der PKI-Administratoren und setzen Sie, wo möglich, rollenbasierte Zugriffe und Genehmigungsprozesse ein.
Fehlende Dokumentation/Backups: Nicht darauf verlassen, dass „schon nichts passiert“. Ohne aktuelle Dokumentation und getestete Backups/Recovery-Pläne steht man im Ernstfall orientierungslos da.
Warnsignale ignorieren: Meldungen wie „Zertifikat ungültig“ oder „CRL nicht verfügbar“ niemals wegklicken, sondern als Alarmsignal sehen. Solche Hinweise frühzeitig zu untersuchen verhindert größere Ausfälle oder Sicherheitsvorfälle.

FAQ – Häufige Fragen zu ADCS und PKI

Frage: Was ist der Unterschied zwischen CRL und OCSP, und wann sollte man welches Verfahren nutzen?
Antwort: Eine CRL ist eine von der CA veröffentlichte Liste widerrufener Zertifikate, die Clients herunterladen und lokal prüfen. OCSP hingegen liefert auf Anfrage den Status eines konkreten Zertifikats („gültig“ oder „widerrufen“) über einen Netzwerkdienst in Echtzeit. CRLs sind dezentral und offline nutzbar, können aber sehr groß werden. OCSP ist aktueller und schlanker, erfordert aber einen verfügbaren OCSP-Server. In modernen PKIs setzt man meist OCSP für schnelle Abfragen ein und behält CRLs als Fallback.

Frage: Empfohlene Gültigkeitsdauern für Root-CA, Intermediate/Issuing CAs und End-Entity-Zertifikate?
Antwort: Übliche Best Practices: Root-CA relativ lang (z.B. 10 Jahre, in manchen Fällen bis 20 Jahre, um selten wechseln zu müssen). Zwischenzertifikate (Intermediates/ausstellende CAs) oft um 5 Jahre, damit sie bei Bedarf erneuert werden können. End-Entity-Zertifikate möglichst kurz: heute meist 1 Jahr (intern maximal 2–3 Jahre, falls Automation vorhanden). Kürzere Laufzeiten erhöhen die Sicherheit durch häufigeren Schlüsselwechsel, erfordern aber funktionierende Erneuerungsprozesse.

Frage: SAN vs. Subject CN – was ist maßgeblich?
Antwort: Moderne Anwendungen prüfen primär die Subject Alternative Name (SAN) Erweiterung. Ist ein SAN vorhanden, wird der Subject-Common-Name (CN) ignoriert. Daher muss der erwartete Name (DNS-Name, E-Mail oder UPN) im SAN-Feld stehen, sonst schlägt die Zertifikatsprüfung fehl. Für Altsysteme, die SAN nicht unterstützen, kann man ausnahmsweise ein Zertifikat ohne SAN (mit relevantem CN) ausstellen – besser ist es, diese Systeme zu modernisieren.

Frage: Wie Autoenrollment (automatische Zertifikatverteilung) sicher konfigurieren?
Antwort: Aktivieren Sie Autoenrollment nur für benötigte Zertifikatstypen und gezielte Sicherheitsgruppen per GPO. Stellen Sie sicher, dass die verwendeten Zertifikatvorlagen restriktiv konfiguriert sind (nur berechtigte Accounts/Gruppen). Überwachen Sie Event-Logs auf etwaige Fehler im Autoenrollment-Prozess. Insgesamt ermöglicht Autoenrollment eine sichere, transparente Zertifikatsversorgung – vorausgesetzt, Rechte und Einstellungen sind korrekt gesetzt und die AD-Infrastruktur ist stabil verfügbar.

Frage: Wann NDES/SCEP einsetzen, wann Alternativen (z.B. ACME)?
Antwort: SCEP (über NDES) eignet sich vor allem für Netzwerkgeräte und mobile Clients ohne Domänenanbindung. Es ist einfach und in viele Geräte/MDM-Lösungen (z.B. Intune) integriert, aber funktional begrenzt. ACME ist moderner und ideal, um Webserver oder Cloud-Dienste automatisiert mit Zertifikaten zu versorgen. Da ADCS ACME nicht nativ spricht (nur via Dritttools), bleibt SCEP in Windows-Umgebungen oft das Mittel der Wahl. In heterogenen Umgebungen kann man ACME parallel nutzen, etwa für Linux-Server oder Container.

Frage: HSM – Pflicht oder Kür für eine CA?
Antwort: Ein HSM ist nicht zwingend vorgeschrieben, aber dringend zu empfehlen. Für eine Root-CA mit langer Lebensdauer sollte ein HSM praktisch Pflicht sein, um den Schlüssel bestmöglich zu schützen. Auch für online betriebene Issuing CAs erhöht ein HSM die Sicherheit und kann bei Audits gefordert sein. Kleine Testumgebungen laufen oft ohne HSM, doch für eine produktive PKI ab gewisser Größe ist ein HSM heute Best Practice.

Frage: Vorgehen bei kompromittiertem CA-Schlüssel?
Antwort: Das betroffene CA-Zertifikat muss sofort widerrufen werden. Bei einer Sub-CA veranlasst das die übergeordnete CA mittels einer Sperrliste, wodurch alle von der kompromittierten CA ausgestellten Zertifikate ungültig werden. Anschließend schnellstmöglich eine neue CA bereitstellen und die Zertifikate neu ausstellen. Ist der Root-CA-Schlüssel kompromittiert, muss das Root-Zertifikat in allen Systemen als nicht vertrauenswürdig markiert und eine neue Root-PKI aufgesetzt werden – ein enormer Aufwand, der zeigt, warum der Root-Schlüssel bestmöglich geschützt sein muss.

Frage: Wie läuft die Erneuerung/Migration einer Root-CA („Root Key Roll“) ab?
Antwort: Lange vor Ablauf der Root-CA (z.B. 1–2 Jahre vorher) plant man einen Root Key Rollover. Die bestehende Root erstellt ein neues selbstsigniertes Root-Zertifikat mit neuem Schlüssel und dieses wird an alle Vertrauensstellungen verteilt. Untergeordnete CAs werden dann angewiesen, fortan Zertifikate unter der neuen Root auszustellen (ggf. durch Erneuern der Intermediate-Zertifikate). Es gibt eine Übergangsphase, in der beide Root-Zertifikate als vertrauenswürdig gelten, bis alle alten Zertifikate abgelaufen oder ersetzt sind. Sorgfältige Planung ist hier entscheidend, damit kein System den neuen Trust Anchor „verpasst“.

Frage: Intune/MDM-Integration mit ADCS – was sind Best Practices?
Antwort: Intune nutzt einen Certificate Connector, der mit NDES auf die lokale CA zugreift. Best Practices: Einen dedizierten NDES-Server (z.B. in der DMZ) verwenden, der nur minimalste Zugriffsrechte hat. Unterschiedliche Zertifikatvorlagen pro Anwendungszweck (WLAN, VPN etc.) definieren und diese in Intune als Profile konfigurieren. Der NDES-Serviceaccount sollte nur auf diese spezifischen Templates zugreifen dürfen. Vor großflächigem Rollout erst mit Testgeräten prüfen, ob die komplette Kette Intune -> NDES -> CA -> Gerät reibungslos funktioniert.

Frage: Umgang mit Legacy-Systemen ohne SAN-Unterstützung?
Antwort: Solche Systeme erwarten den Zielnamen im Subject-CN des Zertifikats. Man kann dafür spezielle Zertifikate ausstellen, bei denen der CN (z.B. Hostname) gesetzt wird und auf SAN verzichtet. Das sollte nur eine Übergangslösung sein. Parallel sollte man planen, diese Legacy-Systeme abzulösen oder Updates einzuspielen, da fehlende SAN-Unterstützung oft ein Indikator für weitere veraltete Komponenten ist.

Frage: OCSP-Responder hochverfügbar auslegen – was beachten?
Antwort: Setzen Sie mindestens zwei OCSP-Responder ein und legen Sie in den Zertifikaten eine gemeinsame OCSP-URL fest, die auf beide zeigt (Load Balancer oder DNS-RoundRobin). Microsofts Online Responder kann als Array betrieben werden, bei dem mehrere Server den gleichen Signaturschlüssel nutzen und identische Antworten liefern. Wichtig ist, das OCSP-Signer-Zertifikat auf allen OCSP-Instanzen bereitzustellen und die Konfiguration synchron zu halten. So bleibt der Dienst verfügbar, auch wenn ein Server ausfällt, und Clients können unter derselben URL den Status abfragen.

Frage: Cross-Forest- und Partner-PKI-Szenarien: Wie richtet man Vertrauensanker ein?
Antwort: In separaten AD-Forests importiert man jeweils die Root-Zertifikate der anderen PKI in den vertrauenswürdigen Stammzertifikatspeicher. Für Smartcard-Logon muss das fremde Root zusätzlich in die NTAuthCertificates-Gruppe des AD aufgenommen werden. Mit externen Partner-PKIs sollte man sparsam sein: Statt eine komplette Trust-Beziehung aller Zertifikate aufzubauen, gibt man besser nur einzelne benötigte Zertifikate frei oder stellt Partnern Zertifikate aus der eigenen PKI aus. Grundsätzlich gilt, die Zahl fremder Trust Anchors klein zu halten, um die Angriffsfläche zu minimieren.

Frage: Auditing und Nachweispflichten in der PKI – wie erfüllt man diese?
Antwort: Stellen Sie sicher, dass alle PKI-Aktivitäten lückenlos protokolliert und gegen Veränderungen geschützt sind. Aktivieren Sie das Audit-Logging der Zertifizierungsstelle (für Ausstellung, Widerruf, Einstellungen) und leiten Sie Protokolle in ein zentrales Log-System weiter. Definieren Sie außerdem schriftliche Policies für den PKI-Betrieb (Rollen, Berechtigungen, Notfallprozesse) und führen Sie regelmäßige interne Audits durch, um die Einhaltung nachzuweisen. Revisionssicherheit bedeutet, dass Sie jederzeit belegen können, wer was wann in der PKI getan hat und dass dies den vorgegebenen Richtlinien entspricht.

Frage: PKI in hybriden Umgebungen (On-Prem und Cloud) – was ist zu beachten?
Antwort: In Hybrid-Szenarien müssen unter Umständen On-Prem-Zertifikate in der Cloud anerkannt werden (z.B. Azure AD Zertifikatsauthentifizierung erfordert das Hochladen des Root-CA-Zertifikats). Umgekehrt brauchen Cloud-Workloads möglicherweise Zertifikate – hier entscheidet man, ob die interne PKI diese ausstellt (erfordert Verbindung, etwa über einen Connector) oder ob man separate cloudbasierte CAs nutzt. Wichtig ist, die Richtlinien einheitlich zu halten (gleiche Algorithmen, Security-Levels) und den Überblick zu bewahren: alle Zertifikate – egal wo ausgestellt – sollten inventarisiert und überwacht werden, damit keine „Schatten-PKI“ entsteht.

Frage: Typische Performance-Engpässe einer PKI und Abhilfen?
Antwort: Probleme treten selten auf, können aber z.B. durch sehr große CRLs entstehen (bei zehntausenden Widerrufen). Abhilfe: Delta-CRLs einsetzen oder die PKI in mehrere CAs aufteilen, um CRLs kleiner zu halten. Auch ein plötzlicher Massenanfall von Zertifikatsanträgen kann eine CA überfordern – hier hilft das Lastverteilen auf mehrere Issuing CAs. Der NDES-Dienst kann bei vielen gleichzeitigen Anfragen zum Flaschenhals werden; in dem Fall mehrere NDES-Instanzen einsetzen oder die Hardware aufrüsten. Außerdem im Blick behalten: Latenzen bei OCSP-Abfragen (ggf. regionale OCSP-Server bereitstellen) und die Größe der CA-Datenbank (alte Einträge archivieren, damit Backups flott bleiben).

Zusammenfassung – Kernbotschaften in 5 Punkten

Digitale Zertifikate bilden die Vertrauensgrundlage moderner IT-Security: Sie sichern Kommunikation, authentifizieren Benutzer und Geräte und gewährleisten Integrität – eine solide PKI ist für jedes Unternehmen heute unerlässlich.
ADCS ermöglicht eine flexible interne PKI, muss aber sorgfältig designt sein: Eine zweistufige Architektur mit Offline-Root ist der bewährte Standard. Sie bietet hohen Schutz und genügt in den meisten Fällen; komplexere Designs sollte man nur bei konkretem Bedarf einsetzen.
Automatisierung und klare Prozesse minimieren Risiken: Durch Autoenrollment, SCEP/NDES und konsistente Zertifikatvorlagen lassen sich Zertifikate zuverlässig ausrollen und erneuern. Definierte Lifecycle-Prozesse (von der Beantragung bis zum Widerruf) verhindern Ablaufchaos oder Sicherheitslücken durch vergessene Sperrungen.
Betriebssicherheit erfordert Kontrollen: PKI-Server müssen gehärtet, gepatcht und kontinuierlich überwacht werden; CRLs/OCSP sind hochverfügbar bereitzustellen. Regelmäßige Backups und geübte Recovery-Verfahren gewährleisten Handlungsfähigkeit im Ernstfall.
Organisation ist genauso wichtig wie Technik: Vier-Augen-Prinzip, klare Dokumentation und geschulte Administratoren helfen, typische Fehler (wie Online-Root, schwache Berechtigungen, veraltete Einstellungen) zu vermeiden und die PKI auf Dauer sicher zu betreiben.

Glossar

Begriff	Erläuterung
X.509	Standardformat für digitale Zertifikate (definiert Aufbau, Felder und Erweiterungen nach X.509).
EKU (Extended Key Usage)	Erweiterte Schlüsselnutzung: Zertifikatserweiterung zur Angabe zulässiger Verwendungszwecke (z.B. nur Serverauthentifizierung, nur Code Signing).
SAN (Subject Alternative Name)	Erweiterung in Zertifikaten, die alternative Namen des Inhabers enthält (DNS, E-Mail, UPN etc.).
CRL (Certificate Revocation List)	Sperrliste widerrufener Zertifikate, die von der CA signiert und veröffentlicht wird.
OCSP (Online Certificate Status Protocol)	Protokoll zur Online-Abfrage des Sperrstatus einzelner Zertifikate bei einem OCSP-Responder.
AIA (Authority Information Access)	Zertifikatserweiterung mit Hinweisen, wo Infos zur CA abrufbar sind (CA-Zertifikat, OCSP-Server).
CDP (CRL Distribution Point)	Zertifikatserweiterung mit den URLs, unter denen die CRL der CA verfügbar ist.
KSP (Key Storage Provider)	Windows-Komponente zur Verwaltung kryptographischer Schlüssel (moderne Alternative zum alten CSP).
HSM (Hardware Security Module)	Spezielles Hardware-Modul zur sicheren Speicherung und Nutzung von Schlüsseln (Schlüssel verlassen das Gerät nicht).
NDES (Network Device Enrollment Service)	ADCS-Rolle, die das SCEP-Protokoll bereitstellt und es Netzwerkgeräten/MDM ermöglicht, Zertifikate von der CA zu erhalten.
SCEP (Simple Certificate Enrollment Protocol)	Einfache HTTP-Schnittstelle zur Zertifikatsbeantragung, meist von Geräten oder MDM genutzt (NDES ist die Windows-Implementierung).

Microsoft ADCS Beratung – PKI-Optimierung direkt vom Experten

Mai 27, 2025 | Uncategorized, Zertifikate

Zu Power Automate biete ich eine eintägige Online-Schulung an, die regelmäßig durchgeführt wird. Hier finden Sie die Schulung zu Power Automate.Als anerkannter PKI-Spezialist und Autor von 20 Fachbüchern unterstütze ich Sie dabei, Ihre Active Directory Certificate...

Microsoft Active Directory Certificate Services (ADCS) – Grundlagen, Architektur und Best Practices

Consulting, Beratung

Weitere Beiträge zum Thema