Tw-city.info

IT Новости
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Центр сертификации в домене

Центр сертификации в домене

Пошаговая инструкция по установке и настройке центра сертификации

Сергей Вессарт | Опубликовано 29.10.2013 в рубрике Новые возможности

Одним из преимуществ ЛОЦМАН:ПГС является применение цифровых подписей достоверно подтверждающих личность и роль подписавшего документ. Для создания цифровых подписей необходимы сертификаты выданные удостоверяющим центром сертификации.

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

В наших примерах мы будем использовать контроллер домена на Microsoft Windows Server 2008 и клиент Microsoft Windows 7.

  1. Для начала нам нужно добавить роль Active Directory Certification Services (Службы сертификации Active Directory) на контроллере домена. Откройте Server Manager и выполните команду «Add Role» («Добавить роли»).
  2. Откроется Add Roles Wizard (Мастер добавления ролей). Нажмите Next.
  3. Выберите роль Active Directory Certification Services(Службы сертификации Active Directory). Нажмите Next.
  4. Next.
  5. Проверьте, что отмечена служба Certification Authority(Центр сертификации).
  6. Вариант установки должен быть указан «Enterprise».
  7. Тип центра сертификации Root CA(Корневой ЦС).
  8. Создайте новый приватный ключ.
  9. Укажите параметры шифрования, например:

    Если Вы меняете параметры, рекомендуем Вам ознакомиться с советами компании Microsoft по безопасности в части выбираемой длины ключа.
  10. Проверьте имя и суффиксы центра сертификации, например:
  11. Задайте срок действия сертификата, например:
  12. Next.
  13. Install.
  14. Процесс установки…
  15. Установка завершена. Close.

    Центр сертификации установлен. Теперь нужно создать шаблон сертификатов.
  16. Перейдите в Certificate Templates (Шаблоны сертификатов) и выполните команду Duplicate Template (Скопировать шаблон) на существующем шаблоне, например User.
  17. Выберите версию Windows Server минимально поддерживаемую ЦС.

    Не выбирайте Windows Server 2008, иначе при подписании созданным сертификатом документов в программных продуктах использующих .NET Framework 4.0 Вы получите сообщение «Указан неправильный тип поставщика (mscorlib)». Иными словами Вы не сможете использовать сертификат.
  18. В открывшихся свойствах шаблона укажите имя и отключите Publish certificate in Active Directory (Опубликовать сертификат в Active Directory):
  19. Перейдите на вкладку Request Handling (Обработка запроса) и измените цель на «Signature» («Подпись»).
  20. Проверьте параметры на вкладке Subject Name (Имя субъекта).
  21. На вкладке Security (Безопасность) для группы Authenticated Users (Прошедшие проверку) разрешите Enroll (Заявка).
  22. На вкладке Extensions (Расширения) скорректируйте Application Policies (Политика применения) .

    Выберите Document Signing (Подписывание документа).

    ОК.

    Шаблон сертификата создан, теперь необходимо его опубликовать.
  23. Перейдите в Certificate Templates (Шаблоны сертификатов) и выполните команду «New -> Certificate Template to Issue» («Новый -> Выдать шаблон сертификата»).
  24. Выберите ранее созданный шаблон. ОК.

    Установка и настройка шаблона сертификатов закончена. Перейдем на клиента и попробуем получить сертификат.
  25. На клиенте запустите Certificate Manager Tool выполнив команду certmgr.msc.
  26. Перейдите в Personal (Личное) и создайте запрос на получение сертификата, выполнив Request New Certificate (Запросить новый сертификат).
  27. Next.
  28. Выберите политику Active Directory. Next.
  29. В типах сертификатов отметьте ранее созданный шаблон.

    Если планируется использование нескольких сертификатов для одного пользователя, желательно присвоить имя запрашиваемому сертификату. Откройте свойства заявки.
  30. На вкладке General (Общие) укажите Friendly name (Понятное имя).

    Сохраните и закройте свойства.
  31. Enroll.
  32. Заявка успешно завершена, сертификат получен.
  33. В Certificate Manager Tool можно посмотреть параметры сертификата.

    Мы получили сертификат только для одного пользователя, а когда пользователей много, такой способ не очень удобен. Для облегчения процесса давайте настроим автоматическую раздачу сертификатов групповой политикой.
  34. Для начала необходимо изменить свойства, созданного ранее шаблона, сделать его доступным для автоматической выдачи. Найдите созданный шаблон в Server Manager и откройте свойства.
  35. Перейдите на вкладку Security (Безопасность) и для группы Authenticated Users (Прошедшие проверку) разрешите Autoenroll (Автозаявка).
  36. Следующий шаг — настроить групповую политику автоматической регистрации сертификатов для домена. Можно изменить политику по-умолчанию, но лучше создать новую, так мы сможем ограничить круг пользователей, охватываемых политикой. На домене выполните команду Create a GPO in this domain, and Link it there… (Создать ОГП в документе и связать его…).
  37. Введите имя групповой политики, например:
  38. Отредактируйте созданную политику.
  39. Перейдите в раздел «User configuration — Policies — Widows Settings — Security Settings — Public Key Policies» (Конфигурация пользователя — Политики — Конфигурация Windows — Параметры безопасности — Политики открытого ключа) и откройте свойства Certificate Services Client — Auto-Enrollment (Клиент службы сертификации — автоматическая регистрация).
  40. Включите автоматическую регистрацию сертификатов и флажки:
    • Обновлять сертификаты с истекшим сроком действия или в состоянии ожидания и удалять отозванные сертификаты;
    • Обновлять сертификаты, использующие шаблоны сертификатов.

  • Закройте редактор групповой политики и в Server Manager при необходимости ограничьте круг пользователей или компьютеров, на которые будет применена политика. Как пример, ниже показана политика, которая будет распространена только на ПК DOMAINCOMPUTER.

    Групповая политика создана, проверим как она работает.
  • На клиенте откройте CMD.exe с правам администратора и выполните команду «gpupdate /force /boot /logoff» или перезапустите ПК.
  • Сертификат должен быть автоматически запрошен и получен. Полученный сертификат можно увидеть в Certificate Manager Tool (пункт 33) или в Control Panel — Internet Options, вкладка Content — Certificates — Personal (Панель управления — Свойства обозревателя, вкладка Содержание — Сертификаты — Личные).

    Это всё, что мы хотели сказать про установку и настройку центра сертификации. Спасибо, что читаете наш блог, до свидания!
  • 9 комментариев

    Сергей, спасибо большое. Очень нужная статья.

    Записки IT специалиста

    Технический блог специалистов ООО»Интерфейс»

    • Главная
    • Windows Server. Создание автономного центра сертификации.

    Windows Server. Создание автономного центра сертификации.

    • Автор: Уваров А.С.
    • 19.11.2010

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

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

    Для чего это может быть нужно на практике? Цифровые сертификаты позволяют использовать шифрование на уровне приложений (SSL/TLS) для защиты веб-страниц, электронной почты, служб терминалов и т.п., регистрацию в домене при помощи смарт-карт, аутентификацию пользователей виртуальных частных сетей (VPN), шифрование данных на жестком диске (EFS), а также в ряде случаев обойтись без использования паролей.

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

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

    ЦС предприятия

    • Требует наличия ActiveDirectory
    • Автоматическое подтверждение сертификатов
    • Автоматическое развертывание сертификатов
    • Возможность запроса сертификатов через Web-интерфейс, мастер запросов и автоматическое развертывание

    Изолированный (автономный) ЦС

    • Не требует наличия ActiveDirectory
    • Ручное подтверждение сертификатов
    • Отсутствие возможности автоматического развертывания
    • Запрос сертификатов только через Web-интерфейс

    Методика развертывания ЦС для Windows Server 2003 и Windows Server 2008 несколько различаются, поэтому мы решили рассмотреть их в отдельности.

    Windows Server 2003

    Для возможности использования Web-интерфейса для выдачи сертификатов нам понадобится установленный web-сервер IIS. Установим его через диспетчер сервера: Пуск — Управление данным сервером — Добавить или удалить роль.
    В списке ролей выбираем роль Сервера приложений. В следующем окне устанавливаем галочку Включить ASP.NET, если IIS уже установлен данный шаг можно пропустить.

    После установки IIS приступим к развертыванию Центра сертификации, это делается через оснастку Установка и удаление программ — Установка компонентов Windows, где выбираем Службы сертификации.

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

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

    Windows Server 2008 R2

    В Windows Server 2008 (2008 R2) все настройки консолидированы в одном месте, что делает установку ЦС более простой и удобной. Выбираем Диспетчер сервера — Роли — Добавить роли, в списке ролей выбираем Службы сертификации Active Directory.

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

    Дальнейшая настройка аналогична Windows Server 2003. Вводим тип ЦС, его имя и место хранения файлов, подтверждаем выбор компонент и завершаем установку.

    Проверка работы ЦС

    Для первоначальной проверки работоспособности ЦС можете запустить оснастку Центр сертификации (Пуск — Администрирование — Центр Сертификации). Если все сделано правильно вы должны увидеть следующее окно:
    Попробуем теперь получить сертификат для клиентского ПК. Запустим браузер, в адресной строке которого укажем адрес http://имя_сервера/certsrv, где имя_сервера — имя сервера ЦС. Вы попадете на главную страницу центра сертификации.
    Прежде всего необходимо загрузить сертификат ЦС и поместить его в хранилище доверенных коренных центров сертификации. Если в вашей сети несколько ЦС следует загрузить и установить цепочку сертификатов. Для этого выбираем: Загрузка сертификата ЦС, цепочки сертификатов или CRL, затем Загрузка сертификата ЦС или Загрузка сертификата ЦС и сохраняем сертификат в любое удобное место.

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

    Для получения клиентского сертификата снова откроем сайт ЦС и выберем Запрос сертификата — расширенный запрос сертификатаСоздать и выдать запрос к этому ЦС. Заполняем форму запроса, в качестве имени указываем имя ПК или пользователя, в качестве типа сертификата указываем Сертификат проверки подлинности клиента и жмем кнопку Выдать.

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

    В этом случае можно добавить данный узел в зону Надежные узлы и установить низкий уровень безопасности для этой зоны. В Windows Server понадобится также разрешить загрузку неподписанных ActiveX.

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

    Теперь вернемся на клиентский ПК и еще раз откроем сайт ЦС. На этот раз выберем Просмотр состояния ожидаемого запроса сертификата, вы увидите свой запрос, щелкнув на которой вы попадете на страницу Сертификат выдан и сможете сразу его установить.

    Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.

    По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.

    Службы сертификации Active Directory. Базовые знания

    Работают в Windows еще с версии 2000. ADCS позволяют выдавать и обслуживать цифровые сертификаты на основе ключей.

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

    На практике сертификаты применяются для:

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

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

    Шифрования каналов – клиент шифрует пакеты публичным ключом сервера, таким образом только сервер, обладающий приватным (закрытым) ключом сможет расшифровать информацию от клиента.

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

    За 17 лет службы сертификации конечно же модернизировались. Последние серьезные изменения в ADCS были внесены в версиях Windows 2012 и 2012 R2 . Наиболее важные из них:

    • Поддержка модуля политики для службы регистрации сертификатов для сетевых устройств
    • Аттестация ключей доверенного платформенного модуля (TPM)
    • Windows PowerShell для служб сертификатов
    • Поддержка обновления сертификата с прежним ключом
    • Поддержка международных имен доменов

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

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

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

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

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

    1. включить корневой центр сертификации
    2. обновить CRL
    3. опубликовать полученный CRL на всех точках проверки отозванных сертификатов.

    После этого обычно выполняются другие процедуры обслуживания сервера. Такие как, установка обновлений и резервное копирование. После чего сервер выключается до следующего обновления CRL или другой потребности его запуска.

    Все операции по управлению сервисом выполняются из нескольких консолей:

    • Управление сервисом
    • Консоли сертификатов

    А также с помощью PowerShell и утилиты certutil, с возможностями которой можно ознакомится, набрав certutil /help в командной строке Windows.

    В частности с помощью командной строки можно публиковать сертификаты и списки отозванных сертификатов в базе Active Directory. Также через службы Active Directory Domain Services (а именно через групповые политики) можно настроить распространение сертификатов: например, добавление сертификата корневого центра сертификации в Trusted certificates рабочих станций организации.

    Помимо того, что сертификат содержит пару закрытого и открытого ключа, в нем также хранится служебная информация, в том числе о том, кому и когда выдан сертификат, алгоритмах генерации длине ключа и пр. Сертификат генерируется по шаблону, который должен быть опубликован уполномоченным администратором. По умолчанию Active Directory Certificate Services имеют набор заготовок шаблонов для различных сервисов (Web-server, Exchange server, RDP Gateway server и пр ), на базе которых можно также создавать шаблоны под собственные нужды.

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

    • Сертификаты для веб ресурса.
    • Сертификаты для защиты соединения.
    • Сертификаты для цифровой подписи.

    Наша компания готова помочь в настройке и администрировании служб сертификации на базе Microsoft Windows 2016 и более ранних версий, а также в выполнении любых работ по защите веб ресурсов, соединений и данных с использованием сертификатов. Обращайтесь, [email protected]

    Active Directory Certificate Services

    В этой статье я рассмотрю следующие темы о тонкостях и лучших практиках для реализации PKI от Microsoft — Active Directory Certificate Services:

    Общие представления о PKI

    Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:

    • Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
    • отношения всеобщего доверия к ЦС
    • выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
    • различные службы поддержки PKI
      • списки отзывов сертификатов (CRL)
      • сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
      • Web Enrollment (средство запроса сертификатов через Web)

    Автоматический запрос сертификатов

    От центра сертификации нет толку, если клиентские компьютеры в вашей сети не имеют к нему доверия и/или не получают сертификаты. При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС и автоматический запрос сертификатов компьютера у него. Однако, при некоторых сценариях эти политики необходимо настраивать вручную и в этом поможет статья TechNet Configure Computer Certificate Autoenrollment .

    Ручная установка сертификата корневого ЦС

    Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации . Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:

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

    Через MMC

    Открыть MMC с правами администратора » добавить оснастку Сертификаты » выбрать в качестве области Локальный компьютер » импортировать нужный сертификат в хранилище Доверенные корневые центры сертификации . Более подробно в статье TechNet Manage Trusted Root Certificates .

    Через свойства сертификата

    Запустить командную строку с правами админа » вызвать в ней с:pathtocert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер .

    Через командную строку

    Потребуется утилита CertMgr , с помощью нее нужно выполнить следующую команду:

    Проверка отзыва сертификатов

    Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

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

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

    • CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
    • Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)

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

    За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation . От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.

    Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network . Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.

    Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:

    где name.cer — имя выданного сертификата.

    Следует иметь ввиду, что проверка отзыва по протоколу OCSP проходит успешно только в том случае, если сертификат ЦС, выдавшего проверяемый сертификат, установлен в хранилище доверенных сертификатов локального компьютера.

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

    Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:

    • запрашивать сертификаты пользователями без участия администратора
    • предоставлять по требованию сертификат корневого ЦС
    • выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
    • делать это все через интернет
    • сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС

    Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов

    • в случае установки Web Enrollment на отличный от ЦС компьютер, необходимо обязательно выполнить шаги, описанные в статье TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account , иначе служба не будет работать, выдавая следующую ошибку:
    • та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
    • при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS

    Запрос сертификата с альтернативным именем

    Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).

    По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:

    Запрос через консоль MMC

    Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты , для этого…

    • В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
    • Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
    • Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.

    Запрос через утилиту certreq

    Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq . Чтобы создать сертификат нужно действовать по следующему алгоритму:

    1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.

    [Version]
    Signature=»$Windows NT$»

    [NewRequest]
    Subject = «CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU»
    KeySpec = 1
    KeyLength = 2048
    HashAlgorithm = SHA256
    Exportable = TRUE
    MachineKeySet = TRUE
    SMIME = FALSE
    PrivateKeyArchive = FALSE
    UserProtected = FALSE
    UseExistingKeySet = FALSE
    RequestType = PKCS10
    KeyUsage = 0xa0
    ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
    FriendlyName = «server.argon.local with SAN»

    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.1 ; Server Authentication

    [RequestAttributes]
    CertificateTemplate = WebServer

    [Extensions]
    2.5.29.17 = «»
    _continue_ = «DNS=*.argon.com.ru&»
    _continue_ = «DNS=argon.com.ru&»
    _continue_ = «DNS=server.argon.local&»
    _continue_ = «DNS=server&»
    _continue_ = «DNS=localhost»

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

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

    3. Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).

    4. Выполнить установку полученного сертификата на целевой компьютер следующей командой

    5. PROFIT. В результате описанных действий в хранилище сертификатов компьютера будет создан сертификат с закрытым ключом, пригодный для авторизации сервера по нескольким именами, прописанным .inf файле.

    Обобщенные лучшие практики

    Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2

    • На контроллере домена развернут корневой центр сертификации
    • Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
    • В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
    • На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
      • Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
      • Online Responder для проверки отзыва сертификатов по протоколу OCSP
    • Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
      • Remote Desktop Gateway
      • Outlook Web Access
      • DirectAccess
      • SharePoint

    Устранение неполадок служб сертификации Active Directory

    В этом разделе перечислены типичные проблемы, встречающиеся при работе с оснасткой «Центр сертификации» и самими центрами сертификации. Дополнительные сведения о разрешении вопросов и устранении неполадок, связанных с центрами сертификации, см. на веб-сайте, посвященном разрешению вопросов, связанных со службами сертификатов Active Directory (
    https://go.microsoft.com/fwlink/?LinkId=89215 ) (может быть на английском языке).

    Вид неполадки

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

  • Решение. Дождитесь окончание репликации групповой политики или используйте средство командной строки Gpupdate для принудительной немедленной репликации. Дополнительные сведения см. в описании команды Gpupdate на веб-сайте корпорации Майкрософт (
  • https://go.microsoft.com/fwlink/?linkid=94248 ) (может быть на английском языке).

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

    Решение. Войдите в систему с правами члена группы Администраторы предприятия или Администраторы домена, чтобы установить центр сертификации и веб-средства регистрации центра сертификации.

    Причина. Во время установки центра сертификации не было доступа к домену.

    Решение. Убедитесь, что во время установки центра сертификации отсутствуют неполадки, связанные с сетевыми подключениями к контроллеру домена.

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

    Решение. Войдите в систему как пользователь, являющийся членом группы Администраторы или Опытные пользователи, чтобы получить доступ к веб-страницам регистрации и загрузить новую версию программного обеспечения.

    Причина. Веб-страницы не установлены в центре сертификации.

    Решение. В командной строке центра сертификации выполните команду certutil -vroot, чтобы установить веб-страницы регистрации.

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

      Убедитесь, что учетная запись компьютера является действующей в домене.

    Используйте оснастку «Сертификаты», чтобы убедиться в том, что сертификат корневого центра сертификации находится в хранилище доверенных корневых центров сертификации на компьютере пользователя.

    Используйте оснастку «Сертификаты», чтобы убедиться в том, что контроллеру домена был выдан сертификат контроллера домена, который может быть удостоверен в корневом центре.

    При попытке регистрации сертификата, используя компьютер или учетную запись, входящую в домен, являющийся дочерним по отношению к тому домену, в котором расположен центр сертификации, будет отображено следующее сообщение об ошибке: «Не найдены шаблоны сертификатов. Нет таких ЦС, в которых вы имеете право запрашивать сертификат, или произошла ошибка доступа к Active Directory.»
    • Причина. Необходимые разрешения безопасности не установлены для шаблонов сертификатов.

  • Решение. Измените разрешения безопасности для шаблонов безопасности, чтобы включить учетные записи дочернего домена, из которого следует подавать заявки. Сведения о том, как задать управление доступом для шаблонов сертификатов, см. на странице «Выдача сертификатов, основанных на шаблонах сертификатов» (
  • https://go.microsoft.com/fwlink/?LinkID=142333 (страница может быть на английском языке) ).

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

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

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

    Причина. Сертификат агента регистрации настроен с использованием ключа криптографии следующего поколения, а сертификат был запрошен центром сертификации на основе Windows Server 2003.

    Решение. Используйте сертификат агента регистрации, совместимый с центрами сертификации под управлением Windows Server 2003, или запросите сертификат из центра сертификации на компьютере, работающем под управлением операционной системы Windows Server 2008 R2 или Windows Server 2008.

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

    Решение. Отключите или измените разрешения ограниченные разрешения инспектора перед повтором регистарции.

    Не удается добавить новый шаблон сертификата версии 2 или версии 3 в центр сертификации.
    • Причина: Центр сертификации установлен на сервере, работающем под управлением операционной системы Windows Server 2008 R2 Standard или Windows Server 2008 Standard. Шаблоны сертификатов версии 2 и 3, а также автоматическую регистрацию сертификатов можно использовать только при наличии центров сертификации, установленных в операционной системе Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Enterprise или Windows Server 2008 Datacenter.

    Решение. Обновите операционную систему на Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Datacenter, Windows Server 2008 Enterprise или Windows Server 2008 Datacenter.

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

    Читать еще:  Обновить политики домена команда
  • Ссылка на основную публикацию
    Adblock
    detector