В этой статье я расскажу о внедрении PKI на платформе Windows Server 2012, но материал актуален и для других версий Windows Server.

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

Да и перед тем как идти на курс, желательно не только ознакомиться с основами, но и пощупать технологию на практике, например в тестовой среде.

В конце статьи я приведу ссылки на материалы, которые пригодяться для самостоятельного обучения, и помогут копнуть глубже.

Возвращаясь к описанию статьи – это некий how-to, написанный мной в процессе создания демо-среды с набором корпоративных сервисов.

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

Что такое и зачем нужен PKI

Инфраструктура открытых ключей (Public-Key Infrastructure, PKI) является технологической основой инфраструктуры информационной безопасности предприятия, с помощью которой обеспечивается реализация таких принципов как:

• Конфиденциальность;
• Целостность;
• Подлинность;
• Не отрицание совершенных действий.

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

А защищать мы будем распространенные вещи объекты: файлы, письма, сайты и каналы – выражаясь официальнее можно предложить такой список:

• Подпись сообщений электронной почты;
• Шифрование сообщений электронной почты;
• Подпись электронных документов;
• Шифрование электронных документов;
• Проверка целостности и/или шифрование VPN трафика;
• Шифрование трафика веб-сайтов и порталов.

Когда цели, сроки и бюджет ясны, можем перейти к рассмотрению сути технологии.

В PKI используется два цифровых ключа:

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

Один из ключей (т.з. «открытый») известен всем, но имея его, невозможно определить второй, «закрытый» ключ, который известен только владельцу и хранится в надежном месте.

При проверке реализуется принцип: никто не доверяет никому, но все доверяют ЦС (Certification Authority, CA). CA в свою очередь подтверждает (либо не подтверждает) принадлежность открытого ключа пользователю, который владеет закрытым ключом.

 

Состав демо-среды:

 

t-gate (192.168.30.1): NAT+Firewall, используется для доступа и публикации в Интернет

t-rca (offline): Автономный корневой ЦС (Offline Root CA)

t-dc (192.168.30.2): Контроллер домена office.kagarlickij.kiev.ua

i-ica (192.168.30.3): Корпоративный подчиненный (издающий) ЦС + Web Enrollment

t-iis (192.168.30.4): Веб-сервер с сайтом, который будет доступен по https

d-ws2 (192.168.30.11): Доменная рабочая станция под управлением Windows 8 Enterprise

pc-19 (192.168.13.13): Сервер в рабочей группе под управлением Windows Server 2012

sf-ios (192.168.13.101): Смартфон под управлением iOS

sf-andr (192.168.13.102): Смартфон под управлением Android

Приступим к настройка корневого центра сертификации t-rca: перейдем в папкуC:\Windows и создадим там файл CAPolicy.inf (кодировка ANSI) следующего содержания:

[Version]
Signature=”$Windows NT$”
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
Notice=”Legal Policy Statement”
URL=http://pki.kagarlickij.kiev.ua/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
CRLPeriod=weeks
CRLPeriodUnits=26
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
AlternateSignatureAlgorithm=1

Установка параметра CRLDeltaPeriodUnits=0 CAPolicy.inf отключает публикацию разностных CRL — для автономного корневого ЦС применяется именно такая установка.

Добавим роль (быстрее это будет с помощью PowerShell):

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Затем пройдем по шагам и определим базовые настройки (нагляднее выглядит в Wizard), аналогичные указанным в CAPolicy.inf:

Ознакомимся с дефолтными настройками путей к CDP и AIA для нашего корневого центар сертификатов:

Get-CAAuthorityInformationAccess | fl

Get-CACRLDistributionPoint | fl

Настроим пути к CDP и AIA:

certutil -setreg CA\CRLPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n2:http:/ /pki.kagarlickij.kiev.ua/%3%8%9.crl”

certutil –setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http:/ /pki.kagarlickij.kiev.ua/%1_%3%4.crt”

Укажем параметры списка отзывов:

certutil -setreg CA\CRLDeltaPeriodUnits 1
certutil -setreg CA\CRLDeltaPeriod “Days”
certutil -setreg CA\CRLOverlapPeriodUnits 12
certutil -setreg CA\CRLOverlapPeriod “Hours”
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod “Years”

Включим аудит:

certutil -setreg CA\AuditFilter 127

Укажем раздел конфигурации в Active Directory:

certutil -setreg CA\DSConfigDN “CN=Configuration,DC=office,DC=kagarlickij,DC=kiev,DC=ua”

Перезапустим службу и опубликуем новый список отзывов:

net stop certsvc

net start certsvc

certutil -crl

Перенесем (например через виртуальный флоппи-диск) содержимое папки C:\Windows\system32\certsrv\certenroll\) с сервера t-rca на сервер i-ica и опубликуем сертификат корневого ЦС в AD:

certutil –dspublish –f %CaCertFileName.CRT% RootCA

Проверим результат с помощью ADSI Edit:

Теперь опубликуем список отзывов корневого ЦС:

certutil –dspublish –f %CrlFileName.CRL% RootCA

Если по каким-либо причинам доменное хранилище недоступно, можно добавить сертификат и список отзывов в локальное хранилище:

certutil –addstore –f root %CaCertFileName.CRT%

certutil –addstore –f root %CrlFileName.CRL%

Снова проверим результат с помощью ADSI:

Теперь установим IIS:

Install-WindowsFeature Web-WebServer -IncludeManagementTools

Затем добавим в DNS А запись о нашем узле pki.kagarlickij.kiev.ua и проверим резолв этого имени в адрес.

Скопируем в папку веб-сайта по-умолчанию сертификаты и списки отзывов корневого ЦС, а затем добавим права Modify для Cert Admins, Full Control для Domain Admins и Read&Execute для IIS AppPool\DefaultAppPool (IIS использует пул приложений по умолчанию, чтобы разрешить анонимный доступ. Благодаря этому пользователям разрешается проверять AIA и CDP, размещенные на IIS).

Также откроем общий доступ к папке wwwroot с такими правами:

Затем перейдем в раздел Request Filtering (на уровне Default Web Site) и на вкладке File Name Extensions нажмем Edit Feature Settings и включим чекбокс Allow Double Escaping (Разрешение двойного преобразования необходимо в случае публикации разностных CRL в IIS ввиду того, что файл разностных CRL содержит символ “+” подробнее тут).

Для Default Web Site анонимную аутентификацию будем выполнять не от имени учетки, а от имени пула:

Положим файл cps.txt в C:\interpub\wwwroot , для тестирования текст для cps можно взять RFC – http://www.ietf.org/rfc/rfc3647.txt

Перезапустим IIS: iisreset

После этого можно проверить доступность crt, crl, cdp через браузер на другом узле, например t-dc

Перейдем к настройке издающего ЦС, первым делом положим в C:\Windows  CAPolicy.infследующего содержания:

[Version]
Signature=”$Windows NT$”
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
Notice=”Legal Policy Statement”
URL=http://pki.kagarlickij.kiev.ua/cps.txt
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=5

Установим роль AD CS:

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Пройдем по шагам мастера и определим базовые настройки:

После этого, в C:\ появиться файл запроса *.req , который мы перенесем на t-rca и обработаем запрос:

certreq -submit *.req , запомним номер запроса.

Откроем консоль центра сертификации, перейдем в Pending Requests , нажмем правой кнопкой на запросе и выберем пункт Issue.

Вернемся в PowerShell и экспортируем выданный сертификат:

certreq –retrieve %Идентификатор_запроса% *.crt

Этот этап выглядит вживую следующим образом:

На сервере i-ica откроем Certification Authority – All Tasks – Install CA Certificate , выберем сертификат (формат Х.509) и запустим службу (если будут проблемы с недоверием к руту – они решаються с помощью обновления групповой политики).

Настроим точки публикации CDP и AIA:

certutil -setreg CA\CRLPublicationURLs “65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n6:http:/ /pki.kagarlickij.kiev.ua/%3%8%9.crl\n65:file://\\i-ica\wwwroot\%3%8%9.crl”

certutil –setreg CA\CACertPublicationURLs “1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http:/ /pki.kagarlickij.kiev.ua/%1_%3%4.crt\n1:file://\\i-ica\wwwroot\%1_%3%4.crt”

Укажем параметры списка отзывов:

certutil -setreg CA\CRLOverlapPeriodUnits 12
certutil -setreg CA\CRLOverlapPeriod “Hours”
certutil -setreg CA\ValidityPeriodUnits 5
certutil -setreg CA\ValidityPeriod “Years”

Включим аудит:

certutil -setreg CA\AuditFilter 127

В локаьной политике включим Audit Object Access, для того чтобы потенциально можно было выполнить аудит ЦС:

Включим возможность выдачи сертификатов со списками альтернативных имен (SAN):

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Перезапустим службу и опубликуем новый список отзывов:

net stop certsvc

net start certsvc

certutil -crl

Откроем ADSI и убедимся что добавление издающего ЦС прошло штатно:

Включим автоматическую регистрацию сертификатов через групповую политику:

Откроем Group Policy Management  (будем редактировать Default Domain Policy) Computer Configuration – Policies – Windows Settings – Security Settings – Public Key Policies , откроем Certificate Services Client – Auto-Enrollment , там установим Enabled и включим оба чекбокса (Renew expired certificates, update pending certificates и Remove revoked certificates and Update certificates that use certificate templates).

Также настроим Automatic Certificate Request:

Переключимся на сервер t-iis, выполним gpupdate /force , затем cd cert:\LocalMachine\My и dir | format-list и убедимся что мы получили сертификат “на сервер” от i-ica.

Теперь можем запросить сертификат для администратора веб-сервера:

Ознакомится с сертификатами пользователя можно также используя консоль Users and Computers, включив в ней Advanced Features:

Для обеспечения возможности сертификатов используя веб установим и настроим рольCertification Authority Web Enrollment на сервере i-ica1, какие-либо пояснения тут не нужны. После успешной установки откроем http://pki.kagarlickij.kiev.ua/certsrv :

Теперь подпишем его сертификатом хоста и сделаем привязку к https, для этого сделаем запрос на сертификат из IIS:

Обработаем запрос через веб интерфейс:

Проверим сертификат выполнив:

certutil -verify – urlfetch %certificate path%

Установим сертификат с помощью mmc:

Настроим привязку нашего сайта к https используя полученный сертификат:

Убедимся что сайт доступен по https:

Самое время проверить все ли ок с точки зрения системы, для этого запустим pkiview.mscи убедимся что с сертификатами и списками отзывов все ок:

На уровне Enterprise PKI выберем Manage AD Containers , пройдемся по табам и убедимся что там тоже все в порядке:

Ранее мы уже включили поддержку SAN, а теперь предположим что на сервере t-iisнаходится некий веб-портал, который должен быть доступен по нескольким именам:portal.kagarlickij.kiev.ua, portal.office.kagarlickij.kiev.ua, t-iis, t-iis.office.kagarlickij.kiev.ua

Для начала создадим файл request.inf на Рабочем столе сервера t-iis:

[Version]
Signature=”$Windows NT$”
[NewRequest]
Subject = “CN=t-iis.office.kagarlickij.kiev.ua, OU=IT, O=Demo, L=Kiev, S=Kiev, C=UA”
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 = “Portal Web Site with SAN”
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
[RequestAttributes]
CertificateTemplate = WebServer
[Extensions]
2.5.29.17 = “{text}”
_continue_ = “DNS=portal.kagarlickij.kiev.ua&”
_continue_ = “DNS=portal.office.kagarlickij.kiev.ua&”
_continue_ = “DNS=t-iis.office.kagarlickij.kiev.ua&”
_continue_ = “DNS=t-iis&”

Затем выполним

certreq -new request.inf

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

Полученный запрос обработаем в ЦС, результат (сертификат в формате .cer) выгрузим на сервер t-iis , а затем импортируем его по аналогии с импортом через mmc (описывал чуть выше):

Подпишем портал (в примере это дефолтная заглушка) полученным сертификатом и убедимся что сайт полноценно доступен по разным именам:

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

TechNet - http://technet.microsoft.com/en-us/library/hh831348.aspx

.. эта же статья на русском - http://technet.microsoft.com/ru-ru/library/hh831348.aspx

Довольно исчерпывающий материал - http://blogs.technet.com/b/askds/archive/2010/05/27/designing-and-implementing-a-pki-part-iii-certificate-templates.aspx

Step by Step Guide – Single Tier PKI Hierarchy Deployment -http://social.technet.microsoft.com/wiki/contents/articles/11750.step-by-step-guide-single-tier-pki-hierarchy-deployment.aspx#Install_and_Configure_Online_Responder_OCSP_Responder