Глава 12. Службы Сертификатов Active Directory

Порой, когда я обсуждаю с пользователями и инженерами зашифрованный обмен, я обнаруживаю что им известно, что SSL (Secure Sockets Layer) более безопасен и работает с портом TCP 443. Однако большинство из них на самом деле не знают какова роль сертификата и как работают шифрование и дешифрация. Очень важно знать как они работают, поскольку это делает простыми развёртывание PKI и управление ими. Большинство связанных с PKI проблем, с которыми я работал, связаны с неправильным пониманием центральных связанных с нею технологий и компонентов, а не с проблемами уровня службы.

Существуют два типа применяемых для шифрования данных криптографических метода:

Цифровое шифрование означает, что обмен данными между двумя частями будет зашифрован, а его отправитель будет уверен что такой обмен может быть открыт только тем кто является предназначенным для этого получателем. Даже когда некая не авторизованная часть получает доступ к таким зашифрованным данным, он не будет иметь возможности расшифровать эти данные. Лучше всего пояснить это следующим примером:

У нас в организации имеется работник с именем Sean. В имеющейся среде PKI он владеет двумя ключами: общедоступным ключом и частным ключом. Sean может применять эти два ключа для процессов шифрования и подписи. Теперь ему требуется получать некий набор конфиденциальных данных от персонального управляющего своей компании, Chris. Он не желает чтобы кто- то ещё обладал этими конфиденциальными сведениями.

Лучше всего сделать это зашифровав те сведения, которые следует отправить от Chris Sean:

Чтобы зашифровать эти сведения, Sean отправляет свой общедоступный ключ Chris. Нет никаких проблем с предоставлением такого общедоступного ключа кому угодно. Затем, Chris применяет этот общедоступный ключ для шифрования тех сведений, которые будут отправляться Sean. Эти зашифрованные данные могут открываться лишь при помощи частного ключа Sean. Исключительно он является тем, кто обладает таким частным ключом. Это проверяет самого получателя и его авторизации для этих сведений.

Цифровая подпись проверяет наличие аутентичности службы или сведений. Это аналогично подписи документа для доказательства его аутентичности. Например, прежде чем купить что- то на каком- то вебсайте, мы можем проверить его цифровой цифровой сертификат и убедиться в аутентичности этого вебсайта и подтвердить что он не является вебсайтом фишинга. Давайте рассмотрим это свойство на варианте применения. В нашем предыдущем сценарии Sean успешно расшифровал свои данные, которые он получил от Chris. Теперь Sean желает отправить некие конфиденциальные сведения обратно Chris. Они могут быть зашифрованы при помощи того же самого метода с применением общедоступного ключа Chris. Однако проблема состоит в том, что Chris не является частью его установки PKI и он не обладает парой ключей. Единственное что требуется Chris, это проверить что данный отправитель правильный и что он именно тот пользователь, коим он себя считает. Когда Sean может сертифицировать это при помощи цифровой подписи и если Chris способен это проверить, данная проблема решается:

Теперь в этом случае Sean шифрует необходимые сведения применяя свой частный ключ. Единственный ключ, при помощи которого эти сведения могут быть расшифрованы это общедоступный ключ Sean. Chris уже имеет этот общедоступный ключ. Когда Chris получает обсуждаемые сведения, он расшифровывает их при помощи общедоступного ключа Sean и это подтверждает факт, что отправитель несомненно Sean.

В двух своих предыдущих сценариях я объяснил как работают с PKI цифровое шифрование и цифровые подписи. Однако эти сценарии можно совместить для предоставления одновременного шифрования и подписи. Для этого мы применим две дополнительные технологии:

Давайте рассмотрим это при помощи некого сценария. Предположим, что у нас имеются два работника, Simran и Brian, причём оба используют некую настройку PKI. Оба обладают выделенными им своими частным и общедоступным ключами:

Simran желает отправить некий зашифрованный и подписанный сегмент данных к Brian. Этот процесс можно разделить на две стадии: подпись данных и шифрование данных. Соответствующие сведения пройдут через обе стадии перед своей отправкой к Brian:

На своей первой стадии наш процесс подписывает необходимый сегмент данных. Эта система получает соответствующие сведения от Simran и самой первой задачей является выработка некой свёртки сообщения с применением алгоритма хэширования . Это обеспечит целостность сведений; если ни будут изменены, их получатель запросто сможет определить это применив свой процесс дешифрации. Это однонаправленный процесс. После выработки свёртки сообщения такая свёртка сообщения будет зашифрована при помощи частного ключа Simran для её цифровой подписи. Она также будет содержать общедоступный ключ Simran с тем, чтобы Brian был способен расшифровать и проверить значение аутентичности данного сообщения. После завершения данного процесса шифрования, будут присоединены необходимые значения первоначальных сведений.

Данный процесс обеспечит неизменность сведений и того что они были отправлены самими ожидаемым отправителем (то есть он подлинный):

Следующая стадия данного процесса заключается в шифровании полученных данных. Самаой первой задачей в этом процессе является выработка одноразового симметричного ключа для шифрования всех данных. Произвольный асимметричный алгоритм менее эффективен симметричных алгоритмов для его использования с большими сегментами данных. После выработки некого симметричного ключа необходимые сведения будут зашифрованы с его помощью (включая цифровую свёртку и подпись). Этот симметричный ключ будет применён Brian для дешифрации данного сообщения. Более того, нам необходимо гарантировать чтобы он был доступен только для Brian. Наилучшим способом для этого является шифрование такого симметричного ключа при помощи общедоступного ключа Brian. Таким образом, когда он его получит, он будет способен расшифровать его при помощи своего частного ключа. Это процесс расшифрует лишь зашифрованное значение симметричного ключа самого по себе, а всё остальное сообщение всё ещё останется прежним. После завершения этого, полученные данные могут быть отправлены к Brian.

Следующий необходимый шаг данного процесса состоит в рассмотрении того как происходит соответствующий процесс дешифрации на стороне Brian:

Процесс расшифровки полученного сообщения начинается с дешифрации значения симметричного ключа. Brian необходимо значение симметричного ключа чтобы продвинуться дальше в общем процессе расшифровки. Его можно расшифровать лишь при помощи частного ключа Brian. После его расшифровки, значение симметричного ключа можно применять для дешифрации полученных свёртки сообщения совместно с его подписью. Однако, после выполнения данной дешифрации сведения того же самого ключа не могут применяться для дешифрации аналогичных сообщений по причине одноразовости такого ключа:

Теперь когда у нас имеются необходимые расшифрованные сведения, наш следующий шаг состоит в проверке их подписи. На этот момент у нас имеется необходимая свёртка сообщения, которая зашифрована при помощи частного ключа Simran. Её можно расшифровать воспользовавшись общедоступным ключом Simran, который присоединён к расшифрованному сообщению. После её расшифровки, мы можем изъять значение свёртки сообщения. Это значение свёртки является односторонним. У нас нет возможности её обратной реконструкции. Вследствие этого, получаемое из изъятых первоначальных сведений значение свёртки будет повторно вычислено с применением того же самого алгоритма, который применял отправитель. После этого, данное вновь выработанное значение свёртки будет сравнено с тем значением свёртки, которое прикреплено к самому сообщению. Если это значение то же самое, это подтверждает что полученные сведения не подвергались изменению в процессе их передачи. Когда эти значения равны, значение подписи будет проверено и сами первоначальные сведения были выпущены для Brian. Если значения свёрток разнятся, такое сообщение будет отклонено, поскольку либо оно было изменено, либо не подписывалось Simran.

Это объясняет как работает среда PKI при помощи процесса шифрования/ дешифрации, а также сам процесс цифровых подписи/ проверки.

До сих пор мы обсуждали то как в PKI работают асимметричная пара ключей и симметричные ключи. Однако когда мы говорим о PKI мы имеем в виду сертификаты SSL. Итак, в чём состоит роль таких сертификатов?

Я регулярно путешествую между Лондоном и Сиэтлом. Когда я появляюсь в международном аэропорту Сиэтла Такома, офицер безопасности на границе просит мой паспорт для проверки моей идентичности. Он не знает меня персонально, однако тот паспорт, который я держу, выпущен неким авторитетом, который работает согласно международным законам о миграции и он сертифицирует, что та персона, которая владеет данным паспортом это Дишан Франсис. Если они желают проверить саму его аутентичность, они могут проверить величину полномочий выпустивших его. Итак, они доказали идентичность и они могут дальше проверить значение состояния визы чтобы принять решение о моём въезде в их страну.

Аналогично, когда мы рассматриваем криптографию общедоступного ключа, мы знаем, что некий общедоступный ключ может применяться многими приложениями и службами. Но как в точности можно его публиковать и как мы можем получать подтверждение в его аутентичности? Это осуществляется с помощью цифрового сертификата, выпускаемого CA (certification authority, Центром сертификации), который может являться доверенным со стороны необходимого получателя. Такой цифровой сертификат будет содержать значение общедоступного ключа того объекта, для которого он был выпущен. Наш получатель может изъять значение общедоступного ключа соответствующего объекта или той службы, к которой он выполняет доступ через некий цифровой сертификат и его можно проверить в обладающем доверием центре.

Такие цифровые сертификаты следуют аналогичной структуре, поэтому все их способны понимать. Это похоже на то как работает соответствующий паспорт; парни в конторе на границе знают куда смотреть, даже тот паспорт, который у них в руках, раньше никогда им не встречался. Такие сертификаты также имеют временные ограничения, что делает их допустимыми только для определённого периода времени. После достижения срока службы, их необходимо выпускать повторно, аналогично обновлению паспорта.

Такой сертификат содержит следующие сведения:

Приводимый ниже экранный снимок показывает образец сертификата:

Типы авторизации сертификатов

Существует два типа Центров сертификации:

Как работают сертификаты при помощи цифровых подписей и шифрования?

В своём предыдущем разделе мы рассмотрели некий сценарий, в котором Simran отправлял зашифрованные и подписанные цифровой подписью сведения к Brian. На протяжении этого процесса мы видели как Simran и Brian пользуются частными и общедоступными ключами друг друга. Некий общедоступный ключ должен разделяться между двумя частями. Теперь основная задача, которую нам предстоит отработать состоит в том, как именно наша система узнаёт что общедоступный ключ Brian именно его, а не от кого-то ещё, претендующего на роль Brian? Чтобы справиться с этой задачей, мы можем воспользоваться сертификатами для проверки того были ли разделяемые общедоступные ключи выпущены их предполагаемыми источниками. Давайте введём в свой предыдущий пример сертификаты и посмотрим как эти моменты работают.

Наш процесс цифровой подписи работает следующим образом:

Соответствующий процесс дешифрации работает следующим образом:

Процесс дешифрации соответствующих сведений работает так:

Процесс проверки подписи работает следующим образом:

Остальные шаги в точности те же самые, которые я пояснял в своём разделе Подписи, шифрование и дешифрация.

Что мы можем делать посредством сертификатов?

Приводимые выше сценарии не являются исключительными способами, которыми мы можем применять сертификат. Давайте рассмотрим ряд сценариев в которых мы можем воспользоваться сертификатами:

Компоненты AD CS

AD CS это набор служб ролей и их можно применять для проектирования PKI вашей организации. Давайте рассмотрим каждую из этих служб ролей и их ответственности.

CA

Держатели службы роли CA отвечают за выпуск, хранение, управление и отзыв сертификатов. Соответствующая установка PKI может обладать множеством CA. Существует два основных типа CA, которые могут быть выявлены в PKI:

Подчинённые CA могут обладать под собой более подчинёнными CA. В такой ситуации подчинённые CA также отвечают и за выпуск сертификатов для своих собственных подчинённых CA. Подчинённые CA, обладающие более подчинёнными CA имеют название промежуточных CA. Они не будут отвечать за выпуск сертификатов пользователям, устройствам или службам. Подчинённые серверы, которые выпускают сертификаты для объектов или служб носят название CA издателей.

Веб служба Регистрации сертификатов

Веб служба Регистрации сертификатов позволяет пользователям, компьютерам или службам запрашивать сертификаты или обновлять их через веб браузер, даже когда они не являются присоединёнными к домену или временно расположены вне своей корпоративной сетевой среды. Когда они подключены к домену и расположены в своей корпоративной сетевой среде, для выборки сертификата могут применяться процессы автоматической регистрации или запросы на основе шаблона.

Веб служба Политик регистрации сертификатов

Эта служба роли работает с Веб службой Регистрации сертификатов и делает возможной регистрацию сертификатов пользователям, компьютерам и службам на основе политик. Аналогично Веб службе Регистрации сертификатов, компьютеры клиента могут быть не присоединёнными к домену устройствами или подключаемыми к домену устройствами, расположенными за пределами границ сетевой среды своей компании. Когда некий клиент запрашивает сведения о политике, Веб служба Политик регистрации сертификатов запрашивает AD DS при помощи LDAP (Lightweight Directory Access Protocol) сведения о такой политике и затем доставляет их своему клиенту через HTTPS. Эти сведения будут кэшированы и применяются для аналогичных запросов. После получения соответствующим пользователем сведений о необходимой политике, он может запросить необходимый сертификат с помощью Веб службы Регистрации сертификатов.

Веб служба Авторизации Регистрации сертификатов

Она аналогична веб интерфейсу для CA. Пользователи, компьютеры или службы имеют возможность запрашивать сертификаты при помощи некого веб интерфейса. При помощи такого интерфейса пользователи способны выгружать установленные сертификаты корня и промежуточные сертификаты для того чтобы удостовериться в сертификате. Это может быть полезным для запроса соответствующего CRL (certificate revocation list, списка отозванных сертификатов). Такой список содержит все те сертификаты, у которых истёк срок или они были отозваны в рамках данной PKI. Когда любой из представленных сертификатов совпадает с некой записью из полученного CRL, он будет автоматически отклоняться.

Регистрация сертификатов сетевых устройств

Такие сетевые устройства как маршрутизаторы, коммутаторы и межсетевые экраны могут иметь сертификаты устройств для проверки необходимой аутентичности проходящего через них обмена. Большинство таких устройств не являются присоединёнными к домену, а их операционные системы также через- чур уникальны и не поддерживают обычных функций компьютеров Windows. Для запроса или выборки сертификатов сетевые устройства применяют SCEP (Simple Certificate Enrollment Protocol). Он позволяет сетевым устройствам обладать сертификатами X.509 версии 3 аналогично прочим присоединённым к доменам устройствам. Это важно, так как если некое устройство намерено применять IPSEC, оно обязано обладать сертификатом X.509 версии 3.

Интернет ответчик

Интернет ответчик (Online Responder) несёт ответственность за производство сведений относительно состояния сертификата. Когда я говорил о Веб службе Авторизации Регистрации сертификатов, я пояснил, что CRL содержит полный список сертификатов с истекшими сроками или отозванными в рамках своей PKI. Этот список продолжит свой рост на основе общего числа управляемых сертификатов.

Вместо того чтобы использовать сваленный в кучу сведения, Интернет ответчик будет откликаться на индивидуальные запросы пользователей для проверки значения состояния определённого сертификата. Это намного действеннее нежели метод CRL, поскольку такой запрос сосредоточен на поиске значения сертификата в заданный момент времени.

Типы CA

Основываясь на своём методе установки, CA могут подразделяться на два типа: Standalone CA (обособленные CA) и Enterprise CA (корпоративные CA). Лучшим объяснением всех возможностей обоих типов является их сопоставление:

Таблица 12-1. Сопоставление обособленных и корпоративных CA

Свойство	Обособленный CA	Корпоративный CA
зависимость от AD DS	Не зависит от AD DS; может устанавливаться как некий сервер участник или отдельно стоящий сервер в какой- то рабочей группе	Может устанавливаться только на некий сервер участник
Работа в автономном режиме	Способен работать в автономном режиме	Не может работать в автономном режиме
Индивидуальные шаблоны сертификата	Не поддерживает; поддерживает только стандартные сертификаты	Поддерживаются
Поддерживаемые методы регистрации сертификатов	Ручная или веб регистрация	Автоматическая, ручная или веб регистрация
Процесс одобрения сертификата	Вручную	Вручную или автоматически на основании выбранной политики
Ввод пользователя в поля сертификата	Вручную	Изымается из AD DS
Выпуск сертификата и управление им при помощи AD DS	не доступно	Поддерживаются

Обособленные CA в основном применяются в качестве CA корня. В своём предыдущем разделе я объяснял как важна безопасность корневого CA. Обособленный CA поддерживает сохранение такого сервера в автономном режиме и приводит его в соединение с сетью по мере необходимости для выпуска некого сертификата или обновления сертификата. Корневой CA применяется только для выпуска сертификатов подчинённых CA. Таким образом, ручная обработка и подтверждение легко управляемы, так как они могут выполняться раз в несколько лет. Этот тип также допустим для общедоступного CA. Издающий CA связан с повседневными задачами, относящимися к CA, такими как выдача, управление, хранение, обновление и отзыв сертификатов. В зависимости от размера своей инфраструктуры могут иметься сотни или тысячи пользователей, применяющих такие издающие CA. Когда процесс запроса и подтверждения ручные, это может требовать большого объёма работы персонала для их сопровождения. Таким образом, в корпоративных сетевых средах всегда рекомендуется применять некий корпоративный тип CA.

Корпоративные CA позволяют инженерам создавать шаблоны сертификатов со специфическими требованиями и публиковать их посредством AD DS. Конечные пользователи могут запрашивать сертификаты на основе таких шаблонов. Корпоративные CA могут устанавливаться только на Windows Server Enterprise Edition или Datacenter Edition.

Теперь мы понимаем сто такое PKI и как она работает. Вы также изучили компоненты AD DS и их возможности. Наш следующий момент заключается в планировании своего развёртывания необходимой PKI. В этом разделе мы рассмотрим те вещи, которые следует рассматривать на протяжении процесса планирования своей PKI.

AD CS это не просто некая роль, которую мы можем установить в сервере и оставить её в рабочем состоянии. Она требует знаний по установке и работе с нею. Она, как и прочие ИТ системы требует сопровождения. Она также нуждается в резервном копировании и высокой доступности. Всё это требует дополнительных затрат. Сертификаты общедоступных CA необходимо приобретать у поставщика услуги. Всякий поставщик такой услуги обладает множеством различных типов с разнообразными диапазонами цен. Важно выполнять оценку стоимостей для требований вашей компании. Когда соответствующая компания рассматривает необходимость нескольких сертификатов для веб служб, нет никаких соображений в поддержке для этого нескольких серверов внутренним образом. Когда некий общедоступный поставщик CA может предложить те же самые вещи за $15, имеет смысл потратить эти деньги вместо того чтобы тратить ресурсы и средства на поддержку некого внутреннего CA. Однако, нам требуется оценивать не только собственно стоимость. Некий внутренний CA предоставляет большую гибкость когда дело касается администрирования. Он допускает для нас создание шаблонов и политик в соответствии с организационными требованиями. Общедоступные CA дают лишь ограниченный контроль. Всё что вы можете делать, так это заплатить за сам сертификат, представить свой подписанный запрос и затем выгрузить выданный сертификат после его выпуска. Общедоступные CA на самом деле обладают репутацией. Когда пользователю за пределами своей корпоративной сетевой среды, ему требуется доверять выпускаемому её внутренним CA сертификату и всем прочим CA в общей цепочке, однако не все бы пожелали этого. Тем не менее, когда определённый сертификат выпущен обладающим репутацией CA, он предоставляет пользователям доверие к своему сертификату и защищаемому им содержимому. Когда вы применяете некий общедоступный CA, пользователи могут получать профессиональную поддержку от производителя когда она им потребуется - нет необходимости обладать глубокими знаниями для запроса и получения цифрового сертификата - в то время как внутренний CA требует навыков в его развёртывании, управлении сопровождении. Рассмотрев все эти за и против нам требуется принять решение какая именно модель лучше подходит к требованиям вашей организации.

Сертификаты могут выпускаться для пользователей, компьютеров или сетевых устройств. Сертификаты пользователей в целом применяются для самого процесса аутентификации. Сертификаты также могут использоваться с некими приложением или службой. Сертификаты пользователя будут устанавливаться в неком хранилище сертификатов пользователя. Сертификаты пользователя позволяют вам уникально идентифицировать некое устройство. Сертификаты компьютера будут храниться в хранилище сертификатов компьютера. Сетевые сертификаты делают возможным использование сертификатов X.509 и их можно применять для сертификации некого устройства и шифрования всего передаваемого через него обмена. Такие службы как веб или электронная почта могут применять сертификаты для аутентификации и шифрования сведений. Служба сама по себе не обладает сертификатом, но будет использовать сертификат компьютера или сертификат пользователя, которые ассоциированы с такой службой. Важно понимать какие именно типы объектов будут обладать сертификатами, ибо на этом основывается сама настройка соответствующего CA. В качестве примера, когда требуются сертификаты для неких сетевых устройств, нам следует установить Службу регистрации Сетевых устройств (Network Device Enrollment Service) и настроить её. Для поддержи такого типа объектов потребуется видоизменить шаблоны сертификатов.

Для некого CA мы можем применять установленного по умолчанию поставщика криптографии Microsoft, в качестве которого выступает RSA Microsoft Software Key Storage Provider, либо прочих современных поставщиков, таких как ECDSA_P256, ECDSA_P521 либо ECDSA_P384. В зависимости от используемого поставщика также могут изменяться длина криптографического ключа и алгоритм хэширования. Пока нет никаких особенных причин делать нечто иное, всегда рекомендуется применять Microsoft RSA.

При увеличении длины используемого криптографического ключа также растёт и безопасность. Рекомендуемым минимумом для размера ключа являются 2048 бит и этот размер может изменяться на основании выбранного поставщика криптографии. При росте значения размера ключа сам процесс шифрования/ дешифрации требует больше системных ресурсов.

В процессе развёртывания CA мы можем выбирать свой стандарт алгоритма хэширования. По умолчанию это SHA256 и это значение можно заменять на SHA384, SHA512 или MD5. SHA1 более не рекомендуется применять, поскольку было доказано что он является более нестойким алгоритмом хэширования по сравнению с прочими.

Действие сертификатов ограничено по времени. Применяя шаблоны сертификатов мы можем задавать значение периода действия сертификата. Это могут быть месяцы или годы. Прежде чем срок действия сертификата истечёт, его требуется обновить (установленный шаблон сертификата будет определять сколько дней или недель наперёд требуются для возможности его обновления). Дата истечения срока выданного сертификата не может быть изменена если не будет продлена или не будет повторной выдачи.

Установленный CA корня в некой PKI может иметь более подчинённые CA. Это создаёт некую иерархию PKI, а значение общего числа подчинённых CA основывается на установленных для данной организации требованиях. Существует два главных типа проектирования иерархии: двухуровневая и трёхуровневая. Они в подробностях будут объяснены в нашем следующем разделе, но тут я бы желал выделить именно тот факт, что выбор верной модели иерархии снизит операционные расходы и ненужные затраты ресурсов.

Основываясь на требованиях вашей организации, вам придётся принять решение каким именно будет наилучшее решение для сопровождения высокой доступности. При интенсивном использовании PKI важна высокая доступность роли CA. Время безотказной работы службы может быть обеспечено запуска такой службы в некой кластерной среде или применении современных решений восстановления, таких как Azure Site Recovery. На основании значения максимального времени простоя, которое допустимо в организации также изменяются и вложения в продукцию высокой доступности, применяемые технологии и общий применяемый подход.

Не всем пользователям, компьютерам или службам требуются одни и те же типы сертификатов. Когда вы приобретаете сертификаты в общедоступном CA, имеется множество различных типов доступных сертификатов, причём все с различными ценами. Каждый из таких сертификатов обладает различными вариантами и дополнительными услугами. Шаблоны сертификатов помогают вам создавать индивидуальные шаблоны которые соответствуют различным требованиям сертификатов. Например, сертификаты пользователей могут требовать ежегодного обновления по причине изменения персонала, в то время как сертификаты компьютеров могут обновляться раз в пять лет. В качестве части общего процесса планирования нам потребуется оценить требования к сертификатам с тем чтобы мы могли создавать новые шаблоны для соответствия этому процессу.

Прежде чем приступать к развёртыванию, важно принять решение по границам работы, в рамках которых будет отражаться данная архитектура PKI. Нам требуется принять решение для каких домена, леса или сегмента сетевой среды будет работать данное развёртывание. Когда такие границы определены, в дальнейшем будет сложно изменять их без изменений уровня физической или логической сетевой среды. Например, когда у нас имеется некий CA в нашей сетевой среде периметра и нам требуется расширить эти границы на всю корпоративную сетевую среду, это потребует также изменений в некоторых границах сетевой среды. В качестве другого примера, когда некая партнёрская компания или третья сторона желают использовать CA вашего предприятия, это потребует изменения роли AD CS, модернизаций межсетевого экрана, модификаций сетевых маршрутов, корректировки DNS и много чего ещё. Вследствие этого важно выполнить оценку этих типов требований работы в самом процессе планирования.

В нескольких местах этой главы я упоминал собственно иерархию PKI и такие компоненты как корневой CA, промежуточный CA и издающий CA. На основании требований состояния ведения дел и операций также может изменяться и топология PKI. Имеются три модели которые могут разрешать требования устанавливаемой PKI. В данном разделе мы рассмотрим эти модели и их характеристики.

Модель с единственным уровнем также носит название одноуровневой модели и это простейшая модель развёртывания для PKI. Она не рекомендуется для применения ни в какой промышленной сетевой среде, ибо это единственная точка отказа для всей PKI целиком:

В этой модели единственный CA будет действовать в качестве корневого CA и выпускающего CA. Как я уже пояснял ранее, именно корневой CA является обладающим наибольшим доверием CA во всей иерархии PKI. Скомпрометированный корневой CA скомпрометирует всю PKI целиком. При данной модели он является единственным сервером, а потому любая брешь в этом сервере запросто скомпрометирует всю PKI целиком, поскольку нет нужды распространяться по различным уровням иерархии. Данную модель просто реализовать и ею просто управлять.

Некоторые осведомлённые об CA приложения нуждаются в сертификатах для своей работы. Одним из таких примеров является SCOM (System Center Operations Manager, Системного центра Диспетчера работ). Он применяет сертификаты для безопасности веб интерфейса, аутентифицированного управления серверами и много иного. Когда ваша организация не обладает неким внутренним CA, вы можете либо приобретать сертификаты у определённого производителя или развернуть новый CA. Обычно инженеры применяют именно данную одноуровневую модель, поскольку она используется только для определённого приложения или задачи:

Таблица 12-2. Преимущества и недостатки одноуровневой модели

Преимущества	Недостатки
Для управления ею требуется меньше ресурсов, поскольку она вся работает в единственном сервере.	Существует высокая вероятность быть скомпрометированной, поскольку корневой CA работает подключённым к сети и запускает все относящиеся к PKI роли. Если некто получает доступ к частному ключу данного корневого CA, он получает полное обладание всей PKI.
Развёртывание быстрее и имеется возможность получить CA запущенным в короткий промежуток времени.	Имеется отсутствие избыточности, так как издание сертификата и управления полностью зависят от единственного сервера; доступность данного сервера будет определять доступность всей PKI.
N/A	Отсутствует масштабирование и требуется реструктурировать имеющуюся иерархию если требуется добавление дополнительных серверов ролей.

Это наиболее распространённая модель развёртывания PKI для сетевых сред предприятия. При данной архитектуре имеющийся корневой CA держится отключённым от сети. Это будет способствовать защите его частного ключа от компрометации имеющегося сертификата корня.

Корневой CA будет издавать сертификаты для подчинённых CA, а подчинённые CA отвечают за выпуск сертификатов для объектов и служб:

Когда истекает срок действия сертификата подчинённого CA, потребуется подключение к сети отключённого от сетевой среды корневой CA для обновления такого сертификата. Имеющийся корневой CA не должен быть участником домена и он должен работать на уровне определённой рабочей группы (обособленный CA). Следовательно, собственно регистрация сертификата, его подтверждение и обновление будут некими выполняемыми вручную процессами. Это масштабируемое решение и общее число издающих CA может увеличиваться на основании рабочей нагрузки. Это позволит вам также расширять необходимые границы CA на множество площадок. При одноуровневой модели в случае компрометации установленной PKI для восстановления всех изданных сертификатов вам потребуется вручную удалить их из соответствующих устройств. При двухуровневой модели, однако, вам просто требуется отозвать те сертификаты, которые выпущены скомпрометированным CA, опубликовать CRL и затем повторно выпустить необходимые сертификаты:

Таблица 12-3. Преимущества и недостатки двухуровневой модели

Преимущества	Недостатки
Она предоставляет улучшенную безопасность PKI, поскольку в этой модели её корневой CA должен оставаться отключённым от сети. Это будет защищать его частный ключ от компрометации.	Высокий уровень сопровождения - она требует определённой поддержки множества систем и навыков для обработки множества сертификатов процесса запроса/ подтверждения/ обновления между установленным корневым и подчинёнными CA.
Гибкое масштабирование - может начинаться с небольшой и расширяться добавлением подчинённых CA по мере необходимости.	Стоимость - общая стоимость ресурсов и лицензий выше по сравнению с затратами для одноуровневой модели.
Вы можете ограничивать воздействие издающих CA для имеющейся иерархии CA через контроль сферы действия сертификатов. Это будет препятствовать выпуску мошеннических сертификатов.	Необходимый для выполнения вручную процесс обновления сертификата между установленным корневым CA и подчинёнными CA добавляет дополнительные риски; если администраторы забудут обновить сертификат вовремя, это может привести к падению всей PKI целиком.
Улучшается производительность, так как рабочие нагрузки могут разделяться по множеству подчинённых CA.	N/A
Гибкие возможности сопровождения, так как имеется меньше зависимостей.	N/A

В общем списке трёхуровневая модель является наиболее развитой и она работает с большей безопасностью, масштабируемостью и контролем. Аналогично двухуровневой модели он также обладает отключённым от сети корневым CA и подключёнными к сети издающими CA. Дополнительно к этому имеются отключённые от сети промежуточные CA, которые работают между установленным корневым и подчинёнными CA. Основная роль таких промежуточных CA состоит в работе в качестве CA политик. В крупных организациях различные подразделения, различные площадки и различные рабочие отделы могут обладать различными требованиями сертификатов. Например, выпускаемый для сетевой среды периметра сертификат будет требовать процесс подтверждения вручную, в то время как пользователи в имеющейся сети предприятия будут предпочитать автоматическое подтверждение. Команды ИТ предпочитают владеть большими ключами и современными поставщиками криптографии для своих сертификатов, в то время как прочие пользователи работают с установленными по умолчанию алгоритмами RSA. Все эти разнообразные требования определяются установленной политикой CA и он издаёт подходящие шаблоны и процедуры для прочих CA:

Данная модель добавляет ещё один уровень безопасности в устанавливаемой иерархии. Тем не менее, если вы не применяете политики CA, такой промежуточный уровень не будет полезным. Он будет пустой тратой средств и ресурсов. Таким образом, большинство организаций предпочитают для начала двухуровневую модель, а уж потом если потребуется, выполняют расширение.

В данной модели и установленный корневой CA и промежуточные CA работают как обособленные CA. Установленный корневой CA будет издавать сертификаты лишь для промежуточных CA, а они будут выпускать сертификаты для издающих CA:

Таблица 12-4. Преимущества и недостатки трёхуровневой модели

Преимущества	Недостатки
Улучшает безопасность, поскольку она добавляет ещё один уровень CA для проверки сертификатов.	Стоимость - общая стоимость ресурсов и лицензий высокая, поскольку требуется поддержка трёх уровней. Это также увеличивает операционные расходы.
Большая масштабируемость, так как каждый уровень может расширяться горизонтально.	Высокий уровень поддержки - при росте общего числа серверов также возрастают усилия для их сопровождения. Оба уровня, которые работают как обособленные CA требуют дополнительного сопровождения, так как не поддерживаются автоматические запросы/ подтверждения/ обновления сертификатов.
В случае компрометации конкретного CA, его промежуточный CA может отозвать такой скомпрометированный CA с минимальным воздействием на имеющуюся установку.	Имеющаяся сложность реализации высока по сравнению с прочими моделями.
Установка с высокой производительностью, так как рабочие нагрузки распределены и границы администрирования хорошо определяются промежуточными CA.	N/A
Улучшенный контроль над политиками сертификатов, позволяя предприятиям обладать сделанными на заказ сертификатами.	N/A
Высокая доступность, поскольку зависимости снижаются дальше.	N/A

Теперь мы завершили с теоретической частью в данной главе и переходим к части развёртывания. В этом разделе я собираюсь показать как мы можем установить некую PKI с применением двухуровневой модели. Я применяю эту модель ибо она чаще всего применяется для организация среднего и малого размера:

Наша предыдущая схема поясняет ту настройку, которую я намерен сконфигурировать. В ней я имею один контроллер домена, один обособленный корневой CA и один издающий CA. Все они работают под Windows Server 2016 с самым последним уровнем исправлений.

Самый первый этап состоит в установке обособленного корневого CA. Он не является сервером участником домена и работает на уровне собственной рабочей группы. Его настройка в обособленной VLAN добавит дополнительную безопасность для такого корневого CA.

После того как этот сервер готов, зарегистрируйтесь в этом сервере как участник его группы локальных администраторов. Самая первая задача состоит в установке необходимой службы роди AD CS. Это можно сделать при помощи следующей команды:

Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
 	   

Когда данная служба роли установлена, наш следующий шаг состоит в настройке этой роли и получении CA поднятым и работающим:

Install-ADcsCertificationAuthority -CACommonName "REBELAdmin Root CA" -CAType StandaloneRootCA -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -HashAlgorithmName SHA256 -KeyLength 2048 -ValidityPeriod Years -ValidityPeriodUnits 20
 	   

В нашем предыдущем коде -CACommonName определяет общее название для созданного CA. Затем -CAType определяет тип операций этого CA. В нашем случае это StandaloneRootCA. Другими возможными вариантами являются EnterpriseRootCA, EnterpriseSubordinateCA и StandaloneSubordinateCA. Теперь -CryptoProviderName определяет устанавливаемого поставщика службы криптографии. В данной демонстрации я применяю устанавливаемую по умолчанию службу Microsoft. -HashAlgorithmName задаёт тот алгоритм хэширования, который используется в данном CA. Вариант для неё будет изменён на основании выбранного нами CSP (Cryptographic Service Provider). SHA1 более не считается неким безопасным алгоритмом; рекомендуется применять SHA256 ил выше. -KeyLength определяет значение размера ключа для данного алгоритма. В данной демонстрации я применяю размер ключа 2048. -ValidityPeriod задаёт период действия сертификатов CA. Это могут быть часы, дни, недели, месяцы и годы. -ValidityPeriodUnits идёт вслед за -ValidityPeriod и определяет сколько часов, дней, недель, месяцев или годов в течении которых он будет действителен. В нашей демонстрации мы пользуемся 20 годами:

Теперь у нас имеется необходимый корневой CA поднятым и работающим. Однако прежде чем его использовать, нам необходимо сделать определённые изменения конфигурации.

DSConfigDN

Как я уже упоминал ранее, это обособленный корневой CA и он не является частью общего домена. Тем не менее, местоположения CDP (CRL Distribution Points, точек распространения CRL) и AIA (authority information access, доступа к информации авторизации), которые будут необходимы для данного CA будут храниться в DC. Поскольку они применяют DN (Distinguished Names, отличительные имена) в неком домене, наш корневой CA нуждается в осведомлённости по сведениям о домене для публикации своих свойств. Он будет изымать эти сведения через ключ реестра:

certutil.exe –setreg ca\DSConfigDN CN=Configuration,DC=rebeladmin,DC=com
 	   

Местоположения CDP

CDP определяют то место, из которого могут изыматься необходимые CRL. Это основанное на веб местоположение и к нему следует выполнять доступ через HTTP. Этот список будет применяться программой проверки корректности сертификата для сверки данного сертификата в имеющемся списке отзыва.

Прежде чем мы это сделаем, нам требуется подготовить свой веб сервер. Он должен быть неким участником домена, так как его выпускающий CA также находится в домене.

В своей демонстрации я намерен применять тот же самый издающий CA что и для местоположения CDP.

Такой веб сервер можно установить при помощи следующей команды:

Install-WindowsFeature Web-WebServer -IncludeManagementTools
 	   

Затем мы создаём некую папку и создаём общий ресурс с тем чтобы его можно было применять в качестве общего виртуального каталога:

mkdir C:\CertEnroll 
New-smbshare -name CertEnroll C:\CertEnroll -FullAccess SYSTEM,"rebeladmin\Domain Admins" -ChangeAccess "rebeladmin\Cert Publishers"
 	   

В качестве части своего упражнения будут установлены полномочия совместного ресурса для rebeladmin\Domain Admins (полный доступ) и rebeladmin\Cert Publishers (доступ на изменение).

После этого загрузите диспетчер IIS ( Internet Information Services) и добавьте виртуальный каталог, CertEnroll, с вышеупомянутым нами путём:

И последнее, но не по значимости, нам требуется создать некую запись DNS для URL своей службы. В этой демонстрации я применяю crt.rebeladmin.com. Это сделает для нас возможным доступ для новой точки распространения при помощи http://crt.rebeladmin.com/CertEnroll.

Теперь всё готово и мы можем опубликовать имеющиеся установки CDP при помощи такой команды:

certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl \n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://crt.rebeladmin.com/CertEnroll/%3%8%9.crl"
 	   

Отдельные числа в этой команде ссылаются на опции, а числа с % ссылаются на соответствующие переменные:

Таблица 12-5. Значения опций местоположения CDP

Опция	Подробности
0	Без изменений.
1	Опубликовать значение CRL для данного заданного местоположения.
2	Подключить значения расширений CDP для издаваемых сертификатов.
4	Включать в значение CRL для поиска значения приращения местоположений CRL.
8	Определить есть ли необходимость в публикации всех сведений CRL для AD при публикации вручную.
64	Приращение местоположения CRL.
128	Включать значение расширения IDP (Issuing Distribution Point) данного издаваемого CRL.

Все эти настройки могут определяться при помощи GUI. Для доступа к ним пройдите в Server Manager | Tools | Certification Authority и кликните правой кнопкой и выберите Properties для данного сервера и пройдите в закладку Extension.

Здесь вы можете добавить следующие переменные при воспользовавшись GUI:

Таблица 12-6. Значения переменных местоположения CDP

Переменная	Ссылка GUI	Подробности
%1	<ServerDNSName>	Имя DNS данного сервера CA
%2	<ServerShortName>	Имя NetBIOS данного сервера CA
%3	<CAName>	Собственное имя для данного CA
%4	<CertificateName>	Обновляемое расширение данного CA
%6	<ConfigurationContainer>	DN контейнера конфигурации в AD
%7	<CATruncatedName>	Усечённое имя данного CA (32 символа)
%8	<CRLNameSuffix>	Вставка суффикса имени в самый конец имени файла перед публикацией CRL
%9	<DeltaCRLAllowed>	Замена CRLNameSuffix отдельным суффиксом для использования значения приращения CRL
%10	<CDPObjectClass>	Идентификатор соответствующего класса объекта для данного CDP
%11	<CAObjectClass>	Идентификатор соответствующего класса объекта для данного CA

Местоположения AIA

AIA это некое расширение, которое имеется в данном сертификате и определяется тем местоположением из которого данное приложение или эта служба может получать данный издаваемый сертификат CA. Это также путь на основе веб и мы можем применять то же самое местоположение, которое мы применяем для своего CDP.

Местоположение AIA может устанавливаться при помощи следующей команды:

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://crt.rebeladmin.com/CertEnroll/%1_%3%4.crt"
 	   

Его опции очень похожи на опции для CDP с несколькими небольшими изменениями:

Таблица 12-7. Значения опций местоположения AIA

Опция	Подробности
0	Без изменений.
1	Опубликовать сертификат CA для заданного местоположения.
2	Подключить расширения AIA для издаваемых сертификатов.
32	Подключить расширения OCSP (Online Certificate Status Protocol).

Временные рамки CA

После того как мы настроили свой CA, мы задали значения периода действия CA на 20 лет. Однако это не означает что все издаваемые сертификаты будут иметь период действия на 20 лет. Корневой CA будет выпускать сертификаты только для издающих CA. Запрос, подтверждение и обновление этих сертификатов выполняются вручную. По этой причине такие сертификаты будут иметь более длительные периоды действия. Для данной демонстрации я установлю его на 10 лет:

certutil -setreg ca\ValidityPeriod "Years"
certutil -setreg ca\ValidityPeriodUnits 10
 	   

Временные рамки CRL

CRL обладает также некими ассоциированными пределами времени:

Certutil -setreg CA\CRLPeriodUnits 13
Certutil -setreg CA\CRLPeriod "Weeks"
Certutil -setreg CA\CRLDeltaPeriodUnits 0
Certutil -setreg CA\CRLOverlapPeriodUnits 6
Certutil -setreg CA\CRLOverlapPeriod "Hours"
 	   

В наших предыдущих командах верно следующее:

Теперь у нас имеются все представленные настройки; для применения всех этих изменений требуется перезапустить данную службу сертификации:

restart-service certsvc
 	   

Новый CRL

Наш следующий шаг состоит в создании нового CRL, который будет выработан с помощью такой команды:

certutil -crl
 	   

После этого в C:\Windows\System32\CertSrv\CertEnroll будут два файла:

Этим завершается первоначальная настройка обособленного корневого CA. В качестве следующего шага нам требуется опубликовать сведения о данном корневом CA в AD. Таким образом присоединяемые к AD компьютеры будут получать сертификаты своего корневого CA в соответствии с сертификатами Trusted Root Certification Authorities (Доверенных Центров сертификации корня).

В нашем предыдущем снимке экрана мы видим наличие двух файлов. Один из них завершается на .crt. Это и есть сертификат нашего корневого CA. Для его распространения прочим клиентам в общем домене для начала требуется опубликовать его в AD. Для этого пройдите далее и скопируйте данный файл из своего корневого CA в сервер установленного AD. Затем зарегистрируйтесь в своём контроллере домена в качестве Администратора домена или Администратора предприятия и исполните такую команду:

certutil –f –dspublish "REBEL-CRTROOT_REBELAdmin Root CA.crt" RootCA
 	   

Наш следующий файл завершается на .crl. Это CRL нашего корневого CA. Его также следует опубликовать в AD с тем, чтобы все в домене также знали о нём. Для этого скопируйте данный файл из установленного корневого CA в свой контроллер домена и выполните следующую команду:

certutil –f –dspublish "REBELAdmin Root CA.crl"
 	   

теперь, когда мы покончили с настройкой своего корневого CA, наш следующий этап состоит в установке своего издающего CA. Издающий CA будет запускаться в сервере участнике домена и будет интегрирован с AD. Для выполнения данной установки зарегистрируйтесь в этом сервере в качестве Администратора домена или Администратора предприятия.

Нашей первой задачей будет установка самой роли AD CS:

Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
 	   

Я воспользуюсь тем же самым сервером для необходимой службы роли веб регистрации (Web Enrollment Role Service). Её можно добавить при помощи такой команды:

Add-WindowsFeature ADCS-web-enrollment
 	   

После этого мы можем настроить эту службу роли воспользовавшись следующей командой:

Install-ADcsCertificationAuthority -CACommonName "REBELAdmin IssuingCA" -CAType EnterpriseSubordinateCA -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -HashAlgorithmName SHA256 -KeyLength 2048
 	   

Чтобы настроить службу роли веб регистрации примените ещё одну команду:

Install-ADCSwebenrollment
 	   

Для получения запущенной AD CS в своём издающем CA требуется выпустить соответствующий сертификат из его родительского CA, коим является наш корневой CA, который мы только что развернули. На протяжении процесса настройки данной роли она автоматически создаёт запрос такого сертификата в C:\, а точное имя файла будет приведено в выходе нашей предыдущей команды:

Данный файл необходимо скопировать с издающего CA в установленный корневой CA, затем вам следует выполнить такую команду:

certreq -submit "REBEL-CA1.rebeladmin.com_REBELAdmin IssuingCA.req"
 	   

Как я уже пояснял ранее, все запросы для нашего корневого CA будут выполняться вручную, поэтому данный запрос будет ожидать подтверждения вручную. Чтобы заверить данный сертификат, пройдите в Server Manager | Tools | Certification Authority | Pending Requests; кликните правой кнопкой по данному сертификату и выберите All Tasks | Issue.

После его издания, его следует экспортировать и выполнить его импорт в свой издающий CA:

certreq -retrieve 2 "C:\REBEL-CA1.rebeladmin.com_REBELAdmin_IssuingCA.crt"
 	   

Наша предыдущая команда выполнит экспорт соответствующего сертификата. Значение числа 2 это величина request ID в MMC (Microsoft Management Console) CA.

По завершению экспорта переместите полученный файл в свой издающий CA и в нём запустите приводимую ниже команду. Она выполнит импорт данного сертификата и запустит данную службу:

Certutil –installcert "C:\REBEL-CA1.rebeladmin.com_REBELAdmin_IssuingCA.crt"
start-service certsvc
 	   

Аналогично варианту с нашим корневым CA после первоначальной установки его службы нам требуется задать некие значения настройки.

Местоположения CDP

Установка местоположения CDP аналогична настройке нашего корневого CA и я намерен применять для этого уже созданное веб- местоположение:

certutil -setreg CA\CRLPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%3%8%9.crl\n2:http://crt.rebeladmin.com/CertEnroll/%3%8%9.crl\n3:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10"
 	   

Местоположения AIA

Местоположения AIA также можно определить при помощи приводимой далее команды:

certutil -setreg CA\CACertPublicationURLs "1:%WINDIR%\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://crt.rebeladmin.com/CertEnroll/%1_%3%4.crt\n3:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"
 	   

Временные рамки CA и CRL

Пределы временных значений CA и CRL также следует отрегулировать. Это можно сделать применив следующие команды:

certutil -setreg CA\CRLPeriodUnits 7
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriodUnits 3
certutil -setreg CA\CRLOverlapPeriod "Days"
certutil -setreg CA\CRLDeltaPeriodUnits 0
certutil -setreg ca\ValidityPeriodUnits 3
certutil -setreg ca\ValidityPeriod "Years"
 	   

Когда всё это сделано, чтобы завершить данную настройку перезапустите свою службу сертификации воспользовавшись такой командой:

restart-service certsvc
 	   

И последнее, но не в отношении его значимости, для выработки необходимого CRL исполните ещё одну команду:

certutil -crl
 	   

Когда это всё сделано, мы можем запустить PKIView.msc для проверки своей настройки:

Теперь у нас имеется рабочая PKI и мы можем выключить свой обособленный корневой CA. Его следует подключать в сеть только когда истечёт срок действия сертификатов издающего CA или скомпрометирована сама PKI.

Наши CA поставляются с предварительно заданными Certificate Templates (Шаблонами сертификатов). Их можно применять для построения индивидуальных шаблонов сертификатов в соответствии с имеющимися организационными требованиями и могут публиковаться в AD.

Шаблоны сертификатов CA доступны из MMC Certificate Templates. Доступ к ним можно получить через Run | MMC | File | Add/Remove Snap-in... | Certificate Templates.

Для создания некого индивидуального шаблона кликните правой кнопкой по шаблону и нажмите на Duplicate Template:

Это откроет окно Properties, в котором вы можете изменить имеющиеся установки данного шаблона сертификата для соответствия имеющимся требованиям. Перечислим некоторые распространённые настройки в шаблоне:

После того как наш шаблон готов, нам требуется его издать. Затем все участники домена способны запрашивать сертификаты на его основании.

Для этого проследуйте в Certification Authority MMC | Certificate Templates, а затем кликните правой кнопкой и выберите New | Certificate Template to Issue.

После этого из полученного перечня выберите подходящий шаблон для издания и кликните по OK:

Теперь у на имеется новый шаблон сертификата. Наш следующий шаг состоит в запросе сертификата на основе созданного нами нового шаблона.

На основании опубликованных шаблонов сертификатов пользователи могут запрашивать сертификаты у издающего CA. Мне придётся зарегистрироваться в качестве конечного пользователя ПК и я намерен запросить сертификат на основании того шаблона, который мы создали на своём предыдущем шагу.

Для этого пройдите в Run, наберите MMC, Add/Remove Snap-in... | Certificates и кликните по кнопке Add.

Из полученного перечня выберите необходимую учётную запись компьютера, для которой вы желаете управлять сертификатами соответствующего объекта компьютера. Это зависит от имеющегося шаблона. После его выбора в следующем окне выберите в качестве цели Local computer.

После загрузки MMC проследуйте в её контейнер Personal, кликните правой кнопкой и затем проследуйте в All Tasks | Request New Certificate.

Это откроет новое окно; кликайте по Next пока не достигните окна Request Certificates. В нём вы можете обнаружить наш новый сертификат. Кликните по блоку пометки для выбора необходимого шаблона сертификата, а затем кликните по ссылке со знаком предостережения для предоставления дополнительных сведений которые требуются для данного сертификата:

Затем предоставьте для всех необходимых полей значения и кликните по OK для продолжения. В большинстве случаев то что требуется, так это Common name:

После завершения этого кликните по Enroll для запроса необходимого сертификата. Затем это автоматически обработает запрос сертификата и издание этого сертификата. После его выпуска, он может быт найден в установленном контейнере Personal | Certificate:

Как и ожидалось, мы можем видеть что был выпущен допустимый сертификат. Сведения об этом изданном сертификате могут быть найдены в MMC издающего CA Certification Authority далее Issued Certificate.

В этом примере вы изучили как настроить двухуровневую PKI с нуля. После такой настройки, как и для прочих систем, для поддержки жизнеспособности имеющейся системы необходимо сопровождение. Также важно обладать надлежащей документацией относительно имеющейся настройки совместно с шаблонами сертификатов и процедурами для успешного издания, обновления и отзыва сертификатов.

Цифровые сертификаты всё больше и больше применяются в современной инфраструктуре как дополнительные уровни безопасности для доказательства подлинности таких объектов и служб. В этой главе вы изучили что представляет из себя PKI и как в точности они работают. Затем мы рассмотрели компоненты AD CS и их роли. После этого мы перешли к планированию некой PKI и обсудили что требуется принимать во внимание при построении PKI. Затем мы и дальше рассматривали модели развёртывание PKI и оценили их преимущества и недостатки. И последнее, но не в отношении значимости, мы прошлись по пошаговому руководству настройки двухуровневой PKI.

В своей следующей главе мы намерены изучить другую роль службы AD - Службу федерализации AD - и увидим как выполнять идентификацию и обработку в некой федеративной среде.