Глава 4. Сертификаты в Windows Server 2019

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

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

Смарт карты также могут храниться виртуально, в рамках специального места на новых машинах, называемых TPM {Прим. пер.: Transaction Processing Monitor, Монитор управления транзакциями}, однако это отдельная тема для обсуждения в другое время. Причина, по которой мы упомянули смарт карты здесь состоит в том, что основной составляющей функциональности аутентификации такой смарт карты обеспечивается неким сертификатом пользователя, хранимом на этой смарт карте.

Другой приобретающей популярность формой аутентификации являются одноразовые пароли (OTP, one-time-passwords, = динамически изменяемые пароли). Он требует от пользователя ввода случайно создаваемого номера в дополнение к их обычным параметрам регистрации и в некоторых случаях, когда пользователи вводят свой пин-код, выпускаются временные пользовательские сертификаты, которые применяются в качестве части цепи сертификации. Ещё и третье место, в котором пользовательские сертификаты находят общее применение состоит в случае, когда компании применяют технологии шифрования, например EFS (аббревиатура от Encrypting File System), или даже при построении систем с VPN (virtual private network) для разрешения удалённым пользователям подключать их ноутбуки обратно к имеющейся корпоративной сетевой среде. Многие компании не желают в явном виде полагаться на имя пользователя и пароль для аутентификации VPN, а следовательно выпуск сертификатов пользователя и требования того чтобы они присутствовали при построении такого туннеля VPN является общим местом.

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

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

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

Давайте рассмотрим быстрый пример. Скажем, один из ваших пользователей находится в кофейне и применяет её общедоступный Wi-Fi. Некий атакующий вас вычисляет способ обработки DNS в такой сетевой среде Wi-Fi и поэтому когда пользователь пытается посетить mail.contoso.com чтобы осуществить доступ к своему Outlook Web Access, такой злоумышленник перехватывает весь этот обмен и такой пользователь теперь сидит в вебсайте, который выглядит как портал его компании, однако в действительности это вебсайт размещаемый самим таким злоумышленником. Наш пользователь набирает своё имя пользователя и пароль и, ура, злоумышленник теперь имеет эти полномочия и может применять их для доступа в вашу реальную сетевую среду. Что предотвращает от того, чтобы это происходило каждый день в реальном мире? сертификаты SSL. Когда вы заставляете свой развёрнутые вовне вебсайты, наподобие страниц регистрации в электронной почте, выступать в роли сайтов HTTPS, это требует от браузеры клиентов проверять сертификат SSL , который представляет подобный сайт. Такой SSL сертификат содержит информацию, которую может иметь только ваша организация, он не может быть подделан. Таким образом, когда когда ваш пользователь осуществляет доступ к действительной странице регистрации, ваш браузер проверяет данный сертификат SSL, определяет его корректность и просто продолжает идти своим чередом. Такие пользователи даже никогда не знают, что они защищены за исключением маленького блокирующего символа рядом с адресным полем в своём браузере. С другой стороны, если их обмен был перехвачен и перенаправлен на подставной вебсайт, подобная проверка сертификата SSL получит отказ (так как сам атакующий не имеет допустимого сертификата SSL для вебсайта с названием вашей компании) и пользователь будет остановлен в своих маршрутах, по крайней мере, он прочтёт предупреждающее сообщение перед тем как будет способен продолжить. В этом месте пользователь должен притормозить и понять что что- то идёт не так как нужно, связаться со своим обслуживающим персоналом ИТ для решения данной проблемы.

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

Когда некая компания получает какой- то сертификат от одного из таких общедоступных центров авторизации, происходит глубокий процесс проверки, который данный орган берёт на себя с целью удостовериться что то лицо, которое запросило данный сертификат (вы) на самом деле некто из соответствующей компании и уполномочены на выдачу таких сертификатов. Именно это составляет основу безопасности применения сертиыикатов SSK от некого общедоступного CA. Все новые системы по умолчанию знают как взаимодействовать с выпускаемыми этими организациями сертификатами и у вас нет необходимости предпринимать некие специальные действия для выполнения своих функций вебсайтов во всемирном Интернете. С другой стороны, существует возможность выпуска сертификатов SSL от некоторого сервера CA, который работает внутри вашей сетевой среды, однако это требует пары вещей, которые делают это трудным. Во- первых, если вы желаете свой собственный сертификат для общедоступного вебсайта, вам необходимо воплотить по крайней мере ЧАСТЬ вашЕЙ внутренний PKI, называемую CRL (Certificate Revocation List, Список отозванных сертификатов) во всемирном Интернете. Всякий раз, когда вы берёте некий являющийся внутренним для вашей сетевой среды компонент и публикуете его во всемирном Интернете, вы вносите риск в безопасность и поэтому пока вам это не является абсолютно необходимым, лучше от этого воздерживаться. Вторая причина состоит именно в трудности применения ваших собственных сертификатов для общедоступных вебсайтов, поскольку только ваши собственные компьютеры будут знать что можно доверять таким сертификатам SSL. Поэтому, если некий пользователь принесёт ноутбук своей компании домой и применит его для доступа к своей странице регистрации электронной почты, он, скорее всего, будет работать нормально. Однако если он попробует осуществить доступ к той же самой странице регистрации в электронной почте со своего домашненго компьютера, который не является частью вашего домена или сетевой среды, он получил бы предупреждающее сообщение о сертификате и должен предпринять специальные шаги для получения доступа к такому вебсайту. Что является головной болью для пользователей. Вам никогда не следует поощрять пользователей к принятию риска прохождения через предупредительное сообщение о сертификате - именно это составляет некий рецепт для катастрофы,даже если тот сертификат, через который они проходят кликнув выпущен вашим собственным CA. Это принципиальный момент - никогда не подвергать себя подобному риску.

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

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

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

Сертификаты отдельного имени

Это наиболее экономичный и наиболее общий маршрут выбираемый при приобретении некоторого сертификата для персонального вебсайта. Сертификат отдельного имени защищает и содержит информацию об одном отдельном имени DNS. Когда вы настраиваете некий новый вебсайт на portal.contoso.com и вы желаете защитить некоторый обмен с применением HTTPS, вы будете устанавливать некий SSL сертификат на такой вебсайт. Когда вы запросите у своей сертифицирующей организации такой новый сертификат, вы введёте определённое имя portal.contoso.com в соответствующее поле Common name своей формы запроса. Такое отдельное имя является единственным именем, кторое может защищаться и подтверждаться данным сертификатом.

Сертификаты Рубрикатора альтернативного имени

Сертификаты Рубрикатора альтернативного имени (SAN Subject Alternative Name) обычно стоят чуть дороже чем сертификат отдельного имени, так как имеют больше возможностей. Когла вы запрашиваете сертификат SAN, у вас существует вариант определения множетсва DNS имён, которые этот сертификат может защищать. Будучи выпущенным единожды, такой сертификат SAN будет содержать некое первичное имя DNS, которое обычно является главным именем вашего вебсайта и далее внутри свойств такого сертификата вы найдёте список дополнительных имён DNS, которые могут быть установлены на веб сервер и применяться для подтверждения обена для любого из списка имён DNS, находящихся внутри этого сертификата. Примером использования сертификата SAN из практики является настройка сервера Lync {Прим. пер.: Skype}. Lync использует множество различных DNS имён, однако все эти имена находятся внутри одного и того же домена DNS. Важно сделать замечание относительно сертификата SAN, что все имена должны быть частью одного и того же домена или субдомена. Вот пример списка имён, которые мы можем включить в сертификат SAN для целей Lync:

Эти различные вебсайты/ службы, применяемые Lync затем реализуются через один или множество серверов и вы можете применять один и тот же сертификат SAN на всех этих серверах для удоставерения обмена, который направляется к одному из этих имён DNS.

Сертификаты группового символа

Последний, но несомненно не менее важный это сертификат группового символа. Это люксовая модель, именно тот сертификат, который имеет больше всего возможностей, причём предоставляет вам наибольшую гибкость и, в то же самое время, самый простой путь реализации множества серверов. Имя в некотором сертификате группового символа (wildcard) начинается с символа звёздочки (*). Такая звезда означает любой, поскольку все предшествующие данному DNS имени домена охватываются данным сертификатом. Если вы владелец contoso.com и планируете устанавливать множество общедоступных записей DNS, которые будут протекать ко множеству различных вебсайтов и веб серверов, вы можете приобрести отдельный сертификат с групповым символом с именем *.contoso.com и он может покрыть все ваши потребности сертификации.

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

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

Так как в данной книге наши обсуждения вращаются вокруг Windows Server 2019, это естественно означает, что ваш сервер CA может и должен быть представлен этими самыми последними и самыми выдающимися операционными системами. Как и для большинства возможностей в Server 2019, создание сервера Центра сертификации в вашей сетевой среде настолько же проста, насколько проста установка роли Windows. Когда вы переходите к добавлению роли для нового сервера, это самая первая роль в перечне с названием Active Directory Certificate Services (AD CS). После установки этой роли вам будет предоставлена пара важных параметров и вы должны понимать назначение этих параметров до того как создадите солидную среду PKI.

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

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

Для целей нашей лаборатории и чтобы обсудить необходимые для большинства бизнесов с размером от малого до среднего возможности, я намерен выбрать только две показанные ранее на снимке экрана возможности: Certification Authority и Certification Authority Web Enrollment.

Следуя за установкой вашей роли AD CS, Диспетчер сервера уведомит вас, что службам сертификации требуются некие дополительные настройки, что обычно для большинства установок ролей. При настройке вашей роли CA для первого раза вам буде предоставлен большой выбор. Хотите ли вы чтобы ваш сервер был корпоративным CA (enterprise CA), либо автономным CA (standalone CA)?

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

Как вы можете подразумевать из предыдущего текста, это означает что автономный (standalone) CA менее распространён в дикой природе. Обособленные CA могут быть участниками домена, либо могут оставаться частью сетевой среды и оставаться в локальной рабочей группе. Если у вас имеются требования безопасности, которые выделяют ваш сервер сертификации, который не может быть подключённым в домен, это может служить причиной зачем бы вам использовать автономный (standalone) CA. Другой причиной может быть среда, в которой просто отсутствует Active Direсtory. В моих глазах это чрезвычайно редкое явление найти сетевую среду в которой некто пытается применять Windows Server 2019 в качестве своего Центра сертификации и в то же самое время не иметь работающих Служб домена Active Directory (AD DS), но я уверен, что где- то существует медвежий угол, который делает именно это. В таком случае вам также необходимо выбирать автономный CA. Третий пример, при котором вы могли бы выбрать автономный CA это уже упоминавшееся нами событие, при котором у вас имеется причина для отключения своего сервера. Когда вы исполняете такой сценарий он обычно называется имеющим отключённый корень (offline root). Мы пока ещё не обсуждали корень (root) CA, однако это произойдёт через минутку. Когда вы работаете с отключённым корнем, вы создаёте самый верхний уровень своей иерархии как автономный корень (stanalone root) CA, а затем выстраиваете под ним подчинённые (subordinate) CA. Ваши подчинённые CA является именно теми, кто выпускает реальные сертификаты, что означает, что корень может быть надёжно отключён. Зачем вы можете пожелать сделать это? Хорошо, большинство компаний этого не делают, однако в своей практике я встречаюсь с некоторыми компаниями, которые имеют политику безопасности очень высокого уровня, и именно эта причина лежит в основе того зачем вы можете с этим столкнуться. Если все сервера CA некоторой компании связаны воедино в качестве корпоративных CA, причём вся их информация хранится внутри Active Directory, в случае компрометации одного из подчинённых выпускающих CA может сулить беду всей вашей PKI. Может так случиться, что единственным способом восстановиться после нападения была бы полная очистка всей вашей среды PKI, всех ваших серверов CA с их повторным построением. Если вам придётся это делать, это может означать не просто повторное построение всех ваших серверов, но также и повторный выпуск принципиально новых копий всех ваших сертификатов для каждого имеющего их пользователя и устройства.

С другой стороны, если у вас имеется автономный корень (standalone root) CA, который был отключён, он не подвергся такой атаке. В таком случае, вы можете снести свои работающие сервера сертификации, в то время, как ваш основной сервер корня остался в целости. Затем вы можете ввести этот корень в строй снова, повторно отстроить подчинённые из него и получить простейший путь восстановить на 100% работоспособность, так как ваши ключи корня, которые хранятся внутри этого CA не нужно повторно выпускать.

Как я уже сказал, я не очень часто встречал такую реализацию на практике, однако она возможна. Если вам интересно изучить более подробно автономный корень CA и его применение, я настоятельно рекомендую ознакомиться со статьёй TechNet по адресу http://social.technet.microsoft.com/wiki/contents/articles/2900.offline-root-certificationauthority-ca.aspx {Прим. пер.: также см. рецепты самого автора в Главе 4, Работа с сертификатами его Книги рецептов.} Если вы задумались о том, чтобы двигаться дальше с автономным корневым CA только потому, что это кажется dfv более безопасным, но у вас нет особой причины для этого, я рекомендую сменить тему и продолжить работу с корневым CA в рабочем режиме. Хотя у автономного отключаемого корня есть некоторые преимущества в плане безопасности, большинство компаний не считают, что эти преимущества стоят дополнительных хлопот, которые сопровождают применение автономного корневого центра сертификации. Есть определенные компромиссы применимости при движении в этом направлении.

В большинстве случаев вы пожелаете остановиться на Enterprise CA и продолжать с ним.

Это второй существенный выбор, который вы должны сделать при псотроении нового CA. Собирается ли ваш новый сервер быть корнем CA (root CA) или подчинённым CA (subordinate CA)? В большинстве случаев, и даже в основной части документации Microsoft подчинённый CA чаще всего называется выпускающим CA. Как правило, в некоторой PKI со множеством уровней, именно подчинённый/ выпускающий CA является тем, кто выпускает сертификаты для пользователей и устройств в вашей сетевой среде.

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

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

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

На данный момент, когда вы теперь установили обсуждаемую роль, имеющееся имя этого хоста теперь высечено в граните. Вы уже знаете об этом. Однако если вы проходите по данному мастеру для настройки своего CA в первый раз, вы пройдёте и экран с названием Specify the name of the CA. Как? Разве я уже не установил имя для этого хоста?

Никак нет, мы сделали своё окончательное именование хоста и этого названия сервера подключённого к Active Directory в качестве моего подключённого к домену сервера, но реальное "CA Namr" это нечто иное. Это именно то название, которое будет указываться внутри всех свойств каждого сертификата, который выпускает данный CA. Это также то название, которое будет настраиваться в различных местах внутри Active Directory, так как я собираю Корпоративный CA. Ваш мастер самостоятельно укзывает некое возможное название для использования вами, которое многие администраторы просто берут и применяют. Если вы желаете ваше собственное название, именно здесь вы и можете это сделать. Если вы здесь установите своё название, это имя станет навсегда названием этого CA:

Поскольку данная роль официально называется ролью Служб сертификации AD (AD CS, Active Directory Certificate Services), означает ли это что я должен устанавливать данную роль на свои сервера контроллера домена? Нет! К сожалению, я работал во многих компаниях малого и среднего бизнеса, которые делали именно это, и по счастливой случайности они не имели слишком больших проблем. Так что, технически, это работает. Однако это не является рекомендуемым Microsoft путём и вам следует строить свои CA на их собственных серверах; попытайтесь сделать так, чтобы они по возможности не совмещали никакие свои роли с прочими.

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

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

Итак, опять, первое что мы должны сделать это запустить соответствующую консоль администрирования чтобы сделать свою работу. Внутри меню Tools в Диспетчере сервера пройдите далее и кликните на Certification Authority. Находясь внутри, вы можете раскрыть название своего Центра сертификации и увидеть ряд папок, включая одну внизу с названием Certificate Templates. Если вы кликните по этой папке, вы обнаружите перечень сертификатов, которые в настоящее время построены внутри нашего сервера CA. Так как мы не хотим применять ни один из таких предварительно построенных шаблонов, в общем случае мы могли бы кликнуть здесь правой кнопкой и создать новый шаблон, однако в действительности это не правильное место для создания нового шаблона. Причина по которой новые шаблоны сертификатов нельзя строить прямо здесь должно быть выше моего уровня оплаты, потому что это кажется глупым, что так делать нельзя, однако чтобы перейти во второй экран, в котором нам необходимо на самом деле управлять и изменять наши шаблоны, вам необходимо кликнуть правой кнопкой по Certificate Templates, а затем выбратьManage:

Теперь вы видите намного более обширный список шаблонов, включая некоторое число, которых мы не могли видеть в своём первом экране. Чтобы построить новый шаблон, то что мы хотим сделать, так это найти предварительно созданный шаблон, который работает аналогично цели, которую мы бы хотели, чтобы обслуживал наш новый шаблон сертификата. Шаблоны компьютера становятся наиболее широко выпускаемыми во многих организациях, из- за того, что всё больше и больше технологий требуют наличия таких сертификатов, тем не менее, раз мы говоримчто мы не хотим применять такие предварительно приготовленные шаблоны, которые просто называются Computer, потому что мы хотим чтобы наши шаблоны имели более определённое название и может быть мы хотим, чтобы период действия такого сертификата был длиннее чем имеющийся в наличии. Что мы делаем далее, кликаем правой кнопкой по встроенному шаблону Computer и нажимаем на Duplicate Template (Дублирование шаблона). Это откроет экран Properties для нашего нового шаблона, в котором первое, что мы хотим сделать - это присвоить своему новому шаблону уникальное имя внутри закладки General.

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

Если сертификат, который вы хотите выпускать требует какие- либо дополнительные изменения настроек, вы можете пройтись по оставшимся закладкам внутри свойств и выполнить необходимые регулировки. Для нашего примера, другая настройка, которую я изменю, находится внутри закладки Subject Name. Я хочу, чтобы мой новый сертификат имел название предмета, которое бы соответствовало общему имени данного компьютерадля которого он выпускается,поэтому я выбрал из ниспадающего перечня Common name:

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

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

Так как это всё что мне нужно внутри моего нового сертификата, я просто нажимаю на OK и мой новый сертификат теперь включён в перечень сертификатов в моём сервере CA.

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

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

Если ваша Certificate Templates Console всё ещё открыта, а она была тем местом, из которого мы управляли своими шабонами, вы можете пройти далее и закрыть её, чтобы мы могли вернуться назад в свою главную консоль центра сертификации. Помните, что мы отметили, что имеющийся перечень доступных шаблонов сертификатов отображаемый нам здесь намного короче? Это происходит потому, что только эти шаблоны сертификатов в настоящий момент опубликованы и доступны для выдачи. Чтобы добавить некоторые дополнительные шаблоны в этот перечень публикаций, включим наш новый, мы просто кликнем правой кнопкой по папке Certificate Templates и затем переместимся в New | Certificate Template to Issue:

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

Если вы просмотрите этот список и не обнаружите свой только что созданный шаблон, вы можете предпринять некий дополнительный шаг. Иногда достаточно просто подождать пока такое поведение разрешится самостоятельно, потому что может случиться, что ваш новый шаблон не отображается в данном списке потому что вы ожидаете пока ваши контроллеры домена закончат репликации. В других случаях вы обнаружите, что даже после такого ожидания ваш новый шаблон всё ещё остутствует в этом списке. В подобном случае вам возможно нужно просто перезапустить службу центра сертификации чтобы заставить её выбрать новую информацию о шаблоне. Чтобы перезапустить такую службу CA, вы кликаете правой кнопкой в названии CA рядом с вершиной своей консоли управления Certification Authority и перемещаетесь к All Tasks | Stop Service. Остановка данной службы обычно требует нескольких секунд, а затем вы можете немедленно кликнуть по данному имени CA вновь и в этот раз переместиться в All Tasks | Start Service. Теперь попробуйте опубликовать свой новый шаблон опять и вы должны обнаружить его в этом перечне:

Наш новый шаблон сертификата был создан, и мы успешно опубликовали его внутри своей консоли CA, тем самым сделав его официально готовым к выдаче. Время проверить его. Пройдите вперёд и зарегистрируйтесь на обычном компьютере клиента в вашей сетевой среде чтобы выполнить это. Существует пара стандартных способов, которые мы можем применять для запроса нового сертификанта на компьютере клиента. Первый состоит в использовании старой доброй консоли MMC. На вашем клиентском компьютере запустите MMCb и добавьте оснастку для Certificates. Когда вы выберете Certificates из списка доступных оснасток (snap-in) и кликните по кнопке Add; вам будут представлены некоторые дополнительные параметры для каких хранилищ сертификатов вы хотите открывать. Вы собираетесь сделать выбор между открытыми сертификатами для учётной записи пользователя, Service account илиComputer account. Так как мы собираемся выпустить сертификат, который будет применяться для самого компьютера, я хочу выбрать из этого списка Computer account и кликнуть Finish:

На следующей странице вновь кликните по кнопке Finish чтобы выбрать значение параметра по умолчанию, которым является Local computer. Это оснастит MMC хранилищем сертификатов вашей локальной машины на основе компьютеров.

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

Чтобы запросить новый сертификат с нашего сервера CA, мы просто кликнем правой кнопкой по папке Personal, а затем переместимся в All Tasks | Request New Certificate…. Выполнекние этого откроет мастер; пройдите далее и кликните один раз по кнопке Next.

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

Отображается экран Request Certificates, который яляется перечнем шаблонов доступных для нас. Этот список является динамически основывающимся на том компьютере, с которого вы зарегистрировались и под те полномочия, которыми обладает ваша учётная запись пользователя. Помните когда мы настраивали закладку безопасности нашего нового шаблона сертификатов? Именно тогда мы определили кто и что могут запрашивать это шаблон и если бы я определил более конкретную группу, нежели компьютеры домена, могло бы случиться так, что мой новый шаблон DirectAccess Machine не был бы отображён в данном списке. Однако, так как я открыл этот шаблон для выпуска любому компьютеру в рамках нашего домена, я могу видеть это:

Поместите маркер сразу за любым желаемым сертификатом и кликните по Enroll (Зарегистрировать). Теперь консоль будет крутиться несколько мгновений, пока сервер CA обрабатывает ваш запрос и выпускает новый сертификат который будет специфичным для вашего компьютера и тех критериев, которые мы поместили внутри своего шаблона сертификата. После завершения, вы сможете теперь увидеть совершенно новый сертификат машины внутри Personal | Certificates в своём MMC. Если вы кликните дважы по этому сертификату, вы сможете проверить его свойства, чтобы гарантировать, что что все нужные вам настройки были помещены в этот сертификат:

Обычно всякий раз, когда это возможно, я применяю MMC для запроса сертификатов, однако существует и доступная в большинстве случаев другая платформа из которой вы можете запрашивать и выпускать сертификаты.Я говорю в большинстве случаев потому что наличие этой опции зависит от того, как ваш сервер CA был построен в своём первом месте. Когда я устанавливал свою роль AD CS, я обеспечил выбор опций и для Certification Authority, и для Certification Authority Web Enrollment. Этот второй вариант является важным для нашего следующего раздела текста. Без фрагмента роли Регистрации через веб, мы не сможем иметь работающий веб интерфейс на своём сервере CA и этот фрагмент будет нам не доступен. Если ваш сервер не имеет включённой Регистрации через веб, вы можете повторно посетить страницу установки роли в Диспетчере сервера (Server Manager) и добавить её к существующим ролям:

Когда на вашем сервере CA установлена Certification Authority Web Enrollment, тогда теперь существует вебсайт работающий на данном сервере, к которому вы можете осуществить доступ через браузер изнутри своей сетевой среды. Наличие такого вебсайта полезно, если у вас имеется потребность для пользователей иметь возможность выпуска их собственных сертификатов по како- либо из причин; будет достаточно легче предоставить им документацию или подготовить их к процессу запроса сертификата через вебсайт, вместо того чтобы ожидать, что они переместятся в консоль MMC. Кроме того, если вы пытаетесь запрашивать сертификаты компьютеров которые находятся не внутри той же самой сетевой среды что и ваш сервер CA, применение MMC может быть затруднено. Например, если у вас имеется потребность для работающих на домупользователей запрашивать новый сертификат без наличия полного VPN туннеля консоль MMC скорее всего не будет иметь возможности соединения с вашим сервером CA чтобы вытащить такой сертификат. Однако раз у нас имеется такой работающий вебсайт регистрации сертификатов, вы можете опубликовать такой вебсайт вовне как вы это делаете с любым другим вебсайтом в своей сетевой среде, применяя обратный прокси или межсетевой экран чтобы сохранять безопасным свой обмен и предоставить пользователям возможность доступа к такому сайту и запрашиватьсертификаты всякий раз, когда они им понадобятся.

Чтобы осуществить доступ к данному вебсайту, давайте снова воспользуемся обычным компьютером клиента. В этот раз, однако, вместо открытия MMC, я просто запущу Internet Explorer или любой другой браузер и зарегистрируюсь на этом вебсайте, выполнив https://<CASERVER>/certsrv. Конкретно в моём случае среды это в точности вебадрес https://CA1/certsrv.

Клик по ссылке Request a certificate приведёт вас в наш мастер, в котором мы можем запросить новый сертификат со своего сервера CA. Когда у вас имеются пользователи прокладывающие свой собственный путь через этот веб интерфейс, это обычно для целей сертификатов на основе пользователей, так как у нас имеются некоторые простые способы автоматического распространения сертификатов уровня компьютеров без какого- либо взаимодействия с пользователями. Мы обсудим это через мгновенье. Однако, для целей данного примера, так как мы запрашиваем своих пользователей здесь регистрироваться и запрашивать некий новый User Certificate, на следующей странице я выбираю эту ссылку:

Далее просто нажмите на кнопку Submit и так как ваш сертификат был создан вы увидите ссылку, которая позволит вам Install this certificate (Установить этот сертификат). Кликните по этой ссылке и новый сертификат, который только что был создан для вас, теперь установлен в вашем компьютере. Вы можете увидеть на следующем снимке экрана отклик, который вебсайт предоставил мне, что отображает успешную установку, и вы также можете отметить, что я открыл этот сертификат внутри MMC чтобы просмотреть и проверить тот факт, что этот сертификат в действительности присутствует:

Наш сервер Центра сертификации настроен и работает и мы можем успешно выпускать сертификаты своим машинам клиентов. Великолепно! Теперь давайте притворимся что у нас имеется новый проект на нашем блюде и одно из требований для этого проекта состоит в том, что все компьютеры в нашей сетевой среде должны иметь копию такого машинного сертификата который мы создали. Ух, ах, это звучит как куча работы. Даже хотя процесс запроса одного из таких сертификатов очень быстрый, всего лишь какая- то доля секунды на каждую рабочую станцию, если приходится делать это для пары тысяч машин, то мы говорми о значительном промежутке времени, которое необходимо затратить на этот процесс. А во многих случаях, выпускаемые вами сертификаты действительны только в течение года. Означает ли это что я стою перед лицом чрезвычайного объёма административной работы по перевыпуску таких сертификатов после истечения их срока действия каждый год? Несомненно нет!

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

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

Зарегистрируйтесь на сервере Контроллера домена и откройте консоль Group Policy Management. Я создал новый GPO с назаванием Enable Certificate Autoenrollment и в настоящий момент вношу изменения в этот GPO чтобы определеить настройки которые мне нужны для того чтобы запустить этот GPO:

Настройки внутри этого GPO, которые мы хотим установить размещены в Computer Configuration | Policies | Windows Settings | Security Settings | Public Key Policies | Certificate Services Client – Auto-Enrollment.

Кликните дважды по этому набору чтобы просмотреть его свойства. Всё что нам требуется сделать, это изменить Configuration Model в Enabled и убедиться в наличии отметки для Renew expired certificates, update pending certificates, and remove revoked certificates. Также проверьте второй блок для Update certificates that use certificate templates. Эти настройки заведомо обеспечат что произойдёт автоматическая регистрация когда эти сертификаты начнут работать внее пределов своих сроков в последующие несколько лет.

Что является последним моментом, который нам необходимо выполнить, чтобы чтобы наш GPO начал жить своей жизнью? Создайте ссылку, для того чтобы он начал применяться! Для вашей собственной среды вы, вероятно, создадите более определённую ссылку на конкретное Подразделение (OU) как мы это обсуждали в предыдущей главе, однако для целей моей лаборатории я желаю применять эти сертификаты к какждой отдельной машине которая подключена к домену, поэтому я присоединю свой новый GPO к корню моего домена с тем, чтобы он применялся ко всем моим клиентам и серверам.

Теперь, когда этот GPO создан и настроен, а мы присоединили его к своему домену, я полагаю, что следовало бы выпустить некоторые новые моей папки Issued Certificates из моей консоли Центра сертификации. Однако это не всё. Постойте, в нашем GPO мы в действительности не определили несто особое для шаблона сертификата моей машины DirectAccess, может ли это быть проблемой? Нет, на самом деле не было вариантов для определения того, какие шаблоны я желаю регистрировать автоматически.

Когда вы включаете автоматическую регистрацию (autoenrollment) в Group Policy перебрасываете свой переключатель во включённое состояние для каждого шаблона. Поэтому теперь, когда у нас имеется политика, которая настроена и разрешена для автоматической регистрации, а также присоединена к нашему домену, это делает её работающей, автоматическая регистрация теперь включена для every certificate template (всех шаблонов сертификатов) которые опубликованы на вашем сервере CA. Пока ещё ни один из них не выпустился для моих компьютеров. Это обусловлено тем, что нам необходимо отрегулировать настройки безопасности в нашем новом шаблоне сертификата Машины DirectAccess. В настоящий момент мы настроили их так, чтобы все компьютеры домена имели полномочия Enroll (Регистрации), однако если вы не забыли про закладку безопасности внутри свойств вашего шаблона сергтиыфиката, существовал также дополнительный идентификатор безопасности с названием Autoenroll. Все шаблоны сертификатов имеют свой идентификатор поломочий автоматической регистрации, а он по умолчанию не включен. Теперь, когда лёгкий переключатель был выставлен в положение ON для автоматической регистрации в нашем домене, нам необходимо включить полномочия автоматической регистрации на моём шаблоне, который мы желаем начать распространять сам по себе. Как только мы включим эти полномочия, эти сертификаты начнут растекаться по нашей сетевой среде.

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

И убедитесь сполна, что если я позволю своей среде некоторое время поработать, предоставив возможность для Active Directory и Групповой политики обновить все мои машины, я теперь обнаружу намного больше сертификатов, выпущенных моим сервером CA:

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

Автоматическая регистрация сертификатов может брать на себя то, что обычно является огромным административным бременем и превратить это в некий полностью автоматизированный процесс!

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

Чтобы применять HTTPS, нам необходимо установить на своём сервере WEB1 некий сертификат SSL. Такой веб сервер работает на платформе веб служб Microsoft, IIS (Internet Information Services). Процесс из трёх этапов, который мы предпримем будет тем же самым, если мы выполняем его на различных веб серверах например, таких как Apache, однако определённые моменты, которые вы будете выполнять на этих трёх стадиях могут различаться, так как Apache или любой другой веб сервер имеет другой интерфейс пользователя, нежели IIS. Так как мы работаем с веб сервером Windows Server 2019, мы применяем IIS 10. {Прим. пер.: в нашем переводе Книги рецептов NGINX Дерека ДеДжонге вы можете ознакомиться с настройкой шифрования SSL в NGINX, который успешно может заменять IIS.}

Прежде чем мы перескочим к выполнению трёх обозначенных шагов, давайте обсудим почему каждый из них имеет значение. Скорее всего вы уже слышали термин частного ключа (private key), но возможно не совсем чётко понимаете что он означает. Когда мы отправляем обмен в интернет, со своих компьютеров клиента к некому вебсайту HTTPS, мы понимаем, что этот обмен шифруется. Это означает, что перед тем как покинуть мой ноутбук все пакеты будут упакованы в симпатичный небольшой свёрток чтобы никто не смог их видеть пока они путешествуют, а затем успешно разворачиваются, после того как эти пакеты успешно достигают самого веб- сервера. Для шифрования обмена мой ноутбук применяет некий ключ, а сервер использует ключ для дешифрации этого обмена, но как они узнают какие ключи применять? Здесь существует два различных вида методологии шифрования, которыми можно пользоваться:

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

Когда вы устанавливаете некий сертификат SSL на веб сервер, очень важно чтобы этот сертификат знал ваш частный ключ. совместно использовали некоторую информацию. Как мы можем быть уверены что это произойдёт? Именно тут в игру вступает Certificate Signing Request (CSR, Запрос на подпиь сертификата). Самаый первый шаг правильного получения некого SSL сертификата состоит в генерации какого= то CSR. Когда вы создаёте этот файл, платформа вашего веб сервера создаёт соответствующий необходимый частный ключ и скрывет его прочь от вашего сервера. Требуемый CSR затем создаётся таким образом, что он в точности знает как взаимодействовать с данным закрытым ключом и затем вы применяете данный CSR всякий раз при регистрации в соответствующем вебсайте CA при запросе своего сертификата.

Для генерации CSR откройте IIS из меню Tools в в Диспетчере сервера (Server Manager) и затем кликните по имени вашего веб сервера в дереве навигации с левой стороны своего экрана. Это наполнит содержанием ряд различных приложений в центральной части вашей консоли. То с которым мы собираемся работать называется Server Certificates. Проследуйте в него двойным нажатием мышью:

Теперь, внутри экрана Server Certificates, вы можете обнаружить перечисленными здесь некоторые уже имеющиеся сертификаты, которые располагаются на этом сервере. Именно в этом месте мы в конце концов должны увидеть свой новый сертификат SSL с тем, чтобы мы могли применять его внутри своих свойств вебсайта когда мы будем готовы включить HTTPS. Самый первый шаг к получению нашего нового сертификата состоит в создании запроса на сертификат, который будет применён к нашему CA, и если мы взглянем на правую сторону вашего экрана, вы увидите раздел Actions, под которым перечисляется Server Certificates Request…. Проследуйте им и кликните по этому Action:

В результирующем мастере нам необходимо заполнить информацию, которая будет сохранена внутри вашего сертификата SSL. Поле Common name является самой важной частью информации здесь, она должна быть зарегистрированным именем DNS, которое данный сертификат предназначен защищать. Поэтому обычно вы вводите здесь имя своего вебсайта. Затем продолжите заполнять оставшуюся часть информации, особенной для вашей компании. Сделаем пару специальных замечаний, о местах, в которых часто спотыкаются администраторы, это то, что Organizational unit может быть чем вам угодно, я обычно простов ввожу слово Web. А также убедитесь расшифровать целиком название своего State; не применяйте сокращения:

На странице span class="term">Cryptographic Service Provider Properties вы обычно желаете оставить настройки по умолчанию Cryptographic service provider, если только у вас нет специальной карты шифрования в вашем сервере и вы не планируете применять её для для обработки шифров для данного вебсайта. На серверах IIS мы почти всегда имеем перечисленным здесь Microsoft RSA SChannel Cryptographic Provider. Что вы, однако, скорее всего захотите изменить, так это Bit length. На протяжении многих лет стандартной длиной бит была 1024, и это продолжает оставаться значением по умолчанию для Windows Server 2019. Тем не менее стандартом в отрасли для шифрования SSL принимается, что 1024 является слишком слабым, и нам необходим стандарт 2048. Когад вы проследуете на вебсайт CA для запроса сертификата, вы скорее всего обнаружите, что ваш запрос должен иметь как минимум 2048 бит. Поэтому проследуйте этому требованию сейчас и измените его в ниспадающей установке на 2048:

Единственная вещь, оставшуюся выполнить для нашего CSR, это определить ему местоположение и имя файла. Сохранение этого csr в виде текстового файла является нормальным способом и отвечает нашим целям, потому что всё что нам нужно сделать, когда мы запрашиваем свой сертификат, это открыть данный файл и выполнить copy & past его содержимого. Теперь вы создали свой файл csr и мы можем воспользоваться им для запроса сертификата у общедоступного CA.

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

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

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

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

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

Войдя назад в консоль управления IIS, мы теперь можем воспользоваться следующим Action в том списке справа под названием Complete Certificate Request…. Оно запустит небольшой короткий мастер, в котором вы обнаружите свой файл нового сертификата, который вы только что выгрузили и импортировали в свой сервер. Теперь этот сертификат располагается внутри вашего сервера и он готов к применению для вашего вебсайта.

Существует один дополнительный элемент, который я всегда проверяю после установки или импортирования некоторого сертификата SSL. Вы можете увидеть теперь новый сертификат перечисленным внутри IIS, и если вы кликните дважды по своему новому сертификату, вы обнаружите страницу свойств для этого сертификата. В закладке General данных свойств давайте заглянем ближе к нижней части. Ваш сертификат должен отображать маленькую иконку ключа с последующим текстом You have a private key that corresponds to this certificate (У вас имеется частный ключ, который соответствует данному сертификату). Если вы можете увидеть это сообщение, оно означает, что ваш импорт был успешным и что новый файл сертификата исключительно соответствует вашему CSR. Данный сервер и сертификат теперь совместно используют эту информацию и такой сертификат SSL будет способен работать надлежащим образом для защиты нашего вебсайта. Если вы не обнаруживаете данного сообщения, это означает, что нечто в процессе запроса и выгрузки нашего сертификата прошло криво. Если вы не видите здесь данного сообщения, вам необходимо начать генерацию нового CSR, так как данный файл сертификата, который вы получили обратно не был подписан соответствующим ключом против своего CSR или какой- либо из этих строк. Без соответствующего текста в нижней части данного экрана ваш сертификат не будет удостоверять надлежащим образом обмен. Вот пример того, как всё должно выглядеть при правильной работе.

Вот пример того как всё должно выглядеть при правильной работе:

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

Означает ли это что мне необходимо генерировать новый CSR с каждого из этих серверов и запрашивать новую копию того же самого сертификата множестов раз? Определённо нет, и на самом деле выполнение этого может вызвать у вас другие проблемы. Как вы можете понять, когда общедоступный CA повторно подписывает (re-key) некий сертификат или, другими словами, если вы уже запрашивали некий сертификат с определённым именем, а затем возвращаетесь позже с запросом другой копии того же самого сертификата, такой CA может признать недействительным первый и выпустит новую вторую копию. Это не всегда происходит немедленно, поскольку обычно существуют установки временных задержек по отзыву самого первого сертификата. Если вы повторно посетите веб интерфейс своего CA, и запросите новую копию того же самого сертификата с использованием нового CSR для вашего второго веб сервера, вы можете обнаружить, что всё великолепно работает несколько дней, однако затем внезапно первичный веб сервер прекращает подтверждать обмен потому что истёк срок действия его сертификата.

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

Вернитесь назад в своё хранилище сертификатов Local Computer в своём MMC и переместитесь в Personal | Certificates чтобы вы могли видеть перечисленным свой сертификат SSL. Кликните правой кнопкой по этому сертификату, а затем переместитесь в All Tasks | Export…. Когда вы пройдёте с этим мастером, важная часть, о которой я бы хотел упомянуть происходит прямо на этих этапах мастера. Самый первый выбор, который вы должны сделать сотсоит в том, дложны ли вы экспортировать свой частный ключ или нет. Опять таки, ваш частный ключ является тем секретным ингридиентом, который позволяет вашему сертификату надлежащим образом взаимодействовать с этим сервером на котором он установлен. Будучи экспортированным без такого частного ключа, данный сертификат не будет работать на другом сервере. Поэтому в данном месте важно то, что если вы экспортируете данный сертификат с намерением установки его на второй веб сервер и применять его для удостоверения обмена SSL, то вы должны выбрать верхний параметр Yes, export the private key (Да, экспортировать частный ключ):

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

Внутри аплета Server Certificates для IIS всё что вам требуется, так это щёлкнуть правой кнопкой по сертификату и выбрать Export…. Это запустит мастер из одной страницы, который просто запросит у вас местоположение и пароль:

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

Каким бы образом вы не выполняли свой экспорт, когда у вас имеется в доступности полностью выгруженный файл PFX, его импорт на второй сервер достаточно прост. Либо изнутри консоли MMC, либо из IIS, вы можете кликнуть правой кнопкой и выбрать действие Import. Проходя его этапами вы просто выбираете необходимый файл PFX, а затем вводите пароль, который используется для защиты этого файла. Затем сертификат импортируется и если вы откроете его свойства, вы сможете увидеть маленькую иконку ключа и сообщение о доступности необходимого частного ключа отображённое надлежащим образом в нижней части данного экрана. Если вы не видите сообщения you have a private key (у вас имеется некий частный ключ), в процессе экспорта вы что- то сделали не так и вам необходимо повторить попытку снова.

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

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