Сертификат для сервера шлюза RDP
 

Имеем Windows Server 2008 R2. Он выполняет функции сервера терминалов. Функции домена сервер не выполняет. Для доступа к 1С используется RemoteApp. Так как есть пользователи которым нужен доступ снаружи (из интернета) я сразу обратил внимание на новую фичу "шлюз удаленных рабочих столов". Функции шлюза выполняет этот же сервер. На этапе настройки сразу возникает вопрос о том как правильно создать сертификат SSL.
В диспетчере служб IIS есть два варианта создания сертификата. Это "создать сертификат домена" и "создать самозаверенный сертификат". Так как домена у нас нет, то получается подходит только второй вариант. То есть нужно создать сертификат и потом установить его на тех машинах, в которых подразумевается доступ к RDP через шлюз. При создании такого сертификата, указывается только один параметр "Понятное имя сертификата". Что туда указывать непонятно (судя по названию параметра, можно вписать все что угодно). После того как сертификат создан и установлен на другой машине при подключении через шлюз предупреждение об отсутствии сертификата пропадает, но появляется новое. :shocked: Скрин предупреждения я выложил в приложении. Предупреждение говорит о том что запрошенный адрес шлюза не соответствует имени субъекта сертификата.

Пробовал в качестве имени задавать IP? тоже не катит! Сразу скажу, чтобы не было неправильных предположений, что сертификат естественно занесен в группу доверенных.

Может, кто поможет разобраться как все таки сделать удобоваримый сертификат.

PS Заранее спасибо!!

Нужно указывать имя сервера по которому вы обращаетесь к серверу из интернета.

Имя чего?? Компьютера? Так не подойдет! Во первых собственного имени в сети интернет машина не имеет. Есть IP, но он может быть динамическим? Непонятно!

Кроме того когда данный сертификат переноситься на другой комп, путь сертификации в нем меняется на имя сервера!

Вот выдержка о создании такого сертификата с сайта microsoft:
"На странице Создание самозаверенного сертификата введите понятное имя сертификата в поле Понятное имя сертификата и нажмите кнопку ОК."

Неужели никто еще шлюз для RDP без домена не настраивал?

Файл сертификатов шлюза (с открытым ключом) RDP можете привести?

Сертфикат хоста всегда содержит DNS-имя или IP-хоста.
Сертфикат нужен для аутентификации сервера на стороне клиента.
Как по вашему, без имени или адреса, клиент проверит, что сервер является тем за кого себя выдает?

Вот неплохо о сертификатах написано,
http://ru.ispdoc.com/index.php/SSL_с...87.D0.BE.D0.BC
либо ищите книгу MS Press о безопасности, вас интересует глава посвященная CA

Спасибо, что обратили внимание.
Об этом я уже слышал, но я пробовал именно с IP сервера и ничего не получил. И тогда также напрашивается вопрос как быть если доступ на сервер идет с нескольких сетей? На входе то IP разные, а в настройках шлюза можно указать только один сертификат. Ну это ладно, хоть с одним бы заработал.
Да пожалуйста, если это чем-то поможет! Выложил сертификат во вложении в форматах cert и prx(пароль на prx: 123). Сертификат самозаверенный. В качестве имени использую адрес сервера в локалке! Тестирую соответственно пока тоже в локалке на VMware.
В случае самозаверенного сертификата его копия передается на сторону клиента и по идее должно и так работать (так гласит microsoft)! А вот в случае доменного сертификата так действительно не получиться!
Списибо конечно за ссылку, но там немного не о том, а именно к Windows Server 2008 отношения не имеет. Да и если честно во всех этих книгах много теории и 0 практики. Меня интересует всего лишь один вопрос. Как правильно создать и потом использовать сертификат для доступа к шлюзу RDP на сервере не являющемся контроллером домена. Инет перерыл и нигде толковой информации не нашел. Инструкции есть только для домена, где соответственно используют доменный сертификат, чего у меня нет! Может я конечно чего-то не понял и может можно как-то создать доменный сертификат для моего случая (хотя он требует сервер сертификации), но как это сделать я не знаю.
Поэтому и прошу помочь.

Вот здесь вполне удобоваримая статья по настройке шлюза RDP. Там есть раздел про создание сертификата, но применительно к домену. :(

Это очень просто, в файле host на клиенте прописываете, то DNS имя которое указано в сертификате.
Если клиентов не много - эт овполне приемлемо.

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


Вы, путаете сертификат и для чего он нужен.

Расшифрую:
- Главная функция это аутентификация сервера на стороне клиента, т. е. клиент (точнее компьютер клиента) пытается убедится, что сервер является тем, за кого себя выдает, а не какая либо бяка вставшая посередине вашего трафика или просто подправившая DNS-разрешения.
Способов аутентификации сервера много, но прижились двое:
- preshared key
- сертификат сервера

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


Кстати, если имя сервера разрешаемое (при помощи DNS) на стороне клиента, не совпадает с именем в предъявлямом сертификате, то и домен вам не поможет.
Домен хорош когда все, и клиенты и серверы в нем находятся ,т.е. распознавание имен у них происходит при помощи одного механизма - серверов имен домена.
Т. е. заранее есть гарантия, что имя под которым себя осознает сервер будет таким же на клиенте.


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


Сертифкаты везеде одинаковые.
В той же MS можно развернуть центр сертифкации интегрированный в домен и не интегрированный.
Интегрированным в домент просто гораздо проще управлять (например с помощью групповых политик), выпускать и отзывать сертификаты.
По рекомендации той же MS корневой CA всегда автономен, т.е. не интегрируется в домен.

Про это я как-то не подумал? В принципе вариант! Пойду сейчас попробую! Спасибо.

Спасибо, что просвящаете, но я четко знаю что сертификат нужен в моем случае для безопасного соединения клиента с сервером! Этого мне достаточно. А за инфу спасибо, я действительно с сертификатами еще плотно не морочился, поэтому слабо подкован в теории.

Если честно просто некогда в инфу вникать, стоит несколько серваков новых и ждут своей участи (и участь у них разная), тут уж не до изучения теории. Начальство напирает, поэтому не до этого. А по поводу тырканья кнопочек вы переборщили все-таки, я обычно тыркаю их с пониманием того, что делаю, кроме того по возможности все стараюсь без них делать, т.е. через консоль, тем более что мелкософт активно ее развивает. А вот с сертификатом вы правы, я просто плясал с бубном! :) Спасибо что помогаете от этих плясок избавится!

Да есть такая роль "Службы сертификации Active Directory", как я понимаю вы про это говорите. Да, создал там сервер сертификации, но как его юзать пока не понял. Я сразу знал что процесс выдачи сертификатов можно автоматизировать, но вопрос как? Не просвятите как правильно развернуть центр сертификации и настроить выдачу или обновление сертификатов? Буду очень благодарен. В сети инфа точечная и целой картины относительно этого собрать не получается.

Брэгг Роберта
Безопасность сети на основе Microsoft Windows Server 2003
Экзамен 70-298
Глава 2
http://www.infanata.org/2006/01/13/b...rver_2003.html


По 2008, к сожалению еще ничего нет.
Однако по собственному опыту хочк сказать ,что работа с сертификатами там не изменилась. просто была добавлена новая версия сертификатов v3 (она функционирует только внутри домена 2008 и отношения к SSL не имеет)

Развертывание центра сертификации для одного, двух серверов - это глупость.

Данная операция имеет смысл при массовых операциях:
- Внедрении услиненной аутентификации пользователей по е-токенам
- Внедерние шифрования файловой системы
- Внедрение защищенной электронной почты
- внедрение аутентификации хостов пользователей в сети по 802.1X, в том числе и безпроводных.

Спасибо, качну для расширения кругозора.

Но вот подключиться к RDP через шлюз пока так и не вышло!
Имею следуещее:
1) Сервер имеет IP 192.168.10.11
2) Имя сервера: server;
Делаю все вот так:
На сервере:
1) Настроил терминальный доступ на сервер. Без шлюза естественно все работает;
2) Создаю две политики для шлюза терминалов(авторизации подключений и авторизации ресурсов). Прописываю им группы пользователей.
2) В оснастке "Диспетчер шлюза удаленных рабочих столов" в свойства сервера в закладке "Сертификат SSL" выбираю опцию "Создать самозаверяющий сертификат", нажимаю кнопку "Создать и импортировать сертификат";
3) Метод проверки для шлюза выбран как пароль;
4) Задаю имя сертификата "server" и выбираю путь для сохранения сертификата. Выставляю галку "Хранить сертификат";
5) Проверяю, что сертификат находится в каталоге доверенных корневых сертификатов;
6) Копирую сертификат на другой компьютер в этой же сети имеющий адрес 192.168.10.1;
На клиенте
1) Устанавливаю сертификат выбрав каталог доверенных;
2) Прописываю в hosts соответствие 192.168.10.11 server;
3) Запускаю mtsc и вношу следующие параметры:
а) Сервер: server
б) Сервер шлюза: server;
в) Убираю галку "не использовать для локальных адресов"(так как сервер у нас локальный)
4) Пытаюсь подключиться!! Выдаеться запрос на имя пользователя и пароль. ВОЙТИ НЕ ПОЛУЧАЕТСЯ! Выдает запрос заново и так до бесконечности.

Что удивительно, если в качестве адреса шлюза при подключении указать его IP, то авторизация проходит успешно, но выдается предупреждение, о котором я писал в первом посте и зайти тоже не получается!?

Что же я делаю не так???

Я, честно говоря не вкурсе данной технологии MS, однако в технологии доступа Citrix, с которой она содрана, доступ осуществляется при помощи браузера, а не mtsc.

Уточните:
- терминальный клиент и его настройки при доступе поверх web
- номер порта сервера который для этого используется (IIS точно не использует RDP порты, вероятнее всего 443 или нечто специфическое)


Это просто "имя" сертификата, имя сервера к которому он привязан вероятнее всего опрделяется в свойствах IIS - проверю сертификат, скажу точнее

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

выведите результаты отработки на клиенте
tracert server

Через браузер ситуация такая. На сертификат ругаеться, но пускает. Но это совсем другое. Это делаеться без шлюза терминалов. Обычное https соединение!
А я делаю по другому. Создаеться подписанный сертификатом rdp файл. Он запускается на клиенте и вуаля, нужное приложение запущено. Ну а для прошаренных разрешен вход через mtsc.
Да нет никакого доступа поверх web. Есть один единственный 443 порт по нему и должен производится доступ на шлюз. Скрины настроек прикрепил к сообщению.
Майкрософт в этом вопросе разошелся во мнениях. В одном месте это просто имя, в другом написано, что это обязательно должно быть имя сервера?? Непонятно!

Ничего подобного! Сертификат у меня на один год!! Более того срок действия я выбрать не могу. Система автоматом год ставит. Скрин прикрепил к сообщению.
Скрин во вложении 4.

1) Да, с временем вы правы.


2) Проверьте версию терминального клиента

3) Судя по этому
http://technet.microsoft.com/ru-ru/l...41(WS.10).aspx

Архитектура идентична той, что я описывал.
У вас сервер терминалов и шлюз на одном компьютере?
Если на разных - данные по ним приведите.

На сервере шлюза данные компоненты активны?
Службы удаленных рабочих столов\Шлюз удаленного рабочего стола
политики сети и службы доступа\сервер политики сети;
веб-сервер (IIS);
RPC через HTTP-прокси.

2) А какие методы входа еще возможны?

Версия клиента подходящая, а именно 6.1.7600. Система Windows 7. То есть и с проверкой подлинности на уровне сети тоже все в порядке!

Да, все на одном компе.

Все данные службы активны!

Да вобщем то никакие..

С виду все настроено и работает, только непонятно почему авторизация не прокатывает?



Такое окошко выскакивает, но сколько раз туда учетные данные не вводи, они не принимаются и окошко заново выскакивает.. Жесть какая то!

Я бы для очистки совести сделал как в приведенном MS материале (два отдельных сервера)
Только боюсь, все таки сервер шлюза и сам терминальный сервер должны в одном домене находится

К сожалению такая возможность отсутствует. Хотя-бы по финансовым соображениям. И не только.

Нет, это не обязательно.

Блин, неужели по старинке VPN мутить придется... А так хотелось по новому..

Я имею в виду не эксплуатацию, а макетирование.
Вы же сами сказали, что на VMware тренируетесь

Поставил вторую систему, сейчас буду проверять! Но хотя это нифига не выход. В итоге мне же это нужно на одной машине.

На двух серваках заработало! Блин, ну это жесть! На одном, даже заново развернутом отказывается работать! Опять тоже самое!
Сейчас поставлю на живую машину и еще раз попробую тоже самое. Причем, что самое странное, у нас уже стоит одна машина, которая выполняет такие функции. И мой коллега, который там все ставил, утверждает, что делал все точно также, как делаю я, только сразу на живую машину (может тут собака порылась).

И еще один вопрос по поводу сертификатов. При установке системы создается два сертификата(они самозаверенные). Один на срок 10 лет, а другой менее чем на год. Так вот , как создать самозаверенный сертификат на срок больше года. Ну лет на 5 например.

Без СА и оснастки выпуска сертификатов - никак.

Судя по всему:
- Сертифкат, тот который на 10 лет - это для подписи собственных сертификатов
- Сертификат, тот который на год - это сертификат веб-морды (шлюза), который, вероятно планируется перевыпускать раз в год.

Тут, может быть пересечение портов, либо требование разности имен (вполне возможно IIS требуется и на шлюзе и на терминальном сервере одновременно, но с разными режимами).
На худой конец можно попробовать такую махинацию:
- определить два интерфейса для одного сервера с разными DNS-именами
- тогда в настройках доступа будут фигурировать, якобы два сервера

Тут есть одна загвоздка. Как быть в случае переименования компьютера. Имя субъекта сертификата поменять же нельзя? Вот поэтому и вопрос, как быть в этом случае!

Буду провбовать в понедельник. Спасибо за помощь.

только перевыпуск сертификата, без вариантов.

Если вы развернули службу сертификатов, то у вас должна быть стандартная оснастка их выпуска.
Что и как есть в той книге, что я привел.

Ну это например не вариант. Потому как для того чтобы развернуть службу сертификатов сервер должен быть контроллером домена! А это не решение..

Это не так.
По крайней мере было не так в 2003.
При установке CA спрашивается об интеграции CA:
- CA предприятия (интегрируется в домен)
- Изолированный CA (домен не нужен)

Да, и правда, что-то я переборщил. Поднял у себя центр сертификации. Создал из Диспетчера IIS запрос на выдачу сертификата в виде txt файла. Далее это запрос обработал из центра сертификации. НО, срок действия сертификата выбрать нельзя, он ставится 1 год.

Здравствуйте!
Столкнулся со схожей проблемой, решил настроить веб-доступ к удаленным раб. столам, но усложняется тем, что внутренняя сеть за маршрутизатором. Создал самозаверенный сертификат, назвал по имени сервера, из локальной сети на сервер запускает, но с предупреждением по поводу сертификата, жму продолжить все ок. Когда из вне подключаюсь, доходит до предупреждения о сертификате, жму продолжить и связь теряется!
Сеть без доменная, имеется только внешний белый IP, ни какого доменного имени не зарегистрировано.
Не пойму как клиент из вне может проверить имя сервера во внутренней сети, у них же dns сервера разные, грубо говоря клиент видит только внешний IP компании.
Если как вы сказали изменить файл hosts, но это же не выход, если сотрудник очень далеко, и с компом на ВЫ?
Третий день сижу, помогите пожалуйста!
Заранее спасибо!

Стоит аннологичная задача. Почти месяц роюсь с этими сертификатами. Так и не получилось настроить. Если делать с доменом, то проблем нет, да и инструкций в инете полным полно. А вот без домена, так это темный лес, сколько копался так и не нашел информации.

Ситуация аналогичная ZOOBR. Значит без домена ни у кого не получилось заставить авторизироваться удаленного клиента? И еще странность: Анализатор соотвествия рекомендациям рапотрует, о том, что нет сертификата и не настроена политика доступа. Хотя в Диспетчере шлюза удаленных рабочих столов все настроено.

Чтобы не плодить темы, спрошу здесь...
Пытаюсь сделать ssl сертификат домена, но вместо выбора "онлайн центра сертификации" мне предлагает "локальный центр"
Что не так делаю?

Вместо этого:

Это:

Спасибо.

Аналогичная проблема с сертификатом. Сеть без домена. В локалке все работает, через инет - нет.
Кому-нибудь удалось подключится?

Мне интересно, почему в теме стоит пометка РЕШЕНО? Я решения тоже не увидел.
Локальная сеть хоть и с доменом, но из инета подключиться к серверу терминалов также не получается. В hosts альяс для доменного имени сервера прописал, клиент к серверу подключается именно по этому имени, проходит авторизацию с доменным логином и паролем, но потом вот такой превед


Сертификат в доверенные корневые центры сертификации клиенту добавлен :closed-to