Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:
Если в среде 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. Этот сертификат не удалось проверить, проследив его до доверенного центра сертификации
Нужно учесть, что сертификат вашего корневого ЦС нужно устанавливать не в хранилище текущего пользователя, а в хранилище локального компьютера, так как только его содержимое действует на всех пользователей и системные учетные записи. Существует несколько способов добавить сертификат ЦС в хранилище локального компьютера.
Запустить командную строку с правами админа » вызвать в ней с:\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 в интернете обращайтесь к статье 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, если по-английски. Весьма полезная роль, которая позволяет:
Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов
Произошла непредвиденная ошибка: Служба центра сертификации (ЦС) не запущена. An unexpected error has occurred: The Certification Authority Service has not been started.
Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).
По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc
net start certsvc
Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…
Более гибким и универсальным способом запроса сертификатов с 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
Рубрика | |
---|---|
Метки | , |
Опубликовано |
Протокол 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)
Отправьте запрос центру сертификации и установите выданный сертификат. Данный сертификат должен быть установлен в локальное хранилище компьютера, иначе он не сможет быть использован службами терминалов. Чтобы проверить это запустим консоль MMC (Пуск - Выполнить - mmc ) и добавим оснастку Сертификаты (Файл - Добавить или удалить оснастку ) для учетной записи компьютера.
В корне консоли выберите нажмите Вид - Параметры и установите режим просмотра Упорядочить сертификаты по назначению . Выданный сертификат должен находиться в группе Проверка подлинности сервера .
Если вы получали сертификат с помощью изолированного (автономного) ЦС (сеть не имеет доменной структуры) то он по умолчанию будет установлен в хранилище учетной записи пользователя и придется выполнить ряд дополнительных действий.
Откройте Internet Explorer - Свойства обозревателя - Содержимое - Сертификаты , выданный сертификат должен быть установлен в хранилище Личные .
Произведите его экспорт. При экспорте укажите следующие опции:
После чего удалите сертификат из данного хранилища. В оснастке Сертификаты (локальный компьютер) выберите раздел Проверка подлинности сервера , щелкните на него правой кнопкой мыши Все задачи - Импорт и импортируйте сертификат.
Теперь в Администрирование - Службы удаленных рабочих столов откройте Конфигурация узла сеансов удаленных рабочих столов (в Windows Server 2003 Администрирование - Настройка служб терминалов).
Выберите необходимое подключение и откройте его свойства. В самом низу нажмите кнопку Выбрать и выберите полученный на предыдущем шаге сертификат (в Windows Server 2003 это окно выглядит несколько по другому).
После выбора сертификата укажите остальные свойства:
Сохраните введенный параметры, на этом настройка сервера закончена.
На клиентском ПК создайте подключение к удаленному рабочему столу, в качестве адреса используйте полное имя сервера, которое указано в сертификате. Откройте свойства подключения и на закладке Подключение - Проверка подлинности сервера установите опцию Предупреждать .
Чтобы данный ПК доверял сертификатам выданным нашим центром сертификации не забудьте установить на него сертификат ЦС в хранилище Доверенные корневые центры сертификации .
В Windows 7 (при использовании RDP клиента версии 7) данный сертификат требуется установить в хранилище учетной записи компьютера , для этого импортируйте его через оснастку Сертификаты (локальный компьютер) в консоли MCC, аналогично тому, как это делали выше. В противном случае подключение будет невозможно и вы получите следующую ошибку:
Установив сертификат ЦС можете пробовать подключиться, обратите внимание, что имя пользователя и пароль будет предложено ввести еще до создания RDP сессии. При успешном соединении обратите внимание на замок в заголовке окна, который свидетельствует о работе через SSL. Нажав на него можно просмотреть информацию о сертификате.
И напоследок капля дегтя в бочке меда. Терминальные службы Windows не умеют проверять подлинность подключающихся клиентов, поэтому если стоит такая необходимость следует использовать дополнительные методы защиты, такие как SSH туннель или IPSec VPN.
Доброго времени суток, Уважаемые Гости! В данной статье мы хотели бы вспомнить про доверие сертификатов в Браузерах, благодаря и . Многие люди не понимают, что сертификат SSL пользователя является только одной частью всей "цепочки сертификатов". Давайте поговорим о промежуточных и корневых сертификатах. SSL (точнее, TLS) - это технология, о которой большинство пользователей практически ничего не знают. Даже люди, приобретающие его, как правило, не знают многого, кроме того, что им нужен сертификат SSL и они должны установить его на своем сервере, чтобы обеспечить HTTPS на своём сайте. Итак, начнём!
Доброго дня!
Я думаю, что почти каждый пользователь (особенно в последнее время) сталкивался с ошибкой в браузере о том, что сертификат такого-то сайта не является доверенным, и рекомендацией не посещать его.
С одной стороны это хорошо (все-таки и браузер, и вообще популяризация подобных сертификатов - обеспечивает нашу безопасность), но с другой - подобная ошибка иногда всплывает даже на очень известных сайтах (на том же Google).
Суть происходящего, и что это значит?
Дело в том, что когда вы подключаетесь к сайту, на котором установлен протокол SSL, то сервер передает браузеру цифровой документ (сертификат ) о том, что сайт является подлинным (а не фейк или клон чего-то там...). Кстати, если с таким сайтом все хорошо, то браузеры их помечают "зеленым" замочком: на скрине ниже показано, как это выглядит в Chrome.
Однако, сертификаты могут выпускать, как всем известные организации (Symantec, Rapidssl, Comodo и др.) , так и вообще кто-угодно. Разумеется, если браузер и ваша система "не знает" того, кто выпустил сертификат (или возникает подозрение в его правильности) - то появляется подобная ошибка.
Т.е. я веду к тому, что под раздачу могут попасть как совсем белые сайты, так и те, которые реально опасно посещать. Поэтому, появление подобной ошибки это повод внимательно взглянуть на адрес сайта.
Ну а в этой статье я хочу указать на несколько способов устранения подобной ошибки, если она стала появляться даже на белых и известных сайтах (например, на Google, Яндекс, VK и многих других. Их же вы не откажетесь посещать?).
1) Обратите внимание на адрес сайта
Первое, что сделайте - просто обратите внимание на адрес сайта (возможно, что вы по ошибке набрали не тот URL). Также иногда такое происходит по вине сервера, на котором расположен сайт (возможно, вообще, сам сертификат просто устарел, ведь его выдают на определенное время). Попробуйте посетить другие сайты, если с ними все OK - то вероятнее всего, что проблема не в вашей системе, а у того конкретного сайта.
Пример ошибки "Сертификат безопасности сайта не является доверенным"
Однако, отмечу, что если ошибка появляется на очень известном сайте, которому вы (и многие другие пользователи) всецело доверяете - то высока вероятность проблемы в вашей системе...
2) Проверьте дату и время, установленные в Windows
Второй момент - подобная ошибка может выскакивать, если у вас в системе неверно задано время или дата. Для их корректировки и уточнения достаточно щелкнуть мышкой по "времени" в панели задач Windows (в правом нижнем углу экрана). См. скрин ниже.
После установки правильного времени, перезагрузите компьютер и попробуйте заново открыть браузер и сайты в нем. Ошибка должна исчезнуть.
Также обращаю внимание на то, что, если у вас постоянно сбивается время - вероятно у вас села батарейка на материнской плате. Представляет она из себя небольшую "таблетку", благодаря которой компьютер помнит введенные вами настройки, даже если вы его отключаете от сети (например, те же дата и время как-то высчитываются?).
3) Попробуйте провести обновление корневых сертификатов
Еще один вариант, как можно попробовать решить эту проблему - установить обновление корневых сертификатов. Обновления можно скачать на сайте Microsoft для разных ОС. Для клиентских ОС (т.е. для обычных домашних пользователей) подойдут вот эти обновления:
4) Установка "доверенных" сертификатов в систему
Этот способ хоть и рабочий, но хотелось бы предупредить, что он "может" стать источником проблем в безопасности вашей системы. По крайней мере, прибегать к этому советую только для таких крупных сайтов как Google, Яндекс и т.д.
Для избавления от ошибки, связанной с недостоверностью сертификата, должен подойти спец. пакет GeoTrust Primary Certification Authority .
Кстати, чтобы скачать GeoTrust Primary Certification Authority:
Теперь необходимо скачанный сертификат установить в систему. Как это делается, по шагам расскажу чуть ниже:
5) Обратите внимание на антивирусные утилиты
В некоторых случаях эта ошибка может возникать из-за того, что какая-нибудь программа (например, антивирус) проверяет https трафик. Это видит браузер, что пришедший сертификат не соответствует адресу, с которого он получен, и в результате появляется предупреждение/ошибка...
Поэтому, если у вас установлен антивирус/брандмауэр, проверьте и на время отключите настройку сканирования https трафика (см. пример настроек AVAST на скрине ниже).
На этом у меня всё...
За дополнения по теме - отдельное мерси!
Всего доброго!
Успешно решил намедни проблемку с терминалами. Может кому ещё пригодится, да и мне в случае, например, амнезии будет полезно вспомнить:)
Суть проблемки в следующем. Имеются сервера терминалов на 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 не считая промежуточных центров сертификатов пока с ними разобрался сколько понаделал:)
Можно (и желательно) получать сертификаты от доверенных сторонних центров сертификации - но они и за денюжку - и по-учиться на сертификатах не дадут.
Продолжим. В процессе кейгенеза должны получить следующие вещи:
Всё последующее требует административной консоли (с повышенными правами) на подопытном сервере.
certutil -addstore root ca.crt
WinHttpCertCfg -a NetworkService -c LOCAL_MACHINE\MY -i test.p12 -p qweДа, если ключик таки уже импортировали как-то по-другому, можно дать правильные права командой:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SSLCertificateSHA1Hash /t REG_BINARY /d 0123456789..DEF
Ну Вот, собственно, и Всё. При следующем подключении - клиент не получит уведомления о неправильном сертификате сервера. Можно снова включать уведомления об этом кошмаре или даже запрещать соединяться с такими серверами.
Не правда ли, Всё очень просто?