Punctele de distribuție Crl și accesul la informațiile de autoritate - extensii pki

Conținutul acestui director este arhivat și nu mai este actualizat.

Notă: acest material este publicat ca obligatoriu pentru cunoștințele profesioniștilor din domeniul IT care se ocupă sau urmează să se ocupe doar de subiectul PKI (Infrastructura publică a cheii publice).







După cum știți, fiecare certificat emis în CA (cu excepția certificatelor cu auto-semnat, certificatul rădăcină este, de asemenea, un certificat cu auto-semnătura) conține 2 extensii:

Aceste legături nu sunt preluate din aer, ci din setările CA. Iată cum acestea caută instalarea implicită a serviciilor de certificare:

Punctele de distribuție Crl și accesul la informațiile de autoritate - extensii pki
Punctele de distribuție Crl și accesul la informațiile de autoritate - extensii pki

Iată cum apar extensiile CDP și AIA în certificatele emise cu aceste setări:

După cum puteți vedea, legăturile din extensii sunt în aceeași ordine ca și în setările CA.

Acest lucru este important de știut, deoarece motorul de înlănțuire a certificatelor (numit în scurt timp CCE) va verifica legăturile în ordinea în care apar în extensiile de certificat. Ie încercați mai întâi să descărcați un fișier din Active Directory în decurs de 10 secunde. Dacă fișierul nu se descarcă în 10 secunde, CCE va încerca să descarce fișierul specificat utilizând următorul link (HTTP). În același timp, aceasta va dura până la 2 ori mai puțin (adică 5 secunde) decât în ​​încercarea anterioară. Și acest lucru se va întâmpla cu fiecare legătură ulterioară, până când fișierul este extras, referințele se termină sau cad din timpul de expirare. Procesarea fiecărei extensii pentru CCE este alocată exact la 20 de secunde.

Implicit în Windows Server, CRL-urile de bază (CRL de bază) sunt publicate o dată pe săptămână, iar CRL-urile incrementale (CRL Delta) sunt publicate o dată pe zi. Fișierele de certificat CA sunt actualizate în mod obișnuit la intervale egale cu durata de viață a certificatului CA în sine (sau mai des, dacă certificatul CA este actualizat în afara programului). În cazul în care certificatele CA trebuie să fie actualizate rar (o dată la câțiva ani), iar acest lucru ar trebui să fie pregătite separat, actualizarea CRL se întâmplă în mod automat, fără intervenția administratorului și sunt necesare ajustări speciale aici, care acum discutăm.

Dacă vă uitați la CRL, vom vedea următoarele:







Punctele de distribuție Crl și accesul la informațiile de autoritate - extensii pki
Punctele de distribuție Crl și accesul la informațiile de autoritate - extensii pki

Acum ne vom interesa doar în 3 domenii:

Notă: timpul din aceste câmpuri este indicat în format UTC fără fusuri orare.

Pentru a face acest lucru în registru pe serverul CA pe calea Nume HKLM \ System \ CurrentControlSet \ Services \ CertSvc \ Configuration \ CA Există 4 taste:

  • CRLOverlapUnits - specifică timpul până la expirarea CRL-ului principal curent, pentru care va fi publicat CRL primar.
  • CRLOverlapPeriod - specifică unitatea de măsură pentru acest timp pentru CRL principal
  • CRLDeltaOverlapUnits - specifică timpul înaintea expirării CRL-ului incremental (dacă este utilizat), pentru care va fi publicat un CRL nou incremental
  • CRLDeltaPeriodPeriod - specifică unitatea de măsură pentru acest timp pentru CRL incrementală.

Dacă utilizați referințe LDAP în extensiile certificate CDP / AIA și / sau aveți o latență de replicare a fișierelor între servere Web, trebuie să se adapteze timp, care nu trebuie să fie mai mică decât durata maximă de replicare directorul AD în întreaga pădure sau DFS ca și atât pentru CRL-urile de bază, cât și pentru cele suplimentare (dacă sunt utilizate de dvs.). Puteți automatiza această operație cu utilitarul certutil:

certutil -setreg ca \ CRLOverlapUnits 1
certutil -setreg ca \ CRLOverlapPeriod "zile"
certutil -setreg ca \ CRLDeltaOverlapUnits 8
certutil -setreg ca \ CRLDeltaOverlapPeriod "ore"
net stop certsvc net start certsvc

[AuthorityInformationAccess]
Gol = adevărat
[CRLDistributionPoint]
Gol = adevărat

Schimbarea căilor în infrastructurile existente este o problemă serioasă, deși este ușor de implementat. Dacă decideți să faceți un astfel de pas, urmați aceste reguli:

Mulțumesc, foarte distractiv. Cu ocazia LDAP, întrebarea nu este atât de clară. Pe de o parte, pentru clienții casnici, cu condiția să nu chiar atât de prost distribuite pădure AD, întârzieri, de obicei, pot fi ignorate - pentru că accesibilitatea este de obicei mai important. Și disponibilitatea, așa cum a remarcat corect colegul Mihail, atunci când se utilizează LDAP pentru a oferi atât mai ușor și mai ieftin. Pe de altă parte, nu este nimic bun dacă clienții externi din LCR sunt reprezentați de o parte din contextul numirii pădurii mele. Și dracu cu el, cu zece secunde de întârziere - problemele șerifilor nu sunt atât de ocupate. De aici inevitabil există un utilizator: pentru serviciile externe, publicați CRL numai prin URL, dar pentru servicii interne - prin LDAP și URL. Cred că nu mă înșel să spun că numărul copios de companii are un set destul de static de resurse externe. Și, atât static, încât pe durata întregului ciclu de viață numărul PKI infrastructurii de operațiuni de emitere / actualizare a cererilor de certificate pentru ele pot fi numărate pe. Poate cu picioarele tale. Modificările interne sunt mult mai frecvente. Și acum pot formula o întrebare: cât de mult de viata este un proces de CA de Service: - În modul normal, am emis ca CDP LDAP, iar adresa URL - Dacă trebuie să emită un certificat pentru un serviciu extern, trebuie să reconfigurați CA pentru a publica doar URL-ul, emite un certificat și Înapoi LDAP / URL. Deoarece deținerea unui CA separat pentru emiterea de certificate la servicii externe la fiecare cinci ani este foarte costisitoare. Sau, poate, există o altă modalitate de rezolvare a sarcinii, mai necunoscută pentru mine? Vă mulțumim anticipat.

Cea mai directă modalitate este de a avea 2 CA-uri: unul numai pentru clienții interni și unul pentru clienții externi.







Trimiteți-le prietenilor: