Konfigurera och felsöka CRL-distributionspunkter (CDP) och auktoritetsinformationsåtkomst (AIA)

CDP- och AIA-punkter kan ibland vara förvirrande men är de viktigaste pelarna i en fungerande PKI- miljö. Konfiguration av korrekta CDP- och AIA-punkter kan resultera i en bättre och hälsosammare PKI-miljö, och felsökning av dessa problem kan vara lika knepigt. Den här artikeln är avsedd att vara ett sätt att stoppa eventuella CDP/AIA-problem som man kan stöta på under PKI-konfigurations- och felsökningsfaserna.

Snabbt svar: Vad är CDP och AIA?

CDP (CRL Distribution Point) och AIA (Authority Information Access) är certifikattillägg som talar om för klienter var de hittar en CA:s återkallningslistor och utfärdarcertifikat. Att konfigurera dem korrekt innebär att ställa in rätt decimalpublikationsflaggor på CA:n, matcha ersättningstokens som %1 och %3 med de faktiska filnamnen och verifiera att varje URL matchas innan certifikaten sätts i produktion.

Senast uppdaterad: augusti 2026 · Senast verifierad: augusti 2026 · Rekommenderad uppdateringskadens: kvartalsvis, eftersom CDP/AIA-beteendet är kopplat till ändringar av giltighetstiden för CA/Browser Forum och leverantörsuppdateringar (Windows CA).

Sammanfattning: Viktiga slutsatser

• Två tillägg, två jobb: AIA talar om för klienter var de ska hämta det utfärdande certifikatet eller rot-CA-certifikatet; CDP talar om för dem var de ska hämta CRL:n för återkallningskontroll.
• Decimalflaggor styr beteendet: AIA använder 1, 2 och 32; CDP använder 1, 2, 4, 8 och 64, och de kombinerar (65, 79, 6) för att representera flera inställningar samtidigt.
• Ersättningstokens bygger filnamnet: %1 till %11 mappas till CA:s DNS-namn, kortnamn, CA-namn och CRL-suffix, så om du byter namn på en publicerad fil bryts sökningen.
• Felsökningen startar i PKIView.msc: den visar vilken specifik plats (AD/LDAP, HTTP eller filresurs) som inte fungerar innan du trycker på någon konfiguration.
• Korrigeringar är vanligtvis ett kommando eller en kopia: certutil -dspublish för AD-luckor, eller kopiera certifikatet till webbservern för HTTP-luckor.

Vem borde bry sig om CDP/AIA-konfiguration

CDP- och AIA-konfiguration är lätt att ignorera tills återkallningskontrollen avbryts. Här är vad varje roll bör äga.

PKI-administratörer

Äg decimalflagkonfigurationen på CA, håll filnamnen för ersättningstoken synkroniserade med vad som faktiskt publiceras och kör PKIView.msc efter varje CA-ändring.

Säkerhetsarkitekter

Bestäm vilka CDP/AIA-platser som är interna (LDAP) kontra internetanslutna (HTTP), och se till att belastningsbalanserade eller klustrade slutpunkter är undantagna från direkt CA-publicering.

Plattformsteam

Håll webbservrarna som är värd för HTTP AIA/CDP-filer synkroniserade med CA:s CertEnroll-mapp och övervaka certifikat- och CRL-filtillgängligheten som vilken annan produktionsslutpunkt som helst.

Compliance-team

Bekräfta att CRL-publiceringsintervall och CDP-tillgänglighet uppfyller organisationens certifikatpolicy och eventuella myndighetskrav för återkallningskontroll.

CISO: er

Spåra CDP/AIA-avbrott som en risk för återkallningskontroll: en oåtkomlig CRL kan i tysthet låta en applikation acceptera ett certifikat som borde ha avvisats.

Varför detta är viktigt: Data och deadlines

Enligt DigiCerts Trust Pulse-undersökning (publicerad 2 juli 2025) upplevde nästan hälften av företagen ett certifikatrelaterat avbrott under det senaste året, och mer än hälften (56.6 %) angav spårning av certifikat och utgångsdata som ett största problem. En trasig CDP- eller AIA-plats är precis den typ av tyst fel som ger detta resultat, eftersom återkallningskontrollen misslyckas tyst tills en applikation börjar avvisa giltiga certifikat eller acceptera sådana som den inte borde.

CA/Browser Forums omröstning SC-081v3 (godkänd 11 april 2025) låser in krympande giltighetstid för TLS-certifikat: 200 dagar från och med 15 mars 2026, 100 dagar från och med 15 mars 2027 och 47 dagar från och med 15 mars 2029. Kortare livslängder innebär att CRL:er och AIA-slutpunkter drabbas mycket oftare, så en felkonfigurerad decimalflagga eller en omdöpt fil orsakar synliga fel mycket tidigare än vad det skulle ha gjort under den gamla maxtiden på 398 dagar.

På kryptografisidan slutförde NIST sina tre första postkvantstandarder , FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) och FIPS 205 (SLH-DSA), den 13 augusti 2024. Alla CDP/AIA-designer som byggs idag bör anta att certifikat- och CRL-storlekar kommer att växa när postkvantalgoritmer tas i bruk, vilket är ytterligare en anledning att skaffa publiceringsflaggor och ersättningstokens just nu istället för att patcha runt dem senare.

Förutsättningar

Innan du konfigurerar eller felsöker CDP/AIA, bekräfta att följande är på plats:

• Administrativ åtkomst till CA-servern och dess kommandorad (certutil).
• Åtkomst till Active Directory-verktyg (ADSIEdit.msc) om några CDP/AIA-platser använder LDAP.
• En dokumenterad lista över alla CDP/AIA-URL:er som för närvarande används, och om var och en är HTTP, LDAP eller en filresurs.
• En testklient utanför CA:s eget nätverk, så att du kan verifiera att URL:er upplöses på samma sätt som riktiga klienter kommer att uppleva dem.

Konfiguration av CDP/AIA-punkter

Korrekt konfiguration av CDP- och AIA-punkter kan vara knepigt. Det kräver korrekt behörighet för var CRL behöver publiceras och var de ska vara åtkomliga.

Felaktig konfiguration av CDP kan resultera i två scenarier

• CRL misslyckas med att publiceras, eller
• CRL:er kan inte nås

Konfiguration av AIA

AIA är enklast att konfigurera. Om OCSP används kan AIA-decimaltecknet inkludera 34; annars är det alltid 2.

Visningsnamn	Decimalt värde
Publicera på den här platsen	1
Inkludera i AIA-förlängningen av utfärdade certifikat	2
Inkludera i OCSP-tillägget (Online Certificate Status Protocol)	32

Decimalvärdet 1 inkluderas vid publicering på platsen %windir%\System32\certsrv\CertEnroll . Det kan också inkluderas för att publicera direkt på AIA-platsen om rätt behörighet tillhandahålls.

[Obs: Om platsen ligger bakom en lastbalanserare kan CA inte komma åt båda servrarna och det kan orsaka fel. Publicera inte på dessa platser; istället rekommenderas manuell kopiering]

Decimalvärdet 2 inkluderas när URL:en ska läggas till i de utfärdade certifikaten. Dessa URL:er fungerar som AIA-punkter varifrån certifikaten kan extraheras.

Konfiguration av CDP

Konfigurationen av CDP kan bero på hur CA är konfigurerad, hur CRL: er publiceras och nås, och om Delta-CRL:er publiceras.

Visningsnamn	BESKRIVNING	Decimalt värde
Publicera CRL:er på den här platsen	Används av CA för att avgöra om grundläggande CRL:er ska publiceras på den här platsen	1
Inkludera i CRL-distributionspunkten (CDP) för utfärdade certifikat	Används av klienter under återkallningskontroll för att hitta bas-CRL-plats	2
Inkludera i [base] CRL:er	Används av klienter under återkallningskontroll för att hitta delta-CRL-plats från bas-CRL:er	4
Inkludera i alla CRL:er	En offline-CA kan använda den för att ange LDAP-URL:en för manuell publicering av CRL:er. Du måste också ange den explicita konfigurationsbehållaren i URL:en eller DSConfigDN värde i registret. certutil -setreg CA\DSConfigDN CN=	8
		16
		32
Publicera Delta CRL:er till den här platsen	Används av CA för att avgöra om Delta CRL:er ska publiceras på den här platsen	64

Decimalvärden används i enlighet därmed baserat på hur CDP:n behöver konfigureras.

Decimalvärde 1 används oftast för att publicera CRL:er till platsen %windir%\System32\certsrv\CertEnroll eller till de platser där CA har behörighet att komma åt. Om Delta CRL:er också publiceras används 65 (1+64).

[Obs: Om platsen ligger bakom en lastbalanserare kan CA inte komma åt båda servrarna och det kan orsaka fel. Publicera inte på dessa platser; istället rekommenderas manuell kopiering]

Decimalvärde 2 inkluderar URL:en eller platsen och låter den fungera som en CDP-plats varifrån bas- eller delta-CRL:er nås.

Exempelvis

Decimalvärde 79 = CRL:er publiceras på den platsen (1) + Platsen läggs till i CDP (2) + Delta CRL-plats (4) + Inkludera i alla CRL:er (8) + Publicera Delta CRL på denna plats (64)

Decimalvärde 65 = Publicera CRL på denna plats (1) + Publicera Delta CRL på denna plats (64)

Decimalvärde 6 = Plats läggs till CDP (2) + Delta CRL-plats (4)

CRL-ersättningstokens

I exemplen ovan kanske du har lagt märke till %1, %3, %4, %8 och %9. Detta representerar hur CA:n är konfigurerad och vad filens namn ska vara. Om filerna byter namn kan AIA- och CDP-punkterna misslyckas eftersom namngivningskonventionen inte matchar.

Token Namn	BESKRIVNING	Kartvärde
Server-DNS-namn	DNS-namnet på CA-servern	%1
ServerShortName	Serverns NetBIOS-namn	%2
CA-namn	Namnet på CA:n	%3
Cert_Suffix	Förlängningen av CA:n	%4 (enligt Windows 2000-mappningen)
Certifikatnamn		%4 (enligt Windows 2003-mappningen)
Konfigurationsbehållare	Platsen för konfigurationsbehållaren i AD	%6
CAT-avkortat namn	Det "sanerade" namnet på CA:n	%7
CRL-namnsuffix	Förnyelseförlängningen av CRL	%8
DeltaCRL Tillåten	Om Delta CRL är tillåtet läggs + till i slutet av filen för att indikera en delta CRL.	%9
CDPObject-klass		% 10
CAObjectClass		% 11

Baserat på mappningsvärdet ges AIA- och CDP-punkterna en namngivningskonvention för att hitta rätt fil från dessa platser.

Felsökning av CDP/AIA-platsproblem

Om CDP/AIA-platserna är korrekt konfigurerade kommer dessa steg att tillfälligt hjälpa till att lösa problemen. Vi kommer till exempel att använda AIA-problem, vilket också fungerar för CDP-problem.

När vi har öppnat och kontrollerat PKIView.msc kan vi se var problemet ligger. Vi kan kopiera URL:en till ett anteckningsblock för vidare undersökning.

AD:n har inte vårt certifikat om problemet ligger på LDAP-platsen. Detta är en ganska enkel lösning.

Certifikat som hämtas via LDAP hämtas från domänkontrollanten. Om vi ​​öppnar domänkontrollanten och ADSIEdit.msc kan vi navigera till Tjänster > Public Key Services > AIA och kontrollera de aktuella certifikaten. Eftersom vårt utfärdande CA- certifikat saknas kan PKI-miljön inte hämta certifikatet från den platsen.

För att lösa detta navigerar vi till vår utfärdande certifikatutfärdare och kör kommandot
certutil -dspublish -f SubCA

När kommandot körs korrekt kan vi uppdatera PKIView.msc för att kontrollera om problemet är löst, och vi bör se en nystart.

Om AIA-plats #2 eller HTTP-platsen orsakar fel beror det här felet på att certifikatet inte finns vid den serverslutpunkten.

För att lösa detta kopierar vi certifikatet från platsen %windir%\System32\certsrv\CertEnroll till vår webbserver, som är värd för vårt certifikat.

Detta skulle lösa vårt problem, vilket vi kan kontrollera igen på PKIView.msc.

Valideringskontroller efter konfiguration

• Kör PKIView.msc efter varje CDP/AIA-ändring och bekräfta att varje rad visar OK, inte "Kan inte laddas ner" eller ett feltillstånd.
• Hämta varje HTTP AIA/CDP-URL direkt från en extern klient och bekräfta att den returnerar den förväntade .crt- eller .crl-filen.
• Bekräfta att CRL:ns NextUpdate-fält är i framtiden genom att öppna CRL-filen eller kontrollera den med certutil.
• För LDAP-publicerade certifikat, öppna ADSIEdit.msc och bekräfta att certifikatet finns under den förväntade behållaren för Public Key Services.

Vanliga fel och felkoder

• "Det gick inte att ladda ner" i PKIView.msc: Platsen är oåtkomlig, har ett felaktigt namn, eller så matchar inte ersättningstoken den publicerade filen.
• CRL_E_REVOCATION_OFFLINE (0x80092013): en klient kan inte nå en HTTP CDP-plats, vanligtvis ett problem med brandvägg, DNS eller belastningsutjämnare.
• Certifikat saknas i AD (LDAP AIA-fel): CA-certifikatet publicerades aldrig till Active Directory; löst med certutil -dspublish -f <path> SubCA (eller RootCA för en rot-CA).
• CertUtil: -dsPublish-kommandot MISSLYCKADES (åtkomst nekad): Kontot som kör kommandot saknar skrivbehörighet till behållaren Public Key Services i AD.
• Filnamnsmatchning efter manuell kopiering: Ett certifikat eller en CRL döptes om under kopieringen och matchar inte längre det %1-%11 ersättningstoken-mönster som CDP/AIA-URL:en förväntar sig.

Återställningssteg

1. Om ett nytt decimalflaggvärde avbryter publiceringen, återställ CDP/AIA-tillägget till dess tidigare värde med certutil -setreg CA\CACertPublicationURLs or CA\CRLPublicationURLs med hjälp av den sparade föregående strängen och starta sedan om certifikattjänsterna.
2. Om en manuell filkopiering orsakade en namngivningsmatchning, radera den felaktigt namngivna filen och kopiera den igen med exakt det %1-%11-mönster som dokumenterats för den certifikatutfärdaren.
3. If certutil -dspublish introducerade en oönskad dubblettpost i AD, ta bort den via ADSIEdit.msc från samma Public Key Services-behållare.
4. Om en belastningsutjämnad plats felaktigt har ställts in för direkt CA-publicering, ta bort decimalvärdet 1 från den platsen och växla tillbaka till manuell kopiering.

Referenstabell för CDP/AIA-konfiguration

Använd den här tabellen som en snabbreferenssammanfattning av varje CDP/AIA-konfigurationsuppgift.

Förutsättning	Kommando / Konfiguration	Valideringskontroll	Vanligt fel	rollback	Ägare
AIA-decimalflaggor inställda på CA	certutil -setreg CA\CACertPublicationURLs med värdena 1, 2 och 32 efter behov	PKIView.msc visar AIA-raden som OK	0x80070005 åtkomst nekad om den inte körs med förhöjda begränsningar	Återställ den tidigare CACertPublicationURLs-strängen och starta om certifikattjänsterna	PKI-administratör
CDP-decimalflaggor inställda på CA	certutil -setreg CA\CRLPublicationURLs med kombinerade värden som 65, 79 eller 6	Ny CRL publicerar med certutil -crl och PKIView.msc visar CDP-raden som OK	0x80092013 CRL_E_REVOCATION_OFFLINE om platsen inte kan nås	Återställ den tidigare CRLPublicationURLs-strängen	PKI-administratör
Ersättningstokens matchade med filnamn	Bekräfta mappningen av %1 (ServerDNSName), %3 (CAName), %8 (CRLNameSuffix), %9 (DeltaCRLAllowed) till det faktiska publicerade filnamnet.	Filnamnen på HTTP/LDAP-platsen matchar exakt det förväntade tokenmönstret	Filnamnet stämmer inte överens efter manuell kopiering eller namnbyte	Kopiera filen igen med hjälp av det dokumenterade tokenmönstret	PKI-administratör
LDAP AIA/CDP-publicering till Active Directory	certutil -dspublish -f <path to certificate> SubCA (eller RootCA)	ADSIEdit.msc visar certifikatet under Tjänster > Public Key Services > AIA	Certifikat saknas i AD, eller åtkomst nekad på -dspublish	Ta bort den duplicerade eller felaktiga AD-posten via ADSIEdit.msc	PKI-administratör / Plattformsteam
HTTP AIA/CDP värd på en webbserver	Kopiera certifikatet/CRL:en från %windir%\System32\certsrv\CertEnroll till webbservern	curl -I mot HTTP-URL:en returnerar den förväntade filen	Certifikatet finns inte vid serverns slutpunkt (404)	Kopiera filen från CertEnroll igen och bekräfta webbserverns behörigheter	Plattformsteamet
Lastbalanserade eller klustrade CDP/AIA-slutpunkter som är undantagna från direkt CA-publicering	Använd manuell kopiering istället för decimalvärdet 1 för lastbalanserade platser	Båda noderna bakom lastbalanseraren hanterar samma fil	CA-publiceringsfel eftersom den inte kan nå båda noderna	Ta bort decimalvärdet 1 för den platsen och återuppta manuell kopiering	Säkerhetsarkitekt / Plattformsteam

Certifikatlivscykelhantering och PKI-modernisering

CDP- och AIA-konfiguration är en grundläggande del av hanteringen av certifikatlivscykeln: om decimalflaggor och ersättningstokens ärvs fel, ärver varje nedströms förnyelse, återkallningskontroll och maskinidentitetsinventering som byggs ovanpå den CA:n problemet. CertSecure Manager automatiserar hanteringen av certifikatlivscykeln, inklusive certifikatautomation för utfärdande, förnyelse och CDP/AIA-medveten återkallningskontroll, så att team inte behöver verifiera decimalflaggor manuellt på varje CA. Organisationer som helt och hållet övergår från självhanterad CDP/AIA-infrastruktur bör utvärdera PKI-as-a-Service för PKI-modernisering med värdbaserade, förvaliderade distributionspunkter.

Eftersom krympande certifikatlivslängder gör att CDP/AIA-fel dyker upp snabbare är detta också ett bra tillfälle att bygga en bredare plan för kryptoagilitet: PQC Center of Excellence erbjuder praktisk postkvanttestning, och en PQC- beredskapsbedömning kan markera var certifikat- och CRL-storlekar kommer att växa när postkvantalgoritmer är involverade. Kombinera båda med CBOM Secure för att hålla en aktuell inventering av certifikatidentifiering och maskinidentitet istället för att återupptäcka varje CDP/AIA-plats manuellt under nästa incident.

För mer information om den omgivande livscykeln, se Vilka är stegen i en certifikatlivscykel? och Hur man undviker certifikatavbrott.

Mätning av framgång och pågående revisioner

Spåra dessa signaler i minst 30 dagar efter eventuella CDP/AIA-ändringar: noll rader med texten "Det gick inte att ladda ner" i PKIView.msc, noll CRL_E_REVOCATION_OFFLINE-fel i klient- eller brandväggsloggar och CRL NextUpdate-datum som förblir aktuella utan manuell åtgärd.

Detta är riktlinjer som är riktlinjerna för policy och leverantör, så verifiera decimalflaggens värden och mappningen av ersättningstoken varje kvartal, särskilt kring eventuella ändringar av giltighetstiden för CA/Browser Forum, och kontrollera hela felsökningsgenomgången varje gång en ny CA upprättas.

Slutsats

Problem med CDP- och AIA-platser kan vara knepiga. Felkonfiguration kan ofta orsaka problem som kan vara svårare att spåra. Med den här guiden hoppas vi kunna göra konfigurationen av CDP/AIA-punkter mycket enklare med felsökningssteg för att stödja eventuella tekniska problem. Om din organisation vill att CDP/AIA-hälsan övervakas automatiskt istället för att kontrolleras manuellt i PKIView.msc, se hur CertSecure Manager hanterar certifikatlivscykelhantering, inklusive återkallningskontroll, över varje CA i din miljö.

Vanliga frågor om partihandel med mat och dryck

Vad är den viktigaste slutsatsen från Konfigurering och felsökning av CRL-distributionspunkter (CDP) och Authority Information Access (AIA)?

Den viktigaste slutsatsen är att CDP och AIA styrs av decimala publiceringsflaggor och ersättningstokens som måste matcha de faktiska publicerade filnamnen exakt. När en flagga är felaktig eller en fil byter namn misslyckas klienterna tyst med att hämta CA:ns certifikat eller CRL, vilket visas i PKIView.msc som ett felmeddelande med "Kan inte laddas ner" långt innan någon annan märker det.

Varför är detta viktigt för PKI-team på stora företag?

Företags-PKI-team kör ofta dessa platser i åratal utan att röra vid dem, så en enda förbisedd ändring, en omdöpt fil, en avaktiverad lastbalanserare, en flyttad webbserver kan i tysthet avbryta återkallningskontroll eller certifikatkedjebyggande i alla applikationer som litar på den certifikatutfärdaren.

Vilka risker ökar om detta ämne hanteras manuellt?

Manuell, odokumenterad CDP/AIA-konfiguration ökar risken för att decimalflaggvärden avviker från vad som faktiskt behövs, att ersättningstoken inte matchar efter en manuell filkopiering och att belastningsbalanserade platser felaktigt ställs in för direkt CA-publicering, som CA inte kan nå och som sedan avbryter publiceringen helt.

Vilka lag borde ta över den här förändringen?

PKI-administratörer äger konfigurationen av decimalflaggor och mappningen av ersättningstoken, säkerhetsarkitekter bestämmer vilka platser som är interna kontra internetvända, plattformsteam håller webbservrarna som är värd för HTTP-slutpunkter synkroniserade med CA:s CertEnroll-mapp och efterlevnadsteam bekräftar att CRL-tillgängligheten uppfyller organisationens certifikatpolicy.

Hur kopplas detta till hantering av certifikatlivscykeln?

CDP och AIA är hämtningsmekanismen under varje steg i hanteringen av certifikatlivscykeln: utfärdandet är beroende av AIA för att bygga en förtroendekedja, och återkallningskontrollen är beroende av CDP för att hitta en aktuell CRL, så en trasig distributionspunkt undergräver livscykeln även om utfärdandet i sig fungerar felfritt.

Hur bör organisationer mäta framgång?

Framgång innebär noll rader av typen "Kan inte laddas ner" i PKIView.msc, noll CRL_E_REVOCATION_OFFLINE-fel i klient- eller brandväggsloggar, CRL NextUpdate-datum som förblir aktuella och varje publicerat filnamn som matchar dess dokumenterade ersättningstokenmönster.

Vad bör granskas eller övervakas regelbundet?

Organisationer bör övervaka PKIView.msc efter varje ändring av CA- eller filserver, granska CDP/AIA-decimalflaggvärden mot dokumentation varje kvartal, bekräfta att CRL-publiceringsintervall inte har ändrats och verifiera att lastbalanserade eller klustrade platser fortfarande är undantagna från direkt CA-publicering.

Hur påverkar detta ämne moln-, hybrid- eller multi-CA PKI?

Moln- och hybrid-PKI lägger till extra HTTP-slutpunkter och lastbalanserare som behöver samma manuella kopieringsbehandling som lokala klustrade servrar, och hierarkier med flera CA-er kräver att varje utfärdande och rot-CA har sina egna korrekt konfigurerade CDP/AIA-platser, eftersom en enda felkonfigurerad CA i kedjan bryter förtroendet för allt den utfärdar.

Vilka förutsättningar krävs innan implementering?

Innan CDP/AIA konfigureras eller felsöks behöver team administrativ åtkomst till CA och dess kommandorad, åtkomst till ADSIEdit.msc om några platser använder LDAP, en dokumenterad lista över varje aktuell CDP/AIA-URL och dess typ, och en testklient utanför CA:s eget nätverk för att verifiera verklig lösning.

Vilka vanliga fel bör administratörer vara uppmärksamma på?

Håll utkik efter "Det går inte att ladda ner" i PKIView.msc, CRL_E_REVOCATION_OFFLINE (0x80092013) på HTTP-platser, ett saknat certifikat i Active Directory för LDAP AIA (löst med certutil -dspublish), fel på grund av nekad åtkomst vid körning av certutil utan utökade behörigheter och filnamnsfel efter en manuell kopiering som inte längre matchar tokenmönstret %1-%11.