В продолжение предыдущих двух статей.
Это не совсем случай из практики, а небольшая шпаргалка, которую я сделал для себя и решил поделится. Если, конечно, есть еще такие же фрики как я.
Сразу замечу- я не пропагандирую использование RDP и Сертификатов без доменов, просто часто попадаются маленькие клиенты с разнесенной географически инфраструктурой. Например офис на 3 компьютера и 10 точек- магазинов, 4 склада, где просто нужен доступ к складской 1С, и пока нет домена(или он не нужен). Картинки можно увеличивать щелчком мыши.
Контрольный список
установки и настройки RemoteApp с использованием RD Gateway
без домена AD и внешнего доменного имени.
*Предполагается, что в сети имеется больше одного сервера, хотя все возможно реализовать и на одном сервере.
1. Установка и настройка роли RDS со службами RD Licensing, RDSH, RD Gateway.
2. Если подключение к интернету осуществляется через роутер — настроить проброс порта 443 на внутренний адрес RD Gateway.
3. Предварительная настройка RDSH. Предварительная настройка RemoteApp. Добавление приложения в список RemoteApp.
4. Настройка RD Gateway. Создание правил RD CAP и RD RAP.
5. Установка роли AD CS для создания сертификата на подключения к RD Gateway. При создании сертификата указываем внешний IP-адрес и внутренний IP-адрес сервера RD Gateway, чтобы сертификат проходил проверку подлинности и мы могли бы подключиться к серверу шлюза терминалов по внешнему статическому адресу снаружи, и по внутреннему NetBIOS имени изнутри.
5.1 Установки роли AD CS в режиме Standalone на другом сервере (который будет центром сертификации, имя сервера после этого изменить будет нельзя).
5.2 Создание на сервере RDGateway пользовательского запроса на сертификат:
то самое окошко ради которого и устанавливалась роль AD CS
выбираем как мы будем использовать ключ:
не забываем эту галочку, чтобы вместе с сертификатом экспортировался и личный ключ.
По окончании настройки запроса сохраняем запрос с раcширением *.req.
5.3 Переходим на сервер с Центром сертификации. Для начала можно настроить время действия сертификата выданного Центром сертификации по умолчанию. В целях безопасности лучше оставить этот параметр равным 1 году. Я делаю это только потому, что я не буду находится у клиента постоянно и возможны простои в работе. А через 5 лет » или падишах помрет или осел….».
Открываем запрос в центре сертификации, и выпускаем новый сертификат(Issue).
Публикуем список отзыва. (CRL).
5.4 Экспортируем сертификат в файл с расширением *.cer. Переходим в папку где хранятся сертификат Центра сертификации и список отзывов. Копируем личный сертификат и эти два файла на сервер RD Gateway(или на файловый сервер как удобнее).
5.5 Открываем личный сертификат на сервере RD Gateway и убеждаемся что доверия к нему нет.
5.6 Устанавливаем: Сертификат центра сертификации в доверенные корневые центры сертификации, устанавливаем список отзывов. Устанавливаем личный сертификат. Открываем его и убеждаемся что цепочка доверия работает.
5.7 Изменяем само подписанный сертификат на вновь выпущенный в настройках RD Gateway, RD Web Access, ну и если надо в настройках RDSH, у него отдельный сертификат, который будет использоваться для внутренних подключений, имейте в виду, когда срок действия само подписанного сертификата закончится сервер в этом случае сам пере выпустит сертификат, если же для RDSH создать сертификат самодельный, то по истечении его срока действия зайти через удаленный рабочий стол не получится, надо отслеживать этот момент. Опять же здесь видны недостатки использования службы сертификации вне домена.
5.8 Создаем rdp-файл для пользователей.
6. Проверяем работу RemoteApp и RDC через RDGateway.
7. Нам нужно также будет создать must-have пакет для клиентов, который представляет архив с набором файлов:
Инструкция по установке сертификатов, списка отзывов, установке обновлений(если клиент не Win7 и выше);
Личный сертификат сервера RDGateway;
Сертификат Центра сертификации;
Список отзывов(CRL);
Инструкцию конечно можно и не писать, но тогда придется либо долго объяснять клиенту все по телефону, либо ехать собственной персоной.
Будет дополняться по мере возможности.
ЗЫ. В процессе тестирования, заметил интересную штуку- несмотря на то, что подключение рабочего стола к тестируемой системе осуществялось успешно, порт 3389 был закрыт на роутере (т.е. подключение явно происходило через порт 443) и RDGateway manager показывал мне что соединение осуществляется через него — заветный значек подключения через шлюз, у меня не появился на полоске RDC. Я попробовал подключить через RDGateway к другому клиенту, где значек точно появлялся- в прошлом Случае из практики есть снимок экрана в подтверждение. Но у другого клиента также не было этого значка… Возможно это просто какой то глюк.
Доброго времени суток, Уважаемые Гости! В данной статье мы хотели бы вспомнить про доверие сертификатов в Браузерах, благодаря и . Многие люди не понимают, что сертификат SSL пользователя является только одной частью всей "цепочки сертификатов". Давайте поговорим о промежуточных и корневых сертификатах. SSL (точнее, TLS) - это технология, о которой большинство пользователей практически ничего не знают. Даже люди, приобретающие его, как правило, не знают многого, кроме того, что им нужен сертификат SSL и они должны установить его на своем сервере, чтобы обеспечить HTTPS на своём сайте. Итак, начнём!
Что такое корневой сертификат?
Корневой сертификат, часто называемый доверенным корневым сертификатом, находится в центре модели доверия, которая поддерживает SSL / TLS. Каждый браузер содержит корневое хранилище. Некоторые браузеры работают самостоятельно, в то время, как другие используют стороннее хранилище сертификатов. Хранилище корневых сертификатов - это набор предварительно загруженных корневых сертификатов, которые находятся на устройстве. Корневой сертификат бесценен, поскольку браузеры автоматически доверяют сертификату, подписанному с доверенным корневым сертификатом. Доверенные корни принадлежат Центрам Сертификации (например , и так далее) - организациям, которые проверяют и выдают .Что такое промежуточный сертификат?
Центры сертификации не выдают сертификаты SSL конечного пользователя непосредственно от их Корневого сертификата. Это было бы опасно, потому что, при неправильной выдаче или ошибке, Root (Корневой сертификат) был бы отозван и каждый выпущенный сертификат, который был подписан с использованием данного Корневого сертификата, станет сразу же "Недоверенным" . Таким образом, чтобы обезопасить себя, CA обычно выдает то, что называется "промежуточным сертификатом". Центр Сертификации подписывает промежуточный сертификат с его закрытым ключом, который делает его "Доверенным" . Затем Центр сертификации использует закрытый ключ промежуточного сертификата для подписи сертификатов SSL конечного пользователя. Этот процесс может играть несколько раз, где промежуточный корень подписывает другое промежуточное звено, и затем CA использует это для подписания сертификата. Вот визуализация цепочки сертификатов. В нашем примере, мы будем использовать только один промежуточный элемент, чтобы упростить её. В основном "Цепочки сертификатов" сложнее.Какую роль играет цифровая подпись?
В этом контексте цифровая подпись является своего рода цифровой формой нотариального заверения. Когда Корневой сертификат подписывает Промежуточный сертификат, он фактически передает часть своего доверия Промежуточному. Поскольку подпись поступает непосредственно из закрытого ключа доверенного Корневого сертификата, она автоматически становится доверенной. Каждый раз, когда браузеру или устройству предоставляется сертификат SSL, он получает сам сертификат, а также открытый ключ, связанный с сертификатом. Используя открытый ключ, расшифровывает цифровую подпись и видит, кто это сделал – какой сертификат подписал. Когда ваш браузер аутентифицирует сертификат SSL конечного пользователя на веб-сайте, он использует открытый ключ, который установлен на веб-сайте, чтобы расшифровать подпись и переместиться далее вверх по цепочке сертификатов. Он продолжает повторять этот процесс – расшифровывая подпись и следуя по цепочке к сертификату, который ее подписал - до тех пор, пока в конечном итоге он не достигнет одного из Корневых сертификатов в доверенном хранилище браузера. Если он не может связать сертификат с одним из своих доверенных корней, он не будет доверять этому сертификату.Итак, в чем разница между Корневым ЦС и Промежуточным ЦС?
Корневой центр сертификации - это центр сертификации, владеющий одним или несколькими доверенными корнями. Это означает, что они имеют корни в хранилищах доверия основных браузеров. Промежуточные сертификаты не имеют корней в Доверенных хранилищах сертификатов браузера. Как мы обсуждали ранее, Центры Сертификации не выдают сертификаты подписывая их своим Корневым сертификатом. Они добавляют уровни безопасности, подписывая "промежуточные звенья", а затем подписывая ими сертификаты. Это помогает свести к минимуму и ограничить ущерб в случае неправильной выдачи или ошибки. Вместо отзыва Корневого сертификата и буквально каждого сертификата, подписанного этим сертификатов, Они просто отзывают "промежуточное звено", что вызывает только недоверие группы выпущенных сертификатов этим "промежуточным звеном". Вот практический пример: Google и другие браузеры недавно перестали доверять сертификатам Symantec CA SSL. Чтобы не отзывать миллионы сертификатов выданных Центром Сертификации, они просто удалили все корни Symantec CA из своих хранилищ доверия и заменили Центром Сертификации DigiCert. То, что мы только, что описали – модель доверия с участием Центров Сертификации, Цепочек Сертификатов и Криптографических подписей – по существу это - PKI или Инфраструктура Открытых Ключей.Протокол RDP с защитой на уровне сети (SSL), к сожалению, не получил широкого распространения среди системных администраторов, предпочитающих защищать терминальные соединения другим способом. Возможно это связано с кажущейся сложностью способа, однако это не так, в данном материале мы рассмотрим как просто и без затруднений организовать такую защиту.
Какие преимущества дает нам защита RDP при помощи SSL? Во первых надежное шифрование канала, проверку подлинности сервера на основании сертификата и проверку подлинности пользователя на уровне сети. Последняя возможность доступна начиная с Windows Server 2008. Проверка подлинности на уровне сети позволяет повысить безопасность сервера терминалов за счет того, что проверка происходит еще до начала сеанса.
Проверка подлинности на уровне сети производится до подключения к удаленному рабочему столу и отображения экрана входа в систему, это снижает нагрузку на сервер и значительно увеличивает его защиту от злоумышленников и вредоносных программ, а также снижает вероятность атак типа "отказ в обслуживании".
Для полноценного использования всех возможностей RDP через SSL клиентские ПК должны работать под управлением Windows XP SP3, Windows Vista или Windows 7 и использовать RDP клиент версии 6.0 или более поздней.
При использовании Windows Server 2003 SP1 и более поздних версий, будут доступны шифрование канала при помощи SSL (TLS 1.0) и проверка подлинности сервера, клиентские ПК должны иметь версию RDP клиента 5.2 или более позднюю.
В нашей статье мы будем рассматривать настройку терминального сервера на базе Windows Server 2008 R2, однако все сказанное будет справедливо и для Windows Server 2003 (за исключением отсутствующих возможностей).
Для успешной реализации данного решения в вашей сети должен находиться работающий центр сертификации, настройку которого мы рассматривали в . Для доверия сертификатам выданным данным ЦС на терминальный сервер необходимо установить сертификат ЦС (или цепочку сертификатов) в хранилище .
Затем следует выполнить запрос сертификата подлинности сервера со следующими параметрами:
Имя - полное имя терминального сервера (т.е. server.domain.com если сервер входит в домен domain.com)
- Тип сертификата - Сертификат проверки подлинности сервера
- Установите опцию Создать новый набор ключей
- CSP - Microsoft RSA SChannel Cryptographic Provider .
- Установите флажок Пометить ключ как экспортируемый .
- Для ЦС предприятия установите флажок Использовать локальное хранилище компьютера для сертификата . (В автономном ЦС данная опция недоступна).
Отправьте запрос центру сертификации и установите выданный сертификат. Данный сертификат должен быть установлен в локальное хранилище компьютера, иначе он не сможет быть использован службами терминалов. Чтобы проверить это запустим консоль MMC (Пуск - Выполнить - mmc ) и добавим оснастку Сертификаты (Файл - Добавить или удалить оснастку ) для учетной записи компьютера.
В корне консоли выберите нажмите Вид - Параметры и установите режим просмотра Упорядочить сертификаты по назначению . Выданный сертификат должен находиться в группе Проверка подлинности сервера .
Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.
Откройте Internet Explorer - Свойства обозревателя - Содержимое - Сертификаты , выданный сертификат должен быть установлен в хранилище Личные .
Произведите его экспорт. При экспорте укажите следующие опции:
- Да, экспортировать закрытый ключ
- Удалить закрытый ключ после успешного экспорта
После чего удалите сертификат из данного хранилища. В оснастке Сертификаты (локальный компьютер) выберите раздел Проверка подлинности сервера , щелкните на него правой кнопкой мыши Все задачи - Импорт и импортируйте сертификат.
Теперь в Администрирование - Службы удаленных рабочих столов откройте Конфигурация узла сеансов удаленных рабочих столов (в Windows Server 2003 Администрирование - Настройка служб терминалов).
Выберите необходимое подключение и откройте его свойства. В самом низу нажмите кнопку Выбрать и выберите полученный на предыдущем шаге сертификат (в Windows Server 2003 это окно выглядит несколько по другому).
После выбора сертификата укажите остальные свойства:
- Уровень безопасности SSL
- Уровень шифрования Высокий или FIPS -совместимый
- Установите флажок Разрешить подключаться только с компьютеров... (недоступно в Windows Server 2003)
Сохраните введенный параметры, на этом настройка сервера закончена.
На клиентском ПК создайте подключение к удаленному рабочему столу, в качестве адреса используйте полное имя сервера, которое указано в сертификате. Откройте свойства подключения и на закладке Подключение - Проверка подлинности сервера установите опцию Предупреждать .
Чтобы данный ПК доверял сертификатам выданным нашим центром сертификации не забудьте установить на него сертификат ЦС в хранилище Доверенные корневые центры сертификации
.
В Windows 7 (при использовании RDP клиента версии 7) данный сертификат требуется установить в хранилище учетной записи компьютера , для этого импортируйте его через оснастку Сертификаты (локальный компьютер) в консоли MCC, аналогично тому, как это делали выше. В противном случае подключение будет невозможно и вы получите следующую ошибку:
Установив сертификат ЦС можете пробовать подключиться, обратите внимание, что имя пользователя и пароль будет предложено ввести еще до создания RDP сессии. При успешном соединении обратите внимание на замок в заголовке окна, который свидетельствует о работе через SSL. Нажав на него можно просмотреть информацию о сертификате.
И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.
Успешно решил намедни проблемку с терминалами. Может кому ещё пригодится, да и мне в случае, например, амнезии будет полезно вспомнить:)
Суть проблемки в следующем. Имеются сервера терминалов на windows 7 (а теперь уже и win8 попадаются - а может даже это же решение и для серверных версий подойдёт).
То есть соединения по протоколу Remote Desktop Protocol (RDP) версий 7 и 8 (бинарник версий 6.1 и 6.2 соответственно) к службе "Удалённый рабочий стол" (remote desktop services).
Теперь соединение с ними требует наличия сертификата у сервера и его проверка у клиента.
Сервер автоматически создаёт самоподписанный сертификат при подключении к нему (или если его "нечаянно" удалить).
Но при этом у клиентов в момент подключения выдаётся предупреждение "Не удается проверить подлинность удаленного компьютера: Сертификат выдан не имеющим доверия центром сертификации" - благо пока отключаемое. У серверов
на Windows XP такой проблемы нет - но клиенты в XP уже ругается.
Не то, чтобы это была такая уж Проблема - так - мелкое неудобство. Но особо комфортной Ежедневную Работу не делает. Особенно администратору - который по несколько раз в день да к разным машинам цепляется..
Итак. Нужно заменить сертификаты у "серверов" на "правильные".
Как сделать "правильные" сертификаты - отдельная песня - отдельным постом.
Делал через openssl + EasyRSA (1.0 - или 2.0 что идёт в комплекте с openvpn - но пришлось слегка допиливать - но главное разобраться с конфигами - хех).
Вполне вероятно, что средствами MS (тем же certutil или GUI каким) можно было бы получить ключики куда проще, но зато слегка копнул эту x509 - теперь чуть лучше понимаю цели танцев с бубном ключами для openvpn.. Одних CA не считая промежуточных центров сертификатов пока с ними разобрался сколько понаделал:)
Можно (и желательно) получать сертификаты от доверенных сторонних центров сертификации - но они и за денюжку - и по-учиться на сертификатах не дадут.
Продолжим. В процессе кейгенеза должны получить следующие вещи:
- Сертификат самопального CA в формате x509/CER/base64 - пусть им будет файлик ca.crt .
- pkcs12/pfx ключик сервера с EKU "remote desktop connection" или "TLS server" подписанный сертификатом, который проверяется через вышеупомянутый CA - им будет файлик test.p12 с паролем "qwe " - хеш ключа - 01:23:..:cd:ef .
- HTTP сервер, отдающий промежуточные, корневые сертификаты и отзывы на них (crl).
Без этого пункта работать RDP без ругани не получилось заставить - так что заранее планируйте; благо хватит какого-нибудь mangoose - ибо нашему CA требуется пока лишь отдавать мелкие статичные файлы и достаточно редко.
Всё последующее требует административной консоли (с повышенными правами) на подопытном сервере.
- Засовываем корневой сертификат в хранилище доверенных корневых сертификатов. Это просто - используем штатную системную утилиту:
certutil -addstore root ca.crt
- Засовываем ключ сервера в персональное хранилище (но "локального компьютера").
Тут есть нюанс. При простом импорте ключа - он может поместиться в личное хранилище пользователя - да ещё и с неправильными правами. При продвинутом импорте - через mmc и оснастку "Сертификаты/Локальный компьютер" - потребуется давать права на доступ к закрытому ключу для Network Service - от имени которого работает termserv - опять же много буков и картинок потребуется, чтобы это всё описать. Самое простое найденное решение - через утилитку WinHttpCertCfg.exe - из состава .WinHttpCertCfg -a NetworkService -c LOCAL_MACHINE\MY -i test.p12 -p qwe
Да, если ключик таки уже импортировали как-то по-другому, можно дать правильные права командой:
WinHttpCertCfg.exe -a NetworkService -c LOCAL_MACHINE\MY -g -s SUBJ
где SUBJ это сабжект ключа - чтобы утилита его смогла найти - и скорее всего он будет совпадать с именем компьютера - достаточно указать %COMPUTERNAME% . - Заставляем терминал сервер отдавать наш ключ, вместо самоподписанного. Просто нужно указать хеш нужного ключа в реестре. Перезапуска сервиса а тем более компьютера не потребуется.
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash /t REG_BINARY /d 0123456789..DEF
Ну Вот, собственно, и Всё. При следующем подключении - клиент не получит уведомления о неправильном сертификате сервера. Можно снова включать уведомления об этом кошмаре или даже запрещать соединяться с такими серверами.
Не правда ли, Всё очень просто?
Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:
- Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
- отношения всеобщего доверия к ЦС
- выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
- различные службы поддержки PKI
- списки отзывов сертификатов (CRL)
- сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
- Web Enrollment (средство запроса сертификатов через Web)
Автоматический запрос сертификатов
Ручная установка сертификата корневого ЦС
Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации. Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:
Компьютеру не удаётся проверить удостоверение шлюза удалённых рабочих столов "server.argon.com.ru". Подключаться к серверам без удостоверений небезопасно. This computer can"t verify the identity of the RD "server.argon.com.ru". It"s not safe to connect to servers that can"t be identified. Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Через MMC
Через свойства сертификата
Запустить командную строку с правами админа » вызвать в ней с:\path\to\cert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.
Через командную строку
Потребуется утилита CertMgr , с помощью нее нужно выполнить следующую команду:
certmgr.exe -add -c "с:\path\to\cert.crt" -s -r localMachine root
Проверка отзыва сертификатов
Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.
Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:
Не удалось проверить, не был ли отозван этот сертификат. A revocation check could not be perfomed for the certificate.
Для решения проблемы доступности проверки отзыва сертификатов из интернета необходимо опубликовать любую из следующих служб:
- CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
- Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)
Для работы обоих вариантов необходимо, чтобы в центре сертификации были заблаговременно настроены доступные из интернета адреса этих служб, так как эти адреса жестко прописываются в каждом выдаваемом сертификате.
За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation . От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.
Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network . Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.
Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:
certutil -url name.cer
где name.cer — имя выданного сертификата.
Следует иметь ввиду, что проверка отзыва по протоколу OCSP проходит успешно только в том случае, если сертификат ЦС, выдавшего проверяемый сертификат, установлен в хранилище доверенных сертификатов локального компьютера.
Веб-службы регистрации сертификатов
Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:
- запрашивать сертификаты пользователями без участия администратора
- предоставлять по требованию сертификат корневого ЦС
- выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
- делать это все через интернет
- сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС
Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов
- в случае установки Web Enrollment на отличный от ЦС компьютер, необходимо обязательно выполнить шаги, описанные в статье TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account , иначе служба не будет работать, выдавая следующую ошибку:
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена. An unexpected error has occurred: The Certification Authority Service has not been started.
- та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
- при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS
Запрос сертификата с альтернативным именем
Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).
По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Запрос через консоль MMC
Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…
- В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
- Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
- Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.
Запрос через утилиту certreq
Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq . Чтобы создать сертификат нужно действовать по следующему алгоритму:
1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.
Signature="$Windows NT$"
Subject = "CN=server.argon.local, OU=IT, O=Argon, L=Kirov, S=Kirovskaya, C=RU"
KeySpec = 1
KeyLength = 2048
HashAlgorithm = SHA256
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
RequestType = PKCS10
KeyUsage = 0xa0
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
FriendlyName = "server.argon.local with SAN"
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
CertificateTemplate = WebServer
2.5.29.17 = "{text}"
_continue_ = "DNS=*.argon.com.ru&"
_continue_ = "DNS=argon.com.ru&"
_continue_ = "DNS=server.argon.local&"
_continue_ = "DNS=server&"
_continue_ = "DNS=localhost"
2. На машине, для которой предполагается запрашивается сертификат, выполнить команду
certreq -new request.inf
3. Отправить запрос центру сертификации и получить в ответ.cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать.req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое.req файла и выбрать шаблон веб-сервера).
4. Выполнить установку полученного сертификата на целевой компьютер следующей командой
certreq -accept request.cer
5. PROFIT. В результате описанных действий в хранилище сертификатов компьютера будет создан сертификат с закрытым ключом, пригодный для авторизации сервера по нескольким именами, прописанным.inf файле.
Обобщенные лучшие практики
Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2
- На контроллере домена развернут корневой центр сертификации
- Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
- В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
- На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
- Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
- Online Responder для проверки отзыва сертификатов по протоколу OCSP
- Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
- Remote Desktop Gateway
- Outlook Web Access
- DirectAccess
- SharePoint
Полезные ссылки
- Устанавливаем Certification Authority — Vadims Podans’s blog
- OCSP (часть 1) , OCSP (часть 2) — Vadims Podans’s blog
| Рубрика | |
|---|---|
| Метки | , |
| Опубликовано |
