Шаг 7. Удаление сертификатов, опубликованных в объекте NtAuthCertificates
После удаления объектов ЦС необходимо удалить сертификаты ЦС, опубликованные в объекте . Чтобы удалить сертификаты из хранилища, используйте следующую команду:
Примечание.
Для выполнения этой задачи у вас должны быть разрешения администратора предприятия.
Действие вызывает пользовательский интерфейс выбора сертификата для набора сертификатов в указанном атрибуте. Вы можете просмотреть сведения о сертификате. Вы можете отменить диалоговое окно выбора, чтобы не вносить никаких изменений. При выборе сертификата этот сертификат удаляется при закрытии пользовательского интерфейса и полном выполнении команды.
Используйте следующую команду, чтобы просмотреть полный путь LDAP к объекту NtAuthCertificates в Active Directory:
Перенаправление трафика IIS сайта с HTTP на HTTPS адрес
Чтобы перенаправить весь входящий HTTP трафик на HTTPS сайт, нужно установить модуль Microsoft URL Rewrite Module (https://www.iis.net/downloads/microsoft/url-rewrite), и убедиться, что в настройках сайта не включена опция обязательного использования SSL (Require SSL). Осталось настроить редирект в файле web.config:
Также вы можете настроить перенаправление трафика через URL Rewrite через графический интерфейс IIS Manager. Выберите Sites -> yoursitename -> URL Rewrite.
Создайте новое правило Add Rule -> Blank rule.
Укажите имя правила и измените значения параметров:
- Requested URL -> Matches the Pattern
- Using -> Regular Expressions
- Pattern -> (.*)
В блоке Conditions измените Logical Grouping -> Match All и нажмите Add. Укажите
- Condition input ->
- Check if input string -> Matches the Pattern
- Pattern -> ^OFF$
Теперь в блоке Action выберите:
- Action Type -> Redirect
- Redirect URL -> https://
- Redirect type -> Permanent (301)
Откройте браузер и попробуйте открыть ваш сайт по HTTP адресу, вас должно автоматически перенаправить на HTTPS URL.
Доверие
Ключевой аспект PKI — это доверие. То есть оба участника аутентификации или обмена сообщениями должны доверять центрам сертификации, которыми выданы сертификаты. Рассмотрим обращение, например, к банковскому сайту по HTTPS. Прежде чем создается защищенное соединение, пользователь должен убедиться, что подключается именно к тому сайту, к которому планировал. Аутентификация сайта происходит с использованием SSL-сертификата. Среди прочего проверяется, что сертификат выдан именно для того сайта, к которому происходит обращение, что сертификат может быть использован для аутентификации сервера, что сертификат не был отозван, что данные в сертификате не были изменены третьей стороной. Последняя проверка требует проверки подписи УЦ, который выдавал сертификат для сервера. То есть необходимо получить сертификат ключа УЦ и выполнить аналогичные проверки для этого сертификата. Опять же, сертификат УЦ должен быть заверен какой-то подписью… До какого момента длятся такие проверки? До тех пор, пока не встретится сертификат УЦ, который находится в списке доверенных сертификатов удостоверяющих центров на стороне клиента. Откуда берутся такие списки? Есть несколько вариантов: списки поставляются вместе с ОС и обновлениями, или доверенные УЦ добавляются администратором или самим пользователем.
Стоит упомянуть еще и самоподписанные сертификаты. Корневые удостоверяющие центры выдают сертификаты сами себе, то есть УЦ1 выдает сертификат для ключа УЦ1, заверенный подписью УЦ1. Такие самоподписанные сертификаты являются основой доверия, и с одной стороны они должны быть доступны всем участникам PKI, а с другой — в случае компрометации или подмены такого сертификата вся система должна перестраиваться заново, с перевыпуском всех сертификатов и защищенным распространением всем пользователям нового корневого сертификата. Существуют коммерческие удостоверяющие центры, которым автоматически доверяют все пользователи ОС, а также пользователи различных браузеров, от Konqueror до Google Chrome.
За выдачу сертификатов большинство из них хотят получать деньги, так что многие компании развертывают свои собственные ЦС, которым изначально никто не доверяет. Корпоративный ЦС удобен возможностью создания собственных политик и шаблонов сертификатов, но создает сложности с доверием со стороны клиентов и партнеров. С клиентами проблемы доверия обычно решаются покупкой SSL-сертификатов для веб-серверов в коммерческих УЦ. С партнерами, или в случае слияний, строятся различные отношения доверия между несколькими УЦ. Для этого используются кросс-сертификаты (сертификат с ключом УЦ1 заверяется подписью УЦ2 и наоборот), которые показывают взаимное доверие между УЦ нескольких организаций. Наиболее распространены три модели доверия (см схему в конце статьи):
- Мостовая (Bridge CA Model). В данной модели существует центральный (мостовой) УЦ, которому доверяют все остальные УЦ. Такая модель позволяет осуществлять централизованное управление при небольшом количестве кросс-сертификатов. В качестве примера можно привести реализацию US government’s Federal Bridge Certification Authority.
- В сетевой модели все УЦ считаются равноправными, и создается до n2 кросс-сертификатов. Кросс-сертификация на уровне корневых УЦ может быть не всегда желательной, в этом случае используются схемы кросссертификации на уровне подчиненных УЦ с ограничением доверия.
- Иерархическая модель обычно используется в компаниях с разветвленной структурой, когда есть корневой УЦ и подчиненные, например, в филиалах. Кроме того, иерархическая модель позволяет минимизировать затраты при перестроении инфраструктуры в случае компрометации ключа УЦ. Действительно, если происходит компрометация ключа одного из издающих (подчиненных) УЦ, то необходимо переиздать только те сертификаты, которые были выданы этим УЦ. Более того, такая модель позволяет создавать УЦ с различными регламентами в рамках одной инфраструктуры.
Еще встречаются гибридные модели и списки доверенных сертификатов, распространяемых между заинтересованными сторонами.
Варианты установки УЦ
Чтобы реализовать иерархическую модель доверия, существуют различные варианты установки ЦС. В Windows Server 2008 установка центра сертификации происходит через добавление роли Active Directory Certificate Services. При прохождении мастера необходимо выбрать тип установки и тип центра сертификации.
Вариант установки (Enterprise или Standalone) влияет на возможности центра сертификации. Например, Enterprise CA может использовать шаблоны и автоматическую подачу заявок на сертификат. Standalone УЦ, несмотря на название, может быть членом домена. В случае же использования Standalone УЦ, в качестве Offline Root CA, он должен быть членом рабочей группы.
Можно установить два типа УЦ — Root CA и Subordinate CA. Для Root CA создается самоподписанный сертификат, для Subordinate CA необходимо запрашивать сертификат у вышестоящего УЦ. После установки УЦ нельзя менять имя сервера, на котором он установлен, так как сертификат УЦ окажется недействительным.
Удостоверяющие центры можно классифицировать по их предназначению: для хранения политик, выпуска сертификатов для подчиненных УЦ или для выпуска сертификатов для конечных пользователей. Можно создавать несколько центров для выпуска сертификатов, разделяя их по географическому признаку или по типу выдаваемых сертификатов. Начиная с Windows Server 2008 R2 отпала необходимость ставить отдельный УЦ в каждом лесу организации, так как появилась возможность выдавать сертификаты пользователям не только того леса, в котором установлен УЦ, но и пользователям тех лесов, с которым настроены доверительные отношения.
Для повышения надежности системы и снижения последствий компрометации корневые УЦ, и УЦ, хранящие политики, используются в режиме Offline, чтобы исключить возможность атак по сети. В качестве типа для таких УЦ выбирают Standalone CA.
Проверка конфигурации
Windows Hello для бизнеса — это распределенная система, которая на первый взгляд кажется сложной и затруднительной в настройке. Залогом успешного развертывания Windows Hello для бизнеса является проверка каждого этапа проделанной работы перед переходом на следующий этап.
Вам надо убедиться, что контроллеры домена регистрируют правильные сертификаты и не регистрируют ненужные (устаревшие) шаблоны сертификатов. Необходимо проверить каждый контроллер домена и убедиться, что для этого компьютера произошла автоматическая регистрация.
Использование журналов событий
Войдите в контроллер домена или рабочие станции управления с учетными данными, эквивалентными администратору домена .
- Используя Просмотр событий, перейдите к журналу событий Application and Services > Майкрософт > Windows > CertificateServices-Lifecycles-System
- Найдите событие, указывающее на регистрацию нового сертификата (автоматическая регистрация):
- Сведения о событии включают шаблон сертификата, на котором был выдан сертификат.
- Имя шаблона сертификата, используемого для выдачи сертификата, должно соответствовать имени шаблона сертификата, включенного в событие.
- Отпечаток сертификата и EKU для сертификата также включаются в событие.
- EKU, необходимый для правильной проверки подлинности Windows Hello для бизнеса, — это проверка подлинности Kerberos в дополнение к другим EKU, предоставляемым шаблоном сертификата.
Сертификаты, заменяемые новым сертификатом контроллера домена, создают архивное событие в журнале событий. Событие архивации содержит имя шаблона сертификата и отпечаток сертификата, который был заменен новым сертификатом.
Диспетчер сертификатов
Можно использовать консоль диспетчера сертификатов для проверки, что у контроллера домена есть правильно зарегистрированный сертификат на основе правильного шаблона сертификата с соответствующими EKU. Используйте certlm.msc, чтобы посмотреть сертификат в хранилище сертификатов на локальном компьютере. Разверните хранилище Личные для просмотра сертификатов, зарегистрированных на компьютере. Архивные сертификаты не отображаются в диспетчере сертификатов.
Certutil.exe
Вы можете использовать команду для просмотра зарегистрированных сертификатов на локальном компьютере. Certutil показывает зарегистрированные и архивные сертификаты для локального компьютера. Из командной строки с повышенными привилегиями выполните команду , чтобы посмотреть локально зарегистрированные сертификаты.
Чтобы просмотреть подробные сведения о каждом сертификате в хранилище, используйте команду для проверки, что автоматическая регистрация сертификатов зарегистрировала необходимые сертификаты.
Диагностика
Windows включает автоматическую регистрацию сертификатов для компьютера во время загрузки и при обновлениях групповой политики. Можно обновить групповую политику из командной строки с повышенными привилегиями с помощью команды .
Кроме того, вы можете принудительно запустить автоматическую регистрацию сертификатов с помощью команды из командной строки с повышенными привилегиями.
Используйте журналы событий для мониторинга регистрации и архивации сертификатов. Проверьте конфигурацию, например публикацию шаблонов сертификатов в центре сертификации и разрешение на автоматическую регистрацию.
Пути защиты
Прежде чем приступить к изучению механизма защиты, очертим перечень угроз, от которых этот самый механизм должен предохранять. Это:
- несанкционированное чтение почты;
- несанкционированная корректировка почтового сообщения;
- формирование и отправка писем от чужого имени.
Все эти опасности давно известны, потому как в равной мере актуальны и при использовании обычной (бумажной) корреспонденции. Пути защиты также идентичны:
- аутентификация отправителя при помощи определенного идентификатора, подделка которого максимально затруднительна (для бумажного письма таким идентификатором является подпись автора);
- шифрование содержимого письма.
Общие сведения
Перед установкой Configuration Manager 2007 в основном
режиме должны быть установлены сертификаты PKI . В данном примере
не описывается установка и настройка Configuration Manager 2007, но
дано описание обеспечения компьютеров сертификатами, необходимыми
для работы Configuration Manager 2007 в основном режиме.
В следующей таблице приведены три типа необходимых
сертификатов PKI с описанием способа их использования на сайте
Configuration Manager 2007, работающем в основном режиме.
| Требования к сертификату | Описание сертификата |
|---|---|
|
сертификат для подписи сервера сайта; |
Этот сертификат устанавливается на сервер, который будет |
|
Сертификат веб-сервера |
Этот сертификат устанавливается на серверы, которые будут |
|
Сертификат клиента |
Этот сертификат устанавливается на компьютеры, которые будут |
Дополнительные сведения о сертификатах см. в разделе
Требования к
сертификатам для работы в основном режиме.
Выполните действия в данном примере, чтобы достичь
следующих целей.
- Обеспечьте рядовой сервер сертификатом для
подписи сервера сайта Configuration Manager 2007, чтобы он смог
работать в качестве сервера сайта Configuration Manager 2007 в
основном режиме. - Обеспечьте рядовой сервер сертификатом
веб-сервера, чтобы он смог работать в качестве сервера системы
сайта Configuration Manager 2007 в основном режиме, который может
исполнять любую из перечисленных ролей системы сайта Configuration
Manager: точка управления, точка распространения, точка обновления
программного обеспечения и точка миграции состояния. - Обеспечьте рабочую станцию и рядовой сервер
сертификатом клиента, чтобы рабочая станция могла работать в
качестве клиента Configuration Manager 2007 в основном режиме, а
точка управления могла передавать данные о ее состоянии на сервер
сайта.
Варианты установки и управления AD CS
AD CS нельзя установить на Itanium редакции Windows Server 2008, а на Server Core все компоненты AD CS можно устанавливать, начиная с Windows Server 2008 R2. Довольно серьезные ограничения по использованию AD CS присутствуют и в стандартной редакции Server 2008 (возможность установки только компонента CA, невозможность использовать Restricted Enrollment Agent и другие новшества), часть из которых были сняты в R2 (наконец в стандартной редакции появилась возможность работать с шаблонами сертификатов версий выше первой).
Все компоненты можно поставить на один сервер, но рекомендуется разносить CA, Online Responder и Web enrollment на различные сервера. Для полноценной работы AD CS требуется AD DS (Active Directory Domain Services). При этом можно обойтись без обновления схемы – AD CS в Server 2008 и в Server 2008 R2 будет работать и на схеме, которая поставляется с Windows Server 2003. Но для работы Certificate Enrollment Web Services уже необходима схема не ниже 47 версии, которая идет с Windows Server 2008 R2. Для работы большинства компонентов также требуется IIS.
Установка AD CS производится через добавление ролей в оснастке Server Manager. Как и раньше, для настройки параметров установки применяется конфигурационный файл CAPolicy.inf, который должен находиться в %SYSTEMROOT%. Если необходимо установить на сервер два компонента Certification Authority и Certificate Enrollment Web Service, то это надо делать в два этапа, так как при установке CA нельзя выбрать для установки компонент Web Service.
В Windows Server 2008 были добавлены новые COM-объекты (подробную информацию о свойствах ICertSrvSetup можно найти на MSDN), которые можно использовать для установки CA. Например, можно автоматизировать установку и настройку с помощью VBScript.
Службы сертификации являются хорошими кандидатами на виртуализацию
Но при этом очень важно обеспечить необходимый уровень безопасности для закрытых ключей. Этого можно достичь, используя аппаратные криптографические модули (HSM)
В этом случае, даже если виртуалка целиком попадет к злоумышленнику (например, из резервной копии), то закрытые ключи не будут потеряны и не придется перестраивать всю инфраструктуру, так как ключи останутся в HSM. Microsoft официально поддерживает виртуализацию служб сертификации начиная с Windows Server 2003 SP1.
Для управления и настройки AD CS можно использовать MMC-оснастки, скрипты или командную строку. Большая часть инструментов существовала и в предыдущих версиях, таких как оснастки Certificates (certmgr.msc), Certification Authority (certsrv.msc) и Certificate Templates (certtmpl.msc), утилиты certutil.exe и сertreq.exe. Добавилась оснастка Online Responder Management (ocsp.msc) для управления одноименным компонентом. Кроме того, в состав ОС вошла оснастка Enterprise PKI (pkiview.msc), которая ранее была частью Windows Server 2003 Resource Kit и называлась PKI Health Tool.
Enterprise PKI позволяет одновременно отслеживать состояние и доступность нескольких CA, проверяет статус сертификатов CA, доступность AIA (Authority Information Access) и списков отзыва. С помощью разноцветных отметок можно судить о доступности и состоянии PKI. Pkiview удобно использовать, когда в организации развернуто несколько CA, и информацию о них можно получить из нескольких источников, работающих по различным протоколам.
Некоторые изменения произошли и в резервном копировании AD CS в Server 2008 R2. Так как закрытые ключи теперь хранятся в скрытой папке %SYSTEMDRIVE%\ProgramData\Microsoft\Crypto\Keys, к которой можно получить доступ через %SYSTEMDRIVE%\Users\All Users\Microsoft\Crypto\Keys, то они не попадают в резервную копию состояния системы. Чтобы можно было восстановить или мигрировать CA при создании использование в качестве резервной копии System State Backup, надо еще создать резервную копию закрытых ключей. Для этого можно воспользоваться командой certutil –backupKey <путь_для_резервной_копии> или оснасткой Certification Authority.
Let’s Encrypt и ACME клиенты для Windows
Наличие TLS/SSL сертификата у сайта позволяет защитить данные пользователей, передаваемые по сети от атак человек-посередине (man-in-the-middle) и гарантировать целостность переданных данных. Некоммерческий центр сертификации Let’s Encrypt позволяет в автоматическом режиме через API выпускать бесплатные криптографические TLS сертификаты X.509 для шифрования (HTTPS) . Выдаются только сертификаты для валидации доменов (domain validation), со сроком действия 90 дней (есть ограничение – 50 сертификатов для одного домена в неделю). Но вы можете автоматически перевыпускать SSL сертификат для своего сайта по расписанию.
API интерфейс, позволяющий автоматически выпускать сертификаты называется Automated Certificate Management Environment (ACME) API. Для Windows систем на данный момент имеется 3 самых популярных реализации клиента ACME API:
- Утилита WindowsACMESimple(WACS) – утилита командной строки для интерактивного выпуска сертификата и привязки его к определенному сайту на вашем веб сервере IIS;
- Модуль PowershellACMESharp – библиотека Powershell с множеством команд для взаимодействия через ACME API с серверами Let’s Encrypt;
- Certify – графический менеджер SSL сертификатов для Windows, позволяет интерактивно управления сертификатами через ACME API.
Шаг 5. Удаление служб сертификатов с сервера
Чтобы остановить службы сертификатов, нажмите кнопку «Пуск», выберите «Выполнить», введите cmd и нажмите кнопку «ОК».
В командной строке введите certutil -shutdown и нажмите клавишу ВВОД.
В командной строке введите certutil -getreg CA\CSP\Provider и нажмите клавишу ВВОД
Обратите внимание на значение поставщика в выходных данных. Например:
Если значение равно microsoft Strong Cryptographic Provider или Microsoft Enhanced Cryptographic Provider версии 1.0, введите CertUtil -Key и нажмите клавишу ВВОД.
Если значение равно поставщику хранилища ключей программного обеспечения Майкрософт, введите CertUtil -CSP KSP -Key и нажмите клавишу ВВОД.
Если значение другое, введите CertUtil -CSP -Key и нажмите клавишу ВВОД.
Эта команда отображает имена всех установленных поставщиков служб шифрования (CSP) и хранилищ ключей, связанных с каждым поставщиком
В списке хранилищ ключей будет указано имя вашего ЦС. Имя будет указано несколько раз, как показано в следующем примере:
Удалите закрытый ключ, связанный с ЦС. Для этого в командной строке введите следующую команду и нажмите клавишу ВВОД:
Примечание.
Если имя ЦС содержит пробелы, заключите его в кавычки.
В этом примере имя центра сертификации — Windows2000 Корпоративный корневой ЦС. Таким образом, командная строка в этом примере выглядит следующим образом:
Снова перечислите хранилища ключей, чтобы убедиться, что закрытый ключ для ЦС удален.
После удаления закрытого ключа для ЦС удалите службы сертификатов. Для этого выполните следующие действия в зависимости от версии Windows Server, которую вы используете.
Если вы удаляете корпоративный ЦС, для выполнения этой процедуры требуется членство в enterprise Admins или его эквиваленте. Дополнительные сведения см. в статье «Role-Based администрирование».
Чтобы удалить ЦС, выполните следующие действия.
Выберите «Пуск», «Администрирование» и «Диспетчер сервера».
В разделе «Сводка ролей» выберите «Удалить роли «, чтобы запустить мастер удаления ролей, а затем нажмите кнопку «Далее».
Снимите флажок «Службы сертификатов Active Directory «, а затем нажмите кнопку «Далее».
На странице «Подтверждение параметров удаления » просмотрите сведения и нажмите кнопку » Удалить».
Если службы IIS запущены и вам будет предложено остановить службу перед продолжением процесса удаления, нажмите кнопку » ОК».
После завершения работы мастера удаления ролей перезапустите сервер. Это завершает процесс удаления.
Процедура немного отличается, если на одном сервере установлено несколько служб ролей служб сертификатов Active Directory (AD CS). Чтобы удалить ЦС, но сохранить другие службы ролей AD CS, выполните следующие действия.
Примечание.
Для выполнения этой процедуры необходимо войти в систему с тем же разрешением, что и пользователь, который установил ЦС. Если вы удаляете корпоративный ЦС, для выполнения этой процедуры требуется членство в enterprise Admins или его эквиваленте. Дополнительные сведения см. в статье «Role-Based администрирование».
Выберите «Пуск», «Администрирование» и «Диспетчер сервера».
В разделе «Сводка ролей» выберите службы сертификатов Active Directory.
В разделе «Службы ролей» выберите «Удалить службы ролей».
Установите этот флажок, чтобы снять флажок центра сертификации, а затем нажмите кнопку «Далее».
На странице «Подтверждение параметров удаления » просмотрите сведения и нажмите кнопку » Удалить».
Если служба IIS запущена и вам будет предложено остановить службу перед продолжением процесса удаления, нажмите кнопку «ОК».
После завершения работы мастера удаления ролей необходимо перезапустить сервер. Это завершает процесс удаления.
Если остальные службы ролей, такие как служба оперативного реагирования, были настроены для использования данных из удаленного ЦС, необходимо перенастроить эти службы для поддержки другого ЦС. После удаления ЦС на сервере будут оставлены следующие сведения:
База данных ЦС.
Открытый и закрытый ключи ЦС.
Сертификаты ЦС в личном хранилище.
Сертификаты ЦС в общей папке, если общая папка была указана во время установки AD CS.
Корневой сертификат цепочки ЦС в хранилище доверенных корневых центров сертификации.
Промежуточные сертификаты цепочки ЦС в хранилище промежуточных центров сертификации.
Список отзыва сертификатов ЦС.
По умолчанию эти сведения хранятся на сервере в случае удаления, а затем переустановки ЦС. Например, вы можете удалить и переустановить ЦС, если вы хотите изменить автономный ЦС на корпоративный ЦС.
Клиент WACS для установки TLS сертификата Let’s Encrypt в IIS на Windows Server
Самый простой способ получить SSL сертификат от Let’s Encrypt — воспользоваться консольной утилитой Windows ACME Simple (WACS) (ранее проект назывался LetsEncrypt-Win-Simple). Она представляет собой простой мастер, который позволяет выбрать один из сайтов, запущенных на IIS, и автоматически выпустить и привязать к нему SSL сертификат.
Итак, предположим у нас имеется веб сайт на IIS, развёрнутый под управлением Windows Server 2016. Наша задача, переключить его в HTTPS режим, установив SSL сертификат от Let’s Encrypt.
Скачайте последний релиз клиента WACS со страницы проекта на GitHub https://github.com/PKISharp/win-acme/releases (в моем случае это версия v2.0.10 – файл win-acme.v2.0.10.444.zip).
Распакуйте архив в каталог на сервере с IIS: c:\inetpub\letsencrypt
Откройте командную строку с правами администратора, перейдите в каталог c:\inetpub\ letsencrypt и запустите wacs.exe.
Запустится интерактивный мастер генерации сертификата Let’s Encrypt и привязки его к сайту IIS. Чтобы быстро создать новый сертификат выберите N — Create new certificates (simple for IIS).
Затем нужно выбрать тип сертификата. В нашем примере нет необходимости использовать сертификат с псевдонимами (несколькими SAN — Subject Alternative Name), поэтому достаточно выбрать пункт 1. Single binding of an IIS site. Если вам нужен Wildcard-сертификат, выберите опцию 3.
Далее утилита выведет список сайтов, запущенных на сервере IIS и предложит выбрать сайт, для которого нужно создать и привязать новый SSL сертификат.
Процесс генерации и установки SSL сертификата Let’s Encrypt для IIS полностью автоматизирован.
По умолчанию выполняется валидация домена в режиме http-01 validation (SelfHosting). Для этого нужно, чтобы в DNS домена имелась запись, указывающая на ваш веб сервера. При запуске WACS в ручном режиме можно выбрать валидацию типа — 4 Create temporary application in IIS (recommended). В этом случае на веб-сервере IIS будет создано небольшое приложение, через которое сервера Let’s Encrypt смогут провести валидацию.
Утилита WACS сохраняет закрытый ключ сертификата (*.pem), сам сертфикат и ряд других файлов в каталог C:\Users\%username%\AppData\Roaming\letsencrypt-win-simple. Затем она в фоновом режиме установит сгенерированный SSL сертификат Let’s Encrypt и привяжет его к вашему сайту IIS. Если на сайте уже установлен SSL сертификат (например, самоподписанный), он будет заменен новым.
В IIS Manager откройте меню Site Binding для вашего сайта и убедитесь, что для него используется сертификат, выданный Let’s Encrypt Authority X3.
В хранилище сертификатов компьютера сертификат Let’s Encrypt для IIS вы можете найти в разделе Web Hosting -> Certificates.
Windows ACME Simple создает новое правило в планировщике заданий Windows (win-acme-renew (acme-v02.api.letsencrypt.org)) для автоматического продления сертификата. Задание запускается каждый день, продление сертификата выполняется через 60 дней. Планировщик запускает команду:
C:\inetpub\letsencrypt\wacs.exe –renew –baseuri “https://acme-v02.api.letsencrypt.org”
Эту же команду вы можете использовать для ручного обновления сертфиката.
Списки отзыва vs. Online Responder
При проверке валидности сертификата среди прочего проверяется срок его действия и состояние отзыва. Сертификат может быть отозван, как в случае компрометации ключа, так и при изменении информации о владельце, например, смене должности или фамилии. Традиционно информация об отозванных сертификатах помещается в списки отзыва (CRL (certificate revocation list)). Чтобы узнать, был ли отозван сертификат, надо получить список отзыва и проверить наличие в нем рассматриваемого сертификата. Если в организации большое количество сертификатов, то список будет быстро расти, а клиенты при проверке статуса сертификата будут ждать закачки списка. Кроме обычных списков существуют еще и разностные (Delta CRL), которые содержат в себе только информацию о сертификатах, статус которых был изменен по сравнению с предыдущим списком отзыва. Delta CRL частично решают проблемы с объемом списков отзыва, но не решают всех проблем, связанных с актуальностью информации. Так как списки публикуются с заданным интервалом, то может быть такая ситуация, что сертификат уже отозван, а информации об этом в CRL еще нет.
В Windows Server 2008 появились сетевые ответчики (Online Responder). Их можно использовать как альтернативу или в дополнение к спискам отзыва сертификатов. Компонент Online Responder использует протокол OCSP (Online Certificate Status Protocol), описанный в RFC 2560. Ответчик разбирает запросы от клиентов, оценивает статус сертификата и отправляет обратно подписанный ответ с информацией о статусе запрошенного сертификата. В случае если клиенту требуется информация о статусе большого количества сертификатов, то целесообразно использовать списки отзыва, так как их достаточно получить один раз, без необходимости многократных запросов к серверу.
Протокол OCSP поддерживают клиенты, начиная с Windows Vista. Они могут быть настроены с помощью новых параметров групповой политики (Certificate Path Validation Settings вкладка Revocation).
В отличие от использования списков отзыва, Online Responder требуется вначале установить и настроить. Для этого надо выполнить следующие шаги:
- Добавить компонент Online Responder роли AD CS. Для работы Online Responder требуется IIS, который будет автоматически предложено установить.
- В свойствах CA для AIA указать путь, по которому доступен ответчик.
- Так как ответ о статусе сертификата подписывается, то для работы Online Responder требуется соответствующий сертификат. Сертификат, который будет использоваться ответчиком, должен обладать следующими атрибутами: короткий срок действия (несколько недель), наличие расширения id-pkix-ocsp-nocheck и расширенного использования ключа id-kp-OCSPSigning, отсутствие CDP и AIA. Эти атрибуты уже настроены в шаблоне OCSP Response Signing. В случае использования Enterprise CA надо только добавить его к доступным шаблонам в Active Directory, настроив на него разрешения (Read и Enroll) для сервера, на который установлен Online Responder. Для StandAlone CA надо еще менять значение соответствующего флага командой certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK. Действия по настройке шаблона в Windows Server 2003 отличаются и здесь не рассматриваются.
- На последнем этапе необходимо настроить сам сетевой ответчик. Для этого в оснастке Online Responder Management с помощью мастера надо создать revocation configuration.
- Для корректной работы Online Responder в период, когда происходит обновление ключа CA, необходимо разрешить обновления сертификатов Online Responder с использованием существующих ключей центра сертификации. Для этого надо выполнить на CA команду certutil -setreg ca\UseDefinedCACertInRequest 1. Данное действие необходимо для получения возможности подписывать ответы Online Responder с помощью сертификата, подписанного тем же ключом CA, который использовался для подписания сертификата, статус которого запрашивается.
В Windows 2003 для разрешения этой ситуации необходимо вручную создать столько сертификатов для подписи ответов OCSP, сколько требуется, чтобы покрыть срок действия двух сертификатов CA. При этом срок действия каждого из выпущенных сертификатов должен быть на две недели больше, чем у предыдущего.
Заключение
Видоизменения служб сертификации производились и в Windows Server 2008, и в R2. В итоге появились возможности, которые будут интересны специалистам по безопасности, инструменты, которые облегчат жизнь администратора, и функции, которые позволят пользователям еще меньше разбираться в сертификатах.
Во-первых, добивалась поддержка новых протоколов и криптографических алгоритмов. Протокол OCSP, который уже не один год присутствовал в других программных продуктах, наконец-то дошел до серверных ОС Microsoft. Таким образом, у администраторов и программистов появились различные варианты для проверки статуса отозванных сертификатов, которые позволяют выбирать между скоростью, объемом данных и актуальностью информации
Немаловажно и появление поддержки алгоритмов на эллиптических кривых. К сожалению, поддерживаются не российские, а американские стандарты, но ожидать иного было бы странно
Во-вторых, многие библиотеки (например, Crypto API и XEnroll.dll) переписаны с нуля, из-за чего можно надеяться на избавление от старых ошибок и проблем, и ждать новых.
В-третьих, значительно расширились способы запроса и получения сертификатов. Теперь сертификаты могут получать и сетевые устройства без записи в домене, и пользователи без прямого доступа к сети с CA.
