Windows Server 2025 / Aufgaben von AD CS und Planung einer internen PKI

Active Directory Certificate Services (AD CS), die Zertifikatdienste von Active Directory, stellen Zertifikate einer Organisation aus und verwalten sie. Vor der Installation müssen Sie festlegen, wem vertraut wird, wer Zertifikate beantragen und genehmigen darf und wer Sperrung, Erneuerung und Wiederherstellung verantwortet.

Bedarf für eine interne CA klären

Mit AD CS betreiben Sie eine Zertifizierungsstelle (Certification Authority, CA) innerhalb einer Public-Key-Infrastruktur (PKI). Die CA signiert Zertifikate, die Identitäten an öffentliche Schlüssel binden; zur PKI gehören außerdem Richtlinien, Schlüsselschutz, Vertrauensverteilung und Betriebsabläufe. Ein Client muss dem Aussteller vertrauen und Namen, Verwendungszweck, Gültigkeit und weitere einschlägige Bedingungen prüfen. Eine vorhandene Zertifikatdatei genügt dafür nicht.

Wiederkehrende Zertifikaterneuerungen interner Dienste oder die Authentifizierung verwalteter Geräte können eine eigene PKI begründen. Eine interne CA genießt jedoch nicht automatisch das Vertrauen beliebiger Browser und fremder Geräte. Für einen öffentlichen Dienst mit nicht verwalteten Clients kann ein öffentlich vertrauenswürdiges Zertifikat für einen kontrollierten Namen geeigneter sein. Vergleichen Sie Bedarf und Betriebsressourcen; ein selbstsigniertes Laborzertifikat schafft keine produktionsreife PKI.

Die Übersicht zu AD CS erläutert die Aufgaben. Erfassen Sie vor einer weiteren CA vorhandene PKI, Zuständige und freigegebene Ausstellungsdienste. Soll etwa aus dem HTTPS-Test auf WEB1 ein interner Dienst werden, dokumentieren Sie DNS-Namen, nutzende Clients, Verantwortliche, Erneuerungsfrist und einen geeigneten bestehenden Aussteller. Eine einzelne Website rechtfertigt nicht automatisch eine neue CA.

Hierarchie und Vertrauensgrenzen entwerfen

Eine offline gehaltene Stamm-CA mit einer online betriebenen ausstellenden CA ist eine mögliche Architektur, keine allgemeingültige Vorgabe. Die Stamm-CA bildet den oberen Vertrauensanker; eine untergeordnete CA stellt die vorgesehenen Zertifikate aus. Der Offlinebetrieb verringert die alltägliche Angriffsfläche, erfordert aber kontrollierte Aktivierung, Veröffentlichung, Erneuerung und Wiederherstellung. Weitere Ebenen schaffen zusätzliche Abhängigkeiten und Arbeit. Bewerten Sie sie anhand von Umfang, Bedrohungen und tatsächlich verfügbaren Betriebsressourcen.

Die Überlegungen zum PKI-Entwurf behandeln CA- und Servernamen, kompatible Kryptografieanbieter, Schlüsselschutz, Gültigkeitszeiträume und Veröffentlichungsadressen vor der Installation. Servername und CA-Name sind unterschiedliche Angaben; die Umbenennung eines installierten CA-Servers ist keine gewöhnliche Routineänderung. Prüfen Sie Verwaltungs- und Schlüsselgrenzen vor einer Kombination mit einem Domänencontroller: Gemeinsame Rollen verbinden auch Berechtigungs- und Wiederherstellungsbereiche.

Vorlagen und Registrierungsrechte begrenzen

Zertifikatvorlagen bestimmen Verwendungszweck, Schlüsselrichtlinien, Gültigkeit und Registrierungsbedingungen. Extended Key Usage (EKU), die erweiterte Schlüsselverwendung, bezeichnet Zwecke wie Server- oder Clientauthentifizierung. Laut Verwaltung von AD-CS-Zertifikatvorlagen verwenden Unternehmens-CAs Vorlagen in Active Directory Domain Services (AD DS), den Active-Directory-Domänendiensten; eigenständige CAs verwenden sie nicht. Eine Vorlage anzulegen, sie auf einer CA zur Ausstellung bereitzustellen und Registrierung zu erlauben sind getrennte Entscheidungen. Zu weit gefasste Ausstellung von Authentifizierungszertifikaten kann Identitätsmissbrauch ermöglichen.

• Trennen Sie Antragsteller von Genehmigung und Ausstellung. Benennen Sie konkrete Gruppen und Verantwortliche für Richtlinienänderungen; verwenden Sie kein gemeinsames Konto für alle Aufgaben.
• Entscheiden Sie, ob Antragsteller Namen selbst angeben dürfen und wer deren Berechtigung dafür prüft. Bei Webzertifikaten muss der genehmigte Name zum vorgesehenen Dienst gehören; frei eingegebene beliebige Identitäten reichen nicht aus.
• Begrenzen Sie die Verwendung privater Schlüssel und begründen Sie eine nötige Exportierbarkeit. Unterscheiden Sie Server-, CA- und Wiederherstellungsschlüssel und dokumentieren Sie Empfänger und Verwahrung vor einer Exportfreigabe.
• Beschränken Sie automatische Registrierung auf freigegebene Gruppen und Zwecke. Planen Sie einen begrenzten Pilotversuch mit erlaubten und unerlaubten Antragstellern sowie Nachweisen zu Fehlern, ausgestellten Zertifikaten und Alarmen, bevor Sie den Geltungsbereich erweitern.

Bewerten Sie die Folgen, bevor Authenticated Users oder andere große Gruppen umfassende Rechte erhalten. Halten Sie Antragsteller, Vorlagenadministration, CA-Administration, für Genehmigung und Sperrung zuständige Zertifikatverwalter sowie Prüfer schriftlich fest und trennen Sie Aufgaben entsprechend dem Risiko. Der Leitfaden zu CA-Sicherheit, Delegierung und Überwachung unterscheidet diese Kontrollen. Zum Lesen von Nachweisen ist keine vollständige CA-Administration erforderlich. Legen Sie erlaubte und abzuweisende Testvorgänge sowie auswertbare Änderungs- und Ausstellungsalarme fest.

Sperrinformationen und Erneuerung betreiben

Planen Sie Sperrungen für kompromittierte Schlüssel, ausscheidende Benutzer und stillgelegte Server. Eine Certificate Revocation List (CRL), eine Zertifikatsperrliste, veröffentlicht gesperrte Zertifikate. Authority Information Access (AIA), der Zugriff auf Ausstellerinformationen, kann etwa auf das CA-Zertifikat verweisen; CRL Distribution Points (CDP) geben Bezugsorte für Sperrlisten an. Zertifikatkette und Sperrstatus sind unterschiedliche Prüfungen. Dokumentieren Sie tatsächliche Pfade, Herausgeber, Veröffentlichungsrhythmus, Ablauf der Listen und die Clients, die sie erreichen müssen.

Nur intern erreichbare DNS- oder LDAP-Veröffentlichungen passen möglicherweise nicht zu externen oder nicht domänengebundenen Clients. Prüfen Sie die Erreichbarkeit mit den wirklichen Geräten und Nutzungskontexten, einschließlich Proxy und Netzbeschränkungen. Das Anhalten der CA sperrt nicht sofort alle ausgestellten Zertifikate, unterbricht aber unterschiedliche Funktionen wie Ausstellung, Erneuerung oder Aktualisierung von Sperrinformationen. CRL-Gültigkeit, Zwischenspeicher und Anwendungsrichtlinien beeinflussen das Ergebnis. Noch gültige Zertifikate garantieren daher keinen ungestörten Betrieb. Neue Veröffentlichungsadressen gelten für neu ausgestellte Zertifikate; ältere Zertifikate können weiterhin die bisherigen Adressen benötigen.

Koordinieren Sie die Erneuerung von Stamm-CA, ausstellenden CAs und Dienstzertifikaten. Eine lange beantragte Laufzeit setzt weder die verbleibende Gültigkeit des Ausstellers noch geltende Richtlinien außer Kraft. Erfassen Sie Abhängigkeiten, Verantwortliche, Handlungstermine und die Prüfung der neuen Kette. Kontrollieren Sie nach einer Diensterneuerung das tatsächlich präsentierte Zertifikat und seine Bindung. Ein neues Objekt im Zertifikatspeicher allein genügt nicht. Bei neuen CA-Schlüsseln oder Ketten müssen Verteilung und Clientkompatibilität vor dem Entfernen bisheriger Bestandteile geklärt sein.

Schlüsselschutz und Wiederherstellung dokumentieren

Ein kompromittierter privater CA-Schlüssel betrifft den gesamten zugehörigen Vertrauensbereich. Prüfen Sie ein Hardware Security Module (HSM), ein spezielles Gerät zum Schlüsselschutz und für kryptografische Operationen, zusammen mit begrenzten Administrationsrechten und geteilten Verantwortlichkeiten. Ein HSM ersetzt keine Abläufe und wiederherstellbaren Sicherungen. Der Leitfaden zur CA-Sicherung und Migration nennt Datenbank, private Schlüssel, Registrierungskonfiguration, gegebenenfalls CAPolicy.inf und die Liste zugewiesener Vorlagen einer Unternehmens-CA. Vorlagen und Zuordnungen in AD DS werden durch eine reine CA-Datenbanksicherung nicht vollständig abgedeckt. Planen Sie geschützte Sicherungen, verwahrte Kennwörter und eine isolierte Wiederherstellung; bei HSM-Schlüsseln zusätzlich das unterstützte Herstellerverfahren. Eine Kopie des öffentlichen Zertifikats sichert den privaten Schlüssel nicht.

1. Erfassen Sie Nutzer, Zwecke und erwarteten Bedarf. Halten Sie je Dienst Namen, Clientgeräte und Benutzer, bisherigen Aussteller, Zuständige, Netzabhängigkeiten und Kontinuitätsbedarf fest.
2. Benennen Sie einen Eigentümer und vergleichen Sie vorhandene freigegebene PKI oder Ausstellungsdienste mit einem Neubau. Dokumentieren Sie Begründung, Betriebsressourcen und offene Punkte statt nur einer Installationsauswahl.
3. Entwerfen Sie Stamm- und ausstellende CAs, Schlüsselschutz, gegebenenfalls Vorlagen, Berechtigungen und Vertrauensverteilung. Bestimmen Sie, wer beantragen, genehmigen, ändern und prüfen darf und wie Vertrauen am Dienstende entzogen wird.
4. Definieren Sie CRL-/AIA-Veröffentlichung, Erneuerungsverantwortliche, Alarme, Sicherung und isolierte Wiederherstellung. Nennen Sie Speicherorte und nachzuweisende Ergebnisse einschließlich alter weiter benötigter URLs und der Wiederherstellung geschützter Schlüsselmaterialien.
5. Prüfen Sie in einer getrennten Umgebung erlaubte und abgewiesene Anträge, zulässige und unzulässige Namen, Erneuerung, anwendungsspezifische Sperrprüfung und Wiederherstellung aus Sicherungen. Dokumentieren Sie Soll, Ist und Fehlermaßnahmen; eine erfolgreiche Ausstellung bestätigt nicht alle übrigen Bedingungen.

Ergebnis dieser Übung ist ein überprüfbarer Entwurf, keine installierte CA. Installieren Sie AD CS dafür nicht auf DC1 und verteilen Sie keinen Labor-Vertrauensanker an reale Geräte. Vor einer Bereitstellung müssen Zuständigkeiten, dauerhaft durchführbare Abläufe, Abnahmenachweise und ein Plan zum Entzug von Vertrauen oder zum Dienstübergang geklärt sein. Ist beispielsweise offen, wer CRLs veröffentlicht, Schlüssel wiederherstellt oder fehlgeschlagene Erneuerungen bearbeitet, dokumentieren Sie diese offene Entscheidung vor der Installationsfreigabe.