Инсталиране на веригата на сертифициране ареста на сървъра
като част от изпълнението на PKI домейн
част 1
Microsoft препоръчва внимателно да планирате PKI, преди да премине към действия за разполагане на компонентите. Що се отнася до СО, тогава ще трябва да се реши дали да се използва само със собствен сертификат за достъп, или необходимостта от използване на услугите и отворен (обществени) CA като VerySign. Специална роля планира местоположението, количеството и вида на SA. Има два основни вида: CA CA (предприятие СА) и СА изолира (самостоятелно СА). От друга страна, те са разделени в два подтипа: главната (ROOT) и роб (подчинен). тип CA определя къде сертификата се съхранява база данни (локално или в Active Directory), тъй като сертификатите се издават (шаблони автоматично или ръчно), и така нататък. Н. Освен това прави (издател) се нарича АК, който обработва заявки от крайните потребители.
CA Избира структура
Трябва да планирате структура на СА на много нива. Теоретично е възможно да се използва сертифициращ орган в същото време като главната СО и издаващите дружества в същото време, но тази конфигурация е силно препоръчително, тъй като от съображения за сигурност, както и от по-нататъшни причини мащабируемост.
Microsoft препоръчва използването на броя на нивата на CA 2 до 4: използване на по-дълбоката структура става трудно да се управлява.
Това може да се нарече "класически" диаграма на три нива на CA (виж фигура 1 ..):
- Първо ниво: самостоятелна корен CA;
- второ ниво: Изолиран подчинен CA (друг се нарича междинно съединение (междинно съединение), или политика CA);
- трето ниво: подчинената CA Enterprise, който също е производство на SA.
Фигура 1. Структура на три CA
Внедряването на подобна структура е и ще бъде разгледана в тази статия. Това гласи: изолиран CA от първи ред (RootCA) произвежда самостоятелно подписан сертификат за себе си, и се използва като корен структура. Изолирана подчинен CA от първи ред (SubCA) получава сертификат от СО корена и се използва, от една страна, да се повиши сигурността на цялата структура, и второ, в случаите, когато на второ ниво е повече от една SA, за да зададете друга операционна политика или политики сигурност за CA-ниски нива. В тази схема въвеждането на междинен слой е по желание и се използва да се доведе до "класическата" означава и мащабируемост възможности в бъдеще. Според препоръките на Microsoft, от съображения за сигурност, на първите две нива на СО трябва да се изолират от мрежата, а след инсталирането и първоначалната конфигурация - по безопасен, защитен от неоторизиран достъп сайт изключен. Спазването на това изискване може да помогне да се използват виртуални машини - Използване на VMware или Virtual Server е идеална за охрана на етапа на изграждане на инфраструктурата и за последващото изолацията на физическите сървъри.
И накрая, подчинен CA Enterprise (EntCA) получава сертификат от междинния сертифициращ орган е в домейн на Active Directory, и издава удостоверения по искане на крайния потребител ръчно или автоматично на базата на шаблони (препоръчително). За гъвкавост трябва да има най-малко два за всяка издаване CA Междинно Калифорния, но ние ще разгледаме само една инсталация на сървъра.
Определяне на функционални параметри за CA
Когато се определя структурата на анализатора, че е необходимо да се вземат под внимание редица важни параметри, засягащи работата на всяка SA. За тези параметри са:
След избиране на очакваните експлоатационни параметри на всеки от анализатора може да отиде директно тяхната инсталация. Трябва да се има предвид, че името на компютъра и промяната членство домейн вече не може да бъде, след като инсталирате удостоверителни услуги. В среда на домейн ще се смята за една гора, състояща се от едно дърво и двата домейна. Dedicated.Root домейн е основен домейн, Res.Dom домейн - дете (ресурс). Удостоверителни услуги за трето ниво ще бъдат разположени на компютър EntCA - член Dedicated.Root домейн.
Инсталирайте корен CA
Тъй като корен CA е изолиран, преди инсталацията, се уверете, че компютърът не е включен в домейн и има име, което впоследствие не се планира промяна - в нашия случай RootCA.
Освен това е необходимо да се подготви специален файл capolicy.inf, която трябва да бъде поставен в% SystemRoot% на. Наличието на този файл, за да инсталирате корен CA е много важно, защото тя определя всички първоначалните параметри за SA. Освен това, инсталационния помощник удостоверителни услуги не само ви предупреждава за липсата на този файл, но няма да се провери неговата правилност.
Липса на capolicy.inf файл или грешна конфигурация, ще доведе до факта, че СО ще бъде инсталиран с настройки по подразбиране, защото няма родител CA за него, от които те биха могли да се наследява. Променете някои от тях след инсталацията няма да е възможно, и, като следствие, трябва да преинсталирате удостоверителни услуги отново. Това не е толкова страшно, като единствено СО в структурата, но това е практически невъзможно, след разполагането на CA-ниските нива.
Стойностите на параметрите в секцията [Certsrv_Server] не трябва да бъдат по-малки от тези, които ще се изисква инсталационния съветник.
Както вече споменахме, в главната CA публикува самостоятелно подписан сертификат, който няма списък на отзиви. Затова е важно секции [CRLDistributionPoint] и [орган InformationAccess] изрично се посочва и оставете празно.
В резултат на това стигнахме до тук е capolicy.inf съдържанието на файла:
Подпис = "$ Windows NT $"
Също така, преди да инсталирате удостоверителни услуги, че има смисъл да се инсталира услугата Internet Information Services и подкрепа за ASP.NET. За да работите с корен и междинния сертифициращ орган на тяхното присъствие не е необходимо, но може да облекчи някои от по-нататъшното издаване на удостоверения за CA-ниските нива, независимо от факта, че почти всички действия, достъпни чрез уеб интерфейса, можете да се дублират и след удостоверителни услуги конзола за управление.
В следващата стъпка от нас се иска да посочите името на нашия Калифорния и DN (уникалното име). В последния случай е необходимо да се уточни точното име във връзка с контекста на Active Directory, независимо от факта, че СО не е CA Enterprise. Така че, като името на АД използва RootCA, като отличава име, въведете DC = посветен, DC = корен. Значение Валидност посочва датата на удостоверението за живота. Както е посочено по-горе, на жизнения цикъл на корен СА е равен на 20 години. Следваща има kriptomateriala поколение, и ние трябва да се изчака края на процеса.
Последната стъпка е да посочите местоположението на файловете с данни, база данни, удостоверение, трупи, както и споделена папка, за които се изисква информация за клиента (по подразбиране е C: \ CAConfig). Въпреки факта, че това е изолиран Калифорния, тя все още е ще бъде създадена локална папка и, в случая на мрежов интерфейс, отворени за обществено ползване.
Проверка и поправка RootCA
Фигура 2. самоподписан сертификат на корен CA.
Каква трябва да бъде в сертификата:
- раздела Общи: стойности на полетата, издавани от Издава се и трябва да бъде същото и точката за инсталираните нови CA (в този случай RootCA). Обхватът на време, през който се счита за валидно удостоверение, трябва да е вярно и в съответствие с това, което беше създадена по време на инсталацията;
- таб Детайли: сертификат в списъка на атрибутите трябва да бъде не CRL Точки за разпространение на атрибути и Достъп до информация;
- в раздела Certification Path: В долното поле трябва да носи Този сертификат е ОК.
Вижте сертификат може да бъде друг метод - използвайте модула в сертифициращ орган, който е на разположение в рамките на административни инструменти контролния панел.
След стартирането си трябва да се случи да се свърже автоматично текущия сървър, и дървото на това ляво трябва да бъдат маркирани с зелена отметка. При натискане на десния бутон на мишката и изберете Properties В раздела Общи, можете да намерите на бутона Преглед на сертификата. Този метод е най-добре, тъй като позволява на правото да се уверите, че сертификатът Услугите успешно стартира, в противен случай ще има CA грешка във връзка. В допълнение, това е мястото, където ние ще продължим конфигурацията на Калифорния и се пристъпи към указанията на дистрибуция CRL точки и AIA.
Нека ви напомня още веднъж за значението на референтната лаборатория на Общността, за да се провери валидността на сертификата. Попитайте CRL разпределителни точки (CRL разпределителни точки - CDP), можете да отидете в раздела Разширения (Extensions) в прозорец SA имоти. Списъкът с падащо меню в горната част на прозореца съдържа само два параметъра: CRL и AIA. CRL напуснете предложения по подразбиране и да се обърнат към следващото поле, което изброява разположенията на референтната лаборатория на Общността.
Тук трябва да бъдат много внимателни - на първо място, а след това тези дистрибуция CRL точки са включени във всички публикувани тези сертификати от сертифициращи органи. Това е теоретично възможно да се промени или да добавите към списъка и след КО ще започне да работи, но на практика това ще означава необходимостта да се преиздаде всички сертификати, които са издадени преди списъка се е променило.
От друга страна, липсата на достъп CRL показва невалидността на сертификата, така че е необходимо да се осигурят най-малко две различни CRL място.
На трето място, не се препоръчва да се излезе от списъка на неизползвани точка разпределение.
В допълнение, всяка от CDP, можете да посочите допълнителни опции:
Връщайки се към точката за задача дистрибуция CRL. Тъй като нашата CA изключен от мрежата, е необходимо да напуснат местната точка за разпределение, която е на първо място в списъка и по подразбиране в папката C: \ Windows \ system32 \ CertSrv \ CertEnroll \. Моля, имайте предвид, че тази опция е с етикет CDP Публикуване CRL на това място. За да се гарантира наличието на CRL да си тръгнем като LDAP-точка (посочва възможности включват във всички РЛО и Включване в разширението CDP на издадените сертификати) и ще създаде нова точка, сочейки към споделена папка в мрежата в локалната мрежа (с възможност да се включат в разширяване CDP от издадена сертификати). Като такъв, ще се въведе папка UNC-пътя към споделена папка, която се намира по-късно и в бъдеще нашата CA дружество, наречено EntCA: файл: // \\ Ent_CA \ CDP \
Фигура 3. Определяне на CDP в главната СО
Фигура 4. Целеви точки AIA
Сега можете да натиснете ОК и да приеме факта, че на удостоверителни услуги трябва да бъдат рестартирани.
Въпреки това, преди да можете да публикувате РЛО, е необходимо да се произведе дисплей на пространство от имена Active Directory в регистъра SA. Това е необходимо, за да се гарантира, че тези контакт LDAP CDP е била подадена в правилната форма. Това се прави с помощта на екипа и за certutil.exe Dedicated.Root домейн, както следва:
certutil.exe -setreg ва \ DSConfigDN CN = Configuration, DC = посветен, DC = корен
Резултатът трябва да бъде приблизително по следния начин:
Свързани статии