Konfigurieren und Beheben von Problemen mit CRL-Verteilungspunkten (CDP) und Authority Information Access (AIA)

CDP- und AIA-Punkte können mitunter verwirrend sein, sind aber die wichtigsten Säulen einer funktionierenden PKI- Umgebung. Die korrekte Konfiguration von CDP- und AIA-Punkten trägt zu einer besseren und stabileren PKI-Umgebung bei, und die Behebung von Problemen kann ebenso knifflig sein. Dieser Artikel soll Ihnen helfen, etwaige CDP/AIA-Probleme, die während der PKI-Konfiguration und -Fehlerbehebung auftreten können, zu vermeiden.

Kurzantwort: Was sind CDP und AIA?

CDP (CRL Distribution Point) und AIA (Authority Information Access) sind Zertifikatserweiterungen, die Clients mitteilen, wo sie die Sperrlisten und Ausstellerzertifikate einer Zertifizierungsstelle (CA) finden. Die korrekte Konfiguration umfasst das Setzen der richtigen Dezimal-Veröffentlichungsflags auf der CA, das Zuordnen von Ersetzungstoken wie %1 und %3 zu den tatsächlichen Dateinamen und die Überprüfung, ob jede URL aufgelöst werden kann, bevor die Zertifikate produktiv eingesetzt werden.

Letzte Aktualisierung: August 2026 · Letzte Überprüfung: August 2026 · Empfohlener Aktualisierungsrhythmus: vierteljährlich, da das Verhalten von CDP/AIA an Änderungen der Gültigkeitsdauer von Zertifizierungsstellen/Browser-Foren und an Aktualisierungen der Hersteller (Windows-Zertifizierungsstelle) gebunden ist.

Zusammenfassung: Wichtigste Erkenntnisse

• Zwei Erweiterungen, zwei Aufgaben: AIA teilt den Clients mit, wo sie das ausstellende oder Stammzertifikat der Zertifizierungsstelle finden können; CDP teilt ihnen mit, wo sie die CRL für die Widerrufsprüfung finden können.
• Dezimalkennzeichen steuern das Verhalten: AIA verwendet 1, 2 und 32; CDP verwendet 1, 2, 4, 8 und 64, und diese werden zu (65, 79, 6) kombiniert, um mehrere Einstellungen gleichzeitig darzustellen.
• Ersetzungstoken bilden den Dateinamen: Die Einträge %1 bis %11 sind auf den DNS-Namen, den Kurznamen, den CA-Namen und das CRL-Suffix der Zertifizierungsstelle (CA) abgebildet. Daher führt das Umbenennen einer veröffentlichten Datei zu einem Fehler in der Namensauflösung.
• Das Debugging beginnt in PKIView.msc: Es zeigt an, welcher spezifische Speicherort (AD/LDAP, HTTP oder Dateifreigabe) fehlschlägt, bevor Sie irgendeine Konfiguration ändern.
• Die Behebung besteht in der Regel aus einem einzigen Befehl oder einer einzigen Kopie: certutil -dspublish um AD-Lücken zu beheben, oder um HTTP-Lücken zu beheben, indem das Zertifikat auf den Webserver kopiert wird.

Für wen ist die CDP/AIA-Konfiguration relevant?

Die Konfiguration von CDP und AIA wird leicht vernachlässigt, bis die Widerrufsprüfung fehlschlägt. Hier ist die Aufgabenliste der einzelnen Rollen.

PKI-Administratoren

Sie müssen die Konfiguration des Dezimal-Flags auf der Zertifizierungsstelle (CA) verwalten, die Dateinamen der Ersatz-Token mit den tatsächlich veröffentlichten Daten synchronisieren und PKIView.msc nach jeder Änderung der CA ausführen.

Sicherheitsarchitekten

Entscheiden Sie, welche CDP/AIA-Standorte intern (LDAP) und welche internetseitig (HTTP) sind, und stellen Sie sicher, dass lastverteilte oder geclusterte Endpunkte von der direkten CA-Veröffentlichung ausgeschlossen sind.

Plattformteams

Halten Sie die Webserver, auf denen HTTP AIA/CDP-Dateien gehostet werden, mit dem CertEnroll-Ordner der Zertifizierungsstelle synchron und überwachen Sie die Verfügbarkeit von Zertifikaten und CRL-Dateien wie bei jedem anderen Produktionsendpunkt.

Compliance-Teams

Bitte prüfen Sie, ob die CRL-Veröffentlichungsintervalle und die CDP-Verfügbarkeit den Zertifikatsrichtlinien der Organisation und allen behördlichen Anforderungen an die Überprüfung des Zertifikatswiderrufs entsprechen.

CISOS

CDP/AIA-Ausfälle sollten als Risiko bei der Überprüfung von Zertifikatssperrlisten betrachtet werden: Eine nicht erreichbare CRL kann dazu führen, dass eine Anwendung stillschweigend ein Zertifikat akzeptiert, das eigentlich hätte abgelehnt werden müssen.

Warum das wichtig ist: Daten und Fristen

Laut der DigiCert Trust Pulse-Umfrage (veröffentlicht am 2. Juli 2025) erlebte fast die Hälfte der Unternehmen im vergangenen Jahr einen Zertifikatsausfall, und mehr als die Hälfte (56.6 %) nannte die Nachverfolgung von Zertifikats- und Ablaufdaten als eines ihrer größten Probleme. Ein fehlerhafter CDP- oder AIA-Standort ist genau die Art von stillem Fehler, der zu diesem Ergebnis führt, da die Überprüfung des Zertifikatswiderrufs unbemerkt fehlschlägt, bis eine Anwendung beginnt, gültige Zertifikate abzulehnen oder ungültige zu akzeptieren.

Der Beschluss SC-081v3 des CA/Browser Forums (angenommen am 11. April 2025) legt die Gültigkeitsdauer von TLS-Zertifikaten schrittweise fest: 200 Tage ab dem 15. März 2026, 100 Tage ab dem 15. März 2027 und 47 Tage ab dem 15. März 2029. Kürzere Gültigkeitsdauern bedeuten, dass CRLs und AIA-Endpunkte deutlich häufiger erreicht werden. Dadurch führen beispielsweise falsch konfigurierte Dezimaltrennzeichen oder umbenannte Dateien viel früher zu sichtbaren Fehlern als unter der alten maximalen Gültigkeitsdauer von 398 Tagen.

Im Bereich der Kryptografie finalisierte das NIST am 13. August 2024 seine ersten drei Post-Quanten-Standards : FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). Jedes heute entwickelte CDP/AIA-Design sollte davon ausgehen, dass die Zertifikats- und CRL-Größen mit der Einführung von Post-Quanten-Algorithmen zunehmen werden. Dies ist ein weiterer Grund, die Veröffentlichungsflags und Ersatztoken jetzt zu implementieren, anstatt sie später zu umgehen.

Voraussetzungen:

Bevor Sie CDP/AIA konfigurieren oder Fehler beheben, vergewissern Sie sich, dass Folgendes vorhanden ist:

• Administrativer Zugriff auf den CA-Server und seine Befehlszeile (certutil).
• Zugriff auf Active Directory-Tools (ADSIEdit.msc) falls CDP/AIA-Standorte LDAP verwenden.
• Eine dokumentierte Liste aller aktuell verwendeten CDP/AIA-URLs und der jeweiligen Information, ob es sich um HTTP, LDAP oder eine Dateifreigabe handelt.
• Ein Testclient außerhalb des eigenen Netzwerks der Zertifizierungsstelle, damit Sie überprüfen können, ob URLs so aufgelöst werden, wie sie von echten Clients wahrgenommen werden.

Konfiguration von CDP/AIA-Punkten

Die ordnungsgemäße Konfiguration von CDP- und AIA-Punkten kann schwierig sein. Dazu gehört die richtige Berechtigung, wo CRLs veröffentlicht werden müssen und wo auf sie zugegriffen werden kann.

Eine falsche Konfiguration von CDP kann zu zwei Szenarien führen

• CRL kann nicht veröffentlicht werden oder
• Auf CRLs kann nicht zugegriffen werden

Konfiguration von AIA

AIA ist am einfachsten zu konfigurieren. Bei Verwendung von OCSP kann der AIA-Dezimalpunkt 34 enthalten, andernfalls ist er immer 2.

Display Name	Dezimalwert
An diesem Ort veröffentlichen	1
In die AIA-Erweiterung der ausgestellten Zertifikate aufnehmen	2
In die Erweiterung Online Certificate Status Protocol (OCSP) aufnehmen	32

Der Dezimalwert 1 wird beim Veröffentlichen im Verzeichnis %windir%\System32\certsrv\CertEnroll mit einbezogen . Er kann auch für die direkte Veröffentlichung im AIA-Verzeichnis verwendet werden, sofern die entsprechenden Berechtigungen vorliegen.

[Hinweis: Wenn sich der Standort hinter einem Load Balancer befindet, kann die CA nicht auf beide Server zugreifen, was zu Fehlern führen kann. Bitte veröffentlichen Sie nicht an diesen Standorten. Stattdessen wird eine manuelle Kopie empfohlen.]

Der Dezimalwert 2 wird eingefügt, wenn die URL zu den ausgestellten Zertifikaten hinzugefügt werden soll. Diese URLs fungieren als AIA-Punkte, von denen die Zertifikate extrahiert werden können.

Konfiguration von CDP

Die Konfiguration von CDP kann davon abhängen, wie die Zertifizierungsstelle konfiguriert ist, wie die CRLs veröffentlicht und abgerufen werden und ob Delta-CRLs veröffentlicht werden.

Display Name	Beschreibung	Dezimalwert
CRLs an diesem Ort veröffentlichen	Wird von der Zertifizierungsstelle verwendet, um zu bestimmen, ob Basis-CRLs an diesem Speicherort veröffentlicht werden sollen	1
In den CRL Distribution Point (CDP) der ausgestellten Zertifikate aufnehmen	Wird von Clients während der Widerrufsprüfung verwendet, um den Basis-CRL-Speicherort zu finden	2
In [Basis]-CRLs einschließen	Wird von Clients während der Widerrufsprüfung verwendet, um den Delta-CRL-Speicherort anhand der Basis-CRLs zu ermitteln.	4
In alle CRLs einschließen	Eine Offline-CA kann damit die LDAP-URL für die manuelle Veröffentlichung von CRLs angeben. Sie müssen außerdem den expliziten Konfigurationscontainer in der URL oder im DSConfigDN Wert in der Registrierung. certutil -setreg CA\DSConfigDN CN=	8
		16
		32
Delta-CRLs an diesem Speicherort veröffentlichen	Wird von der Zertifizierungsstelle verwendet, um zu bestimmen, ob Delta-CRLs an diesem Speicherort veröffentlicht werden sollen	64

Je nachdem, wie das CDP konfiguriert werden muss, werden entsprechend Dezimalwerte verwendet.

Der Dezimalwert 1 wird hauptsächlich verwendet, um CRLs im Verzeichnis %windir%\System32\certsrv\CertEnroll oder an anderen Orten zu veröffentlichen, zu denen die Zertifizierungsstelle über die erforderlichen Zugriffsrechte verfügt. Werden zusätzlich Delta-CRLs veröffentlicht, wird der Wert 65 (1+64) verwendet.

[Hinweis: Wenn sich der Standort hinter einem Load Balancer befindet, kann die CA nicht auf beide Server zugreifen, was zu Fehlern führen kann. Bitte veröffentlichen Sie nicht an diesen Standorten. Stattdessen wird eine manuelle Kopie empfohlen.]

Dezimalwert 2 enthält die URL oder den Standort und lässt ihn als CDP-Standort fungieren, von dem aus auf Basis- oder Delta-CRLs zugegriffen wird.

Beispiel

Dezimalwert 79 = CRLs werden an diesem Standort veröffentlicht (1) + Standort wird zu CDP hinzugefügt (2) + Delta-CRL-Standort (4) + In alle CRLs einschließen (8) + Delta-CRL an diesem Standort veröffentlichen (64)

Dezimalwert 65 = CRL an diesem Ort veröffentlichen (1) + Delta-CRL an diesem Ort veröffentlichen (64)

Dezimalwert 6 = Standort wird zu CDP hinzugefügt (2) + Delta CRL-Standort (4)

CRL-Ersatztoken

In den obigen Beispielen sind Ihnen möglicherweise %1, %3, %4, %8 und %9 aufgefallen. Dies stellt die Konfiguration der Zertifizierungsstelle und den Dateinamen dar. Wenn die Dateien umbenannt werden, können die AIA- und CDP-Punkte fehlschlagen, da die Namenskonvention nicht übereinstimmt.

Token-Name	Beschreibung	Kartenwert
ServerDNSName	Der DNS-Name des CA-Servers	%1
ServerShortName	Der NetBIOS-Name des Servers	%2
CAName	Der Name der Zertifizierungsstelle	%3
Cert_Suffix	Die Erneuerungsverlängerung der CA	%4 (gemäß Windows 2000-Zuordnung)
Zertifikatname		%4 (gemäß Windows 2003-Zuordnung
Konfigurationscontainer	Der Speicherort des Konfigurationscontainers in AD	%6
CATruncatedName	Der „bereinigte“ Name der CA	%7
CRLNameSuffix	Die Erneuerungsverlängerung der CRL	%8
DeltaCRLAllowed	Wenn Delta CRL zulässig ist, wird am Ende der Datei ein + hinzugefügt, um eine Delta-CRL anzuzeigen.	%9
CDPObjectClass		%10
CAObjectClass		%11

Basierend auf dem Zuordnungswert wird den AIA- und CDP-Punkten eine Namenskonvention zugewiesen, um die richtige Datei an diesen Standorten zu finden.

Behebung von CDP/AIA-Standortproblemen

Wenn die CDP/AIA-Standorte ordnungsgemäß konfiguriert sind, helfen diese Schritte vorübergehend bei der Behebung der Probleme. Wir verwenden beispielsweise AIA-Probleme, die auch bei CDP-Problemen funktionieren.

Nachdem wir PKIView.msc geöffnet und überprüft haben, können wir sehen, wo das Problem liegt. Wir können die URL zur weiteren Untersuchung in einen Notizblock kopieren.

Das AD verfügt nicht über unser Zertifikat, wenn das Problem am LDAP-Speicherort liegt. Dies lässt sich recht einfach beheben.

Über LDAP abgerufene Zertifikate werden vom Domänencontroller bezogen. Öffnen Sie den Domänencontroller und ADSIEdit.msc. Unter „Dienste“ > „Öffentliche Schlüsseldienste“ > „AIA“ können Sie die vorhandenen Zertifikate überprüfen. Da das Zertifikat unserer ausstellenden Zertifizierungsstelle fehlt, kann die PKI-Umgebung das Zertifikat nicht von diesem Speicherort abrufen.

Um dies zu beheben, navigieren wir zu unserer ausstellenden CA und führen den Befehl aus
certutil -dspublish -f SubCA

Sobald der Befehl erfolgreich ausgeführt wird, können wir unsere PKIView.msc aktualisieren, um zu überprüfen, ob das Problem behoben ist, und wir sollten eine saubere Tafel sehen

Wenn jedoch der AIA-Standort Nr. 2 oder der HTTP-Standort Fehler verursacht, liegt dieser Fehler daran, dass das Zertifikat an diesem Serverendpunkt nicht vorhanden ist.

Um dies zu beheben, kopieren wir das Zertifikat vom Speicherort %windir%\System32\certsrv\CertEnroll auf unseren Webserver, der unser Zertifikat hostet.

Dies würde unser Problem lösen, das wir erneut auf PKIView.msc überprüfen können.

Validierungsprüfungen nach der Konfiguration

• Führen Sie nach jeder Änderung an CDP/AIA das Programm PKIView.msc aus und vergewissern Sie sich, dass in jeder Zeile „OK“ angezeigt wird und nicht „Download nicht möglich“ oder ein Fehlerstatus.
• Rufen Sie von einem externen Client aus jede HTTP-AIA/CDP-URL direkt ab und überprüfen Sie, ob sie die erwartete .crt- oder .crl-Datei zurückgibt.
• Prüfen Sie, ob das Feld „NextUpdate“ der CRL in der Zukunft liegt, indem Sie die CRL-Datei öffnen oder sie mit certutil überprüfen.
• Öffnen Sie bei LDAP-veröffentlichten Zertifikaten ADSIEdit.msc und vergewissern Sie sich, dass das Zertifikat im erwarteten Container für öffentliche Schlüsseldienste vorhanden ist.

Häufige Fehler und Fehlercodes

• „Download nicht möglich“ in PKIView.msc: Der Speicherort ist nicht erreichbar, falsch benannt oder das Ersatztoken stimmt nicht mit der veröffentlichten Datei überein.
• CRL_E_REVOCATION_OFFLINE (0x80092013): Ein Client kann einen HTTP-CDP-Standort nicht erreichen, üblicherweise liegt ein Problem mit der Firewall, dem DNS oder dem Load Balancer vor.
• Fehlendes Zertifikat in AD (LDAP-AIA-Fehler): Das CA-Zertifikat wurde nie in Active Directory veröffentlicht; Problem behoben mit certutil -dspublish -f <path> SubCA (oder RootCA für einen Wurzel-CA).
• CertUtil: -dsPublish-Befehl FEHLGESCHLAGEN (Zugriff verweigert): Dem Konto, das den Befehl ausführt, fehlen die Schreibberechtigungen für den Public Key Services-Container in AD.
• Dateinamenskonflikt nach manuellem Kopieren: Ein Zertifikat oder eine CRL wurde beim Kopieren umbenannt und entspricht nicht mehr dem %1-%11-Ersetzungstokenmuster, das die CDP/AIA-URL erwartet.

Schritte zum Zurücksetzen

1. Falls ein neuer Dezimalkennzeichenwert die Veröffentlichung unterbricht, setzen Sie die CDP/AIA-Erweiterung mit diesem Befehl wieder auf ihren vorherigen Wert zurück. certutil -setreg CA\CACertPublicationURLs or CA\CRLPublicationURLs Verwenden Sie anschließend die zuvor gespeicherte Zeichenfolge und starten Sie die Zertifikatdienste neu.
2. Falls beim manuellen Kopieren einer Datei eine Namensabweichung entstanden ist, löschen Sie die falsch benannte Datei und kopieren Sie sie erneut, indem Sie das für diese Zertifizierungsstelle dokumentierte Muster %1-%11 genau verwenden.
3. If certutil -dspublish Es wurde ein unerwünschter doppelter Eintrag in AD eingeführt. Entfernen Sie ihn über ADSIEdit.msc aus demselben Public Key Services-Container.
4. Falls irrtümlicherweise ein Load-Balancing-Speicherort für die direkte CA-Veröffentlichung festgelegt wurde, entfernen Sie den Dezimalwert 1 von diesem Speicherort und schalten Sie wieder auf manuelles Kopieren um.

CDP/AIA-Konfigurationsreferenztabelle

Nutzen Sie diese Tabelle als Kurzübersicht über die einzelnen Konfigurationsaufgaben von CDP/AIA.

Voraussetzung	Befehl / Konfiguration	Validierungsprüfung	Häufiger Fehler	Rollback	Eigentümer
AIA-Dezimalkennzeichen auf dem CA gesetzt	certutil -setreg CA\CACertPublicationURLs mit den Werten 1, 2 und 32 nach Bedarf	PKIView.msc zeigt die AIA-Zeile als OK an.	Fehlercode 0x80070005: Zugriff verweigert, wenn nicht mit Administratorrechten ausgeführt.	Stellen Sie die vorherige CACertPublicationURLs-Zeichenfolge wieder her und starten Sie die Zertifikatdienste neu.	PKI-Administrator
CDP-Dezimalflags auf dem CA gesetzt	certutil -setreg CA\CRLPublicationURLs mit kombinierten Werten wie 65, 79 oder 6	Neue CRL veröffentlicht mit certutil -crl und PKIView.msc zeigt die CDP-Zeile als OK an.	0x80092013 CRL_E_REVOCATION_OFFLINE, wenn der Standort nicht erreichbar ist	Stellen Sie die vorherige CRLPicationURLs-Zeichenfolge wieder her.	PKI-Administrator
Ersetzungstoken wurden den Dateinamen zugeordnet	Bestätigen Sie, dass %1 (ServerDNSName), %3 (CAName), %8 (CRLNameSuffix), %9 (DeltaCRLAllowed) dem tatsächlich veröffentlichten Dateinamen zugeordnet sind.	Die Dateinamen am HTTP/LDAP-Speicherort entsprechen exakt dem erwarteten Token-Muster.	Dateinamen stimmen nach manuellem Kopieren oder Umbenennen nicht überein	Kopieren Sie die Datei erneut mithilfe des dokumentierten Token-Musters.	PKI-Administrator
LDAP AIA/CDP-Veröffentlichung in Active Directory	certutil -dspublish -f <path to certificate> SubCA (oder RootCA)	ADSIEdit.msc zeigt das Zertifikat unter Dienste > Öffentlicher-Schlüssel-Dienst > AIA an.	Fehlendes Zertifikat in Active Directory oder Zugriff verweigert für -dspublish	Entfernen Sie den doppelten oder fehlerhaften AD-Eintrag über ADSIEdit.msc.	PKI-Administrator / Plattformteam
HTTP AIA/CDP wird auf einem Webserver gehostet	Kopieren Sie das Zertifikat/die CRL von %windir%\System32\certsrv\CertEnroll zum Webserver	curl -I Die Anfrage an die HTTP-URL liefert die erwartete Datei zurück.	Zertifikat am Serverendpunkt nicht vorhanden (404)	Kopieren Sie die Datei von CertEnroll erneut und überprüfen Sie die Webserver-Berechtigungen.	Plattform-Team
Lastverteilte oder geclusterte CDP/AIA-Endpunkte sind von der direkten CA-Veröffentlichung ausgeschlossen.	Verwenden Sie für lastverteilte Standorte die manuelle Kopie anstelle des Dezimalwerts 1.	Beide Knoten hinter dem Load Balancer bedienen die identische Datei.	Fehler bei der CA-Veröffentlichung, da nicht beide Knoten erreicht werden können.	Entfernen Sie den Dezimalwert 1 an dieser Stelle und setzen Sie das manuelle Kopieren fort.	Sicherheitsarchitekt / Plattformteam

Zertifikatslebenszyklusmanagement und PKI-Modernisierung

Die Konfiguration von CDP und AIA ist ein grundlegender Bestandteil des Zertifikatslebenszyklusmanagements: Werden die Dezimalkennzeichen und Ersatztoken falsch konfiguriert, erbt jede nachfolgende Erneuerung, Widerrufsprüfung und jedes auf dieser Zertifizierungsstelle basierende Inventar der Maschinenidentitäten dieses Problem. CertSecure Manager automatisiert das Zertifikatslebenszyklusmanagement, einschließlich der Zertifikatsausstellung, -erneuerung und CDP/AIA-konformen Widerrufsprüfung. Dadurch entfällt die manuelle Überprüfung der Dezimalkennzeichen auf jeder einzelnen Zertifizierungsstelle. Organisationen, die ihre selbstverwaltete CDP/AIA-Infrastruktur vollständig aufgeben möchten, sollten PKI-as-a-Service für die PKI-Modernisierung mit gehosteten, vorvalidierten Verteilungspunkten in Betracht ziehen.

Da sich CDP/AIA-Fehler aufgrund kürzerer Zertifikatslebensdauern schneller bemerkbar machen, ist jetzt der ideale Zeitpunkt, einen umfassenderen Plan für kryptografische Agilität zu entwickeln: Das PQC Center of Excellence bietet praxisnahe Post-Quantum-Tests an, und eine PQC-Readiness -Bewertung kann aufzeigen, wo die Zertifikats- und CRL-Größen mit dem Einsatz von Post-Quantum-Algorithmen zunehmen werden. Kombinieren Sie beides mit CBOM Secure , um eine aktuelle Zertifikatserkennung und ein aktuelles Inventar der Maschinenidentitäten zu gewährleisten, anstatt bei einem erneuten Vorfall jeden CDP/AIA-Standort manuell neu ermitteln zu müssen.

Weitere Informationen zum zugehörigen Lebenszyklus finden Sie unter Welche Phasen umfasst ein Zertifikatslebenszyklus? und Wie lassen sich Zertifikatsausfälle vermeiden?

Erfolgsmessung und laufende Audits

Verfolgen Sie diese Signale mindestens 30 Tage lang nach jeder CDP/AIA-Änderung: keine „Download nicht möglich“-Zeilen in PKIView.msc, keine CRL_E_REVOCATION_OFFLINE-Fehler in Client- oder Firewall-Protokollen und CRL NextUpdate-Daten, die ohne manuelles Eingreifen aktuell bleiben.

Dies ist eine hersteller- und richtliniennahe Anleitung. Überprüfen Sie daher vierteljährlich die Dezimal-Flag-Werte und die Zuordnung der Ersatz-Token, insbesondere im Zusammenhang mit jeder Änderung der Gültigkeitsdauer einer Zertifizierungsstelle/eines Browser-Forums, und führen Sie immer dann einen vollständigen Debugging-Workflow durch, wenn eine neue Zertifizierungsstelle eingerichtet wird.

Fazit

Probleme mit CDP- und AIA-Standorten können knifflig sein. Fehlkonfigurationen verursachen häufig Probleme, die schwer zu beheben sind. Mit diesem Leitfaden möchten wir die Konfiguration von CDP/AIA-Punkten vereinfachen und bieten Ihnen Schritte zur Fehlerbehebung bei technischen Problemen. Wenn Ihre Organisation die CDP/AIA-Integrität automatisch statt manuell in PKIView.msc überwachen möchte, erfahren Sie, wie CertSecure Manager das Zertifikatslebenszyklusmanagement, einschließlich der Sperrprüfung, für alle Zertifizierungsstellen in Ihrer Umgebung handhabt.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem Abschnitt „Konfigurieren und Beheben von Problemen mit CRL-Verteilungspunkten (CDP) und Zugriff auf Autorisierungsinformationen (AIA)“?

Die wichtigste Erkenntnis ist, dass CDP und AIA durch Dezimal-Veröffentlichungsflags und Ersetzungstoken gesteuert werden, die exakt mit den veröffentlichten Dateinamen übereinstimmen müssen. Wenn ein Flag falsch ist oder eine Datei umbenannt wird, können Clients das Zertifikat oder die CRL der Zertifizierungsstelle nicht abrufen, was in PKIView.msc als „Download nicht möglich“ angezeigt wird, lange bevor es jemand anderes bemerkt.

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

Enterprise-PKI-Teams betreiben diese Standorte oft jahrelang, ohne sie zu verändern. Daher kann eine einzige übersehene Änderung, eine umbenannte Datei, ein außer Betrieb genommener Load Balancer, ein verschobener Webserver unbemerkt die Überprüfung des Widerrufs oder den Aufbau der Zertifikatskette für jede Anwendung, die dieser Zertifizierungsstelle vertraut, beeinträchtigen.

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

Eine manuelle, undokumentierte CDP/AIA-Konfiguration erhöht das Risiko, dass Dezimalflagwerte von den tatsächlich benötigten Werten abweichen, dass es nach dem manuellen Kopieren einer Datei zu Fehlern bei den Ersatztoken kommt und dass fälschlicherweise Load-Balancing-Speicherorte für die direkte CA-Veröffentlichung festgelegt werden, die die CA nicht erreichen kann und die dann die Veröffentlichung vollständig unterbricht.

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

Die PKI-Administratoren sind für die Konfiguration des Dezimal-Flags und die Zuordnung der Ersatz-Token zuständig, die Sicherheitsarchitekten entscheiden, welche Standorte intern und welche dem Internet zugewandt sind, die Plattformteams halten die Webserver, die die HTTP-Endpunkte hosten, mit dem CertEnroll-Ordner der Zertifizierungsstelle synchron, und die Compliance-Teams stellen sicher, dass die CRL-Verfügbarkeit den Zertifikatsrichtlinien der Organisation entspricht.

Wie hängt das mit dem Zertifikatslebenszyklusmanagement zusammen?

CDP und AIA sind der Abrufmechanismus, der jeder Phase des Zertifikatslebenszyklusmanagements zugrunde liegt: Die Ausstellung ist auf AIA angewiesen, um eine Vertrauenskette aufzubauen, und die Widerrufsprüfung ist auf CDP angewiesen, um eine aktuelle CRL zu finden. Daher untergräbt ein defekter Verteilungspunkt den Lebenszyklus, selbst wenn die Ausstellung selbst einwandfrei funktioniert.

Wie sollten Organisationen ihren Erfolg messen?

Erfolg bedeutet null Zeilen mit der Meldung „Download nicht möglich“ in PKIView.msc, null CRL_E_REVOCATION_OFFLINE-Fehler in Client- oder Firewall-Protokollen, aktuelle CRL NextUpdate-Daten und dass jeder veröffentlichte Dateiname dem dokumentierten Ersatztoken-Muster entspricht.

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

Organisationen sollten PKIView.msc nach jeder Änderung an einer Zertifizierungsstelle oder einem Dateiserver überwachen, die CDP/AIA-Dezimalflagwerte vierteljährlich anhand der Dokumentation prüfen, sicherstellen, dass die CRL-Veröffentlichungsintervalle nicht abgedriftet sind, und überprüfen, ob lastverteilte oder geclusterte Standorte weiterhin von der direkten CA-Veröffentlichung ausgeschlossen sind.

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

Cloud- und Hybrid-PKI fügen zusätzliche HTTP-Endpunkte und Load Balancer hinzu, die die gleiche manuelle Kopierbehandlung wie lokale Cluster-Server erfordern, und Multi-CA-Hierarchien erfordern, dass jede ausstellende und Stamm-CA über eigene korrekt konfigurierte CDP/AIA-Standorte verfügt, da eine einzige falsch konfigurierte CA in der Kette das Vertrauen für alles, was sie ausgestellt hat, unterbricht.

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

Vor der Konfiguration oder Fehlerbehebung von CDP/AIA benötigen die Teams administrativen Zugriff auf die Zertifizierungsstelle und deren Befehlszeile, Zugriff auf ADSIEdit.msc, falls Standorte LDAP verwenden, eine dokumentierte Liste aller aktuellen CDP/AIA-URLs und deren Typen sowie einen Testclient außerhalb des eigenen Netzwerks der Zertifizierungsstelle, um die Auflösung in der Praxis zu überprüfen.

Auf welche häufigen Fehler sollten Administratoren achten?

Achten Sie auf die Meldung „Download nicht möglich“ in PKIView.msc, CRL_E_REVOCATION_OFFLINE (0x80092013) bei HTTP-Speicherorten, ein fehlendes Zertifikat in Active Directory für LDAP AIA (behebt sich mit certutil -dspublish), Zugriffsverweigerungsfehler beim Ausführen von certutil ohne erhöhte Berechtigungen und Dateinamenskonflikte nach einem manuellen Kopieren, die nicht mehr dem Tokenmuster %1-%11 entsprechen.