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

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

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

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

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

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

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

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

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

Теперь в этом случае Sean шифрует необходимые сведения применяя свой частный ключ вместо общедоступного ключа Chris. Единственный ключ, при помощи которого эти сведения могут быть расшифрованы это общедоступный ключ 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, Центром сертификации), который может являться доверенным со стороны необходимого получателя. Такой цифровой сертификат будет содержать значение общедоступного ключа того объекта, для которого он был выпущен. Наш получатель может изъять значение общедоступного ключа соответствующего объекта или той службы, к которой он выполняет доступ через некий цифровой сертификат и его можно проверить в обладающем доверием центре.

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

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

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

Сертификаты обычно выпускаются CA (Центрами сертификации), только если они не являются самостоятельно подписываемыми (self-signed Certificate). Давайте двинемся далее и рассмотрим различные типы авторизации сертификатов.

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

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

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

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

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

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

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

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

Теперь мы знаем что способны выполнять сертификаты. В своём следующем разделе мы намерены пройтись по компонентам и ролям AD CS/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все эти разнообразные требования определяются установленной политикой Центра сертификации и он издаёт подходящие шаблоны и процедуры для прочих Центров сертификации:

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

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

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

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

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

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

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

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

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

Add-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
 	   

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

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

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

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

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

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

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

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

В своей демонстрации я намерен применять тот же самый издающий Центр сертификации что и для местоположения 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, с вышеупомянутым нами путём:

После этого загружаем необходимый диспетчер Internet Information Services (IIS) и добавляем виртуальный каталог, 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"
 	   

Предыдущую команду необходимо выполнить в самом корне сервера Центра сертификации.

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

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

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

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

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

Таблица 13-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

После того как настройки CDP размещены, наш следующий шаг состоит в ом что мы двинемся далее и настроим местоположения AIA.

AIA это некое расширение, которое имеется в данном сертификате и определяется тем местоположением из которого данное приложение или эта служба может получать данный издаваемый сертификат Центра сертификации. Это также путь на основе веб и мы можем применять то же самое местоположение, которое мы применяем для своего 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 с несколькими небольшими изменениями:

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

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

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

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

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, который будет выработан с помощью такой команды:

certutil -crl
 	   

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

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

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

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

Нашу предыдущую команду необходимо выполнить из приглашения командной строки (PowerShell). В этой демонстрации я скопировал соответствующий файл в устройство C:\ и выполнил эту команду в том же самом пути:

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

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

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

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

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

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

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"
 	   

После определения местоположений CDP наш следующий шаг состоит в обновлении настроек местоположения 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"
 	   

После этого, нашим следующим шаг конфигурирования является обновление временных пределов Центра сертификации и CRL.

Пределы временных значений Центра сертификации и 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 для проверки своей настройки:

PKIView.msc впервые был введён в Windows Server 2003 и оно предоставляет визуализацию конфигурации инфраструктуры общедоступных ключей (PKI) предприятия. Оно также проверяет имеющиеся сертификаты и CRL для каждого Центра сертификации.

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

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

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

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

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

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

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

Расширенная поддержка Windows Server 2008 R2 завершилась 14 января 2020 года.

Это вызвало интерес к переносу различных ролей Windows Server с Windows Server 2008 R2 на последнюю версию.

Я подумал, что было бы полезно включить шаги по переносу ролей AD CS с Windows Server 2008 R2 на Windows Server 2022. Мы также можем применять эти же шаги для переноса роли AD CS с Windows Server 2012/2012R2/2016/2019.

Наша следующая схема показывает демонстрационную среду, которую я буду применять для этой конкретной задачи:

Как это отражено на нашей предыдущей схеме, в своей демонстрационной среде я обладаю 4 серверами/ ПК. Роль каждого из серверов/ ПК такова:

Таблица 13-8. Роли серверов/ ПК демонстрационной среды

Имя хоста	Операционная система	Роль
REBEL-PDC01	Windows Server 2022	Первичный Контроллер домена в домене Active Directory rebeladmin.com.
W08CS	Windows Server 2008 R2	Имеющийся Центр сертификации.
W22CS	Windows Server 2022	После миграции конфигурации AD CS этот сервер превратится в Центр сертификации в rebeladmin.com.
PC01	Windows 10	Тестовый ПК.

В данном случае план будет состоять в миграции конфигурации AD CS из имеющегося Центра сертификации на базе Windows Server 2008 R2 во вновь построенный сервер с Windows Server 2022. Для целей данной демонстрации наш текущий Центр сертификации развёрнут с применением модели с единственным уровнем, что означает, что единственный сервер будет работать как корневой Центр сертификации, так и как выпускающий Центр сертификации. Собственно процесс миграции в целом состоит из таких шагов:

Давайте двинемся далее и начнём свой процесс с экспорта конфигурации имеющегося Центра сертификации из своего сервера W08CS.

Существуют два способа экспорта базы данных Центра сертификации и частного ключа из имеющегося Центра сертификации Windows Server 2008 R2:

Из Windows Server 2012 для резервного копирования имеющейся конфигурации Центра сертификации мы также можем воспользоваться командлетом PowerShell Backup-CARoleService.

В данной демонстрации я намерен воспользоваться утилитой командной строки certutil в качестве Администратора домена. Для этого выполните такие шаги:

Теперь, когда у нас имеется сохранённой соответствующая резервная копия, прежде чем мы импортируем её в свой новый сервер, нам необходимо удалить роль AD CS из своего имеющегося сервера Центра сертификации. Удалим эту роль AD CS из Windows Server 2008 R2.

Для удаления роли AD CS выполните следующие шаги:

После копирования папки резервной копии мы также можем выключить и удалить свой старый сервер Центра сертификации из своего домена.

Наш следующий шаг настройки состоит в установке роли AD CS в своём новом Windows Server 2022 (W22CS). Для осуществления этого выполните такую последовательность:

Это установит необходимую роль AD CS в нашем сервере. Однако перед её применением нам требуется восстановить имеющуюся конфигурацию.

Теперь, когда у нас имеется установленной в новом Windows 2022 сервере роль AD CS, мы можем восстановить свою резервную копию AD CS при помощи одного из следующих методов:

Для этой демонстрации я намерен восстановить имеющуюся резервную копию при помощи командлета PowerShell Restore-CARoleService. Однако перед этим нам сначала необходимо настроить свою роль AD CS при помощи имеющегося сертификата. Для этого выполните такую последовательность:

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

В своей демонстрационной среде мы применяем компьютер Windows 10 (PC01). Этот компьютер уже обладает сертификатом, выпущенным нашим предыдущим Центром сертификации Windows Server 2008 R2. Я проследовал далее и зарегистрировался в PC01 и открыл Консоль управления (mmc) сертификатами. Здесь я могу наблюдать уже имеющийся сертификат и он отображается как допустимый сертификат:

Я также проверил все сертификаты из Certificate Authority | Issued Certificates и я способен наблюдать здесь тот же самый сертификат. Это означает, что наша предыдущая конфигурация Центра сертификации мигрировала в наш новый Центр сертификации.

В Центре сертификации Windows Server 2008 R2 у меня имелся индивидуальный шаблон сертификата, созданный для компьютеров. Из PC01 я двинулся далее и запросил новый сертификат на компьютер. Как и ожидалось, я всё ещё могу наблюдать созданный мною ранее такой шаблон сертификата:

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

После выполнения процесса регистрации я прошёл в свою Консоль управления (mmc) Certificate Authority | Issued Certificate в сервере W19CS. Здесь я могу наблюдать только что созданный сертификат:

Как мы можем заключить отсюда, наш новый Центр сертификации работает ожидаемым образом и уже обладает конфигурацией предыдущего Центра сертификации. Это завершает наш процесс миграции AD CS и, в своём следующем разделе, мы собираемся взглянуть на резервное копирование Центра сертификации и disaster recovery (DR, восстановление после сбоев).

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