Как установить сайт на windows server 2016

Опубликовано: 28.11.2019

Используемые термины: IIS, PHP, MySQL.

Чаще всего, PHP и MySQL устанавливается на серверы с Linux. Однако, при необходимости, можно настроить запуск и обработку PHP скриптов на Windows. Версии последней могут быть разные, например, Server 2008/2012/2016/2019 или не серверные системы, такие как, 7/8/10. Данная инструкция подойдет как для чайника, так и опытного специалиста (в качестве шпаргалки).

Установка IIS

Для установки веб-сервера, открываем Диспетчер серверов — переходим в Управление — Добавить роли и компоненты:

Если откроется окно с приветствием, нажимаем Далее:

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

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

Среди ролей выбираем Веб-сервер (IIS) — во всплывающем окне кликаем по Добавить компоненты:

Также среди ролей в подразделе «Разработка приложений» ставим галочку для установки CGI — этот компонент нам нужен для работы PHP:

При выборе компонентов ничего не меняем — нажимаем Далее:

Откроется окно настройки роли веб-сервера — просто нажимаем Далее:

Выбор служб ролей — нажимаем далее или, при необходимости, выбираем FTP-сервер:

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

Дожидаемся окончания процесса установки.

Сразу после установки IIS запускается автоматически. Но, если что, его можно запустить с помощью команды iisreset:

iisreset /start

* если выполнить данную команду без опций, то она перезапустить веб-сервер.

Также мы можем открыть диспетчер служб (команда services.msc) и перезапустить Службу веб-публикаций:

Открываем браузер и вводим адрес http://localhost — должен открыться стартовый портал:

Развертывание отдельного сайта

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

Открываем Диспетчер серверов — кликаем по Средства — Диспетчер служб IIS:

Находим раздел сайты — кликаем правой кнопкой мыши по Добавить веб-сайт…:

Заполняем данные для нового сайта:

* где:

• Имя сайта — произвольно имя будущего сайта.
• Физический путь — путь до папки на сервере, где будут расположены файлы сайта.
• Тип — тип соединения (http или https). Для первого запуска обойдемся http. При необходимости, его можно всегда поменять или использовать оба типа одновременно.
• IP-адрес — если на сервере много IP-адресов, то мы можем выбрать конкретный, на котором будет работать сайт.
• Порт — сетевой порт, на котором будет работать сайт. Как правило, это 80 для http или 443 для https.
• Имя узла — доменное имя сайта, при обращении по которому должен открываться создаваемый сайт.

После заходим в каталог с сайтом (в нашем примере, это C:inetpubwwwrootphp) и создадим в нем файл index.html со следующим содержимым:

<h1>Hello from PHP site</h1>

Открываем браузер и переходим на созданный сайт, например, как в нашей инструкции — http://php.dmosk.ru. Мы должны увидеть страницу с написанным нами текстом:

Тестовый сайт создан.

PHP

Установка PHP

Для установки php на Windows переходим на страницу загрузки PHP — выбираем нужную нам версию, например, последнюю стабильную и переходим по ссылке для загрузки версии для Windows:

Откроется страница с несколькими версиями пакета — там как мы ставим PHP как FastCGI, нам нужна версия «Non Thread Safe» (не потокобезопасная), так как она будет работать быстрее. И так, скачиваем zip-архив на сервер:

Для установка PHP на Windows достаточно просто распаковать содержимое архива в любой каталог, например, C:Program FilesPHP:

Делаем копию файла php.ini-production и переименовываем его в php.ini:

Открываем на редактирование данный файл и правим следующее:

open_basedir = C:inetpubwwwroot
…
cgi.force_redirect = 0
…
short_open_tag = On

* где open_basedir — директория, в которой будут разрешены PHP-скрипты; cgi.force_redirect — указывает будет ли скрипты обрабатываться при прямом запросе или только при запросе от веб-сервера. В IIS запросы контролируются самим веб-сервером, поэтому опция может оказать обратный эффект; short_open_tag — позволяет использовать короткий вид открывающих тегов для PHP.

Проверяем, что PHP работает. Открываем командную строку Windows — переходим в каталог с установленным PHP:

cd «C:Program FilesPHP»

Запускаем php с параметром -m:

php -m

Мы должны получить список подключенных модулей:

[PHP Modules]
bcmath
calendar
Core
ctype
…

Но если мы получим ошибку, связанную с отсутствием файла VCRUNTIME140.dll:

… необходимо установить Microsoft Visual C++ Redistributable. Переходим на страницу https://www.microsoft.com/ru-RU/download/details.aspx?id=52685 и скачиваем компонент:

После загрузки, устанавливаем его на сервер, после чего, снова пробуем вывести на экран модули php:

php -m

Настройка сайта на IIS для работы с PHP

И так, веб-сервер поднят, PHP установлено, сайт работает. Настроим связку IIS + PHP. Открываем панель управления IIS — переходим к созданному сайту и кликаем по Сопоставления обработчиков:

В меню справа кликаем по Добавить сопоставление модуля:

Заполняем поля:

* где:

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

Нажимаем OK и подтверждаем действие. Сопоставление создано.

Теперь заходим в Документ по умолчанию:

… и добавляем новый документ:

* в данном примете мы указываем, что по умолчанию сервер будет искать файл index.php, если таковой не указан явно в запросе.

Открываем в проводнике папку, в которой находятся файлы сайта (в нашем примере, C:inetpubwwwrootphp). Создаем файл index.php с содержимым:

Открываем браузер и снова переходим на наш сайт — мы должны увидеть страницу с информацией о php:

PHP Manager в IIS

Для того, чтобы упростить настройку PHP мы можем установить диспетчер PHP для IIS. Для этого переходим по ссылке https://www.iis.net/downloads/community/category/manage и переходим по ссылке для скачивания стабильной версии php-менеджера:

Скачиваем дополнение:

Выполняем установку на сервере, запустив загруженный файл. Открываем диспетчер управления IIS — мы должны увидеть PHP Manager:

Установка MySQL

MySQL для Windows можно скачать бесплатно. Переходим на страницу https://dev.mysql.com/downloads/mysql/ — выбираем операционную систему Microsoft Windows — кликаем по Go to Download Page:

На следующей странице выбираем для скачивания mysql-installer-community:

В открывшемся окне кликаем по No thanks, just start my download:

Начнется загрузка файла для установки MySQL. Дожидаемся скачивания и запускаем установочный файл — в открывшемся окне выбираем Server only:

В следующем окне кликаем по Execute:

… и дожидаемся установки СУБД:

Откроется окно конфигурации MySQL — нажимаем Next:

Выбираем установку одиночного сервера MySQL:

Оставляем все значения по умолчанию для настроек сети:

Требуем сложные пароли:

Вводим дважды пароль для пользователя root:

* также, на данном этапе мы можем сразу добавить новых пользователей.

Устанавливаем СУБД как сервис и стартуем его:

Настройки готовы для применения — нажимаем Execute:

Дожидаемся применения настроек и кликаем по Next:

Настройка завершена:

Установка завершена — нажимаем Finish.

Сервер баз данных готов к использованию.

По умолчанию, PHP поддерживаем mysql — в этом можно убедиться на странице phpinfo, найдя раздел mysqlnd:

IIS (Internet Information Services) — это службы интернета для ОС Windows. Включают в себя веб-сервер, ftp-сервер и другие компоненты. Применительно к веб-серверу IIS используется как синоним, что немного неправильно, однако достаточно распространено. В данной инструкции Мы будем настраивать веб-сервер IIS с поддержкой php. Это будет делаться в два этапа — сначала установим IIS, потом поставим PHP.

Так как веб-сервер входит в службы IIS (Internet Information Services), необходимо предварительно установить роль “Веб-Сервер (IIS)”. Для этого нажмите комбинацию клавиш Win+R для запуска командной строки и введите туда servermanager.

Далее запустить мастер установки ролей и компонентов нажав кнопку “добавить роли и компоненты”.

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

Далее ОС уточнит что именно вы хотите сделать — просто добавить роли и компоненты или установить службы удаленного доступа. Выберем установку ролей и компонентов.

Далее спрашивается на какие сервера устанавливать роли и компоненты. У вас может быть несколько серверов и они могут быть объединены в пул для централизованного управления с одной консоли. Также роль может быть установлена на виртуальный жесткий диск. Выберем интересующий нас сервер и нажмем далее.

На этом этапе необходимо выбрать роль, которую мы желаем установить на выбранный нами на предыдущем шаге сервер. В данном случае это роль “Веб-сервер (IIS)”.

Далее ОС предложит дополнительно установить необходимые компоненты — следует согласиться, нажав кнопку добавить компоненты.

Далее выводится информационное сообщение о том что такое роль iis.

Служба IIS — большой продукт, включающий в себя множество различных компонентов, поэтому далее потребуется указать какие именно компоненты следует установить — нас интересует веб-сервер. Остальные компоненты можно оставить как есть или отключить, если не хотите ставить лишние компоненты. Оставим также и консоль управления.

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

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

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

В данном случае мы видим что установка уже завершена. Можно приступать к настройке.

Для настройки перейдем в оснастке “диспетчер сервера” во вкладку IIS, выберем сервер и нажмем правую кнопку мыши. Выбираем из него “Диспетчер служб IIS”. Слева в дереве подключений находим наш сервер и разворачиваем его двойным щелчком мыши. Встаем на закладку “Сайты” и видим что сайт по умолчанию уже настроен.

.Для проверки достаточно в проводнике windows набрать http://<имя компьютера> после чего должна открыться тестовая страница iis.

Для установки PHP воспользуемся установщик Microsoft Web Platform Installer 5.0 (WPI), скачать который можно по этой ссылке.

Установим сам инсталлятор. Примем лицензионное соглашение и нажмем install.

Теперь запустим его выбрав в главном меню соответствующий пункт.

В правом верхнем углу введем php для поиска необходимого нам компонента.

Найдем нужную нам версию php — например 7.1.19 (x64) и добавим ее для установки кнопкой “Добавить”.

После этого нажмем кнопку установить внизу страницы.

Согласимся с лицензионными соглашениями нажав кнопку ”Принимаю”.

Начнется загрузка и установка компонентов,

По завершении нажмите кнопку “Готово”. Для проверки cоздадим индексный файл php файл c:inetpubwwwrootindex.php выводящий версию php.

После этого удаляем файлы iisstart* из папки c:inetpubwwwroot, и проверим что php работает набрав в браузере http://<имя или ip сайта>.

На этом настройка PHP+IIS на Windows Server 2016 окончена. В нашей базе знаний вы найдёте ещё множество статей посвящённых различным аспектам работы в Windows, а если вы ищете надежный виртуальный сервер под управлением Windows, обратите внимания на нашу услугу — Аренда виртуального сервера Windows.

В этом обзоре мы расскажем об особенностях установки и привязки бесплатного TLS/SSL сертификата от Let’s Encrypt для сайта на веб сервере IIS, запущенного на Windows Server 2019/2016/2012 R2.

Let’s Encrypt и ACME клиенты для Windows

Наличие TLS/SSL сертификата у сайта позволяет защитить данные пользователей, передаваемые по сети от атак человек-посередине (man-in-the-middle) и гарантировать целостность переданных данных. Некоммерческий центр сертификации Let’s Encrypt позволяет в автоматическом режиме через API выпускать бесплатные криптографические TLS сертификаты X.509 для шифрования (HTTPS) . Выдаются только сертификаты для валидации доменов (domain validation), со сроком действия 90 дней (есть ограничение – 50 сертификатов для одного домена в неделю). Но вы можете автоматически перевыпускать SSL сертификат для своего сайта по расписанию.

API интерфейс, позволяющий автоматически выпускать сертификаты называется Automated Certificate Management Environment (ACME) API. Для Windows систем на данный момент имеется 3 самых популярных реализации клиента ACME API:

• Утилита Windows ACME Simple (WACS) – утилита командной строки для интерактивного выпуска сертификата и привязки его к определенному сайту на вашем веб сервере IIS;
• Модуль Powershell ACMESharp – библиотека Powershell с множеством команд для взаимодействия через ACME API с серверами Let’s Encrypt;
• Certify – графический менеджер SSL сертификатов для Windows, позволяет интерактивно управления сертификатами через ACME API.

Клиент WACS для установки TLS сертификата Let’s Encrypt в IIS на Windows Server

Самый простой способ получить SSL сертификат от Let’s Encrypt — воспользоваться консольной утилитой Windows ACME Simple (WACS) (ранее проект назывался LetsEncrypt-Win-Simple). Она представляет собой простой мастер, который позволяет выбрать один из сайтов, запущенных на IIS, и автоматически выпустить и привязать к нему SSL сертификат.

Итак, предположим у нас имеется веб сайт на IIS, развёрнутый под управлением Windows Server 2016. Наша задача, переключить его в HTTPS режим, установив SSL сертификат от Let’s Encrypt.

Скачайте последний релиз клиента WACS со страницы проекта на GitHub https://github.com/PKISharp/win-acme/releases (в моем случае это версия v2.0.10 – файл win-acme.v2.0.10.444.zip).

Распакуйте архив в каталог на сервере с IIS: c:inetpubletsencrypt

Откройте командную строку с правами администратора, перейдите в каталог c:inetpub letsencrypt и запустите wacs.exe.

Запустится интерактивный мастер генерации сертификата Let’s Encrypt и привязки его к сайту IIS. Чтобы быстро создать новый сертификат выберите N: — Create new certificates (simple for IIS).

Затем нужно выбрать тип сертификата. В нашем примере нет необходимости использовать сертификат с псевдонимами (несколькими SAN — Subject Alternative Name), поэтому достаточно выбрать пункт 1. Single binding of an IIS site. Если вам нужен Wildcard-сертификат, выберите опцию 3.

Далее утилита выведет список сайтов, запущенных на сервере IIS и предложит выбрать сайт, для которого нужно создать и привязать новый SSL сертификат.

Укажите ваш email, на который будут отправляться уведомления о проблемах с обновлением сертификата сайта и другие о повешения (можно указать несколько email через запятую). Осталось согласится с условиями использования и Windows ACME Simple подключится к серверам Let’s Encrypt и попытается автоматически сгенерировать новый SSL сертификат для вашего сайта.

Процесс генерации и установки SSL сертификата Let’s Encrypt для IIS полностью автоматизирован.

По умолчанию выполняется валидация домена в режиме http-01 validation (SelfHosting). Для этого нужно, чтобы в DNS домена имелась запись, указывающая на ваш веб сервера. При запуске WACS в ручном режиме можно выбрать валидацию типа — 4 [http-01] Create temporary application in IIS (recommended). В этом случае на веб-сервере IIS будет создано небольшое приложение, через которое сервера Let’s Encrypt смогут провести валидацию.

Примечание. При выполнении TLS/HTTP проверки ваш сайт должен быть доступен снаружи по полному DNS имени по протоколам HTTP (80/TCP) и HTTPS (443/TCP).

Утилита WACS сохраняет закрытый ключ сертификата (*.pem), сам сертфикат и ряд других файлов в каталог C:Users%username%AppDataRoamingletsencrypt-win-simple. Затем она в фоновом режиме установит сгенерированный SSL сертификат Let’s Encrypt и привяжет его к вашему сайту IIS. Если на сайте уже установлен SSL сертификат (например, самоподписанный), он будет заменен новым.

В IIS Manager откройте меню Site Binding для вашего сайта и убедитесь, что для него используется сертификат, выданный Let’s Encrypt Authority X3.

В хранилище сертификатов компьютера сертификат Let’s Encrypt для IIS вы можете найти в разделе Web Hosting -> Certificates.

Windows ACME Simple создает новое правило в планировщике заданий Windows (win-acme-renew (acme-v02.api.letsencrypt.org)) для автоматического продления сертификата. Задание запускается каждый день, продление сертификата выполняется через 60 дней. Планировщик запускает команду:

C:inetpubletsencryptwacs.exe --renew --baseuri "https://acme-v02.api.letsencrypt.org"

Эту же команду вы можете использовать для ручного обновления сертфиката.

Перенаправление трафика IIS сайта с HTTP на HTTPS адрес

Чтобы перенаправить весь входящий HTTP трафик на HTTPS сайт, нужно установить модуль Microsoft URL Rewrite Module (https://www.iis.net/downloads/microsoft/url-rewrite), и убедиться, что в настройках сайта не включена опция обязательного использования SSL (Require SSL). Осталось настроить редирект в файле web.config:

<system.webServer>
<rewrite>
<rules>
<rule name="HTTP to HTTPS Redirect" enabled="true" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>

Также вы можете настроить перенаправление трафика через URL Rewrite через графический интерфейс IIS Manager. Выберите Sites -> yoursitename -> URL Rewrite.

Создайте новое правило Add Rule -> Blank rule.

Укажите имя правила и измените значения параметров:

• Requested URL -> Matches the Pattern
• Using -> Regular Expressions
• Pattern -> (.*)

В блоке Conditions измените Logical Grouping -> Match All и нажмите Add. Укажите

• Condition input -> {HTTPS}
• Check if input string -> Matches the Pattern
• Pattern -> ^OFF$

Теперь в блоке Action выберите:

• Action Type -> Redirect
• Redirect URL -> https://{HTTP_HOST}/{R:1}
• Redirect type -> Permanent (301)

Откройте браузер и попробуйте открыть ваш сайт по HTTP адресу, вас должно автоматически перенаправить на HTTPS URL.

Использование сертификата Let’s Encrypt для Remote Desktop Services

Если вы используете для подключения внешних пользователей в корпоративную сеть шлюз Remote Desktop Gateway/ RD Web Access, вы можете использовать нормальный SSL сертификат Let’s Encrypt вместо обычного самоподписанного сертификата. Рассмотрим, как корректно установить сертификат Let’s Encrypt для зажиты служб Remote Desktop Services в Windows Server.

Если на Remote Desktop Gateway сервере поднята также роль RDSH, нужно запретить пользователям Read доступ к каталогу, в котором у вас хранится WACS (в моем примере это c:inetpubletsencrypt ) и к каталогу с сертификатами сертификат Let’s Encrypt (C:ProgramDatawin-acme).

Затем на сервере RDP GW, запускаете wacs.exe, как описано выше, и вы выбираете нужный сайт IIS (обычно, Default Web Site). Let’s Encrypt выдает вам новый сертификат, который устанавливается для веб-сайта и в планировщике появляется задание на автоматические обновление сертификата.

Вы можете вручную экспортировать данный сертификат и привязать его к нужным службам RDS через SSL binding. Но вам придется выполнять эти действия вручную каждые 60 дней при перевыпуске сертификата Let’s Encrypt.

Нам нужен скрипт, который бы сразу после получения (продления) сертификата Let’s Encrypt применял бы его для RD Gateway.

В проекте win-acme есть готовый PowerShell скрипт ImportRDGateway.ps1 (https://github.com/PKISharp/win-acme/tree/master/dist/Scripts), который позволяет установить выбранный SSL сертификат для служб Remote Desktop. Главный недостаток скрипта – приходится вручную указывать отпечаток нового сертификата:
ImportRDGateway.ps1 <certThumbprint>

Для автоматического получения отпечатка сертификата с указанного сайта IIS используйте доработанный скрипт ImportRDGateway_Cert_From_IIS.ps1 (основан на стандартном ImportRDGateway.ps1).

Инструкция и модифицированный PowerShell скрипт присланы нашим читателем Антоном, за что посылаем ему лучи благодарности!

Вы можете запустить это скрипт вручную:

powershell -File ImportRDGateway_Cert_From_IIS.ps1

Если у вас RDS Gateway живет на стандартном IIS сайте «Default Web Site» с индексом 0, можете использовать скрипт без изменений.

$NewCertThumbprint = (Get-ChildItem IIS:SSLBindings)[0].Thumbprint

Теперь откройте задание планировщика win-acme-renew (acme-v02.api.letsencrypt.org) и на вкладке Action добавьте новое задание, которое запускает скрипт ImportRDGateway_Cert_From_IIS.ps1 после обновления сертификата.

Чтобы не менять разрешения на выполнение скриптов PowerShell, вы можете вызывать скрипт командой:

PowerShell.exe -ExecutionPolicy Bypass -File c:inetpubletsencryptImportRDGateway_Cert_From_IIS.ps1

Теперь скрипт привязки SSL сертификата к службам RDS будет выполнятся сразу после продления сертификата Let’s Encrypt. При этом автоматически перезапускается служба RD Gateway командой:

Restart-Service TSGateway

При перезапуске службы TSGateway все текущие сессии пользователей разрываются, поэтому желательно изменить периодичность запуска задания обновления сертфиката на 1 раз в 60 дней.

Также вы можете использовать бесплатные сертификаты Let’s Encrypt в Linux для веб сайтов на Nginx или apache.

Отметим, что сертификаты Let’s Encrypt в настоящий момент широко используются на сайтах многих крупных компаний и им доверяют все браузеры. Надеюсь, что судьба бесплатного центра сертификации Let’s Encrypt не постигнет участь WoSign и StartCom.

Опубликовано
⏰ 27.06.2019

Привет всем, уважаемые читатели. Сегодня у нас тема: «WEB-сервер в Windows Server 2012-2016». И снова две версии ОС в одной статье. На очереди Веб-сервер, роль позволяющая создавать на сервере веб-сайты, веб-приложения, и прочие веб-ресурсы.

Установка WEB-сервера в Windows Server 2012-2016

• В диспетчере сервера, переходим в раздел «Добавить роли и компоненты».

• Появляется памятка мастера добавления ролей.
• Жмём «Далее».

Следующий шаг, это «выбор типа установки».

• Нас интересует «Установка ролей и компонентов».
• Жмём «Далее».

На следующем шаге, нам нужно выбрать целевой сервер.

• Выбираем нужный сервер, или виртуальный диск.

Открывается окно выбора ролей сервера.

• Находим «Веб-сервер», и выбираем его.

• Появляется окно, с предложением установить необходимые Веб-серверу компоненты.
• Жмём «Добавить компоненты».

• В окне выбора ролей, жмём «Далее».

• На следующем шаге можно добавить нужные компоненты, помимо тех, которые уже выбраны.
• Если нужно, добавляем.
• Жмём «Далее».

Появляется информативное окно о роли веб-сервера.

• Жмём «Далее».

Следующим шагом идёт «Выбор служб ролей».

• Если что-то нужно, выбираем и двигаемся дальше.

Появляется сводка выбранных нами параметров.

• Можно вернутся и что-то изменить.
• Если всё устраивает, то жмём «Установить».

• Ждём завершения процесса добавления роли.
• По окончании, сводка произведённых действий. Жмём «Закрыть».

• Веб сервер появился на панели мониторинга.
• Удаляем задачу в области уведомлений, чтобы не висела.

Теперь делаем проверку.

• Открываем браузер и вводим ip адрес Вашего сервера. (Если в Вашей сети есть DNS-сервер, и Ваш сервер имеет доменное имя, то можно ввести доменное имя.)
• Открывается индекс страница WEB-сервера.

Сегодня мы рассмотрели тему: «WEB-сервер в Windows Server 2012-2016». Добавили роль Веб-сервера с основными компонентами, и проверили его работу.

Надеюсь статья была вам полезна. До встречи в новых статьях.

✍

С уважением, Андрей Бондаренко.

---

Видео на тему «WEB-сервер в Windows Server 2012»:

Видео на тему «WEB-сервер в Windows Server 2016»:

✧✧✧

Поблагодарить автора за полезную статью:

WMZ-кошелёк = Z667041230317

---

✧ Рубрика «Windows server»

✧ Комментарии: нет

Похожие записи

А вот и финальная третья часть нашей серии статей о центре сертификации на предприятии. Сегодня рассмотрим развертывание службы сертификатов на примере Windows Server 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, которые будут выполнять следующие функции:

1. Контроллер домена — необходим для функционирования домена Active Directory;
2. Веб-сервер — будет обеспечивать доступ к сертификатам ЦС и спискам отзывов для клиентов;
3. Корневой ЦС — будет выполнять функции корневого ЦС;
4. Подчинённый ЦС — будет выполнять функции издающего ЦС.

Развёртывание PKI будет проходить поэтапно на каждом сервере в том порядке, в котором они указаны выше. Подготовка контроллера домена будет сводиться к обеспечению функций Active Directory, GPO и учётных записей.

Подготовка контроллера домена

Перед развёртыванием PKI необходимо убедиться в работоспособности домена Active Directory и что все необходимые серверы (а именно, веб-сервер и подчинённый ЦС) введены в домен. А так же, что подготовлены необходимые учётные записи. На данном этапе нам потребуется только учётная запись с правами Enterprise Admins.

Ряд операций на подчинённом ЦС требуют прав Enterprise Admins, поскольку производится запись в раздел configuration naming context. Если это корневой домен леса, то для этих операций достаточно прав Domain Admins.

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

• Computer ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate Services Client – Auto-Enrollment
• User ConfigurationPoliciesWindows SettingsSecurity SettingsPublic Key InfrastructureCertificate 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

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

Install-WindowsFeature -Name Web-Server, Web-WebServer -IncludeManagementTools

• Создание папки PKIdata

Согласно нашей конфигурационной таблице (см. часть 2), для хранения сертификатов ЦС и списков отзыва нам потребуется общая папка с сетевым именем PKI по следующему пути: C:InetPubwwwrootPKIdata

New-Item -ItemType Directory -Path C:InetPubwwwroot -Name PKIdata -Force
New-SmbShare -Path C:inetpubwwwrootPKIdata -Name PKI -FullAccess everyone

После этого нужно выдать права NTFS на запись в эту папку для группы Cert Publishers.

• Создание веб-сайта

Теперь нам необходимо создать отдельный веб-сайт с именем “CDP” и хост-именем “cdp.contoso.com”:

New-Website -Name CDP -HostHeader cdp.contoso.com -PhysicalPath C:inetpubwwwrootPKIdata
New-WebVirtualDirectory -Site cdp -Name pki -PhysicalPath C:inetpubwwwrootPKIdata

• Включение поддержки Delta CRL

В нашем сценарии издающий ЦС будет публиковать Delta CRL, которые содержат символ плюс «+» в имени файла (например, contoso-pica+.crl). По умолчанию, IIS будет расценивать этот символ в запросе как метасимвол и не позволит клиентам скачать список отзыва. Для этого необходимо включить двойной эскейпинг в настройках IIS, чтобы расценивать знак плюса в запросе как литерал:

Import-Module -Name WebAdministration
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Filter /system.webServer/security/requestFiltering -name allowdoubleescaping -Value 'true'

Установка корневого ЦС

Фактическая установка ЦС будет включать в себя несколько этапов:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки.

Перед установкой корневого ЦС, необходимо ещё раз вернуться к конфигурационным таблицам:

В таблице я выделил только те параметры, которые задаются до и в процессе установки. Остальные параметры будут настраиваться после установки.

Предварительная конфигурация

Предварительные конфигурационные файлы необходимы для ряда настроек, которые невозможно задать во время установки компонента (ни при помощи графического интерфейса, ни при помощи командной строки или PowerShell). К ним обычно относятся настройки расширений сертификата ЦС. Например, для настройки расширения сертификата Certificate Policies, необходимо использовать предварительный конфигурационный файл, в котором настраиваются параметры расширения. Для Microsoft ADCS таким файлом является файл CAPolicy.inf, который должен быть расположен по следующему пути: %windir%CAPolicy.inf. С синтаксисом этого файла можно ознакомиться в следующей статье: How CA Certificates Work. Поскольку никаких специфичных или нестандартных настроек в сертификате корневого ЦС мы делать не будем, поэтому и предварительный конфигурационный файл сейчас нам не потребуется.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого сверьтесь с предыдущей таблицей, чтобы определить параметры установки. Исходя из данных таблицы, зададим параметры для командлета 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 "System32CertLog")

Итоговая настройка

После установки компонента ЦС необходимо настроить рабочие параметры ЦС. Рассмотрим ещё раз элементы, которые нам необходимо настроить:

* — копируется на сервер IIS

Скрипт настройки

Для конфигурирования настроек ЦС мы будем использовать BATCH скрипт с использованием утилиты certutil.exe:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Root CA post-installation script                               ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=C:CertDatacontoso-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 CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8.crln1:%CrlLocal%n2:%CDP%"

certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в папку CertData
ren %windir%system32CertSrvCertEnroll*.crt contoso-rca.crt
copy %windir%system32CertSrvCertEnrollcontoso-rca.crt C:CertData

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CAValidityPeriodUnits 15
certutil -setreg CAValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
certutil -setreg CACRLPeriodUnits 180
certutil -setreg CACRLPeriod "Days"
certutil -setreg CACRLOverlapPeriod "Months"
certutil -setreg CACRLOverlapUnits 1

:: Отключаем дифференциальные списки отзыва (или Delta CRL)
certutil -setreg CACRLDeltaPeriodUnits 0

:: Отключаем генерацию кросс-сертификатов
certutil -setreg caCRLFlags +CRLF_DISABLE_ROOT_CROSS_CERTS

:: Конфигурируем ЦС для включения истёкших отозванных сертификатов в списки отзыва
certutil –setreg caCRLFlags +CRLF_PUBLISH_EXPIRED_CERT_CRLS

:: Включаем полный аудит событий на ЦС**
certutil -setreg CAAuditFilter 127

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg cacspCNGHashAlgorithm SHA256

:: Перезапускаем службу ЦС для применения изменений.
net stop certsvc && net start certsvc

:: Публикуем списки отзыва.
certutil -CRL

Ряд команд нуждается в более развёрнутом пояснении. Команды с настройкой расширений CRL Distribution Points и Authority Information Access имеют специфический синтаксис. Во-первых, пути публикации и распространения указываются в одну строку и разделяются символом новой строки «n». Каждый путь начинается с числа и отделяется от самого пути символом двоеточия. Это число в начале пути указывает битовую маску флагов публикации для конкретного пути. Значение каждого бита для расширений CDP и AIA приведено в следующей таблице:

Если взять путь для CDP: 1:%windir%system32CertSrvCertEnroll%%3%%8.crl, то цифра 1 в начале строки говорит о том, что это путь физического размещения файла (Publich CRLs to this location). Другие опции здесь не используются. Для включения пути, который будет публиковаться в издаваемых сертификатах, мы будем использовать опцию «Include in the CDP extension of issued certificates» с числовым значением 2. Такой же принцип применяется и для остальных путей.

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

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

Следующая таблица содержит описание всех доступных переменных и их краткое описание:

В нашем конкретном случае будут использоваться только две переменные: <CertificateName> и <CRLNameSuffix>. Для исходного сертификата ЦС эти переменные пустые. При обновлении сертификата ЦС, переменная будет заменяться на «(index)», где index — номер сертификата ЦС. Индексирование начинается с нуля. Например, имя файла для последующего сертификата ЦС будет иметь вид: contoso-rca(1).crt. И так далее. То же самое касается и переменной , только здесь будет указываться индекс ключевой пары ЦС.

Отдельного внимания заслуживает команда, которая включает аудит операций на сервере ЦС, которые регистрируются в системном журнале Security.evtx. К ним относятся все основные операции: запуск/остановка службы, отправление запроса, выпуск или отклонение сертификата, выпуск списка отзыва. Эту строчку можно найти практически в каждом постустановочном скрипте для ЦС, которые можно найти в похожих статьях в интернете. И практически никто не утруждает себя в подробном объяснении механизма его работы, просто копируют из статьи в статью.

Особенность ведения аудита ЦС заключается в том, что настройка флагов аудита на ЦС является необходимым, но не достаточным условием. Механизм аудита основан на регистрации событий в журнале Security.evtx, который, в свою очередь зависит от настройки политики Audit Object Access в групповых политиках. Т.е. без настройки групповых политик никакого аудита не будет.

Опытные администраторы знают к чему приводит включение Audit Object Access — к лавинному созданию записей в журнале от других компонентов ОС. Например, аудит доступа файловой системы, реестра, других установленных ролей и т.д. В результате, журнал может буквально за день-два заполниться до отказа. Поэтому для эффективного использования аудита необходимы меры по фильтрации ненужных событий, например, при помощи функции подписки на интересующие события. Нет смысла в аудите, если его никто не может прочитать и эффективно проанализировать. Но эта тема уже выходит за рамки этой статьи.

Прочие настройки

После того как корневой ЦС установлен и сконфигурирован, убедитесь, что всё прошло без ошибок:

• Откройте оснастку Certification Authorities MMC (certsrv.msc), убедитесь, что служба запущена;
• Выберите свойства узла ЦС и проверьте поля сертификата, что они соответствуют ожидаемым значениям;
• Найдите в корне системного диска папку CertData и убедитесь, что там находится два файла: сертификат и список отзыва. Убедитесь, что поля списка отзыва соответствуют ожидаемым значениям.

Если всё хорошо, тогда скопируйте содержимое папки C:CertData на сервер IIS в папку PKIData. Сертификат корневого ЦС уже можно импортировать на все устройства, которые будут использовать нашу PKI.

Для импорта сертификата на доменные клиенты, достаточно загрузить его в Active Directory и после обновления групповых политик на клиентах, сертификат будет установлен в локальные хранилища сертификатов во всём лесу. Для публикации сертификата в AD необходимо выполнить следующую команду:

Certutil -f -dspublish pathcontoso-rca.crt RootCA

Для установки сертификата на клиентах в рабочих группах и мобильные устройства необходимо воспользоваться другими инструментами, которые есть в вашем распоряжении. Например, System Center Configuration Manager или Mobile Device Management. Если подходящих инструментов нет, можно копировать и устанавливать сертификат на компьютеры при помощи утилиты certutil.exe. Для установки сертификата в локальное хранилище сертификатов выполните следующую команду:

Certutil -f -addstore Root pathcontoso-rca.crt

Установка издающего ЦС

Как и в случае с корневым ЦС, установка издающего ЦС включает в себя четыре этапа:

1. Подготовка предустановочных конфигурационных файлов (CAPolicy.inf);
2. Установка компонента ЦС;
3. Выполнение постустановочной конфигурации;
4. Проверка установки и конфигурации.

Предустановочная конфигурация

Если для корневого ЦС предустановочный конфигурационный файл нам не требовался, то для издающего ЦС он понадобится. В нём мы настроим расширения Certificate Policies и Basic Constraints для сертификата ЦС. Если с политиками всё понятно, то в расширении Basic Constraints мы запретим выдачу сертификатов другим ЦС с издающего ЦС, поскольку у нас двухуровневая иерархия и добавление новых уровней только усложняет нашу структуру и увеличивает время, затрачиваемое на проверку сертификатов клиентами. Также отключим автоматическую загрузку шаблонов из Active Directory в список выдаваемых шаблонов. По умолчанию, сервер ЦС загружает на выдачу некоторый набор шаблонов сертификатов. Это вредно по двум причинам:

1. Контроллеры домена практически мгновенно обнаруживают появление ЦС в лесу и даже при отключённой политике автоматической выдачи сами запрашивают себе сертификаты.
2. Администраторы сами должны определять какие шаблоны будут использовать в организации.

Поэтому мы сконфигурируем ЦС так, что список шаблонов к выдаче будет пустым. Это возможно сделать только через CAPolicy.inf. В нашем случае он будет иметь следующее содержимое:

; заголовок INI файла
[Version]
Signature= "$Windows NT$"

; указываем список политик, которые будут включены в сертификат ЦС. В нашем
; случае будет одна политика под названием AllIssuancePolicies.
[PolicyStatementExtension]
Policies = AllIssuancePolicy
; конфигурируем детали самой политики. Ссылку на документ Certificate Practice
; Statement (CPS) и объектный идентификатор политики
[AllIssuancePolicy]
URL = http://cdp.contoso.com/pki/contoso-cps.html
OID = 2.5.29.32.0
[BasicConstraintsExtension]
IsCA = True
PathLegth = 0
IsCritical = True
; секция прочих настроек ЦС
[certsrv_server]
; отключаем автоматическую загрузку шаблонов сертификатов для выдачи
LoadDefaultTemplates = 0

Файл с именем CAPolicy.inf необходимо скопировать в системную папку Windows до установки ЦС.

Установка компонента ЦС

Прежде всего необходимо добавить установочные компоненты для AD CS:

Install-WindowsFeature AD-Certificate, ADCS-Cert-Authority -IncludeManagementTools

После этого посмотрим на установочную таблицу, чтобы определить параметры установки:

В таблице я выделил только те параметры, которые задаются в процессе установки. Остальные параметры будут настраиваться после установки. Исходя из этих данных сформируем параметры для командлета Install-AdcsCertificationAuthority:

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. Но прежде всего посмотрим установочную таблицу и выясним параметры, которые нам необходимо настроить:

Аналогичная таблица составляется и для издающего ЦС.

За основу мы возьмём скрипт с корневого ЦС и изменим только отдельные фрагменты:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::                     Issuing CA post-installation script                            ::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: все комментарии помечены знаком двойного двоеточия (::)
:: записываем пути для публикации и распространения сертификатов ЦС и списков отзыва
:: в отдельные переменные
SET CrlLocal=\IISPKIcontoso-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 CACRLPublicationURLs "1:%windir%system32CertSrvCertEnroll%%3%%8%%9.crln65:%CrlLocal%n6:%CDP%"

certutil -setreg CACACertPublicationURLs "1:%windir%system32CertSrvCertEnroll%%1_%%3%%4.crtn2:%AIA%"

:: Поскольку мы не можем указывать пути публикации для файла сертификата, мы
:: вручную переименовываем его в необходимый формат и копируем в сетевую папку
ren %windir%system32CertSrvCertEnroll*.crt contoso-pica.crt
copy %windir%system32CertSrvCertEnrollcontoso-pica.crt \IISPKI

:: Задаём срок действия издаваемых сертификатов
certutil -setreg CAValidityPeriodUnits 5
certutil -setreg CAValidityPeriod "Years"

:: Задаём время жизни списков отзыва согласно нашей конфигурации
:: базовый CRL
certutil -setreg CACRLPeriodUnits 1
certutil -setreg CACRLPeriod "weeks"

:: Delta CRL
certutil -setreg CACRLDeltaPeriodUnits 1
certutil -setreg CACRLDeltaPeriod "days"

:: Включаем полный аудит событий на ЦС**
certutil -setreg CAAuditFilter 127

:: Включаем наследование расширения Certificate Policies в издаваемых сертификатах 
certutil -setreg PolicyEnableRequestExtensionList +"2.5.29.32"

:: Включаем поддержку расширения OcspRevNoCheck, если планируется установка
:: сетевого ответчика (Online Responder или OCSP сервера)
certutil -v -setreg policyeditflags +EDITF_ENABLEOCSPREVNOCHECK

:: если версия ОС ниже, чем Windows Server 2016 необходимо задать алгоритм подписи.
:: Windows Server 2016 по умолчанию использует SHA256.
Certutil -setreg cacspCNGHashAlgorithm 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 (pkiview.msc). Оснастка автоматически построит текущую иерархию и проверит доступность всех путей для скачивания сертификатов ЦС и списков отзыва. Никаких ошибок быть не должно. Если есть ошибка, необходимо её точно идентифицировать и устранить. В случае успешной настройки оснастка будет выглядеть следующим образом для корневого ЦС:

И для издющего ЦС:

Если вся итоговая конфигурация соответствует ожидаемым значениям и оснастка Enterprise PKI Health не показывает ошибок, это может судить о том, что PKI установлена верно.

Рекомендации

После того, как все ЦС установлены, сконфигурированы и их работоспособность проверена, можно приступать к их эксплуатации. В этом разделе я дам несколько полезных рекомендаций, которых следует придерживаться, чтобы предостеречь себя от возможных потенциальных проблем во время эксплуатации 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 отмечены такие проблемы. Примеры статей:

• Certificate validation fails when a certificate has multiple trusted certification paths to root CAs.
• «0x80092013, CRYPT_E_REVOCATION_OFFLINEA» error message when you try to verify a certificate that has multiple chains in Windows Server 2008 or in Windows Vista.

При генерации новой ключевой пары для каждого сертификата будет гарантирован только один путь к корневому сертификату и модуль построения цепочек сертификатов уже не ошибётся.

Резервное копирование

Вопросы резервного копирования и восстановления после отказа являются отдельной темой. Здесь я лишь отмечу основные моменты, которые следует учесть при планировании стратегии резервного копирования.

Microsoft Active Directory Certificate Services предоставляет инструменты для резервного копирования компонентов ЦС:

• Оснастка Certification Authority MMC (certsrv.msc);
• Утилита certutil.exe с параметром -backup.

С ними можно сделать резервную копию для ключевой пары ЦС и базы данных. Однако эти инструменты не позволяют делать резервную копию настроек ЦС. Эти операции необходимо выполнять вручную. Все настройки ЦС находятся в реестре по следующему пути:

HKLMSystemCurrentControlSetServicesCertSvc

При резервном копировании всегда экспортируйте данную ветку реестра. При восстановлении ЦС сохранённый REG файл импортируется обратно в реестр после установки роли ЦС.

Полный список элементов ЦС, который подлежит обязательному резервному копированию выглядит так:

• Ключи и сертификаты ЦС;
• База данных ЦС;
• Настройки ЦС из реестра;
• Предустановочный конфигурационный файл;
• Установочные и конфигурационные скрипты.

Этот список не зависит от принятой в вашей компании стратегии резервного копирования, он всегда должен быть включён в список резервных копий.

Об авторе

Вадим Поданс — специалист в области автоматизации PowerShell и Public Key Infrastructure, Microsoft MVP: Cloud and Datacenter Management с 2009 года и автор модуля PowerShell PKI. На протяжении 9 лет в своём блоге освещает различные вопросы эксплуатации и автоматизации PKI на предприятии. Статьи Вадима о PKI и PowerShell можно найти на его сайте.