Этой небольшой статьей я планирую начать цикл статей, посвященных настройке Windows Server 2008 R2 . Планируется несколько статей — пошаговых мануалов, таких как миграция с Exchange 2003 на Exchange 2010, публикация сервисов Exchange на TMG, настройка Remote Desktop Services и опять же публикация их на TMG и т.п.
Мы рассмотрим установку служб сертификации Active Directory (AD CS), так как они мне понадобятся во всех последующих статьях.
Исходные данные : как всегда, имеется в наличии домен testcompany.local , контроллер домена dc01 под управлением Windows Server 2008 R2, единственный, для тестовой среды достаточно.
Будет рассматриваться упрощенная модель развертывания служб сертификации, достаточная для большинства небольших и средних организаций, с установкой единственного центра сертификации с типом Enterprise. Для развертывания инфраструктуры с подчиненными центрами сертификации эта статья не подходит. Впрочем, если всё же захочется, в Microsoft Technet всё есть, дерзайте. Также можно ознакомиться со статьей на сайте Вадима Поданса: Обсуждение схем иерархии Certification Authority .
В тестовой среде я буду устанавливать службы сертификации (AD CS) на контроллер домена, dc01 , в реальной же сети, есть варианты. Если поставить на контроллер домена, то корневой сертификат автоматом распространится на все компьютеры домена без каких-либо усилий с вашей стороны. На отдельном сервере придется публиковать его в AD. Редакцию лучше выбрать Windows Server 2008 R2 Enterprise Edition, в которой можно будет создавать свои шаблоны сертификатов, а также там присутсвуют другие возможности, недоступные в редакции Standard. Различия можно увидеть по этой ссылке: http://technet.microsoft.com/en-us/library/cc755071.aspx . Не всем это правда будет нужно, но тем не менее, всегда лучше иметь больше возможностей, чем меньше 🙂
Запускаем Server Manager > Roles > Add Roles. Запустится визард, в нем на шаге Select Server Roles ставим галку напротив строчки Active Directory Certificate Services и нажимаем кнопку Next:
На следующем шаге Introduction to Active Directory Certificate Services
внимательно читаем, что там написано и нажимаем Next.
На шаге Select Role Services
дополнительно ставим галку Certification Authory Web Enrollment, остальные компоненты нам пока не понадобятся:
Появится окно с компонентами, которые необходимо добавить для этой роли, в нем нажимаем Add Required Role Services:
Следующий шаг — Specify Setup Type — выбор типа Certificate Authority, выбираем Enterprise, как планировали выше и нажимаем Next:
Следующий шаг — Specify CA Type — выбор корневого или подчиненного CA, выбираем корневой естественно, нажимаем Next:
Далее на шагах Setup Privat Key
и Criptography
соглашаемся с значениями по умолчанию и переходим к шагу Configure CA Name
. Здесь задаем понятное имя нашего корневого центра сертификации, в данном случае TestCompany Root CA:
На шаге Set Validate Period задаем срок действия сертификата корневого CA, в моем примере можно согласиться с значением по умолчанию в 5 лет, в производственной среде можно сделать побольше, лет 10-15:
На всех дальнейших шагах соглашаемся с значениями по умолчанию, нажимаем везде Next и на последнем шаге Install:
Работают в Windows еще с версии 2000. ADCS позволяют выдавать и обслуживать цифровые сертификаты на основе ключей.
Любой сертификат представляет собой пару закрытого и открытого ключа. Закрытый ключ – приватная информация, идентифицирующая владельца, требующая защиты и не подлежащая распространению. Открытый ключ – доступная любому часть, использующаяся для проверки
На практике сертификаты применяются для:
Аутентификации – пользователь подписывает пакет приватным ключом из выданного ему сертификата, а сервер аутентификации проверяет подпись публичным ключом этого же сертификата, который опубликован в доступном серверу месте.
Подписи документов — пользователь подписывает пакет приватным ключом из выданного ему сертификата, а другие пользователи, у которых есть доступ к публичному ключу сертификат подписывающего, используя публичный ключ, могут убедиться, что именно владелец сертификата подписал документ.
Шифрования каналов – клиент шифрует пакеты публичным ключом сервера, таким образом только сервер, обладающий приватным (закрытым) ключом сможет расшифровать информацию от клиента.
Шифрование данных — два сотрудника, обменявшись открытыми (публичными) ключами, могут шифровать с их помощью файлы. Таким образом, расшифровать файл сможет только владелец приватного ключа. Или другой пример: для шифрования диска система использует публичный ключ, в то время как приватный хранится на флешке, без которой невозможно дешифрование.
За 17 лет службы сертификации конечно же модернизировались. Последние серьезные изменения в ADCS были внесены в версиях Windows 2012 и 2012 R2 . Наиболее важные из них:
- Поддержка модуля политики для службы регистрации сертификатов для сетевых устройств
- Аттестация ключей доверенного платформенного модуля (TPM)
- Windows PowerShell для служб сертификатов
- Поддержка обновления сертификата с прежним ключом
- Поддержка международных имен доменов
Простейшая архитектура Certificate services состоит из 2х серверов: корневого и выдающего. Помимо этого в инфраструктуре наверняка присутствует домен-контроллер, который может быть использован, как точка распространения сертификатов. Также для этих целей желательно иметь сервер с ролью Web. В прочем этот функционал может быть настроен на сервере с ролью выдающего центра сертификации.
Для того, чтобы службы сертификации заработали в вашей инфраструктуре необходимо настроить:
Корневой сервер сертификации. Несет функции инстанции, которой мы безоговорочно доверяем. Корневой сервер сертификации выдает сертификат для подписи выдающего сервера сертификации. После генерации доверенного корневого сертификата и CRL этот сервер рекомендуется выключить и (слава богу используется виртуализация) сложить в сейф.
Выдающий сервер сертификации. Основной сервер, который выдает сертификаты в организации. Также может выступать в роли точки проверки отозванных сертификатов, храня на себе список отозванных сертификатов.
Сертификаты, которыми подписаны центры сертификации, а также списки отозванных сертификатов имеют срок жизни, по истечении которого должны быть обновлены. Обновление CRL выдающего сервера происходит автоматически, в то время как обновление CRL корневого центра сертификации нужно проводить вручную (по умолчанию – раз в пол года). Для этого необходимо:
- включить корневой центр сертификации
- обновить CRL
- опубликовать полученный 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 и более ранних версий, а также в выполнении любых работ по защите веб ресурсов, соединений и данных с использованием сертификатов. Обращайтесь,
Нет похожих статей.
В этой части серии использованы следующие сокращения и аббревиатуры:- PKI (Public Key Infrastructure ) - инфраструктура открытого ключа, набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. Поскольку аббревиатура ИОК не является распространённой, здесь и далее будет использоваться более знакомая англоязычная аббревиатура PKI.
- X.509 - стандарт ITU-T для инфраструктуры открытого ключа и инфраструктуры управления привилегиями.
- ЦС (Центр Сертификации ) - служба выпускающая цифровые сертификаты. Сертификат - это электронный документ, подтверждающий принадлежность открытого ключа владельцу.
- CRL (Certificate Revocation List ) - список отзыва сертификатов. Подписанный электронный документ, публикуемый ЦС и содержащий список отозванных сертификатов, действие которых прекращено по внешним причинам. Для каждого отозванного сертификата указывается его серийный номер, дата и время отзыва, а также причина отзыва (необязательно). Приложения могут использовать CRL для подтверждения того, что предъявленный сертификат является действительным и не отозван издателем… Приложения могут использовать CRL для подтверждения, что предъявленный сертификат является действительным и не отозван издателем.
- SSL (Secure Sockets Layer ) или TLS (Transport Layer Security ) - технология обеспечивающая безопасность передачи данных между клиентом и сервером поверх открытых сетей.
- HTTPS (HTTP/Secure ) - защищённый HTTP, является частным случаем использования SSL.
- Internet PKI - набор стандартов, соглашений, процедур и практик, которые обеспечивают единый (унифицированный) механизм защиты передачи данных на основе стандарта X.509 по открытым каналам передачи данных.
- CPS (Certificate Practice Statement ) - документ, описывающий процедуры управления инфраструктурой открытого ключа и цифровыми сертификатами.
Общий план развёртывания
Для развёртывания службы сертификатов нам потребуется четыре машины с Windows Server 2016, которые будут выполнять следующие функции:- Контроллер домена - необходим для функционирования домена Active Directory;
- Веб-сервер - будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
- Корневой ЦС - будет выполнять функции корневого ЦС;
- Подчинённый ЦС - будет выполнять функции издающего ЦС.
Подготовка контроллера домена
Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.
Следующим шагом будет конфигурирование политики автоматической выдачи сертификатов (autoenrollment). Эта политика нужна будет в процессе эксплуатации служб сертификатов для автоматической выдачи и обновления истёкших сертификатов на клиентах. Политика настраивается в конфигурации компьютера и пользователя:
- Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment
- User Configuration\Policies\Windows Settings\Security Settings\Public Key Infrastructure\Certificate Services Client – Auto-Enrollment
Сконфигурированный объект групповых политик (GPO) должен быть пристыкован к корню домена. Данную процедуру необходимо повторить во всех доменах текущего леса Active Directory.
Далее, необходимо создать запись типа CNAME с именем CDP на сервере ДНС, который будет указывать на веб-сервер (IIS). Эту процедуру необходимо выполнить как на внутреннем, так и на внешнем (который обслуживает зону в интернете) серверах ДНС. Запись можно создать при помощи PowerShell:
Add-DnsServerResourceRecord -CName -Name "cdp" -HostNameAlias "iis.contoso.com" -ZoneName "contoso.сom"
Подготовка веб-сервера
На веб-сервере нам потребуется выполнить следующее: установить службу IIS (если ещё не установлена), создать общую папку и сконфигурировать веб-сайт на использование этой папки.- Установка службы IIS
Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools
- Создание папки PKIdata
New-Item -ItemType Directory -Path C:\InetPub\wwwroot -Name PKIdata -Force
New-SmbShare -Path C:\inetpub\wwwroot\PKIdata -Name PKI -FullAccess everyone
После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.
- Создание веб-сайта
New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:\inetpub\wwwroot\PKIdata New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:\inetpub\wwwroot\PKIdata
- Включение поддержки Delta CRL
Import-Module -Name WebAdministration Set-WebConfigurationProperty -PSPath "MACHINE/WEBROOT/APPHOST" -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value "true"
Установка корневого ЦС
Фактическая установка ЦС будет включать в себя несколько этапов:- Установка компонента ЦС;
- Проверка установки.
В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.
Предварительная конфигурация
Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%\CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work . Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.Установка компонента ЦС
После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета Install-AdcsCertificationAuthority :
Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Root Certification Authority" ` -CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" ` -CAType StandaloneRootCA ` -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" ` -KeyLength 4096 ` -HashAlgorithmName SHA256 ` -ValidityPeriod "years" ` -ValidityPeriodUnits 15 ` -DatabaseDirectory $(Join-Path $env:SystemRoot "System32\CertLog")
Итоговая настройка
После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:| Название параметра | Значение параметра |
|---|---|
| Сервер ЦС | |
| 15 лет | |
| Точки публикации CRT | 1) По-умолчанию 2) C:\CertData\contoso-rca< CertificateName >.crt < CertificateName >.crt* |
| Точки распространения CRT | 1) cdp.contoso.com/pki/contoso-rca < CertificateName >.crt |
| Точки публикации CRL | 1) По-умолчанию 2) C:\CertData\contoso-rca< CRLNameSuffix >.crt 3) IIS:\InetPub\PKIdata\contoso-rca< CRLNameSuffix >.crt* |
| Точки распространения CRL | 1) cdp.contoso.com/pki/contoso-rca < CRLNameSuffix >.crt |
| Сертификат | |
| Состав CRL | Base CRL |
| Base CRL | |
| Тип | Base CRL |
| Срок действия | 6 месяцев |
| Расширение срока действия | 1 месяц |
| Алгоритм подписи | SHA256 |
| Публикация в AD | Нет |
Скрипт настройки
Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe: ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Root CA post-installation script::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва:: в отдельные переменные
SET CrlLocal=C:\CertData\contoso-rca%%8.crl
SET CDP=http://cdp.contoso.com/pki/contoso-rca%%8.crl
SET AIA=http://cdp.contoso.com/pki/contoso-rca%%4.crt:: Создаём папку в корне системного диска, куда будут записываться файлы ЦС. Эта папка:: создаётся для удобства, чтобы не искать папку CertEnroll в глубине папки Windows.
md C:\CertData:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8.crl\n1:%CrlLocal%\n2:%CDP%"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"
:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы:: вручную переименовываем его в необходимый формат и копируем в папку CertData
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-rca.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-rca.crt C:\CertData:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 15
certutil -setreg CA\ValidityPeriod "Years"
:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CA\CRLPeriodUnits 180
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapPeriod "Months"
certutil -setreg CA\CRLOverlapUnits 1:: Отключаем дифференциальные списки отзыва (или Delta CRL)
certutil -setreg CA\CRLDeltaPeriodUnits 0:: Отключаем генерацию кросс-сертификатов
certutil -setreg ca\CRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
certutil –setreg ca\CRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc:: Публикуем списки отзыва.
certutil -CRL
Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «\n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:
| Название галочки в MMC | Числовое значение | Название галочки в MMC | Числовое значение |
|---|---|---|---|
| Publish CRLs to this location. | 1 | Include in the AIA extension of issued certificates. |
2 |
| Include in the CDP extension of issued certificates. | 2 | Include in the Online Certificate Status. Protocol (OCSP) extension. | 32 |
| Include in CRLs. Clients use this to find Delta CRL locations. | 4 | ||
| Include in all CRLs. Specifies where to publish in AD DS when publishing manually. | 8 | ||
| Publish Delta CRLs to this location. | 64 | ||
| Include in the IDP extension of issued CRLs. | 128 |
В каждом пути включены переменные с двойным знаком процента «%%». Это переменные, которые ЦС при формировании пути будет автоматически заполнять исходя из типа переменной.
Первый знак процента используется как эскейп-символ, чтобы процессор командной строки воспринял следующий знак процента как литерал. Дело в том, что знак процента в командном процессоре CMD является служебным символом. Сервер ЦС так же использует знак процента для указания, что это переменная. Для исключения конфликта в командном процессоре используется последовательность из двух знаков процента.
Следующая таблица содержит описание всех доступных переменных и их краткое описание:
| Переменная в редакторе расширений CDP и AIA | Переменная в скрипте | Где используется | Значение |
|---|---|---|---|
| < ServerDNSName > | %1 | CDP/AIA | Полное ДНС имя сервера ЦС |
| < ServerShortName > | %2 | CDP/AIA | Короткое (NetBIOS) имя сервера ЦС |
| < CaName > | %3 | CDP/AIA | Имя ЦС (атрибут CN в сертификате) |
| < CertificateName > | %4 | AIA | Индекс сертификата ЦС. Используется только при обновлении сертификата ЦС. |
| < ConfigurationContainer > | %6 | CDP/AIA | Путь к configuration naming context в Active Directory |
| < CATruncatedName > | %7 | CDP/AIA | Укороченное (санитизированное) имя сертификата ЦС. В общем случае будет совпадать с полным именем ЦС |
| < CRLNameSuffix > | %8 | CDP | Индекс ключа ЦС, которым был подписан данный CRL. Используется при обновлении ключевой пары ЦС. |
| < DeltaCRLAllowed > | %9 | CDP | Добавляет суффикс для Delta CRL (знак «+»). |
| < CDPObjectClass > | %10 | CDP | |
| < CAObjectClass > | %11 | CDP/AIA | Класс объекта в Active Directory |
Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.
Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.
Опытные администраторы знают к чему приводит включение Audit Object Access - к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.
Прочие настройки
После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:- Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
- Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
- Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.
Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:
Certutil -f -dspublish path\contoso-rca.crt RootCA
Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:
Certutil -f -addstore Root path\contoso-rca.crt
Установка издающего ЦС
Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:- Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
- Установка компонента ЦС;
- Выполнение постустановочной конфигурации;
- Проверка установки и конфигурации.
Предустановочная конфигурация
Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:- Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
- Администраторы сами должны определять какие шаблоны будут использовать в организации.
; заголовок INI файла
Signature= "$Windows NT$"
; указываем список политик, которые будут включены в сертификат ЦС. В нашем; случае будет одна политика под названием AllIssuancePolicies.
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0
Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.
Установка компонента ЦС
Прежде всего необходимо добавить установочные компоненты для AD CS:Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools
После этого посмотрим на установочную таблицу, чтобы определить параметры установки:
| Название параметра | Значение параметра |
|---|---|
| Сервер ЦС | |
| Класс ЦС | Enterprise CA |
| Тип ЦС | Subordinate CA | Нет |
| Сертификат | |
| Имя сертификата | Contoso Lab Issuing Certification authority |
| Дополнительный суффикс | OU=Division Of IT, O=Contoso Pharmaceuticals, C=US |
| Провайдер ключа | RSA#Microsoft Software Key Storage Provider |
| Длина ключа | 4096 бит |
| Алгоритм подписи | SHA256 |
| Срок действия | 15 лет (определяется вышестоящим ЦС) |
| Политики выдачи | 1) Имя: All Issuance Policies OID=2.5.29.32.0 URL=http://cdp.contoso.com/pki/contoso-cps.html |
| Basic Constraints | isCA=True (тип сертификата - сертификат ЦС) PathLength=0 (запрещается создание других промежуточных ЦС под текущим ЦС). |
Install-AdcsCertificationAuthority -CACommonName "Contoso Lab Issuing Certification authority" `
-CADistinguishedNameSuffix "OU=Division Of IT, O=Contoso Pharmaceuticals, C=US" `
-CAType EnterpriseSubordinateCa `
-CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
-KeyLength 4096 `
-HashAlgorithmName SHA256
После выполнения этой команды будет выведено сообщение о том, что установка ЦС не завершена и для её завершения необходимо отправить сгенерированный запрос (находится в корне системного диска) на вышестоящий ЦС и получить подписанный сертификат. Поэтому находим файл с расширением «.req» в корне системного диска и копируем его на корневой ЦС и на корневом ЦС выполняем следующие команды:
# отправляем запрос на ЦС.
certreq -submit "C:\CA-01.contoso.com_Contoso Lab Issuing Certification authority.req"
# предыдущая команда выведет номер запроса. Укажите этот номер запроса в следующей команде
# в моём случае это номер 2
certutil -resubmit 2
# после выпуска сертификата сохраните его в файл. При этом укажите тот же самый номер
# запроса, который был указан после выполнения первой команды
certreq -retrieve 2 C:\subca.crt
Полученный файл (subca.crt) необходимо скопировать обратно на издающий ЦС и завершить инсталляцию:
Certutil -installcert c:\subca.crt
net start certsvc
Мы устанавливаем на ЦС выписанный сертификат и запускаем службу сертификатов. После успешной установки можно запустить оснастку Certification Authorities MMC (certsrv.msc) и убедиться, что сертификат успешно установлен и ЦС в работающем состоянии. Теперь осталось дело за постустановочной конфигурацией.
Итоговая настройка
По аналогии с корневым ЦС, нам потребуется сконфигурировать ряд параметров на издающем ЦС. Для этого мы снова напишем BATCH скрипт с использованием утилиты certutil.exe. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:Аналогичная таблица составляется и для издающего ЦС.
| Название параметра | Значение параметра |
|---|---|
| Сервер ЦС | |
| Срок действия издаваемых сертификатов | Максимально: 5 лет (остальное контролируется шаблонами сертификатов) |
| Публикация в AD (контейнеры) | AIA NTAuthCertificates |
| Состав CRL | Base CRL Delta CRL |
| Точки публикации CRT | 1) По-умолчанию 2) \\IIS\PKI\contoso-pica< CertificateName >.crt |
| Точки распространения CRT | 1) cdp.contoso.com/pki/contoso-pica < CertificateName >.crt |
| Точки публикации CRL | 1) По-умолчанию 2) \\IIS\PKI\contoso-pica< CRLNameSuffix >< DeltaCRLAllowed >.crl |
| Точки распространения CRL | 1) cdp.contoso.com/pki/contoso-pica < CRLNameSuffix >< DeltaCRLAllowed >.crl |
| Base CRL | |
| Тип | Base CRL |
| Срок действия | 1 неделя |
| Расширение срока действия | По умолчанию |
| Алгоритм подписи | SHA256 |
| Публикация в AD | Нет |
| Delta CRL | |
| Тип | Delta CRL |
| Срок действия | 1 день |
| Расширение срока действия | По-умолчанию |
| Алгоритм подписи | SHA256 |
| Публикация в AD | Нет |
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Issuing CA post-installation script::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва:: в отдельные переменные
SET CrlLocal=\\IIS\PKI\contoso-pica%%8%%9.crl
SET CDP=http://cdp.contoso.com/pki/contoso-pica%%8%%9.crl
SET AIA=http://cdp.contoso.com/pki/contoso-pica%%4.crt:: Настраиваем пути публикации и распространения для сертификатов ЦС и списков отзыва.
certutil -setreg CA\CRLPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n65:%CrlLocal%\n6:%CDP%"
certutil -setreg CA\CACertPublicationURLs "1:%windir%\system32\CertSrv\CertEnroll\%%1_%%3%%4.crt\n2:%AIA%"
:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы:: вручную переименовываем его в необходимый формат и копируем в сетевую папку
ren %windir%\system32\CertSrv\CertEnroll\*.crt contoso-pica.crt
copy %windir%\system32\CertSrv\CertEnroll\contoso-pica.crt \\IIS\PKI:: Задаём срок действия издаваемых сертификатов
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod "Years"
:: Задаём время жизни списков отзыва согласно нашей конфигурации:: базовый CRL
certutil -setreg CA\CRLPeriodUnits 1
certutil -setreg CA\CRLPeriod "weeks"
:: Delta CRL
certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod "days"
:: Включаем полный аудит событий на ЦС**
certutil -setreg CA\AuditFilter 127:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах
certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.32"
:: Включаем поддержку расширения OcspRevNoCheck, если планируется установка:: сетевого ответчика (Online Responder или OCSP сервера)
certutil -v -setreg policy\editflags +EDITF_ENABLEOCSPREVNOCHECK:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg ca\csp\CNGHashAlgorithm SHA256:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc:: Публикуем списки отзыва.
certutil -CRL
Заметим, что в путях CRLDistribution Points, изменены флаги публикации (добавлена публикация Delta CRL) и добавлена переменная %9 в имя файла для поддержки уникального имени для дельты.
Здесь мы больше не создаём папку в корне системного диска, а используем сетевую папку PKI на сервере IIS, куда напрямую копируем файл сертификата и публикуем списки отзыва.
Прочие настройки
После того как издающий ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:- Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена
- Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям.
- Откройте сетевую папку PKI (на сервере IIS) и убедитесь, что там есть два файла сертификата (корневого и издающего ЦС) и три списка отзыва (один для корневого, два для издающего ЦС). Убедитесь, что поля в сертификатах и списках отзыва соответствуют ожидаемым значениям.
И для издющего ЦС:
Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health
не показывает ошибок, это может судить о том, что PKI установлена верно.
Шаблоны сертификатов
Наряду с установкой издающего ЦС, в Active Directory устанавливается набор уже готовых шаблонов сертификатов. Их можно просмотреть в оснастке Certificate Templates MMC (certtmpl.msc). Рекомендации по шаблонам сертификатов:Использование готовых шаблонов сертификатов
Я рекомендую использовать их копии, даже если вы не планируете вносить в них изменения. Для создания копии шаблона выберите в списке подходящий шаблон, в контекстном меню выберите Duplicate Template и создайте его копию. Целесообразно в имя шаблона включить название компании, чтобы отличить предустановленный шаблон от вами созданного. Например, Contoso Web Server, Contoso Smart Card Logon . Это позволит сравнить настройки исходного и вами созданного шаблона в случае неработоспособности шаблона.
Версия шаблона
Начиная с Windows Server 2012, интерфейс создания шаблона несколько изменился. В самом начале появляется окно с выбором версии ОС на ЦС и предполагаемом клиенте:
Если у вас используются современные версии ОС (например, Windows 7 и выше), может появиться желание выставить настройки на максимум. Если вы не уверены, что ваше приложение совместимо с CNG (Cryptography Next Generation), следует использовать настройки, которые приведены на картинке. Если вы выставляете ОС сервера и клиента выше, чем Windows Server 2003/Windows XP, шаблон будет использовать криптографию несовместимую с этими приложениями. Например, большинство приложений, написанных на.NET, семейство продуктов System Center, службы федераций (AD FS) и т.д. не смогут использовать ключи таких сертификатов (но проверять смогут).
Успешно такие сертификаты смогут использовать приложения, которые используют не.NET, а нативные функции CryptoAPI. К таким приложениям можно отнести, например, IIS, Remote Desktop Services.
Поля Subject и Subject Alternative Names
Существует два метода заполнения поля Subject и расширения Subject Alternative Names: автоматический и ручной. Это настраивается в настройках шаблона сертификата, во вкладке Subject Name.
Если выбран второй пункт (как на картинке), ЦС игнорирует имя субъекта из запроса сертификата и заполняет эти поля из свойств учётной записи пользователя или устройства, которое запрашивает сертификат. В ряде случаев это не подходит (например, сертификаты для внутренних веб-сайтов) и имя субъекта заполняется из значения в запросе сертификата. Тогда переключатель необходимо выставить в верхнее положение. Дополнительно к этому, на вкладке Issuance Requirements обязательно надо выставить галочку «CA certificate manager approval».
Это необходимо затем, что имя для сертификата никак не проверяется. Если этот момент не контролировать, пользователь может запросить сертификаты на любое имя и скомпрометировать весь лес Active Directory. Вряд ли вы позволите рядовому пользователю получить сертификат на имя администратора. После требования одобрения запроса менеджером сертификатов на ЦС, каждый запрос с явным указанием субъекта сертификата будет попадать на ЦС в папку Pending Requests и не будет подписан, пока оператор ЦС не изучит его содержимое и не примет решение о выпуске. Т.е. каждый такой запрос необходимо вручную проверять на содержимое и убедиться, что в запросе указаны верные и допустимые имена. В противном случае запрос должен быть отклонён.
Права на шаблоны сертификатов
Шаблоны сертификатов в Active Directory хранятся в разделе configuration naming context, который реплицируется между всеми контроллерами домена в лесу. Поэтому для назначения прав на шаблоны сертификатов можно использовать только глобальные и универсальные группы. Избегайте назначения прав отдельным пользователям и устройствам.
Обновление сертификатов ЦС
Периодически необходимо обновлять сертификаты ЦС. Рассмотрим несколько аспектов, связанных с обновлением сертификатов ЦС.Периодичность обновления сертификата ЦС
Это делается в следующих случаях:
- Срок жизни сертификата ЦС истекает;
- Ключ ЦС скомпрометирован;
- Необходимо изменить длину ключа или алгоритм подписи;
- Слишком большой список отзыва (больше нескольких мегабайт).
Сертификат издающего ЦС должен обновляться за максимальный срок действия издаваемых сертификатов. В нашем случае срок действия сертификата издающего ЦС 15 лет, а максимальный срок действия издаваемых сертификатов 5 лет (см. конфигурационную таблицу). Это означает, что сертификат издающего ЦС необходимо обновить через 10 лет. Если это время затянуть, то мы не сможем обеспечить необходимый срок действия для самого долгосрочного шаблона.
Порядок обновления ЦС
В нашей двухуровневой иерархии сертификаты корневого и издающего ЦС имеют одинаковый срок действия. Поэтому, когда вы принимаете решение об обновлении сертификата любого ЦС, необходимо обновлять их вместе. Первым обновляется сертификат корневого ЦС, затем сертификат издающего ЦС.
Генерация ключей при обновлении сертификатов ЦС
При обновлении сертификатов ЦС вам предлагается две опции: использовать существующую ключевую пару или сгенерировать новую:
В диалоговом окне обновления ключевой пары приведены рекомендации Microsoft по выбору ключевой пары. Однако, практика показывает, что эти рекомендации устарели. Следует всегда генерировать новую ключевую пару. При использовании нескольких сертификатов ЦС клиентский модуль построения цепочки сертификатов иногда может ошибиться и выбрать неправильный сертификат. В базе знаний Microsoft отмечены такие проблемы. Примеры статей.
Друзья, столкнулся с интересной задачей — перенести центра сертификации Microsoft на новый сервер. Ну для начала мы должны понимать, что сама по себе инфраструктура открытых ключей просто так не разворачивается, следовательно уже есть выданные сертификаты и пред настроенные шаблоны. Причина, по которой может возникнуть необходимость миграции может быть много, от аппаратных проблем с сервером до переноса сервера в виртуальную среду.
Диспозиция:
Сервер Windows Server 2008 R2 c установленной ролью Active Directory Certificate Service и наличием аппаратных проблем)
Новый сервер Windows Server 2012 R2.
Перенос сервиса сертификации Active Directory на Windows Server 2012 R2.
Для начала подготовим резервную копию текущего центра сертификации. Для этого в оснастке Certificate Authority через
все задачи выбираем Архивация ЦС
Указываем архивирование всех элементов ЦС и путь для резервной копии
Для защиты закрытого ключа и файла сертификата центра сертификации указываем пароль
Архивация центра сертификации выполнена
Кроме базы данных центра сертификации Microsoft необходимо выгрузить и настройки, которые хранятся в реестре.
Для этого нужно выгрузить ветку
Итог должен выглядеть так:
После проведения подобных манипуляция можно остановить службу сервера сертификатов и в последствии удалить центр сертификации со старого сервера. Данный процесс описывать большого смысла не имеет. Идем дальше.
В промежуточном результате мы имеем экспортированную конфигурацию служба сертификатов Active Directory и желание его «реанимировать» на новом сервере.
Продолжим, установим cлужбу сертификатов Active Directory c необходимыми компонентами. Та этом вопросе останавливаться долго не будем, полагаю тут все просто:
Выбор необходимых ролей
Непосредственно процесс установки
После завершения установки диспетчер серверов автоматически предложит произвести первоначальную конфигурацию сервера сертификатов в соответствии с необходимыми требованиями. В нашем случае — это восстановление из действующей резервной копии.
Нажимаем «Настроить службы сертификатов Active Directory..»
В открывшемся окне выбираем учетную запись от имени которой будет производится настройка сервера. Роль должна входить в группу «Администраторы предприятия»
На следующем шаге указываем какие роли мы будем настраивать
В следующем окне выбираем “Корневой ЦС” в качестве типа ЦС и нажмите “ Далее” для продолжения.
На следующем этапе мы указываем что это не новая установка, а миграция. Т.е. у нас уже есть зарезервированный закрытый ключ. Выбираем этот пункт и продолжаем.
На этом этапе указываем путь к выгруженному сертификату со старого центра сертификации и пароль указанный при экспорте к нему.
После импорта то мы увидим наш сертификат
На следующем этапе определяем путь к базе данных сертификата. Тут я оставил все как есть, по умолчанию. Далее.
Итоговая проверка всех указанных выше параметров для настройки
Процесс настройки завершен.
После настройки параметров ЦС, преступим у его восстановлению. На созданном сервере сертификатов выбираем «Восстановление ЦС»
Выбираем элементы, и указываем путь к папке в которую произведен экспорт
На следующем этапе вводим пароль, который мы использовали для того, чтобы защитить закрытый ключ в процессе резервирования.
Восстановление завершено. Осталось только восстановить параметры, которые хранятся в реестре. Для этого как раз мы и экспортировали ветку реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
Для импорта открываем фай и добавляем его в реестр. Появится предупреждающее окно. Нажмите “ Да ” для восстановления ключа реестра.
Осталось проверить работу нового центра сертификации. Как видим, все выданные сертификаты перенесены.
Новый Web сервер работает выдачи сертификатов работает.
Итог: Сервис сертификации Active Directory успешно перенесен на новый сервер, при этом как мы видели, произошла и миграции в рамках операционной системы 2008R2 -> 2012R2.
Перед каждым администратором рано или поздно возникает необходимость обеспечить безопасный обмен информации через интернет, внешние и внутренние сети, а также проверку подлинности каждой из сторон, участвующих в обмене информацией. На помощь здесь приходит инфраструктура открытых ключей (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.
Теперь на сервере откроем оснастку Центр сертификации и в разделе Запросы на ожидание найдем наш запрос и щелкнув на него правой кнопкой выберем Все задачи - Выдать .
Теперь вернемся на клиентский ПК и еще раз откроем сайт ЦС. На этот раз выберем Просмотр состояния ожидаемого запроса сертификата , вы увидите свой запрос, щелкнув на которой вы попадете на страницу Сертификат выдан и сможете сразу его установить.
Если все сделано правильно, то сертификат успешно установится в хранилище личных сертификатов.
По окончании проверки не забудьте удалить ненужные сертификаты с клиентского ПК и отозвать их в центре сертификации на сервере.
Теги:
Трекбэк
Протокол RDP с защитой на уровне сети (SSL), к сожалению, не получил широкого распространения среди системных администраторов, предпочитающих защищать терминальные соединения другим способом. Возможно это связано с кажущейся сложностью способа, однако...
