CDP- och AIA-poäng kan ibland vara förvirrande men är de viktigaste pelarna i en funktionell 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.
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
På samma sätt, om AIA inte är korrekt konfigurerat, kan certifikat för rot- och utfärdande certifikatutfärdare inte nås.
I båda scenarierna fungerar inte PKI korrekt.
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ärde 1 inkluderas vid publicering i %windir%\System32\certsrv\CertEnroll plats. Det kan också inkluderas för att publicera direkt på AIA-platsen om korrekta behörigheter 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.
Exempelvis:
Här tillhandahåller vi en lokal CertEnroll-mapp med decimalvärdet 1, eftersom det är där AIA:n skulle publiceras. HTTP-platsen har ett decimalvärde på 2, där vi inte publicerar certifikaten, men den kommer att fungera som en AIA-plats varifrån andra klienter kan komma åt dess certifikat.
Konfiguration av CDP
Konfigurationen av CDP kan bero på hur CA:n är konfigurerad, hur CRL publiceras och åtkoms, och om Delta CRL 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 %windir%\System32\certsrv\CertEnroll plats 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åra Utfärdande CA Certifikatet saknas, PKI-miljön kan 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.
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.
