Crearea unui lanț de servere de certificare ca parte a implementării programului pki în domeniu

Instalarea unui lanț de servere de certificare
ca parte a implementării PKI în domeniu
Partea 1

Microsoft recomandă planificarea cu atenție a PKI înainte de a continua implementarea componentelor. În ceea ce privește CA, este necesar să se decidă dacă va fi utilizată doar autoritatea de certificare proprie sau dacă va trebui să recurgă la servicii și la CA deschise (publice), cum ar fi VerySign. Un rol special îl joacă planificarea locației, cantității și tipului de CA. Există două tipuri principale de CA: o întreprindere CA (CA) și o CA izolată (CA autonomă). La rândul lor, ele sunt împărțite în două subtipuri: rădăcină (rădăcină) și subordonată (subordonată). tip CA determină în cazul în care certificatul este stocat de baze de date (local sau în Active Directory), deoarece certificatele sunt emise (template-uri în mod automat sau manual), și așa mai departe. N. În plus, face o (emitentă) este numit CA, care se ocupă de solicitări din partea utilizatorilor finali.







Selectarea unei structuri CA

Este necesar să se planifice o structură pe mai multe niveluri a SA. În mod teoretic, este posibil să se utilizeze un CA în același timp cu rădăcina CA a întreprinderii CA și emitentul simultan, însă această configurație este descurajată puternic din motive de securitate și de scalabilitate ulterioară.

Microsoft recomandă utilizarea numărului de niveluri CA între 2 și 4: utilizarea unei structuri mai profunde devine dificil de gestionat.

Puteți apela o schemă "clasică" de trei niveluri de CA (a se vedea figura 1):

  • primul nivel: rădăcină izolată CA;
  • al doilea nivel: un subordonat izolat SA (numit și intermediar, (intermediar) sau CA);
  • nivelul al treilea: o SA subordonată a nivelului întreprinderii, care emite CA, de asemenea.

Figura 1. Structura a trei CA

Implementarea unei astfel de structuri va fi luată în considerare în acest articol. Ce face: un CA izolat la primul nivel (RootCA) eliberează un certificat auto-semnat și se folosește ca rădăcină a structurii. Izolat subordonat CA nivel (SubCA) primește un certificat de la Root CA, și este utilizat, în primul rând, pentru a spori securitatea întregii structuri, și în al doilea rând, în cazul în care al doilea nivel este mai mult de o SA, pentru a atribui politica de operare diferite sau politici Securitate pentru nivelurile inferioare ale CA. În schema avută în vedere, introducerea celui de-al doilea nivel intermediar nu este obligatorie și este folosită pentru ao aduce în viziunea "clasică" și pentru posibilitatea unei scalabilități în viitor. Conform recomandărilor Microsoft din motive de siguranță, primele două niveluri ale CA trebuie să fie izolat de rețeaua de alimentare, și după instalarea și configurarea inițială - într-un seif, protejat de site-ul de acces neautorizat off. Implementarea acestei cerințe poate ajuta la utilizarea mașinilor virtuale - utilizarea VMware sau Virtual Server este ideală atât pentru securitatea în timpul fazei de implementare a infrastructurii, cât și pentru izolarea fizică ulterioară a serverelor.

În cele din urmă, un subordonat CA Enterprise (EntCA) primește un certificat de intermediar CA este într-un domeniu Active Directory, și emite certificate la cererea utilizatorului final pe bază fie manual sau automat pe template-uri (recomandat). Pentru toleranța la defecte, trebuie să aveți cel puțin două CA-uri emise pentru fiecare CA intermediar, dar vom lua în considerare instalarea unui singur server.

Definiția parametrilor funcționali pentru CA

Atunci când structura CA este definită, este necesar să se ia în considerare un număr de parametri importanți care afectează funcționarea fiecăreia dintre SA. Acești parametri includ:

După selectarea parametrilor de funcționare așteptați pentru fiecare CA, puteți merge direct la instalarea lor. Trebuie avut în vedere faptul că numele calculatorului și calitatea de membru după instalarea serviciilor de certificare nu vor fi modificate. Ca mediu de domeniu vom considera o pădure constând dintr-un copac și două domenii. Domeniul Dedicated.Root este domeniul rădăcină, domeniul Res.Dom este domeniul copil (resursă). Serviciile de certificare la cel de-al treilea nivel vor fi implementate pe membrul computerului EntCA din domeniul Dedicated.Root.

Instalarea CA Root

Din moment ce rădăcina CA va fi izolată, înainte de instalare, asigurați-vă că calculatorul nu este inclus în domeniu și are, de asemenea, un nume care nu va fi modificat mai târziu - în cazul nostru, RootCA.

Apoi, trebuie să pregătiți un fișier special capolicy.inf, care trebuie plasat în% Systemroot%. Prezența acestui fișier pentru a instala CA rădăcină este foarte importantă, deoarece stabilește toți parametrii inițiale pentru CA. Mai mult, Expertul de configurare a serviciilor de certificare nu numai că vă va avertiza că acest fișier nu este prezent, dar nu va verifica corectitudinea acestuia.







Lipsa de fișier capolicy.inf sau configurare greșită va avea ca rezultat faptul că CA va fi instalat cu setările implicite, deoarece nu există nici un CA-mamă pentru el, de la care acestea ar putea fi moștenit. Pentru a schimba unele dintre ele după instalare va fi imposibil și, ca urmare, este necesar să reinstalați din nou serviciile de certificare. Acest lucru nu este atât de teribil, în timp ce CA este singurul în structură, dar aproape imposibil după implementarea CA a nivelurilor care stau la baza.

Valorile parametrilor din secțiunea [Certsrv_Server] nu trebuie să fie mai mici decât cele care vor fi solicitate de expertul de instalare.

După cum am menționat deja, autoritatea de bază emite un certificat auto-semnat, care nu are o listă de recenzii. Prin urmare, este foarte important să specificați în mod explicit secțiunile [CRLDistributionPoint] și [Authority InformationAccess] și să le lăsați necompletate.

Ca rezultat, vom obține următorul conținut al fișierului capolicy.inf:

Semnătura = "$ Windows NT $"

De asemenea, înainte de instalarea serviciilor de certificare, este logic să instalați suport pentru Internet Information Services și ASP.NET. Pentru a opera rădăcină și intermediar CA al prezenței lor nu este necesară, dar poate atenua unele dintre eliberarea ulterioară a certificatelor pentru nivelurile inferioare CA, în ciuda faptului că aproape toate acțiunile disponibile prin intermediul interfeței web, puteți duplica și după serviciile de certificare consola de administrare.

În etapa următoare, suntem rugați să specificăm numele CA-ului nostru și numele distins (numele distins). În acest din urmă caz, trebuie să specificați numele corect în raport cu contextul Active Directory, chiar dacă acest CA nu este un CA la nivel de întreprindere. Deci, folosim RootCA ca nume CA, introduceți DC = dedicat, DC = root ca nume distins. Perioada de valabilitate indică durata de viață a certificatului. După cum sa menționat mai sus, durata de viață a rădăcinii CA va fi egală cu 20 de ani. Apoi, materialul criptografic este generat și este necesar să așteptați puțin pentru sfârșitul acestui proces.

Ultimul pas este să specificați locația fișierelor de bază de date ale certificatelor, jurnalele și folderul partajat pentru a găsi informațiile necesare pentru clienți (în mod implicit, acesta este C: \ CAConfig). În ciuda faptului că acesta este un CA izolat, dosarul local va fi în continuare creat și, dacă există o interfață de rețea, acesta este deschis accesului general.

Verificarea și configurarea funcției RootCA

Figura 2. Certificat CA de auto-semnare

Ce trebuie să fie în certificat:

  • în fila General: valorile câmpurilor emise de și emise trebuie să se potrivească și să indice CA nou instalat (în cazul nostru, acesta este RootCA). Intervalul de timp în care un certificat este considerat valabil trebuie să fie corect și să corespundă cu ceea ce a fost stabilit în timpul instalării;
  • în fila Detalii: în lista atributelor certificatelor, atributele punctelor de distribuție CRL și accesul la informațiile despre autoritate trebuie să lipsească;
  • în fila Cale de certificare: câmpul din partea de jos trebuie să fie "Acest certificat este OK".

Puteți vedea certificatul într-un mod diferit - utilizați modulul snap-in pentru Autoritatea de certificare, care este disponibil în secțiunea Instrumente de administrare a panoului de control.

După lansare, ar trebui să se conecteze automat la serverul curent, în timp ce în arborele din stânga ar trebui să fie marcat cu un tick verde. Dând clic dreapta pe el și selectând Properties din fila General, puteți găsi butonul View Certificate. Această metodă este mai bună deoarece asigură imediat că serviciile de certificare au lansat cu succes, altfel ar exista o eroare de conectare la CA. În plus, aici continuăm să configuram CA și să procedăm pentru a specifica punctele de distribuție ale CRL și AIA.

Permiteți-mi să vă reamintesc încă o dată importanța LCR pentru verificarea validității unui certificat. Puteți seta puncte de distribuție CRL (CDP) accesând fila Extensii din fereastra proprietăților CA. Lista derulantă din partea de sus a ferestrei conține doar doi parametri: CRL și AIA. Să lăsăm CRL implicit și să mergem la câmpul următor, care afișează locațiile pentru CRL.

Aici trebuie să fii foarte atent - în primul rând, punctele de distribuție CRL menționate aici pot fi incluse în toate certificatele emise de acest CA. Asta este, teoretic, este posibilă modificarea sau completarea acestei liste și după ce CA începe să lucreze, în practică aceasta va însemna necesitatea de a re-emite toate certificatele emise înainte ca lista să se fi schimbat.

În al doilea rând, inaccesibilitatea LCR înseamnă că certificatul nu este valid, deci trebuie să furnizați cel puțin două locații diferite pentru CRL.

În al treilea rând, nu se recomandă lăsarea punctelor de distribuție neutilizate în listă.

În plus, puteți specifica opțiuni suplimentare pentru fiecare CDP:

Să revenim la specificarea punctelor de distribuție ale CRL. Ca CA nostru deconectat de la rețea, este necesar să părăsească punctul de distribuție locală, care este primul din listă și implicit în folderul C: \ Windows \ System32 \ CertSrv \ CertEnroll \. Rețineți că pentru acest CDP opțiunea Publicare CRL este marcată în această locație. Pentru a asigura disponibilitatea CRL vom lăsa ca LDAP-punct (opțiuni specificând includă în toate CRLs și include în extinderea CDP a certificatelor emise) și va crea un nou punct, arătând spre un folder de rețea partajat în rețeaua locală (cu opțiunea de a include în extinderea CDP a emis certificate). Ca atare, vom introduce dosarul UNC-calea către directorul partajat, care este situat mai târziu în viitorul nostru CA întreprindere numit EntCA: file: // \\ Ent_CA \ CDP \. Vederea finală a ferestrei task CDP este prezentată în Fig. 3.

Figura 3. Setarea CDP pe root-ul CA

Figura 4. Specificarea punctelor AIA

Acum puteți să faceți clic pe OK și să acceptați că serviciile de certificare trebuie să fie repornite.

Cu toate acestea, înainte de a putea publica CRL, trebuie să mutați spațiile de nume Active Directory în registrul CA. Acest lucru este necesar pentru ca CDP-urile LDAP să fie prezentate în forma corectă. Acest lucru se face folosind comanda certutil.exe și pentru domeniul Dedicated.Root este după cum urmează:

certutil.exe -setreg ca \ DSConfigDN CN = Configurare, DC = dedicat, DC = root

Rezultatul ar trebui să fie ceva de genul:







Articole similare

Trimiteți-le prietenilor: