Не удалось подключиться к удаленному компьютеру поскольку сертификат сервера шлюза просрочен
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Пробовал поднять службы сертификации Active Directory на шлюзе, создать сертификат, картина та же 🙁
Ответы
на самом деле тут не всё так просто как кажется. Даже если вы решите проблему доверия корневому сертификату, у вас появится другая проблема — сертификат не сможет быть проверен на отзыв извне (из интернета) и снова случится фейл. Следовательно, я тут вижу 2 приемлемых варианта.
1) Простой и дорогой
Если вы планируете использовать только один (или несколько, но не более 10) сертификат для шлюза — проще будет купить сертификат у коммерческого CA.
2) сложный и относительно дешёвый.
Если вы планируете массово использовать сертификаты в своей организации и работе — придётся самостоятельно установить и сконфигурировать центры сертификации. Вот пример, как это можно сделать:
Путь долог и тернист, но весьма полезный. ————————————————————— И напоследок прокомментирую некоторые высказывания в этом топике:
это не минимальные усилия. Особенно, если в лесу несколько доменов. Тогда придётся создавать эту политику в *каждом* домене. Вместо этого проще сертификат опубликовать в AD:
в таком случае все компьютеры *леса* будут доверять этому корневому сертификату.
эмм..а зачем в PFX? Надо просто в CER.
неправильная последовательность. Чтобы установить корневой сертификат на изолированную рабочую станцию надо сделать:
1) запустить MMC.EXE с правами администратора
2) добавить оснастку Certificates с фокусом на *учётную запись компьютера*.
3) добавить сертификат в Trusted Root CAs
это вы заблуждаетесь и сильно. Сертификаты выпускаемые центром сертификации под управлением Windows Server 2003 ничем не отличаются от Windows Server 2008 или от центров сертификации VeriSign.
Причина
Проблемы возникают потому, что служба шлюза удаленных рабочих Столов получает привязку неверный сертификат.
Настройка доверенных SSL/TLS сертификатов для защиты RDP подключений
В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.
Общие обсуждения
Имеется сервер Server 2008 SP2, на нем стоит терминальный сервер
Сгенерен самозаверяющий сертификат, и установлен в «доверенные» и в «личные»(в личных не отображается) на сервере
Этот же сертификат поставлен в рабочую станцию, с которой пытаюсь подключится.
Я опустила руки. Нет ни идей, ни вариантов, что делать.
Где брать этот, просроченный, ума не прилажу.
Может у кого будут какие то идеи?
П.с. сертифкат этот, просроченный(с 2005 по 2006 год, тогда и системы то не стояло, ни серверной, ни моей. ), откуда-то взялся на моем компе в «доверенных», хотя я его не устанавливала. После удаления с ошибки «срок действия» переключился на «не стоит доверия».э
Но проблему это не решает.
Т.е. он должен лежать на сервере, куда пытаюсь подключится. Но ГДЕ?
Все ответы
Там один, мой сертификат. Сгенеренный.
«Точно смотрите сертификат в хранилище «Личные» локального компьбютера, а не «Личные» для вашей учетки?»
Захожу в точности как описали выше
А если зайти через панель управления-свойства обозревателя-содержание-сертификаты-личное(как раз сертификаты пользователя) то там именно сертификат пользователя, который нигде не вылазит(и не должен ведь)
Вроде поняла где собака зарыта с этим сертификатом от 2005 года. Скорее всего он привязан к программе, которую я пытаюсь открыть через RemoteApp.
Но если не программу открывать, а выбрать «Удаленный рабочий стол», то все равно вылазит сертификат от 15.06.2011, который я опять нигде не могу найти. Самозаверяющий, выданный этим сервером, на который пытаюсь зайти. Т.е. где-то он в настройках должен светиться.
Он то конечно действующий, но через пол года закончится, и как его менять, если его нигде не найти? 🙁
Компьютеру не удается подключиться к серверу шлюза удаленных рабочих столов windows 10
Ошибка «Не удалось подключиться к удалённому компьютеру, поскольку сертификат сервера шлюза удалённых рабочих столов отозван или просрочен».
При этом Windows 10 (8, 7) этот сертификат (выданный доменным Центром сертификации) не просрочен и подключение в этих ОC происходит без проблем. В хранилище Доверенные корневые центры сертификации (локальный компьютер) сертификат доменного ЦС есть.
Списки отзыва актуальные, серийного номера сертификата шлюза в них нет.
Пока нагуглил, что какие-то проблемы с Службой времени Windows в этой ОС. В Просмотре событий очень много 158 кодов про ошибку VMICTimeProvider. Вместе с тем, время в трее показывается актуальное, синхронизация с сервером времени time.windows.com происходит успешно.
Кто-нибудь сталкивался с подобной проблемой? Нашлось решение?
Буду признателен за любую помощь по существу проблемы.
Answers
Скорее всего на WIN11 старый TLS запрещен или его можно включить.
Спасибо, что ответили. Я уж думал, что я один с такой проблемой столкнулся. Я создал обращение в техподдержку MS, сегодня ко мне подключались специалисты, смотрели и недоумевали, обещали подключить спецов уровнем выше. Можно поинтересоваться, а какая у Вас версия Windows на Шлюзе удалённых рабочих столов? У меня 2008R2.
Есть такая же проблема, шлюз 2008R2. На самом деле по ошибкам time-service мы ничего не определим т.к. на ОС Win10 они точно такие же, но при этом все прекрасно работает.
Спасибо Вам за Ваш вопрос.
2. Убедитесь, что URL-адрес rdweb работает нормально.
3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?
4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.
Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов как исправить
Сервер RDP находится за маршрутизатором. На маршрутизаторе был проброшен 403 порт.
Программы не запускаются, а скачиваются *.rdp файлы.
Через эти файлы программы не запускаются, так как в них указан удаленный компьютер и сервис шлюза в формате ServerName.DomainName.
Как исправить ситуацию?
Вопрос 2. Что указывать в параметрах подключения RDP клиента?
Удаленный компьютер- внешний IP?
Шлюз тоже внешний IP?
При указании внешнего IP в обеих случаях был получен сертификат для внешнего IP, который я занес на локальный компьютер, но в резульате выдоло сообщение.
Обратитесь к администратору сети за помощью.
Здравствуйте. Пытаюсь поднять RDS, столкнулся с проблемой.
Все необходимые роли службы удаленных рабочих столов заведены на одном сервере. Доменное имя сервера внутри сети server.mydomen.com совпадает с «внешним» доменным именем. Настроил веб-доступ к удаленным рабочим столам, личные рабочие столы для пользователей и тд.
Если так же заходить снаружи, не из домена, ошибка следующая:
Удаленному рабочему столу не удалось подключиться к удаленному компьютеру «server.mydomen.com» по одной из этих причин: 1) Данной учетной записи пользователя не предоставлены права на доступ к шлюзу удаленных рабочих столов «server.mydomen.com» 2) Данный компьютер не авторизован для доступа к шлюзу удаленых рабочих столов «server.mydomen.com» 3) Используется несовместимый метод проверки подлинности (например, шлюз удаленных рабочих столов ожидает смарт-карту, а предоставлен пароль)
Переустановил роль rdg, перенастроил точно так же. В итоге получил ещё одну ошибку (в дополнение к трём существующим):
4. В группе «Пользователи удаленного рабочего стола» на сервере узла сеансов удаленных рабочих столов должны присутствовать пользователи или группы домена.
После этого на клиенте через rdweb появилась уже другая ошибка:
«При отправке данных на сервер шлюза удаленных рабочих столов произошла ошибка. Сервер временно недоступен или не работает сетевое подключение.»
ПС: давно не работал с виндовс, совсем забыл про актуальность шутки:
Едут в машине таксист, бизнесмен и программист. Вдруг машина ломается. Таксист говорит: — Давайте мотор смотреть. Бизнесмен: — Да ладно, давай тачку поймаем. Программист: — А давайте все выйдем и снова войдем, может, она заработает?
При этом политики диспетчера шлюза удаленных рабочих столов:
Политики авторизации подключений
Если пользователь является членом любой из перечисленных ниже групп пользователей:
mydomen.comАдминистраторы предприятия, mydomen.comГости домена, mydomen.comСотрудники mydomen.com Если клиентский компьютер является членом любой из следующих групп компьютеров: mydomen.comГости домена, mydomen.comКомпьютеры домена Если пользователь использует следующие поддерживаемые методы проверки подлинности Windows: Пароль Разрешить пользователю подключение к этому серверу шлюза удаленных рабочих столов и отключить перенаправление устройств для следующих клиентских устройств: Неприменимо (перенаправление устройств включено для всех клиентских устройств) По истечении времени ожидания в режиме простоя: — Не применяется (без времени ожидания простоя) По истечении времени ожидания сеанса: — Не применяется (без времени ожидания простоя)
Политики авторизации ресурсов
PROGRESS-MАдминистраторы предприятия, mydomen.comГости домена, mydomen.comСотрудники mydomen.com
Сетевой ресурс: разрешить подключение пользователей к любому сетевому ресурсу
1. Проверьте наличие учетной записи RDG в группе безопасности RAS and IAS Servers в Active Directory.
1. Что вы имеете в в виду под «учетной записью RDG»? Группу RAS and IAS Servers нашел. Вот список моих групп:
2. Настройку осуществил, выбрал уровень безопасности RDP. Только в статье тип подключения 6.1, а у меня 7.1. Немного изменился ход подключения, но ошибка в итоге та же самая.
Никто ещё что-нибудь не подскажет?
бывает если подключаться к члену фермы через имя компьютера, а не фермы. У вас случайно не включена эта фича?
Вот она по-моему где включается. Видимо нет.
Таким образом настроено.
Про виртуальные машины ранее информации не было, то есть это физическая машина одна. Может быть еще информация какая-нибудь будет? Где стоит Web-Access и что происходит на виртуальных машинах?
Да, всё на одной машине. Чтобы наружу не пробрасывать кучу портов на вирт. машины. Да и безопаснее.
Физическая машина вообще одна. На ней 11 виртуальных машин. Все роли установлены на хостовой системе. Домен active directory mydomen.com. Сервер (хостовая система) server.mydomen.com. Всем пользователям назначены виртуальные рабочие столы (например vm1.mydomen.com). При заходе в rdweb (без разницы извне или снаружи) пользователи авторизуются и нормально видят свои опубликованные столы. При попытке подключения ошибка в первом посте. Сертификат используется самоподписанный, один для всех служб, занесённый на сервере и на клиентах в доверенные. Ещё какая информация, вроде всё описал? Сейчас в службах удаленных рабочих столов обнаружил три ошибки: 1. Cервер шлюза удаленных рабочих столов должен иметь возможность подключения к доменным службам Active Directory. 2. На сервере шлюза удаленных рабочих столов необходимо включить хотя бы одну политику авторизации подключений к удаленным рабочим столам. 3. На сервере шлюза удаленных рабочих столов следует настроить использование действительного SSL-сертификата
1. RDG стоит на контроллере домена. Каким образом он не может достучаться до AD?
2. Политики есть и они включены.
Точно такие же проблемы на форуме видел, но решения там не было.
Настройка групповой политики для выдачи RDP сертификатов
Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.
Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:
Теперь при RDP подключении к серверу перестанет появляться запрос на доверие сертификату (чтобы появился запрос о доверии сертификату, подключитесь к серверу по IP адресу вместо FQDN имени сервера, для которого выпущен сертификат). Нажмите кнопку “Посмотреть сертификат”, перейдите на вкладку “Состав”, скопируйте значение поля “Отпечаток сертификата”.
Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:
Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.
Не удалось подключиться к удаленному компьютеру так как запрошенный адрес сервера шлюза удаленных
Все службы RDS установлены на одном сервере W2012.
Все работает в пределах домена, есть пользователи в удаленной сети (другая подсеть+VPN до офиса).
Через Rdp-сессию сидят без проблем.
Ну, вообще, должен быть указан тип лицензирования, на пользователя или на устройство, но не об этом речь, я имел ввиду в настройках шлюза указана ли галка:
Машина по прежнему пытается подключиться через шлюз.
Если вы поставили галки, то этого происходить не должно.
Если не получится, то в качестве теста, попробуйте отключить шлюз.
На машинках в какой сети возникает ошибка?
Какая версия клиентских ОС?
Используется ли у вас шлюз для внутренних сетей?
Если True, то авторизация для пользователей внутри сети на шлюзе не происходит.
На машинах из внешки.
в основном 7х64. и та с корой надо заставить работать тоже.
насчет шлюза не понял? филиал выходит в инет через другого провайдера. между роутерами впн-канал(ходят на файл шару, 1с.) впринципе именно 1с в remoteapp и не работает.
развернуты службы удаленных рабочих столов.
сейчас залез в свойства развертывания
Попробуйте с включенной галкой обновить подключение RemoteApp
Какой сертификат у вас используется?
у меня вообще вот так причем с одной машины запускается норм так как есть опция продолжить а на другой ругается на сертификат и не пускает дальше
Значит у вас используется дефолтный самоподписный сертификат.
Когда вы подключаете RemoteApp вы прописываете путь подключения к серверу в виде
Соединение по https, соответственно нужен сертификат.
Если у вас есть доменный центр сертификации рекомендую выдать сертификат для вашего сервера.
Пришлите, пожалуйста, ошибку сертификата с той машины где не запускается.
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
Итак, сертификат 61619b9c000000000013
а что у вас ссылка на CRT делает в расширении OCSP? Как минимум из-за этих ошибок у вас неполная цепочка сертификатов.
корневой сертификат этой цепочки (сервера DGET-CA) у вас не установлен в доверенные центры сертификации компьютерного хранилища.
61619b9c000000000013 — нужно удалить. Корректно настроить расширение AIA на издающем CA и выпустить новый сертификат.
61fb04be000000000017 — сертификат сервера DGET-CA нужно установить в доверенные центры сертификации компьютерного хранилища.
на самом деле, не знаю, чего она там делает =) сертификат сервера стоял и стоит в доверенных центрах удалённой машины.
переделал сертификаты. собственно, ничего не поменялось, ошибка та же:
Ошибка подключения к удаленному рабочему столу из-за невозможности проверить подлинность удаленного компьютера. Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным. Имя в сертификате от удаленного компьютера: msk-db01.msk.dget.ru. Не удалось проверить, не был ли отозван сертификат. Продолжение невозможно из-за серьезных ошибок сертификатов.
Поставщик: CN=DGET-CA DC=msk DC=dget DC=ruСубъект: CN=compas.myftp.orgСерийный номер сертификата: 613796c600000000001d
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)SimpleChain.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
Поставщик: CN=DGET-CA DC=msk DC=dget DC=ruСубъект: CN=msk-db01.msk.dget.ruСерийный номер сертификата: 613f693700000000001e
Ошибка «компьютеру не удается подключиться к удаленному компьютеру» так как зависание службы шлюза удаленных рабочих Столов в Windows Server 2012 R2
В данной статье описывается проблема, которая возникает при попытке доступа к серверу служб удаленных рабочих столов (RDS) через службу шлюза удаленных рабочих столов (шлюз RD) в Windows Server 2012 R2. Доступно исправление для решения этой проблемы. Исправление с условием.
Не удаётся подключиться к RDP через шлюз?
Пробовал подключаться с двух разных компьютеров, которые территориально находятся совсем в разных местах (разные провайдер, IP и пр.). На обеих стоит Windows 7 x64 uk-UA (без SP, без обновлений), оба настраивались и используются мной. Нет даже предположений, в чём проблема. Какой-то софт, либо сделанные мной настройки, или ещё что.
Ну и, собственно, вопрос. Что не так и что делать? Как локализовать проблему? Чем мои компьютеры так уникальны и не нравятся шлюзу?
Ваш компьютер не может подключиться к серверу шлюза удаленных рабочих столов —
Ошибка ‘Ваш компьютер не может подключиться к серверу шлюза удаленных рабочих столов’, Когда вы не можете подключиться к удаленной системе. Причиной ошибки, по-видимому, является использование HTTP / UDP-соединения клиентом удаленного рабочего стола. Клиент удаленного рабочего стола время от времени получает обновления от Microsoft, и они обычно предлагают более новую версию с выпуском новой Windows. С течением времени они также выпустили поддержку RDP-соединений по HTTP.
Хотя новые версии и больше функций всегда ценятся сообществом, они также сопровождаются его ошибками и проблемами, которые могут вызвать появление определенных ошибок. Тем не менее, все вопросы также имеют свои выборочные решения. Вы можете найти решение для указанной проблемы ниже.
Сообщения: 12 Благодарности:
Сообщения: 425 Благодарности: 72
если порт отвечает снаружи, соединение должно проходить
нужно тогда больше информации с клиента смотрите логи по службе RDP
вы к серверу подключаетесь через шлюз?
то есть у вас 2 сервера, шлюз к которому вы изначально подключаетесь через HTTPS, и сам сервере терминалов?
Что вызывает ошибку «Ваш компьютер не может подключиться к серверу удаленного рабочего стола» в Windows 10?
Что ж, после небольшого исследования мы обнаружили реальную причину сообщения об ошибке, которая неизвестна многим. Ошибка вызвана по следующей причине —
Теперь, чтобы исправить вашу проблему, вы должны будете следовать предложенному ниже решению. Для добавления нового ключа в реестр Windows потребуется учетная запись администратора.
Создайте новый ключ реестра ‘RDGClientTransport’
Решение указанной проблемы довольно простое и понятное. Вам просто нужно добавить новый ключ DWORD в реестр Windows с именем ‘RDGClientTransport». Это заставляет клиента RDP использовать соединение RPC-HTTP через соединение HTTP / UDP. Вот как добавить ключ:
Это, вероятно, решит вашу проблему, и вы сможете снова подключиться к удаленной системе.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
В связи с недавними обновлениями безопасности Windows, закрывающее уязвимости в протоколе CredSSP, парочка маков (mac mini середины 2007 года) потеряли доступ к терминальному серверу на базе Windows Server 2008R2.
Программе подключения к удаленному рабочему столу не удается проверить удостоверение компьютера, к которому осуществляется подключение.
Дело в том, что старая версия маковского rdp client 2.1.1 от Microsoft, ставшая последней доступной для Mac OS X 10.7 (Lion), не работает не только с Windows Server 2012, но после вышеупомянутого обновления перестала подключаться и к WinServer 2008R2. В природе существует и неофициальная версия rdp-клиента 2.1.2, однако разыскивать её, нет особого резона — результат будет аналогичным.
Актуальные, на данный момент, клиенты Microsoft Remote Desktop 8.0 (совместима с OS X 10.9 и выше) и Microsoft Remote Desktop 10.0 (macOS 10.10 и выше) поставить на старую систему OS X не представляется возможным. Из вменяемых альтернатив, можно выделить, пожалуй, только Parallels Client. и вроде вот оно счастье, ведь в минимальных требованиях значится Mac OS X 10.7.3, однако не стоит верить всему что пишут. Хоть программа и благополучно устанавливается, позволяет внести данные о вашем подключении, однако вылетает на попытке соединения с сервером вываливая кучу ошибок.
От безысходности можно пойти от обратного, изменив работу службы удаленных рабочих столов на сервере (метод работает и на Windows Server 2012), однако лучшим вариантом станет замена клиентской машины.
Подключения старой версии rdp client 2. 1 к Windows Server 2012
Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:
Здесь следует поменять значение двух параметров:
Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.
Если считаете статью полезной,не ленитесь ставить лайки и делиться с друзьями.
Комментариев
Добрый день. Не ожидал что в 2018 найду свежую информацию для старых маков. Вот мне как раз актуально, так как подключаюсь по удалёнке не к серверу, а к своему рабочему компьютеру на Windows 10, обновился недавно. Теперь RDP снова работает 🙂
Вы так конкретно и доступно всё описали, что до меня наконец-то дошло почему не удаётся подключиться к удалённому компу. Спасибо за помощь!
Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата
Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.
Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:
Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).
Четверг, 29 сентября 2016 г.
Поиск виновника «торжества» привел к обновлению, известному как Windows 10 Anniversary Update, повышающему версию ОС до 1607. При этом, судя по всему, проблеме подвержены в основном ПК под управлением 32-х битной версии ОС. К сожалению долгий поиск официального решения данной проблемы ни к чему не привел, поэтому пришлось воспользоваться найденными на просторах сети «костылями», а именно подменой проблемного RDP клиента и соответствующей ему системной библиотеки с версии 10.0.14393.187 (Windows 10 build 1607) на версию 10.0.10586.589 (Windows 10 build 1511).
Для этого необходимо:
При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.
В этой статье предоставляется решение для различных сообщений об ошибках, связанных с сертификатом, при подключении к серверу терминала.
Применяется к: Windows Server 2012 R2 Исходный номер КБ: 2000960
Устранение ошибки проверки подлинности RDP
8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.
После установки данного обновление пользователи не могут подключиться к удаленным ресурсам посредством RDP или RemoteApp. При подключении происходит такая ошибка:
Появление ошибки обусловлено установкой данных обновлений безопасности:
В данной статье мы рассмотрим варианты исправления данной ошибки.
Вариант №1: Убираем проверку подлинности.
Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.
Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.
Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.
Вариант №3: Через групповые политики.
В свойствах данной политики выбираем пункт Включено и ниже в параметрах выбираем уровень защиты Оставить уязвимость.
После того, как данные действия выполнены, необходимо зайти в командную строку от имени администратора и выполнить данную команду:
Вариант №4. Редактирование реестра.
Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:
После выполнения данных действий с реестром выполняем перезагрузку устройства.
Нужна помощь в настройке RDP-подключений? Обращайтесь к нам!
Frage
Привет!, а Вас не смутило, то что Вы допустили две ошибки:
-вопросу уже более полутора лет;
-Автор вопроса, не Вы.
Правильнее задавать свой вопрос, указывая ссылкой на это обсуждение вопроса.
Начните с внимательного изучения серии статей, начав со статьи «Краткое руководство по Microsoft PKI». Особое внимание обратите на требование для Внешних Пользователей, и Корневой сертификат, должен быть подписан Доверенным корневым центром сертификации.
Да, я Жук, три пары лапок и фасеточные глаза :))
Alle Antworten
Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты. Сейчас в личном хранилище кроме него больше нет сертификатов. На компьютере с Windows 7 только добавлен сертификат ЦС предприятия в доверенные корневые ЦС компьютера.
На всякий случай упомяну, при подключении «сервер» с Windows 8 выдает для проверки именно сертификат от ЦС, а не самоподписанный. Для этого подправил групповую политику, чтобы RDP использовал сертификаты с шаблоном Machine.
Запрос на создание Сертификата, должен создаваться на том компьютере, для которого он предназначен. Этот сертификат должен быть в Личных, этот Сертификат компьютер должен предъявить Серверу, и этот Сертификат должен проверяться на отзыв. Корневой доверенный Сертификат, как правило, не проверяется на отзыв.
Ваша цитата: «Да, на клиентском компьютере с Windows 7.», что входит в противоречие с Вашей же цитатой: «Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты.».
Дополнительно, воспользуйтесь серией статей:
Я лично под клиентом понимаю компьютер с Windows 7, у него нет никаких своих сертификатов. Свой сертификат есть у компьютера с Windows 8 ( «Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты.» ), я его экспортировал в файл, проверил на клиенте ( «Да, на клиентском компьютере с Windows 7.») и выложил лог в 1 сообщении. Но когда я подключаюсь с клиента к компьютеру с Windows 8, получаю ту самую ошибку, что не удается проверить, не отозван ли сертификат. Я тут же открываю сведения о сертификате, копирую оттуда URL на список отзыва и без проблем скачиваю этот самый список отзыва, в котором у меня уже штук 5 отозванных сертификатов.
За статьи спасибо, но не нашел в них решения своей проблемы.
https://www.dropbox.com/sh/y3qr6f34sf7ip5o/BgQLYhzgQr по данной ссылке выложил сертификаты ЦС, компьютера с Windows 8 и списки отзыва. Само собой, клиент может разрешить имена, указанные в сертификате.
Из статей, ссылки на которые Вам дал ранее, следует, что для того что бы Клиент мог проверить легитимность предъявляемого ему Сертификата, необходимо или в ручную установить СОС (Список Отзыва Сертификатов) или обеспечить Клиенту, OCSP проверку Сертификата.
Установите на Клиенте вручную, СОС сертификата, которого проверяет Клиент, проверьте и напишите результат.
СОС необходимо устанавливать в Промежуточные центры сертификации.
Руководствуясь разделом Q9 справки, загрузите в общедоступную папку SkyDrive, публичный Сертификат (cer-файл) компьютера Windows 8.
По 2 части я не понял, что это за СОС. Знаю только СОС, который публикуется ЦС в соответствии с настройками CDP.
Минимум же, первым в цепочке в Путь сертификации, должен быть SERVER-CA.TC-SOTKA.INT.
2. Список отзыва данного Вами сертификата, не доступен по указанному в сертификате адресу:
Выпущенный Вами сертификат для Windows 8, на этом компьютере в таком случае должен быть установлен в Корневые центры сертификации и Личные Сертификаты.
На компьютере Клиенте с Windows 7, он должен быть установлен в Корневые центры сертификации, список отзыва сертификатов для которых, не проверяется. Что неправильно.
1. Меня тоже сначала это смутило, но на компьютере с Windows 8 (сразу) и на компьютере с Windows 7 (после добавления сертификата ЦС в корневые доверенные) путь сертификации выглядит вот так https://www.dropbox.com/s/bxiyskoa0kgmvdy/2.jpg Как писал ранее, сертификат для Windows 8 запрашивался через оснастку сертификаты, там небыло иного выбора как запросить сертификат по шаблону Компьютер (Machine).
2. Он недоступен у Вас, потому что это внутренний адрес. В данный момент решил вопрос добавлением записи в файл hosts. У клиента доступ к сайту по имени работает.
Внимательно изучите серию статей:
Именно по этой статье я настраивал публикацию СОС.
Сегодня установил онлайн ответчик, с ним проверка сертификата отрабатывает корректно. Очень жаль, что так и не получилось довести до ума проверку СОС по HTTP, придется что-то делать с клиентами на Windows XP.
Жук, спасибо за желание помочь и с наступающим.
Ради интереса попробуй следующие:
В IIS manager, в настройках сайта для CRL, найдите Request Filtering:
Зайдите туда и справа будут Actions, нажмите там Edit feature settings. Откроется окно как на картинке, выставите там галку Allow double escaping
И посмотрите изменится ли что-то для машин с Win XP.
Взаимно, так же с наступающим новым годом.
У нас, есть хорошее правило: «Никогда не опускать лапки. «. Так что, могу только порекомендовать, передохнуть, выпить чашечку кофе, принять ванну :)), и засучив рукава, с новыми силами, всё же постараться разрешить эту проблему.
Жук, привет. Есть вопрос.
Сразу скажу что пока силен в вопросе слабо, но головняк уже поймал:
Есть пара машин вне домена + RDS доменный. вопрос вот о чем: 1я машина (ipsec + WIN 8.1) DNS конечно не понимает, поэтому по ip к RDS(генерированный фаил с rds), предлагает убедится в надежности издателя и дает запрос на лог/пас домена. Далее сертификат RDP, предупреждение: «Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности». И вот проблема: «Не удается проверить не был ли отозван сертификат». В целом не велика, так как это всего лишь предупреждение и жить бы можно. НО хочется по уму. Сертификат тот же самый что предлагается вначале всего для того чтоб убедиться что подключение доверенное(ну зрительно, CA добавлен в доверенные корневые центры сертификации).
Как я и говорил и сам не ас. Поэтому буду очень рад ответам. И если заодно посоветуешь где на клиенте более подробные логи этого всего посмотреть буду очень благодарен?
Проблема возникает из-за неправильного сертификата, который используется для сеанса сервера терминала или удаленного рабочего стола.
Предупреждение о самоподписанном сертификате RDP
По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный
сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:
Чтобы продолжить установление RDP подключении пользователь должен нажать кнопку Да. Чтобы RDP предупреждение не появлялось каждый раз, можно включить опцию “Больше не выводить запрос о подключениях к этому компьютеру».
General discussion
Прочитал похожие темы и «тот самый блог Вадима.»
Все сделал как описано.
Пытаюсь из одной подсети(2008R2) подключится к терминальному серверу на 2008R2 в другой подсети, через интернет.
Результат и там и там одинаков » не удалось проверить не был ли отозван этот сертификат».
Серийный номер сертификата : 428d050d0000000001de
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
SimpleChain.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
SubjectAltName: DNS- имя =MO1TS01.kaventdom.local
ca 63 de 3a 08 cd 49 a7 bb e0 56 9a 49 49 60 75 c9 18 d3 b6
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
64 1c 33 49 43 47 29 98 7d 7c b6 a0 93 2c 7e d1 80 6e b5 5a
ad f4 63 27 bd 1f 3e 47 09 e9 4c a1 57 45 ec ff ff b0 f1 06
NotBefore: 18.03.2011 18:29
NotAfter: 18.03.2031 18:39
Subject: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
ff d2 72 dd e5 19 d8 ae 71 b1 cb 42 43 b5 8b cd d5 3d 06 ea
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
e0 99 12 cd 1f 0a bf f8 4e cd de 65 79 62 29 b6 d6 fd ee e9
fb 6e 1e e0 73 68 ba 3e 78 a7 08 24 a6 9b 65 d8 29 ca e4 6e
Проверенные политики выдачи: Нет
Проверенные политики применения:
1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
1.3.6.1.5.5.7.3.1 Проверка подлинности сервера
Проверка отзыва сертификата выполнена
Сертификат сервера шлюза удаленных рабочих столов просрочен или отозван windows 7
Спасибо за наводку! Включил TLS v.1 согласно этой статьи (выполнил пункты 3.1 и 3.2) и тоже всё заработало. ОГРОМНОЕ Спасибо! Конечно, со временем будем переходить новые серверные ОC.