Глава 4. Работа с сертификатами

Самый первый барьер, который необходимо преодолеть когда вы хотите начать работу с сертификатами, состоит в помещении такого сервера на место. Существует множество справедливых вопросов на которые необходимо ответить. Нужен ли вам выделенный сервер для этой задачи? Мог ли я совмещать эту роль на существующем сервере? Нужно ли мне устанавливать Корпоративный (Enterprise) или автономного (stand-alone) CA (Органа сертификации)? Я слышал термин отключённого (offline) корня, но что он означает? Давайте начнём с основ и предположим, что вам нужно построить самый первый сервер CA в вашем окружении.

В сетевой среде домена AD наиболее полезными серверами CA является разновидность Корпоративных (Enterprise). Серверы корпоративного CA интегрированы с AD, что делает их видимыми для машин в такой сетевой среде и автоматически заслуживают доверие (trusted) у компьютеров, которые присоединены к данному домену. Существуют различные мнения по природе наилучшего использования при установке последовательностей серверов CA. Например, существует хорошее руководство тестовой лаборатории (ссылка на который приводится в конце данного рецепта), опубликованное Microsoft, которое проводит вас через настройку автономного (stand-alone) Корневого (Root) CA, Подчинённого Корпоративного (Subordinate Enterprise) CA, с последующим изъятием в выключенное состояние автономного корня (stand-alone root offline). Преимущество этого состоит в том, что сертификаты выпускаются из подчинённого CA, а не напрямую из корня и, тем самым, если ключи сертификата каким- то образом скомпрометированы в данном окружении, Корневой CA полностью отключён и недоступен с тем, чтобы быть скомпрометированным. В подобной ситуации вы можете вычистить Подчинённого и опубликованные им сертификаты, поднять отключённый Корень, построить нового Подчинённого и вернуться к делу публикации сертификатов без какой- бы то ни было повторной генерации нового сервера Корня CA.

С учётом предыдущего практического опыта, или как это определено тем или иным образом, удивительно, что я крайне редко вижу Корневой CA отключённым на практике. На самом деле, практически никогда. А в некоторых имевшихся у меня случаях наличие отключённого Корня CA вызывало проблемы. Просто для примера, при размещении инфраструктуры DirectAccess с возможностями одноразового пароля (OTP, one-time-password) в среде заказчика, было обнаружено, что чтобы заставить такие OTP работать правильно, отключённый Корень CA должен быть приведён назад в рабочее состояние. Это не было самым насущным интересом нашего варианта для создания PKI, и поэтому взамен мы реализовали вторую среду сертификата с автономным корнем и и двумя промежуточными чтобы поддерживать отключённым Корень CA для данной цели сертификатов OTP. Это вызвало большие задержки в нашем проекте, так как мы должны были построить три новых сервера, необходимых просто для получения публикации сертификатов правильным образом, что впоследствии привело к намного более сложной инфраструктуре сертификации.

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

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

Я создал новый Windows Server 2016 с именем CA1, причём он является участником домена, на котором мы будем включать нашу новую инфраструктуру сертификации.

Чтобы установить Службы сертификации AD (Active Directory Certificate Services) на вашем Server 2016, воспользуйтесь следующим набором инструкций:

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

Существует пара моментов, которые не были охвачены в данном рецепте и которые следует отметить. Следование приведённым шагам приведёт ваш сервер CA в запущенное и рабочее состояние, которое будет готово к выпуску сертификатов, это несомненно так. Остальные рецепты в данной главе отражают построение CA в точности как показано здесь. Однако, существуют дополнительные шаги, которые могут быть предприняты чтобы и далее персонализировать ваши настройки CA если вам это нужно. Если вы планируете выпускать сертификат SSL для вебсайтов, в особенности, если вы планируете устанавливать эти сертификаты на веб серверы, повёрнутые в сторону всемирного Интернета, тогда вам необходимо ознакомиться с настройками CRL (Certificate Revocation List, Списка отозванных сертификатов). При каждом доступе к сертификату компьютер клиента проверяется в CRL чтобы гарантировать, что данный сертификат всё ещё действует. Если сертификат не действительный, или мошеннический в каком- либо виде, проверка CRL определит эту скомпрометированность и запретит такое соединение. В частности, при публикации вебсайтов в Интернет, которые применяют сертификаты, выпускаемые вашим внутренним PKI, вам придётся планировать публикацию вашего CRL с тем, чтобы компьютеры внешних клиентов могли осуществлять к нему доступ свободным, безопасным образом. Вот прекрасная ссылка, с которой вы можете начать изучать информацию CRL: http://technet.microsoft.com/en-us/library/cc771079.aspx.

Второй фрагмент информации, которую я бы хотел отметить это файл CAPolicy.inf. Именно этот файл можно заполнять различными персональными настройками для вашего сервера CA, такими как период действия вашего корневого сертификата, информация об CRL, а также хотите вы или нет чтобы шаблоны сертификатов по умолчанию загружались в процессе установки роли CA. Если какие- либо из этих настроек представляют для вас интерес, вы просто создаёте файл CAPolicy.inf с соответствующими настройками и помещаете вовнутрь C:\Windows в вашем сервере CA перед установкой роли. Мастер установки роли затем применит эти настройки внутри данного файла в процессе установки роли и присоединит ваши персональные установки. Если вы не применяете один из этих файлов, это неплохо, и ваша роль будет установлена с некоторыми настройками по умолчанию на своих местах, в точности как это имело место в данном рецепте. Однако, если вы заинтересованы в изменении некоторых из них, ознакомьтесь с данной ссылкой для получения дополнительной информации по файлу CAPolicy.inf: http://technet.microsoft.com/en-us/library/jj125373.aspx.

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

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

В действительности мы строим Подчинённый (Subordinate) CA не с целью избыточности, как это имеет место для многих прочих видов серверов, а потому что существует множество особенных задач, которые вы можете пожелать выполнить в Подчинённом CA, в отличие от Корня (Root) CA. Если вы выпускаете большое число сертификатов или различные виды сертификатов, вы можете захотеть установить различие между серверами CA при выпуске. Возможно, вы пожелаете, чтобы машины, которые применяются для сертификатов IPsec выпускались из IPSEC-CA, в то время как выпускаемые вами SSL сертификаты вебсайта должны быть представляться с WEB-CA. Вместо того, чтобы строить два независимых Корня CA, которые оба имели бы права верхнего уровня, вы должны рассмотреть создание отдельного Корня CA, возможно, с именем ROOT-CA и поместить эти два сервера CA в подчинённую роль под такой Корень CA в цепочку. Это может быть также полезно для географически распределённых сетевых сред, имеющих Подчинённые серверы CA, выделенные для назначения сертификатов различным офисам или регионам.

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

Мы находимся внутри сетевого домена и имеем поднятым и работающим отдельный Корпоративный Корень (Enterprise Root) CA. Теперь нам требуется некий дополнительный сервер, который будет присоединён к нашей среде CA в качестве нового Подчинённого (Subordinate) CA.

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

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

Рецепт Настройка первого сервера Сертификационной авторизации в сети

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

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

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

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

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

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

Мы собираемся воспользоваться нашей машиной Windows Server 2016, которая является нашим Корпоративным Корнем (Enterprise Root) CA.

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

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

Наиболее распространённый способ, который я наблюдаю в качестве взаимодействия администраторов со всеми сертификатами в их системах состоит в инструменте оснастки MMC. MMC является сокращением (Microsoft Management Console, Консоль управления Microsoft), а применяя MMC вы можете выполнять администрирование практически всем в своей операционной системе. Хотя возможно это чрезвычайно незаслуженно обходимый вниманием инструмент, я обычно вижу его открытым для некоторых избранных задач. Запрос сертификатов является одной из таких задач.

Мы собираемся применять консоль MMC в своём новом сервере, который имеется в нашей сетевой среде. Существует новый шаблон сертификата, который мы создали, а также мы бы хотели выпустить один из этих сертификатов для нашего нового веб- сервера.

Сервер Корпоративного Корня (Enterprise Root) CA, Server 2016, запущен и работает в нашей сетевой среде. На нём мы должны настроить новый шаблон сертификата с названием IPsec Certificate. Необходимо выполнить шаги для публикации этого шаблона с тем, чтобы его можно было запрашивать с компьютеров в нашей сетевой среде. Теперь мы работаем с нового именованного веб сервера, который также исполняется под Server 2016 и присоединён к нашему домену, где мы собираемся выполнить необходимую работу запроса вручную некоторого сертификата со своего сервера CA.

Для запроса нового сертификата при помощи консоли MMC выполните следующие шаги:

Применение консоли MMC является быстрым и простым способом запроса нового сертификата, выпускаемого вручную. В любой среде Active Directory будет доступен для просмотра и регистрации любой шаблон сертификата на вашем сервере CA, на который у вас имеются полномочия для регистрации (enroll). Наш сегодняшний пример отображает процесс регистрации для сертификата машины, который мы планируем применять в будущем для аутентификации IPsec. Однако, существует множество вариантов использования, при которых вы можете пожелать выпуск сертификатов уровня пользователя вместо сертификатов компьютера. В этих случаях вам понадобится оснастка сертификатов учётных записей Пользователя в том месте нашего примера, где мы определяем сертификаты учётных записей компьютера.

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

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

Нашим Корпоративным Корнем (Enterprise Root) CA является Windows Server 2016, который имеет установленную роль Служб Сертификации AD (Active Directory Certificate Services). Когда мы установили и настроили эту роль, мы проверили, что выбрали опцию для веб служб с тем, чтобы применять её для запроса нового сертификата.

Мы не обязаны быть зарегистрированы напрямую в сервере CA для выполнения данной работы. Вместо этого мы регистрируемся в некотором новом веб сервере в нашей среде. Находясь в таком веб сервере мы выполняем следующие шаги:

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

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

Множество новых технологий требуют применения сертификатов для аутентификации, запрашивая такие сертификаты для распространения в больших масштабах. Например, если мы хотим применять подобную сертификацию Компьютеров для аутентификации DirectAccess, нам необходимо выпускать некий сертификат для каждого клиентского компьютера DirectAccess. Это могут быть тысячи ноутбуком в нашей сетевой среде. Если мы желаем начать шифровать обмен внутри своей сетевой среды при помощи IPsec и требовать распространения сертификатов для этой цели, вам потенциально понадобится выпустить некий вид сертификационной машины для каждого компьютера внутри вашей сетевой среды. Хотя вы, несомненно, можете выдавать каждый сертификат вручную с применением консоли MMC или через веб интерфейс CA, это не звучит как нечто, доставляющее удовольствие.

Введите Autoenrollment. Мы можем включить эту функциональность, которая является неким видом зеркального отражения коммутации в Active Directory, и сделав это мы можем запросить AD автоматически выпускать сертификаты для своих компьютеров, даже если нам нужно получать их для каждого отдельного домена присоединённого к вашей системе. Давайте совместно пройдём этот рецепт чтобы включить данную опцию и проверить её.

Мы работаем внутри некоего Windows Server 2016 на основе домена Active Directory. У нас также имеется Корпоративный Корень (Enterprise Root) CA Server 2016, работающий в данной сети. Работа, которую мы будем выполнять состоит в комбинации работы с вашим сервером CA и работой внутри Групповой политики в Контроллере Домена.

Чтобы включить в вашем домене Autoenrollment (Автоматическую регистрацию), просмотрите следующие инструкции:

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

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

После настройки этих установок, если вы перезагрузите несколько подключённых к домену машинв своей сетевой среде, вы заметите, что когда они вернутся назад в рабочее состояние, будут присутствовать новые сертификаты, расположенные в хранилище персональных сертификатов компьютеров. Присядьте и подождите несколько часов, и они накатятся на всех автоматически. Если вам не нравится ожидать обновления Групповой политики, вы можете открыть приглашение командной строки в одном из этих компьютеров и выполнить команду gpupdate /force для обновления политик вручную и установки на место данного сертификата.

Помните, какое-то время тому назад, мы настраивали самый первый сервер CA, а именно Корпоративный Корень (Enterprise Root)? Мы оставили многие из параметров на их местах со значениями по умолчанию, и это означало, что наш сертификат корня устанавливался автоматически с периодом действия в пять лет. Это выглядит достаточно продолжительным сроком, однако пять лет могут пролететь за миг, в особенности если у вас есть дети. итак, что же случится когда сертификат корня наконец истечёт? Случатся плохие вещи. Несомненно, вы захотите отследить дату истечения срока вашего корневого сертификата и поторопиться обновить его до того, как закончится срок действия!

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

Чтобы обновить сертификат корня CA выполните следующие шаги:

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

Однако - и это является ЗНАЧИТЕЛЬНЫМ однако - если вы позволите вашему сертификату авторизации корня превысить срок действия, а вы выпустили сертификаты, которые применяются клиентами и серверами для сетевой аутентификации, истечение срока действия сертификата корня будет означать, что такие системы больше на смогут подключаться в вашу сетевую среду. Вы можете легко обновить свой сертификат корня и привести сервер во включённое и работающее состояние, однако, не имея действующего метода аутентификации в вашей сетевой среде, ваши системы, которые полагаются на действующий сертификат для соединения с такой сетью сядут на мель. Вам придётся искать альтернативный способ присоединения их в свою сетевую среду и обновления их Групповой политики прежде чем они изучат как доверять вновь обновлённому сертификату авторизации корня. Это предостережение приходит мне на ум, поскольку я только что помогал некоей компании воевать в точности с этой проблемой. Срок действия их сертификата корня истёк, и они имели целые офисы, полные персонала, который был подключён к их центру обработки данных и их домену исключительно через технологию удалённого соединения DirectAccess. DirectAccess полагается на сертификаты как на часть своего процесса аутентификации, поэтому такие удалённые системы полностью утратили возможность подключения к своей сетевой среде, раз уж срок действия их сертификата корня истёк. нам пришлось подключать их к сети различными путями чтобы поместить установки GPO и новую копию нового сертификата корня на место прежде чем начать удалённое соединение вновь.

Мораль этой истории: не забывайте отмечать в календарях необходимость обновления сертификатов ДО истечения их срока действия!