В этой статье я расскажу о внедрении PKI на платформе Windows Server 2012, но материал актуален и для других версий Windows Server. В то же время я осознаю, что обучать людей специфическим темам могут позволить себе далеко не все, а задачи на внедрение могут возникать.
В конце статьи я приведу ссылки на материалы, которые пригодяться для самостоятельного обучения, и помогут копнуть глубже.
Возвращаясь к описанию статьи – это некий how-to, написанный мной в процессе создания демо-среды с набором корпоративных сервисов.
Применить описанную ниже конфигурацию можно в тестовой среде, а для продуктивной есть моменты, которые нужно отслеживать на аудите и уже исходя из них, корректировать план развертывания.
Инфраструктура открытых ключей (Public-Key Infrastructure, PKI) является технологической основой инфраструктуры информационной безопасности предприятия, с помощью которой обеспечивается реализация таких принципов как:
Для успешной реализации PKI недостаточно аппаратных и программных средств, но необходима разработка соответствующих политик и процедур, а главное четкое понимание что и от кого будем защищать.
А защищать мы будем распространенные вещи объекты: файлы, письма, сайты и каналы – выражаясь официальнее можно предложить такой список:
Когда цели, сроки и бюджет ясны, можем перейти к рассмотрению сути технологии.
В 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
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\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
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%
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:
Пройдем по шагам мастера и определим базовые настройки:
После этого, в 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\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”
В локаьной политике включим Audit Object Access, для того чтобы потенциально можно было выполнить аудит ЦС:
Включим возможность выдачи сертификатов со списками альтернативных имен (SAN):
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Откроем 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