Entmystifizierung der Active Directory-Zertifikatdienstcontainer 

Einführung

Die Active Directory Certificate Services (ADCS)-Container sind die spezifischen Objekte innerhalb der Konfigurationspartition von Active Directory, in denen eine Windows PKI CA-Zertifikate, Zertifikatvorlagen, CRLs und Registrierungsdaten speichert. Sie werden benötigt, da jeder Zertifikatsausstellungs- und Zertifikatsvalidierungsvorgang in der Gesamtstruktur davon abhängt, was dort veröffentlicht ist.

Die Untersuchung der Active Directory Certificate Services (ADCS)-Container innerhalb der Active Directory-Struktur ist entscheidend, um zu verstehen, wie digitale Zertifikate in einer Organisation verwaltet und verteilt werden. Sind diese Container nicht korrekt befüllt, können Clients keine Zertifikatskette erstellen, den Sperrstatus nicht überprüfen, keine Unternehmenszertifizierungsstelle für die Registrierung finden und kein Zertifikat für die Smartcard-Anmeldung verwenden, selbst wenn das Zertifikat an sich gültig ist.

Dieser Leitfaden beschreibt die Funktion der einzelnen ADCS-Container, die Voraussetzungen und die schrittweisen Befehle für die Arbeit mit ihnen, wie man überprüft, ob eine Änderung wirksam wurde, die häufigsten Fehler, auf die Administratoren stoßen, die Schritte zum Zurücksetzen, falls eine Änderung fehlschlägt, und eine Kurzübersichtstabelle, die jeden Container seinem Besitzer zuordnet.

Wichtige Erkenntnisse

• Alle ADCS-Container befinden sich im Konfigurationsnamenskontext, der gesamtstrukturweit repliziert wird, sodass eine Änderung, die auf einem Domänencontroller vorgenommen wird, letztendlich alle Domänen in der Gesamtstruktur betrifft.
• Jeder Container hat eine bestimmte Aufgabe: AIA und Zertifizierungsstellen unterstützen den Aufbau der Zertifizierungskette, CDP unterstützt die Überprüfung von Widerrufen, Enrollment Services unterstützt die Client-Erkennung von Zertifizierungsstellen und NTAuthCertificates steuert die Anmeldung mit Smartcards.
• Die meisten PKI-Ausfälle in der Praxis lassen sich darauf zurückführen, dass einer dieser Container veraltet ist, einen Eintrag nicht enthält oder ein abgelaufenes Objekt enthält, und nicht auf die CA-Software selbst.
• Standardmäßig können nur Enterprise-Administratoren diese Container ändern. Daher ist eine Änderungskontrolle und eine Rollback-Planung vor jeder Änderung unerlässlich.
• Unternehmen, die auf manuelle, undokumentierte PKI-Konfigurationen angewiesen sind, meldeten im vergangenen Jahr in 45 % der Fälle zertifikatsbedingte Ausfallzeiten. Laut der Trust Pulse Survey von DigiCert, die am 2. Juli 2025 veröffentlicht wurde, waren 37.5 % dieser Ausfälle speziell auf ein abgelaufenes Zertifikat zurückzuführen; ein veralteter CDP- oder AIA-Container trägt direkt zu diesem Ergebnis bei.

Für wen sind ADCS-Container in Active Directory relevant?

Diese Container sind unterhalb der PKI angesiedelt, daher sind diejenigen, die die Auswirkungen einer Fehlkonfiguration spüren, oft nicht diejenigen, die sie konfiguriert haben. Im Folgenden wird beschrieben, was jedes Team konkret tun sollte.

• PKI-Administratoren Die Container müssen direkt verwaltet werden. Maßnahme: Dokumentieren Sie, welche CA- und Template-Objekte in jedem Container vorhanden sein sollten, und überprüfen Sie diese Liste regelmäßig anhand der Live-Konfiguration, nicht erst, wenn ein Fehler auftritt.
• Sicherheitsarchitekten Entscheiden Sie, wer sich für welche Vorlagen registrieren kann und welche Zertifizierungsstellen für die Smartcard-Anmeldung vertrauenswürdig sind. Maßnahme: Überprüfen Sie NTAuthCertificates und den Zertifikatvorlagencontainer gemeinsam, da eine permissive Vorlage in Kombination mit einem ungeprüften NTAuth-Eintrag ein bekannter Weg zur Rechteausweitung ist.
• Plattform- und Identitätsteams Führen Sie die Domänencontroller aus, die diese Konfigurationsdaten replizieren. Maßnahme: Stellen Sie sicher, dass die Replikation der Konfigurationspartition auf allen Domänencontrollern einwandfrei funktioniert, bevor Sie ein containerbezogenes Problem als PKI-Problem behandeln.
• Compliance und GRC Es ist ein Nachweis erforderlich, dass nur zugelassene Zertifizierungsstellen vertrauenswürdige oder Smartcard-fähige Zertifikate ausstellen dürfen. Maßnahme: Fügen Sie der regelmäßigen PKI-Zugriffsprüfung eine Containerprüfung hinzu, die speziell Zertifizierungsstellen, AIA und NTAuthCertificates umfasst.
• CISOS Sie tragen das Risiko, dass ein gesamtstrukturweiter Container ein fehlerhaftes oder vergessenes Zertifizierungsstellenobjekt enthält. Maßnahme: Behandeln Sie diese Container als Assets der Stufe 0, da sie Vertrauensentscheidungen in allen Domänen der Gesamtstruktur beeinflussen, nicht nur in einer.

Was sind Active Directory Certificate Services (ADCS)-Container und wozu benötigt man sie?

ADCS-Container sind die Active Directory-Objekte im Container „Public Key Services“ im Namenskontext „Konfiguration“. Sie speichern alle für den Betrieb einer Windows-PKI erforderlichen Daten: vertrauenswürdige Stammzertifikate, Zwischenzertifizierungsstellenzertifikate, Zertifikatssperrlisten, Zertifikatvorlagen, Registrierungen des Registrierungsdienstes, Zertifikate des Schlüsselwiederherstellungsagenten, Objektkennungen und die Liste der für die Smartcard-Anmeldung vertrauenswürdigen Zertifizierungsstellen. Diese Container sind notwendig, da Windows-Clients direkt von ihnen lesen und nicht von der Zertifizierungsstelle selbst, um Vertrauens- und Validierungsentscheidungen zu treffen. Selbst eine einwandfrei funktionierende Zertifizierungsstelle, deren Zertifikat jedoch nicht im richtigen Container gespeichert wurde, kann die Validierung für Clients in der gesamten Gesamtstruktur nicht durchführen.

Wo ADCS-Container gespeichert sind: der Konfigurationsbenennungskontext

Sie müssen zu Ihrem Domänencontroller navigieren und ADSIEdit.msc öffnen . Klicken Sie nach dem Öffnen auf Aktionen , dann auf Verbinden mit und wählen Sie anschließend unter dem bekannten Dropdown-Menü Namenskontext die Option Konfiguration aus.

ADCS-Container werden im Konfigurationsbenennungskontext unter dem Public Key Services-Container gespeichert:

Diese Behälter erleichtern die Lagerung und Verteilung verschiedener Komponenten, die für das Zertifikatsmanagement im gesamten Waldgebiet unerlässlich sind.

Voraussetzungen:

Bitte überprüfen Sie jeden dieser Punkte, bevor Sie einen ADCS-Container anzeigen oder ändern:

• Mitgliedschaft in der Gruppe „Unternehmensadministratoren“ oder eine delegierte Berechtigungserteilung für den spezifischen Container, der geändert wird.
• Zugriff auf einen in die Domäne eingebundenen Rechner, auf dem ADSIEdit.msc, PKIView.msc und certutil.exe verfügbar sind.
• Vor jeder Änderung sollte eine aktuelle Sicherungskopie oder ein Export des Containerinhalts erstellt werden, da diese Objekte für die gesamte Gesamtstruktur gelten und sich ein Fehler überall auswirkt.
• Bestätigung, dass die Active Directory-Replikation über die Domänencontroller hinweg einwandfrei funktioniert, damit eine Änderung nicht fälschlicherweise als Replikationsfehler interpretiert wird.
• Eine dokumentierte Liste der CA-Zertifikate, Vorlagen und CRLs, die in jedem Container vorhanden sein sollten, um sie während der Validierung abzugleichen.

Schritt für Schritt: Anzeigen und Verwalten von ADCS-Containern

Bearbeiten Sie jeden der unten aufgeführten Container mithilfe von ADSIEdit.msc zum Anzeigen und certutil.exe zum Veröffentlichen der Änderungen. Jeder Container hat eine andere Funktion; behandeln Sie daher jeden Schritt als separate Überprüfung und nicht als einen einzigen Durchgang.

Im AIA-Container (Authority Information Access) veröffentlichen

Der AIA-Container dient als Speicherort für Zwischenzertifikate von Zertifizierungsstellen und Cross-Zertifikate. Diese Zertifikate sind entscheidend für den Aufbau von Vertrauensketten innerhalb der PKI-Infrastruktur . Neuinstallationen von Unternehmenszertifizierungsstellen füllen den AIA-Container automatisch.

Um CA-Zertifikate programmatisch in diesen Container zu installieren, verwenden Sie folgenden Befehl:

Der AIA-Container speichert Zwischenzertifikate von Zertifizierungsstellen und Kreuzzertifikate und ist eine entscheidende Komponente im Zertifikatsvalidierungsprozess. Clients nutzen den AIA-Container, um fehlende Zwischenzertifikate von Zertifizierungsstellen abzurufen , die für den Aufbau von Zertifikatsketten erforderlich sind. Dies gewährleistet eine nahtlose Vertrauensbildung und -validierung innerhalb der PKI-Infrastruktur.

CRLs im CDP-Container (CRL-Verteilungspunkt) veröffentlichen

Der CDP-Container dient der Speicherung von Zertifikatssperrlisten (CRLs). Jede Zertifizierungsstelle (CA) verfügt über einen eigenen CDP-Container, der üblicherweise durch den NetBIOS-Namen des CA-Hosts identifiziert wird. Neu bereitgestellte Enterprise-CAs veröffentlichen die initialen CRLs automatisch im CDP-Container.

Um CRLs programmatisch in diesen Container zu installieren, verwenden Sie folgenden Befehl:

Neben der Speicherung von Sperrlisten (CRLs) spielt der CDP-Container eine entscheidende Rolle für die Integrität und Sicherheit des PKI-Ökosystems, da er die zeitnahe Verteilung von Sperrdaten an Clients ermöglicht. Die korrekte Konfiguration der CDP-Speicherorte ist unerlässlich, um sicherzustellen, dass Clients CRLs bei Bedarf effizient abrufen können.

Überprüfen Sie den Zertifikatvorlagencontainer

Dieser Container enthält Unternehmenszertifikatvorlagen, die von Unternehmenszertifizierungsstellen verwendet werden. Die direkte Bearbeitung der Vorlagen wird hier nicht empfohlen; verwalten Sie die Vorlagen stattdessen mit dem MMC-Snap-In „Zertifikatvorlagen“ (certtmpl.msc).

Der Container für Zertifikatvorlagen enthält zwar primär vordefinierte Unternehmenszertifikatvorlagen, bietet aber auch ein Framework zur Anpassung von Richtlinien für die Zertifikatsausstellung. Administratoren können Vorlagen an die Unternehmensanforderungen anpassen, indem sie die Schlüsselverwendung, das Format des Subjektnamens und die Gültigkeitsdauer definieren und dabei branchenübliche Best Practices und Compliance-Standards einhalten.

Veröffentlichung von Root-CA-Zertifikaten im Zertifizierungsstellen-Container

Der Container für Zertifizierungsstellen speichert vertrauenswürdige Stammzertifikate, die für den Aufbau von Vertrauensbeziehungen innerhalb der PKI-Infrastruktur unerlässlich sind. Installationen von Unternehmens-Stammzertifizierungsstellen fügen ihre Zertifikate automatisch diesem Container hinzu.

Um Root-CA-Zertifikate programmatisch in diesen Container zu installieren, führen Sie folgenden Befehl aus:

Neben der Speicherung vertrauenswürdiger Stammzertifikate dient der Container „Zertifizierungsstellen“ als zentrales Repository für die Verwaltung von Vertrauensankern innerhalb der PKI-Hierarchie . Administratoren können ihn nutzen, um Vertrauensbeziehungen zu externen Entitäten wie Partnern oder Drittanbieter-Zertifizierungsstellen herzustellen. Die Aktualisierung dieser Liste ist unerlässlich für die Authentizität und Integrität der innerhalb der Organisation ausgestellten Zertifikate.

Überprüfen Sie den Container für Einschreibungsdienste

Enterprise-CA-Objekte werden im Container „Registrierungsdienste“ gespeichert und ermöglichen so den Clientzugriff auf Enterprise-CAs in der gesamten Gesamtstruktur. Dieser Container spielt eine entscheidende Rolle bei Zertifikatregistrierungsprozessen.

Der Container „Registrierungsdienste“ erleichtert Clients die Suche nach Unternehmenszertifizierungsstellen und spielt eine entscheidende Rolle bei der Automatisierung des Zertifikatregistrierungsprozesses . Clients nutzen diesen Container, um verfügbare Registrierungsdienste innerhalb der Gesamtstruktur zu identifizieren und so Zertifikate nahtlos anzufordern und zu erhalten. Die zentrale Verwaltung ermöglicht es Unternehmen, einheitliche Ausstellungsrichtlinien durchzusetzen.

Überprüfen Sie den KRA-Container (Key Recovery Agent).

Der KRA-Container speichert Key Recovery Agent-Zertifikate für jede Enterprise-CA und ermöglicht bei Bedarf Schlüsselwiederherstellungsvorgänge.

Neben der Speicherung von Schlüsselwiederherstellungszertifikaten unterstützt dieser Container wichtige Archivierungs- und Wiederherstellungsvorgänge, die für Datenschutz und Compliance unerlässlich sind. Organisationen können bestimmte Personen als Schlüsselwiederherstellungsbeauftragte benennen, und die regelmäßige Überprüfung und Aktualisierung dieser Zertifikate ist entscheidend für die Wahrung der Integrität und Vertraulichkeit sensibler Informationen.

Überprüfen Sie den OID-Container (Objektkennung).

Der OID-Container verwaltet Objektkennungen, die innerhalb des Unternehmens registriert sind und für die Definition benutzerdefinierter Anwendungsrichtlinien, Ausstellungsrichtlinien und Zertifikatvorlagen unerlässlich sind.

Der OID-Container dient als Register für unternehmensweit registrierte Objektkennungen und ermöglicht so Interoperabilität und Standardisierung zwischen Systemen und Anwendungen. Administratoren weisen benutzerdefinierten Anwendungsrichtlinien, Ausstellungsrichtlinien und Zertifikatvorlagen eindeutige OIDs zu. Die zentrale Verwaltung der OIDs trägt dazu bei, Konflikte zu vermeiden und die Kompatibilität mit Industriestandards zu gewährleisten.

Überprüfen Sie den Eintrag „NTAuthCertificates“.

NTAuthCertificates ist kein Container, sondern ein Eintrag. Hier werden Zertifikate für Zertifizierungsstellen gespeichert, die berechtigt sind, Smartcard-Anmeldezertifikate auszustellen und private Clientschlüssel zu archivieren. Die Smartcard-Anmeldung und bestimmte Zertifikatsregistrierungsprozesse basieren auf den hier gespeicherten Zertifikaten.

Der Eintrag „NTAuthCertificates“ unterstützt erweiterte Authentifizierungsmechanismen in Active Directory-Umgebungen, wie z. B. die Anmeldung per Smartcard. Er speichert Zertifikate von Zertifizierungsstellen (CAs), die zur Ausstellung von Smartcard-Anmeldezertifikaten berechtigt sind, und archiviert private Schlüssel. Unternehmen können ihre Sicherheitslage verbessern, indem sie sicherstellen, dass hier nur vertrauenswürdige CAs aufgeführt werden. Dadurch wird das Risiko unberechtigten Zugriffs und von Datenlecks minimiert.

Verwenden Sie alternative AD-Containerverwaltungstools (PKIView.msc).

Während ADSIEdit.msc Einblicke in die Details des ADCS-Containers bietet, bieten Tools wie PKI Health Monitor (PKIView.msc) eine benutzerfreundlichere Oberfläche für die Verwaltung der Containerinhalte, und certutil.exe bleibt das primäre Tool zum Hinzufügen von Zertifikaten und CRLs zu diesen Containern.

So öffnen Sie den Bereich „AD-Container“ in PKIView:

• Führen Sie PKIView.msc auf Ihren ausstellenden Zertifizierungsstellen aus.
• Klicken Sie auf Enterprise PKI, dann auf Aktionen und anschließend auf AD-Container verwalten.



• Dadurch wird der Bereich „AD-Container“ geöffnet, der über eine benutzerfreundlichere Oberfläche verfügt und mit dem die AD-Container direkt angezeigt und bearbeitet werden können.

Validierungsprüfungen

Nach der Veröffentlichung in einem beliebigen Container muss überprüft werden, ob die Änderung tatsächlich wirksam geworden ist und von Clients genutzt werden kann:

• Führen Sie certutil -store -enterprise Root um zu bestätigen, dass ein Root-CA-Zertifikat im Container „Zertifizierungsstellen“ angezeigt wird.
• Führen Sie certutil -store -enterprise SubCA um zu bestätigen, dass ein Zwischenzertifizierungsstellenzertifikat im AIA-Container angezeigt wird.
• Führen Sie certutil -store -enterprise NTAuth um zu überprüfen, ob eine Zertifizierungsstelle im Eintrag NTAuthCertificates vorhanden ist, bevor man sich beim Smartcard-Login darauf verlässt.
• Führen Sie certutil -verify -urlfetch um den vollständigen Aufbau der Kette zu simulieren, einschließlich des Abrufs von den AIA- und CDP-URLs, und um zu bestätigen, dass die Kette fehlerfrei aufgelöst wird.
• Öffnen Sie PKIView.msc und vergewissern Sie sich, dass für jede Zertifizierungsstelle ein grünes Statussymbol anstelle einer gelben oder roten Warnung für ihren AIA- oder CDP-Standort angezeigt wird.
• Erzwingen Sie eine Richtlinienaktualisierung mit certutil -pulse auf den betroffenen Domänencontrollern und überprüfen Sie den Container nach Abschluss der Replikation erneut.

Häufige Fehler und deren Behebung

CERT_E_UNTRUSTEDROOT (0x800B0109)

Dieser Fehler bedeutet, dass der Client keine vertrauenswürdige Stammzertifizierungsstelle in seiner Zertifikatskette finden kann. Stellen Sie sicher, dass das Stammzertifizierungsstellenzertifikat im Container „Zertifizierungsstellen“ veröffentlicht wurde und dass der Client seit der Veröffentlichung des Zertifikats mit einem Domänencontroller synchronisiert wurde.

„Die Widerrufsfunktion konnte den Widerruf nicht prüfen, da der Widerrufsserver offline war.“

Dies deutet auf eine fehlende, abgelaufene oder nicht erreichbare CRL im CDP-Container hin. Prüfen Sie, ob die CRL noch gültig ist, veröffentlichen Sie sie mit `certutil -crl` auf der Zertifizierungsstelle erneut und vergewissern Sie sich, dass das CDP-Objekt vom Netzwerksegment des Clients aus erreichbar ist.

Die Zertifikatsregistrierung schlägt fehl, da keine Zertifizierungsstelle verfügbar ist.

Dies bedeutet in der Regel, dass im Container „Registrierungsdienste“ das CA-Objekt fehlt oder dass es nach einer Umbenennung oder Migration der Zertifizierungsstelle veraltet ist. Prüfen Sie, ob das CA-Objekt in „Registrierungsdienste“ vorhanden ist und ob dessen Attribut „certificateTemplates“ die angeforderte Vorlage enthält.

Anmeldung mit Smartcard trotz gültigem Zertifikat verweigert

Dies deutet fast immer auf einen fehlenden Eintrag in NTAuthCertificates für die ausstellende Zertifizierungsstelle hin. Überprüfen Sie mit `certutil -store -enterprise NTAuth` , ob das Zertifikat der Zertifizierungsstelle aufgeführt ist , veröffentlichen Sie es gegebenenfalls und erzwingen Sie eine Richtlinienaktualisierung auf allen Domänencontrollern.

Schritte zum Zurücksetzen

1. Bevor Sie Änderungen vornehmen, exportieren Sie die Objekte des betroffenen Containers mit ADSIEdit oder ldifde, damit der vorherige Zustand wiederhergestellt werden kann.
2. Falls ein neu veröffentlichtes Zertifikat oder eine CRL Validierungsfehler verursacht, entfernen Sie das betreffende Objekt aus dem Container mithilfe von ADSIEdit, anstatt den gesamten Container zu löschen.
3. Importieren Sie den exportierten vorherigen Zustand erneut, wenn ein Rollback erforderlich ist und das spezifische Objekt nicht eindeutig identifiziert werden kann.
4. Replikation erzwingen und ausführen certutil -pulse auf den betroffenen Domänencontrollern, damit der Rollback vor dem erneuten Testen wirksam wird.
5. Als letzte Möglichkeit bei einem Replikationsproblem im gesamten Ökosystem, das durch eine fehlerhafte Änderung verursacht wurde, sollte eine autoritative Wiederherstellung der Konfigurationspartition durchgeführt werden, anstatt weitere Live-Änderungen vorzunehmen.

Berechtigungen

Standardmäßig besitzen nur Mitglieder der Gruppe „Unternehmensadministratoren“ die Berechtigung, Inhalte der Dienste für öffentliche Schlüssel zu ändern. Administratoren können die entsprechenden Berechtigungen bei Bedarf über ADSIEdit.msc delegieren. Die Delegierung sollte sich jedoch auf den spezifischen Container beschränken, den eine Einzelperson oder ein Team tatsächlich verwalten muss, und nicht auf die gesamte Struktur der Dienste für öffentliche Schlüssel.

Kurzübersicht: Voraussetzungen, Befehle/Konfiguration, Validierungsprüfung, Häufige Fehler, Rollback und Verantwortlicher

Container	Voraussetzung	Befehl/Konfiguration	Validierungsprüfung	Häufiger Fehler	Rollback	Eigentümer
Zertifizierungsstellen	Root-CA-Zertifikatdatei verfügbar; Zugriff für Unternehmensadministratoren	certutil -dspublish -f RootCA	certutil -store -enterprise Root	CERT_E_UNTRUSTEDROOT (0x800B0109)	Entfernen Sie das betreffende veröffentlichte Objekt über ADSIEdit; stellen Sie gegebenenfalls den vorherigen Export wieder her.	PKI-Administrator
AIA	Zwischenzertifikatsdatei der Zertifizierungsstelle verfügbar	certutil -dspublish -f SubCA	certutil -store -enterprise SubCA	Fehler bei der Kettenvalidierung; Zwischenprodukt fehlt	Entfernen Sie das veröffentlichte Objekt; veröffentlichen Sie das korrekte Zertifikat erneut.	PKI-Administrator
CDP	Aktuelle CRL-Datei; Zugriff auf den CA-Server	certutil -dspublish -f SubCA / certutil -crl	certutil -verify -urlfetch	Widerrufsserver offline-Fehler	Eine gültige CRL vor deren Ablauf erneut veröffentlichen; die Erreichbarkeit der CDP-URL überprüfen.	PKI-Administrator
Zertifikatvorlagen	Zertifikatvorlagen für MMC-Zugriff; genehmigtes Vorlagendesign	Verwaltung über certtmpl.msc, nicht direkte AD-Bearbeitungen.	Überprüfen Sie die Anmeldeberechtigungen und die Einstellungen für die Managergenehmigung.	Übermäßig großzügige Zulassungsrechte (Probleme der ESC-Klasse)	Registrierungsberechtigungen widerrufen; Vorlage von betroffenen Zertifizierungsstellen entfernen	Sicherheitsarchitekt
Registrierungsdienste	Enterprise CA ist bereits installiert und funktionsfähig.	Automatische Installation bei der Zertifizierungsstelle; Überprüfung über PKIView	Bestätigen Sie das CA-Objekt und das Attribut „certificateTemplates“.	Die Registrierung schlägt fehl, da kein CA verfügbar ist.	Entfernen Sie das veraltete CA-Objekt; registrieren Sie die CA neu, falls sie migriert wurde.	PKI-Administrator
NTAuthCertificates	CA-Zertifikat für Smartcard-Anmeldung genehmigt	certutil -dsPublish -f NTAuthCA	certutil -store -enterprise NTAuth	Anmeldung mit Smartcard trotz gültigem Zertifikat verweigert	Entfernen Sie den nicht autorisierten CA-Eintrag; veröffentlichen Sie den korrekten Eintrag erneut.	Sicherheitsarchitekt

Wie ADCS-Container mit dem Zertifikatslebenszyklusmanagement verbunden werden

Diese Container geben an, was als vertrauenswürdig und gültig gilt, verfolgen aber nicht die unter dieser Konfiguration ausgestellten Zertifikate im Hinblick auf deren Ablaufdatum. Die DigiCert Trust Pulse Survey vom 2. Juli 2025 ergab, dass 45 % der Unternehmen im vergangenen Jahr zertifikatsbedingte Ausfallzeiten verzeichneten, wobei 37.5 % dieser Vorfälle direkt durch ein abgelaufenes Zertifikat verursacht wurden – ein Ausfall, den ein korrekt konfigurierter CDP-Container zwar schneller aufdeckt, aber nicht von selbst verhindern kann.

Zertifikatslebenszyklusmanagement-Plattformen wie CertSecure Manager erweitern die Transparenz über die in diesen Containern veröffentlichten Informationen hinaus auf jedes tatsächlich unter dieser Konfiguration ausgestellte Zertifikat. Dadurch wird die Lücke zwischen „Die Container sind korrekt“ und „Jedes Zertifikat wird bis zur Erneuerung verfolgt“ geschlossen. Wenn Sie Ihre PKI-Abläufe umfassender modernisieren, erfahren Sie, wie PKI-Modernisierung und CLM zusammenwirken und wie eine kombinierte PKI- und CLM-Roadmap die Zertifikatsautomatisierung im gesamten Ökosystem berücksichtigt, nicht nur die Containerhygiene.

ADCS-Container in Cloud-, Hybrid- und Multi-CA-PKI-Umgebungen

Hybridumgebungen, die die AD CS-Vertrauensstellung auf in die Cloud oder Azure AD eingebundene Geräte ausdehnen, sind weiterhin darauf angewiesen, dass diese Container korrekt auf jeden Domänencontroller repliziert werden, den diese Geräte erreichen können, einschließlich schreibgeschützter Domänencontroller an Zweigstellen. Hierarchien mit mehreren Zertifizierungsstellen erhöhen den Überprüfungsaufwand: Jede Zertifizierungsstelle in der Hierarchie verfügt über eigene Einträge für AIA, CDP und Registrierungsdienste, und eine Lücke in einem dieser Einträge führt zu inkonsistenten Vertrauensstellungen und Registrierungsvorgängen in der gesamten Gesamtstruktur.

Für Organisationen, die mehrere Zertifizierungsstellen (CAs) oder eine Mischung aus On-Premises- und Cloud-PKI verwalten, zentralisiert ein PKI-as-a-Service- Modell die Containerhygiene und das Maschinenidentitätsinventar, die andernfalls für jede CA in der Hierarchie separat überprüft werden müssten.

Erfolgsmessung und was regelmäßig überprüft werden sollte

Eine einwandfreie ADCS-Containerkonfiguration ist keine einmalige Angelegenheit. Überprüfen Sie diese regelmäßig, nicht erst, wenn ein Client einen Fehler meldet:

• Ob jeder Eintrag in den Containern „Zertifizierungsstellen“ und „AIA“ einer bekannten, zugelassenen Zertifizierungsstelle entspricht und keine unerwarteten Zusätze enthält.
• Ob für jeden CDP-Eintrag eine aktuelle, nicht abgelaufene CRL im Zeitplan veröffentlicht ist
• Ob der Eintrag NTAuthCertificates nur Zertifizierungsstellen auflistet, die explizit für die Anmeldung mit Smartcards zugelassen sind
• Ob die Objekte der Registrierungsdienste mit aktuell laufenden, korrekt benannten Zertifizierungsstellen übereinstimmen und keine veralteten Einträge von außer Betrieb genommenen oder umbenannten Zertifizierungsstellen enthalten.
• Ob die Berechtigungen für die Zertifikatvorlagenregistrierung noch dem beabsichtigten Zugriffsmodell entsprechen, insbesondere für Vorlagen, bei denen die Managergenehmigung deaktiviert ist.

Ein Inventar kryptografischer Assets wie CBOM Secure erweitert die Inventarisierung von Maschinenidentitäten und die Zertifikatserkennung über das hinaus, was diese Container beschreiben, und bietet PKI-Teams einen Prüfpfad für die tatsächlich verwendeten Zertifikate, nicht nur für die Konfiguration, die sie autorisiert.

Langfristig gesehen bedeutet die Abstimmung des CA/Browser-Forums vom 11. April 2025 zur Verkürzung der maximalen Gültigkeitsdauer von TLS-Zertifikaten auf zunächst 200 Tage, dann 100 Tage und schließlich 47 Tage bis 2029, dass CDP und die Automatisierung der Registrierung an Bedeutung gewinnen werden. Denn eine kürzere Gültigkeitsdauer lässt weniger Spielraum für veraltete Zertifikate, die unbemerkt bleiben und zu Ausfällen führen können. Das NIST hat am 13. August 2024 seine ersten drei Post-Quanten-Kryptografiestandards, FIPS 203, FIPS 204 und FIPS 205, finalisiert. Jeder Plan zur Krypto-Agilität für die gesamte Infrastruktur sollte berücksichtigen, wie Root- und Zwischenzertifizierungsstellenzertifikate in diesen Containern zukünftig mit Post-Quanten-Algorithmen neu ausgestellt werden müssen. Das PQC Center of Excellence von Encryption Consulting und eine PQC-Readiness-Assessment sind die ideale Plattform, um diesen Übergang zu planen.

Einschätzung von Encryption Consulting

Encryption Consulting bietet spezialisierte Dienstleistungen zur Identifizierung von Schwachstellen und zur Risikominderung durch PKI-Services . Unsere strategische Beratung richtet PKI-Lösungen an den Unternehmenszielen aus, steigert die Effizienz und minimiert die Kosten. So können Unternehmen das volle Potenzial ihrer PKI-Investition ausschöpfen und gleichzeitig hohe Sicherheitsstandards gewährleisten.

Encryption Consulting bietet mit PKIaaS eine flexible und sichere PKI-Lösung, die auf Ihre spezifischen Bedürfnisse zugeschnitten ist. Sie zeichnet sich durch anpassbare Optionen, hohe Sicherheitsstandards und einen risikoarmen Managementansatz aus. PKIaaS automatisiert die Schlüssel- und Zertifikatsverwaltung, reduziert den Betriebsaufwand und minimiert das Risiko menschlicher Fehler. Gleichzeitig verbessert die Lösung die Netzwerktransparenz durch die Zertifikatspflicht für den Zugriff. PKIaaS übernimmt den Aufbau und die Verwaltung Ihrer PKI-Umgebung – ob in der Cloud, hybrid oder On-Premise.

CertSecure Manager bietet umfassende Funktionen für das Lebenszyklusmanagement – ​​von der Erkennung und Inventarisierung über die Ausstellung, Bereitstellung, Verlängerung und den Widerruf bis hin zum Reporting. Intelligente Berichtserstellung, Benachrichtigungen, Automatisierung, automatische Bereitstellung auf Servern und Zertifikatsregistrierung sorgen für zusätzliche Funktionen und machen CertSecure Manager zu einem vielseitigen und intelligenten Tool für genau die Art von Container- und Zertifikatstransparenz, die in diesem Leitfaden beschrieben wird.

Fazit

Das Verständnis der komplexen Funktionsweise von ADCS-Containern ist entscheidend für ein effektives Zertifikatsmanagement in Active Directory-Umgebungen. Durch die korrekte Nutzung dieser Container, die Validierung von Änderungen nach jeder Veröffentlichung und die Kenntnis des Rollback-Pfads vor jeder Bearbeitung können Unternehmen eine robuste und sichere PKI-Infrastruktur in der gesamten Gesamtstruktur aufrechterhalten.

Wenn Sie Hilfe mit Ihrer PKI-Umgebung benötigen, senden Sie uns gerne eine E-Mail an [email protected].

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis darüber, warum Sie Active Directory Certificate Services (ADCS)-Container in Ihrem Active Directory hinzufügen müssen?

Windows-Clients lesen Vertrauens- und Validierungsentscheidungen direkt aus ADCS-Containern, nicht von der Zertifizierungsstelle selbst. Daher kann eine korrekt funktionierende Zertifizierungsstelle für Clients dennoch fehlschlagen, wenn ihr Zertifikat, ihre Sperrliste (CRL) oder ihr Registrierungsobjekt im richtigen Container fehlt. Die Überprüfung dieser Container ist eine separate Aufgabe von der Verwaltung der Zertifizierungsstelle.

Warum ist das für PKI-Teams in Unternehmen wichtig?

Diese Container sind gesamtstrukturweit, daher wirkt sich ein fehlender oder veralteter Eintrag in einem von ihnen auf alle Domänen in der Gesamtstruktur aus, nicht nur auf die Domäne, in der die Zertifizierungsstelle (CA) ausgeführt wird. Die meisten PKI-Ausfälle in der Praxis lassen sich auf ein Containerproblem und nicht auf die CA-Software selbst zurückführen.

Welche Risiken erhöhen sich, wenn dieses Thema manuell behandelt wird?

Manuelle, undokumentierte Containerverwaltung führt dazu, dass sich veraltete CA-Objekte, abgelaufene CRLs und ungeprüfte NTAuthCertificates-Einträge unbemerkt ansammeln, bis ein clientseitiger Fehler eine Untersuchung erzwingt. Zu diesem Zeitpunkt liegt die eigentliche Ursache oft mehrere Änderungen entfernt vom Symptom.

Welche Teams sollten für diese Änderung verantwortlich sein?

Die PKI-Administratoren verwalten die Container direkt. Sicherheitsarchitekten sind für die Vorlagenberechtigungen und den Eintrag „NTAuthCertificates“ verantwortlich. Plattform- und Identitätsteams verwalten die Domänencontroller-Replikation, von der diese Container abhängen. Compliance- und CISO-Beauftragte überwachen dies im Rahmen des umfassenderen PKI-Risikomanagements.

Wie hängt das mit dem Zertifikatslebenszyklusmanagement zusammen?

Diese Container beschreiben, was als vertrauenswürdig eingestuft wird; sie verfolgen nicht die einzelnen Zertifikate, die im Rahmen dieser Berechtigung ausgestellt wurden, bis zu deren Ablaufdatum. Tools für das Zertifikatslebenszyklusmanagement wie CertSecure Manager erweitern die Transparenz auf jedes ausgestellte Zertifikat, nicht nur auf die Konfiguration auf Containerebene.

Wie sollten Organisationen ihren Erfolg messen?

Ein Erfolg liegt vor, wenn jeder Eintrag in Certification Authorities, AIA und NTAuthCertificates mit einer bekannten, zugelassenen Zertifizierungsstelle übereinstimmt, jeder CDP-Eintrag eine aktuelle CRL enthält und nach einer Umbenennung oder Außerbetriebnahme einer Zertifizierungsstelle keine veralteten Enrollment Services-Objekte mehr vorhanden sind.

Was sollte regelmäßig geprüft oder überwacht werden?

Prüfen Sie die Container „Zertifizierungsstellen“, „AIA“, „CDP“, „Registrierungsdienste“ und „NTAuthCertificates“ anhand einer dokumentierten Liste zugelassener Zertifizierungsstellen und Vorlagen und überwachen Sie diese auf unerwartete Ergänzungen – eine klassische Methode, um eine betrügerische vertrauenswürdige Zertifizierungsstelle zu etablieren.

Welche Auswirkungen hat dieses Thema auf Cloud-, Hybrid- oder Multi-CA-PKI?

Hybridbereitstellungen setzen voraus, dass diese Container auf jeden Domänencontroller repliziert werden, den ein Gerät erreichen kann, einschließlich schreibgeschützter Domänencontroller an Zweigstellen. Hierarchien mit mehreren Zertifizierungsstellen (CAs) vervielfachen den Prüfaufwand, da jede CA über eigene Einträge für AIA, CDP und Registrierungsdienste verfügt, die alle der gleichen Prüfung bedürfen.

Welche Voraussetzungen müssen vor der Implementierung erfüllt sein?

Mitgliedschaft in der Gruppe der Unternehmensadministratoren oder eine delegierte Berechtigungsvergabe, Zugriff auf ADSIEdit.msc, PKIView.msc und certutil.exe, ein aktueller Export des zu ändernden Containers, eine einwandfreie AD-Replikation und eine dokumentierte Liste dessen, was in jedem Container vorhanden sein sollte.

Auf welche häufigen Fehler sollten Administratoren achten?

Achten Sie auf CERT_E_UNTRUSTEDROOT (0x800B0109) aufgrund eines fehlenden Stammzertifikats, „Widerrufsserver war offline“ aufgrund einer fehlenden oder abgelaufenen CRL, Registrierungsfehler, weil keine Zertifizierungsstelle verfügbar ist, aufgrund eines veralteten Registrierungsdiensteobjekts und Anmeldeverweigerungen für Smartcards aufgrund eines fehlenden NTAuthCertificates-Eintrags.