Сертификат сервера шлюза удаленных рабочих столов просрочен или отозван windows 7

Симптомы

Рассмотрим следующий сценарий:

• Установить службу шлюза удаленных рабочих столов (шлюз RD) на компьютере под управлением Windows Server 2008 R2.

• Существует несколько привязок сертификат на порт 443 этого компьютера.

В этом случае шлюз удаленных рабочих Столов может работать неправильно. Некорректное поведение зависит от привязки выбранного сертификата имя хранилища сертификатов. Имя различные проблемы привязки вызывает хранилища сертификата следующие значения:

• Имя хранилища сертификатов не равно NULL для привязки

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

  • Проверка подлинности смарт-карты настраивается на стороне шлюза удаленных рабочих Столов.

  • Проверки работоспособности защиты доступа к сети применяются на стороне клиента.

• Имя хранилища сертификатов для привязки равно NULL

  В этом случае все соединения друг с другом сбой и появляется следующее сообщение об ошибке:

  Компьютеру не удается подключиться к удаленному компьютеру, так как отсутствует сертификат, настроенный для использования на сервере шлюза удаленных рабочих столов. Обратитесь к сетевому администратору за помощью.

  В то же время добавляется следующее событие шлюза службы терминалов с 306 идентификатор журнала шлюза службы терминалов:
  Примечание. Чтобы проверить, установлено ли значение NULL имя хранилища сертификатов, выполните следующие действия.

  1. В командной строке введите следующую команду и нажмите клавишу ВВОД:

     netsh http show sslcert

  2. Проверьте значение из первой привязки, который прослушивает порт 443 Имя хранилища сертификатов . Значение (null) , указывает имя хранилища сертификатов для данной конкретной привязки равно NULL.

Причина

Проблемы возникают потому, что служба шлюза удаленных рабочих Столов получает привязку неверный сертификат.

Решение

Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.

Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Чтобы получить полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание, посетите следующий веб-сайт корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Для установки этого исправления компьютер должна быть запущена Windows Server 2008 R2.

Необходимость перезагрузки

После установки исправления компьютер необходимо перезагрузить.

Сведения о замене исправлений

Это исправление не заменяет других исправлений.

Сведения о файлах

Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, следует использовать
Часовой пояс
вкладке
Дата и время
элемент панели управления.

Для всех поддерживаемых 64-разрядных версий Windows Server 2008 R2

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Aaedge.dll	6.1.7600.20546	304,128	10-Oct-2009	06:12	x64
Aaedge.mof	Неприменимо	1,268	10-Jun-2009	20:31	Неприменимо
Aatspp.dll	6.1.7600.16385	65,024	14-Jul-2009	01:39	x64
Aatspp.mof	Неприменимо	1,271	10-Jun-2009	20:31	Неприменимо
Rap.xml	Неприменимо	895	10-Jun-2009	20:31	Неприменимо
Tsgateway.xml	Неприменимо	429	10-Jun-2009	20:31	Неприменимо
Tsgclean.exe	6.1.7600.16385	428,032	14-Jul-2009	01:39	x64
Tsproxy-edgeadapter-ppdlic.xrm-ms	Неприменимо	3,018	10-Oct-2009	08:55	Неприменимо

Статус

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Дополнительные сведения

Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт

Сведения о дополнительных файлах для Windows Server 2008 R2

Дополнительные файлы для всех поддерживаемых версий Windows Server 2008 R2 для систем на базе x64

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Amd64_microsoft-windows-tsproxy-edgeadapter_31bf3856ad364e35_6.1.7600.20546_none_9ab543bbff629cbd.manifest	Неприменимо	99,560	11-Oct-2009	19:00	Неприменимо
Package_for_kb976484_rtm~31bf3856ad364e35~amd64~~6.1.1.0.mum	Неприменимо	1,458	11-Oct-2009	19:00	Неприменимо

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

Используемые термины: Remote Desktop Gateway, Active Directory, Терминальный сервер.

В данном руководстве мы рассмотрим развертывание роли шлюза удаленных рабочих столов (Remote Desktop Gateway или RDG) на отдельном сервере с Windows Server 2019. Действия будут аналогичны для Windows Server 2012 и 2016 (даже, в основных моментах, 2008 R2). Предполагается, что в нашей инфраструктуре уже имеются:

1. Служба каталогов Active Directory — настроено по инструкции Как установить роль контроллера домена на Windows Server.

2. Два терминальных сервера — настроено по инструкции Установка и настройка терминального сервера на Windows Server.

Пошагово, мы выполним следующие действия:

Установка роли

Открываем Диспетчер серверов:

Переходим в Управление — Добавить роли и компоненты:

При появлении окна приветствия нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

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

Выбираем целевой сервер — если установка выполняется на сервере локально, то мы должны увидеть один сервер для выбора:

Ставим галочку Службы удаленных рабочих столов:

Дополнительные компоненты нам не нужны:

… просто нажимаем Далее.

На странице служб удаленных рабочих столов идем дальше:

Выбираем конкретные роли — нам нужен Шлюз удаленных рабочих столов. После установки галочки появится предупреждение о необходимости поставить дополнительные пакеты — кликаем по Добавить компоненты: 

Откроется окно для настроек политик:

… нажимаем Далее.

Откроется окно роли IIS:

… также нажимаем Далее.

При выборе служб ролей веб-сервера ничего не меняем:

… и идем дальше.

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

Нажимаем Установить:

Дожидаемся окончания установки роли:

Сервер может уйти в перезагрузку.

Настройка RDG

Для настройки Microsoft Remote Desktop Gateway мы создадим группу компьютеров в Active Directory, настроим политику для RDG и создадим сертификат.

Создание групп для терминальных серверов

Политика ресурсов позволит задать нам конкретные серверы, на которые терминальный шлюз позволит нам подключаться. Для этого мы откроем консоль Active Directory — Users and computers (Пользователи и компьютеры Active Directory) и создаем группу:

* в данном примере мы создаем группу All terminals в организационном юните Servers Group. Это группа безопасности (Security), локальная в домене (Domain local).

Добавим в нашу группу терминальные серверы:

* в данном примере у нас используются два сервера — Terminal-1 и Terminal-2.

Закрываем консоль Active Directory — Users and computers.

Настройка политик

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

В диспетчере сервера переходим в Средства — Remote Desktop Services — Диспетчер шлюза удаленных рабочих столов:

Раскрываем сервер — кликаем правой кнопкой по Политики — выбираем Создание новых политик безопасности:

Устанавливаем переключатель в положении Создать политику авторизации подключений к удаленным рабочим столам и авторизации ресурсов удаленных рабочих столов (рекомендуется):

Даем название политике:

Задаем параметры авторизации:

* мы указали, что пользователи должны подтверждать право вводом пароля, также мы указали, что для применения политики они должны принадлежать группе Domain Users.

В следующем окне есть возможность настроить ограничения использования удаленного рабочего стола. При желании, можно их настроить:

* в нашем случае ограничений нет. При необходимости, устанавливаем переключатель в положение Отключить перенаправление для следующих типов клиентских устройств и оставляем галочки пункты для ограничений.

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

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

Идем далее.

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

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

* как и при создании первой политики, мы добавили группу Domain Users.

Теперь выбираем группу ресурсов, на которую будет разрешен доступ со шлюза терминалов:

* мы выбрали группу, созданную нами ранее в AD.

Указываем разрешенный для подключения порт или диапазон портов:

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

Нажимаем Готово:

Политики будут созданы.

Настройка сертификата

Для работы системы нам необходим сертификат, который можно купить или получить бесплатно от Let’s Encrypt. Однако, с некоторыми неудобствами, будет работать и самоподписанный. Мы рассмотрим вариант настройки с ним.

Запускаем «Диспетчер шлюза удаленных рабочих столов» — кликаем правой кнопкой по названию нашего сервера — выбираем Свойства:

Переходим на вкладку Сертификат SSL:

Выбираем вариант Создать сомозаверяющий сертификат и кликаем по Создать и импортировать сертификат:

Задаем или оставляем имя для сертификата — нажимаем OK:

Мы увидим информацию о создании сертификата:

Консоль диспетчера шлюза перестанет показывать ошибки и предупреждения:

Сервер готов к работе.

Подключение к серверу терминалов через шлюз

Выполним первое подключение с использованием шлюза. В качестве клиентской операционной системы могут использоваться Windows, Linux, Mac OS. Рассмотрим пример на Windows 10.

Запускаем «Подключение к удаленному рабочему столу» (приложение можно найти в Пуск или ввести команду mstsc). На вкладке Общие вводим локальное имя конечного сервера, к которому мы хотим подключиться:

* в нашем случае мы будем подключаться к серверу terminal-1.dmosk.local.

Переходим на вкладку Дополнительно и кликаем по Параметры:

Переключаем параметр приложения в положение Использовать следующие параметры сервера шлюза удаленных рабочих столов и указываем внешнее имя сервера:

* важно указать именно имя сервера, а не IP-адрес. В моем примере имя сервера rdp.dmosk.local (данное имя не является правильным внешним, но это только пример).

Кликаем Подключить:

Если мы используем самозаверенный сертификат, приложение выдаст ошибку. Кликаем по Просмотреть сертификат:

Переходим на вкладку Состав и кликаем Копировать в файл:

Указываем путь для выгрузки файла:

Открываем папку, куда сохранили сертификат. Кликаем по сохраненному файлу правой кнопкой и выбираем Установить сертификат:

Выбираем Локальный компьютер — Далее:

В качестве размещения сертификата выбираем Доверенные корневые центры сертификации:

Импортируем сертификат.

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

Система запросит логин и пароль для подключения (возможно, дважды) — вводим данные для учетной записи с правами на подключение (на основе настройки политики RDG).

Настройка Remoteapp через Gateway

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

…
gatewayhostname:s:rdg.dmosk.local
gatewayusagemethod:i:1
…

* где:

• gatewayhostname:s:rdg.dmosk.local — добавленная строка. Настройка говорит, что если при подключении к серверу нужно использовать шлюз, то это должен быт rdg.dmosk.local.
• gatewayusagemethod:i:1 — отредактированная строка. Указывает, что необходимо использовать шлюз.

Пробуем подключиться.

Несколько терминальных серверов и dns round robin

При наличие нескольких серверов терминалов, мы можем создать несколько записей в DNS, чтобы получать по round robin разные серверы:

Однако, при попытке подключиться к незарегистрированному серверу мы увидим ошибку:

Для решения переходим в настройку шлюза — кликаем правой кнопкой по Политики авторизации ресурсов и выбираем Управление локальными группами компьютеров:

Выбираем нужную группу компьютеров и нажимаем Свойства:

* в моем случае это была единственная группа, созданная по умолчанию.

На вкладке Сетевые ресурсы добавляем имя, созданное в DNS:

Теперь подключение будет выполняться без ошибок.

Возможные ошибки

При подключении мы можем столкнуть со следующими ошибками.

1. Учетная запись пользователя не указана в списке разрешений шлюза удаленных рабочих столов.

Причиной является отсутствие пользователя, под которым идет подключение к шлюзу, в группе, которой разрешено использование политики. Для решения проблемы проверяем настройки политики — группы пользователей, которым разрешено использование политики и к каким ресурсам разрешено подключение. В итоге, наш пользователь должен быть в нужной группе, а терминальный сервер, к которому идет подключение должен быть указан в соответствующей группе ресурсов.

2. Возможно, удаленный компьютер указан в формате NetBIOS (например, computer1), но шлюз удаленных рабочих столов ожидает полное доменное имя или IP-адрес (например, computer1.fabrikam.com или 157.60.0.1).

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

3. Сертификат шлюза удаленных рабочих столов просрочен или отозван.

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

Не удалось проверить не был ли отозван этот сертификат rdp windows 7

Question

Ошибка «Не удалось подключиться к удалённому компьютеру, поскольку сертификат сервера шлюза удалённых рабочих столов отозван или просрочен».

При этом Windows 10 (8, 7) этот сертификат (выданный доменным Центром сертификации) не просрочен и подключение в этих ОC происходит без проблем. В хранилище Доверенные корневые центры сертификации (локальный компьютер) сертификат доменного ЦС есть.

Списки отзыва актуальные, серийного номера сертификата шлюза в них нет.

Пока нагуглил, что какие-то проблемы с Службой времени Windows в этой ОС. В Просмотре событий очень много 158 кодов про ошибку VMICTimeProvider. Вместе с тем, время в трее показывается актуальное, синхронизация с сервером времени time.windows.com происходит успешно.

Кто-нибудь сталкивался с подобной проблемой? Нашлось решение?

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

Answers

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Спасибо за наводку! Включил TLS v.1 согласно этой статьи (выполнил пункты 3.1 и 3.2) и тоже всё заработало. ОГРОМНОЕ Спасибо!
Конечно, со временем будем переходить новые серверные ОC.

Спасибо добрый человек, но чтоб долго не искать напишу тут, нужно создать reg файл с содержимым, добавить в реестр и перезагрузиться:

Спасибо, что ответили. Я уж думал, что я один с такой проблемой столкнулся. Я создал обращение в техподдержку MS, сегодня ко мне подключались специалисты, смотрели и недоумевали, обещали подключить спецов уровнем выше.
Можно поинтересоваться, а какая у Вас версия Windows на Шлюзе удалённых рабочих столов? У меня 2008R2.

Есть такая же проблема, шлюз 2008R2. На самом деле по ошибкам time-service мы ничего не определим т.к. на ОС Win10 они точно такие же, но при этом все прекрасно работает.

Как бы товарищи из Microsoft не предложили обновляться до 2016.

Как бы товарищи из Microsoft не предложили обновляться до 2016.

Спасибо Вам за Ваш вопрос.

2. Убедитесь, что URL-адрес rdweb работает нормально.

3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?

4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.

Спасибо Вам за Ваш вопрос.

2. Убедитесь, что URL-адрес rdweb работает нормально.

3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?

4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.

Источник

Не удалось проверить не был ли отозван этот сертификат rdp windows 7

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.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

SimpleChain.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0

Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local

NotBefore: 12.04.2011 9:46

NotAfter: 11.04.2012 9:46

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)

Проверено «Сертификат (0)» Время: 4

Проверено «Базовый CRL (20)» Время: 4

Проверено «Разностный CRL (20)» Время: 4

ОК «Разностный CRL (20)» Время: 4

Отсутствуют URL «Нет» Время: 0

Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local

64 1c 33 49 43 47 29 98 7d 7c b6 a0 93 2c 7e d1 80 6e b5 5a

Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local

ad f4 63 27 bd 1f 3e 47 09 e9 4c a1 57 45 ec ff ff b0 f1 06

Application[0] = 1.3.6.1.5.5.7.3.2 Проверка подлинности клиента

Application[1] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0

Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local

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)

Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)

Отсутствуют URL «Нет» Время: 0

Отсутствуют URL «Нет» Время: 0

Отсутствуют URL «Нет» Время: 0

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 Проверка подлинности сервера

Проверка отзыва сертификата выполнена

Источник

Не удалось проверить не был ли отозван этот сертификат 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

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)

Источник

Не удалось проверить не был ли отозван этот сертификат rdp windows 7

Frage

Antworten

Привет!, а Вас не смутило, то что Вы допустили две ошибки:

-вопросу уже более полутора лет;

-Автор вопроса, не Вы.

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

Начните с внимательного изучения серии статей, начав со статьи «Краткое руководство по 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.

1. Сертификат sysadmina, если он выпускался Вами для компьютера Windows 8, выпущен как корневой:

Минимум же, первым в цепочке в Путь сертификации, должен быть 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.

Именно по этой статье я настраивал публикацию СОС.

Сегодня установил онлайн ответчик, с ним проверка сертификата отрабатывает корректно. Очень жаль, что так и не получилось довести до ума проверку СОС по HTTP, придется что-то делать с клиентами на Windows XP.

Жук, спасибо за желание помочь и с наступающим.

Взаимно, так же с наступающим новым годом.

У нас, есть хорошее правило: «Никогда не опускать лапки. «. Так что, могу только порекомендовать, передохнуть, выпить чашечку кофе, принять ванну :)), и засучив рукава, с новыми силами, всё же постараться разрешить эту проблему.

Да, я Жук, три пары лапок и фасеточные глаза :))

Жук, привет. Есть вопрос.

Сразу скажу что пока силен в вопросе слабо, но головняк уже поймал:

Есть пара машин вне домена + RDS доменный. вопрос вот о чем:
1я машина (ipsec + WIN 8.1) DNS конечно не понимает, поэтому по ip к RDS(генерированный фаил с rds), предлагает убедится в надежности издателя и дает запрос на лог/пас домена. Далее сертификат RDP, предупреждение:
«Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности». И вот проблема: «Не удается проверить не был ли отозван сертификат». В целом не велика, так как это всего лишь предупреждение и жить бы можно. НО хочется по уму. Сертификат тот же самый что предлагается вначале всего для того чтоб убедиться что подключение доверенное(ну зрительно, CA добавлен в доверенные корневые центры сертификации).

Как я и говорил и сам не ас. Поэтому буду очень рад ответам. И если заодно посоветуешь где на клиенте более подробные логи этого всего посмотреть буду очень благодарен?

Источник

Не удалось проверить не был ли отозван этот сертификат 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

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)

Источник

Windows, Windows Server

Исправляем ошибку: «сертификат проверки подлинности просрочен или недействителен»

• 24.02.2015
• 26 727
• 1
• 19.01.2020
• 5
• 4
• 1

• Содержание статьи
  • Описание
  • Комментарии к статье ( 1 шт )
  • Добавить комментарий

В данной статье пойдет речь об ошибке «сертификат проверки подлинности просрочен или недействителен», которая может возникать при попытке запуска опубликованного приложения RemoteApp и о том, как эту ошибку можно исправить.

Описание

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

Как и написано в тексте ошибки, все дело в том, что компьютер, на котором запускается RemoteApp приложение считает сертификат просроченным или недействительным. Если с сертификатом проблем нет, то дело скорей всего именно в неверной дате на сервере или на клиенте. Если проблема на всех клиентах, то значит смотрим в сторону сервера (проверяем, что установлена текущая дата).

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

Особенно внимательно смотрим, чтобы год был указан правильно, а то часто бывает что стоит правильная дата, правильное время и год 2002

Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов как исправить

Win Server 2012 Std

Поднята роли AD, Hyper-V, Шлюз RDS.

На VM (также Win Server 2012 Std) поднят TS и опубликованы приложения RemoteApp.

Внутри доменной сети %domain.local% RemoteApp работает. Снаружи — нет. О чём свидетельствует сабж.

Понимаю, что проблема в сертификатах, но как правильно настроить — не знаю.

В настройке развёртывания служб RDS при добавлении шлюза создал сертификат с FQDN для домена %publicdomain.ru%.

Каким образом настроить сертификат(ы?), чтобы RemoteApp запускались извне?

Подключения старой версии rdp client 2.1.1 к Windows Server 2012

Нам понадобится запустить редактор групповых политик. В командной строке набираем gpedit. Переходим в раздел настроек безопасности RDP:

Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Безопасность

Здесь следует поменять значение двух параметров:

• Требовать использования специального уровня безопасности для удаленных подключений по методу RDP (ставим «Включить», а уровень безопасности выбираем «RDP»)
• Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (ставим «Отключить»)

Теперь даже старые версии Microsoft Remote Desktop будут подключаться к терминальному серверу, правда только по дефолтному порту 3389. Замечен и побочный эффект — Windows клиенты, которые ставили галочку «сохранить пароль» лишились такой возможности. В общем, данная статья носит скорее познавательный характер, приделывать подобные костыли рабочим серверам я бы не стал.

Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.

Загадочный IPsec Определение температуры процессора в Windows 10 через PowerShell. Синий экран смерти (BSOD) и причём тут DrWeb? Ноутбук с Windows 10 в качестве точки доступа Wi-Fi Сбой в алгоритме Яндекса заставил пользователей понервничать Что делать, если перестала работать панель задач и кнопка «ПУСК» в Windows 10

«Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов»

Первый раз столкнулась с подключением к удаленному рабочему столу,сертификат установила но вот только при подключении возникает ошибка с таким текстом:
«Компьютеру не удается проверить удостоверение шлюза удаленных рабочих столов «server_name». Подключатся к серверам без удостоверений не безопасно. Обратитесь за помощью к администратору сети»

Подскажите что можно сделать, что бы решить эту ситуацию

Не удается подключиться через службу удаленных рабочих столов к серверу
Суть проблемы: Рабочая станция: Win 7 Enterprise, ip-адрес статический(192.168.1.167), подключен к.

Службы удаленных рабочих столов
Службы удаленных рабочих столов- коллекции (можно несколько создать коллекция и как?)

Служба удаленных рабочих столов
Здравствуйте, вопрос состоит в следующем стоит Windows server 2008 r2 как активировать службу.

Ip виртуализация удаленных рабочих столов
Добрый день! После настройки ip виртуализации удаленных рабочих столов для сеансов в Windows.

Если отключить проверку в клиенте RDP?
При подключениидополнительновкладка подключениеПроверка подлинности сервера

Выбрано — «Подключатся без предупреждения».

У того сертификата что мне дали, закончился строк действия. Нажав на кнопку «Просмотреть сертификат», открывается новый сертификат, я его сохранила с помощью кнопки «Копировать в файл» и потом установила этот новый сертификат. Возможно причина в этом, и мне нужно попросить что бы мне сбросили новый сертификат и потом все получится? Хотя почему не выходит если я сама его скачала и установила.

Сервер удаленных рабочих столов
Здравствуйте. На работе установили новый сервер под управлением Windows Server 2012, настроил.

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

Сервер лицензирования удалённых рабочих столов
Здравствуйте, Win 2008R2, 64x, SuperMicro Столкнулся с такой проблемой: Поднял терминальный.

Установка роли удаленных рабочих столов
Здравствуйте! При установки роли удаленных рабочих столов появляется ошибка (вложения). Как это.

Групповые политики

Нажмите Win + R и введите gpedit.msc, чтобы открыть редактор групповых политик. В политиках перейдите «Конфигурация компьютера» > «Административные шаблоны» > «Система» > «Передача учетных данных» > справа найдите «Защита от атак с использованием криптографического оракула» (Oracle Remediation) и нажмите по этой политике два раза мышкой, чтобы открыть свойства.

• В свойствах выберите «Включено» и ниже в графе «уровень защиты» поставьте «Оставить уязвимость«. Нажмите применить и следуйте сразу ниже пункту.

• Запустите теперь командную строку от имени администратора и введите gpupdate /force , чтобы обновить политики и применения вступили в силу. Проверьте устранена ли ошибка проверки подлинности RDP, если нет, то перезагрузите ПК.

Не удается подключиться по rdp «Ошибка проверки подлинности»

При подключение к удаленному компьютеру по RDP возникают различные проблемы и ошибки. Их достаточно много и решаются все они по разному. Сегодня разберем наверно самую популярную ошибку которая связанная с проверкой подлинности.

И так при попытке подключения к удаленному рабочему столу вы видите сообщение.

Произошла ошибка при проверки подлинности

Указанная функция не поддерживается

Удаленный компьютер 192.168.0.0

Причиной ошибки может быть исправление шифрования CredSSP

Дополнительную информацию смотрите в статье …

Для её решение необходим на компьютере к которому не удается подключиться изменить групповую политику. Для этого нажимаем Win + R вводим gpedit.msc.

Откроется редактор групповой политики. В нем необходимо открыть раздел «Безопасность». Путь до него такой «Конфигурация компьютера» — «Административные шаблоны» — «Компоненты Windows» — «Службы удаленных рабочих столов» — «Узел сеансов удаленных рабочих столов» — «Безопасность».

Тут открываем политику «Требовать проверку подлинности пользователя …»

Дальше открывает политику «Требовать использования специального уровня…», включаем и в пункте «Уровень безопасности выбираем» RDP.

Пробуем подключиться к удаленному рабочему столу. Если вы все сделали правильно то должны без проблем подключиться.

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

Добрый день.
Мне решение с добавлением RDGClientTransport не помогло.
Удалось подключиться к серверу, только после выполнения следующих действий.
Включение поддержки TLS 1.2 на ОС Windows 7 и Windows 8
Для включения поддержки протоколов TLS 1.2 в Windows 7 и Windows 8 необходимо выполнить
следующие действия на:
A. Для Windows 7 проверить установлен ли Пакет обновления 1 (SP1) (KB976932). Скачать и
установить обновление (KB3140245).
B. Для Windows 7 (только для 32 разрядной версии) скачать и установить обновление (KB3080079).
C. Для Windows 8 скачать и установить обновление (KB3140245).
D. Для включения поддержки TLS 1.2 необходимо внести правки в реестр:
1. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet
SettingsWinHttp – В подразделе WinHTTP, необходимо выбрать ‘DefaultSecureProtocols’ и
исправить его. Изменить значение с a00 to a80. В случае отсутствия, необходимо создать
запись.
2. HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionInternet SettingsWinHTTP – Выполнить действия из пункта 1. Это необходимо для 32-
битной версии Internet explorer-a из папки C:Program Files (x86)Internet
Exploreriexplorer.exe.
3. HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings –
Необходимо проверить, что запись ‘SecureProtocols’ имеет значение равное a80.
4. HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternet Settings –
Выполнить действия из пункта 3.
Все эти действия может заменить исправление MicrosoftEasyFix51044.msi.
E. Включение поддержки TLS 1.2 на уровне компонентов SChannel. Так как протокол TLS 1.2 по
умолчанию отключен, необходимо включить поддержку TLS 1.2 в этих версиях Windows:
1. В редакторе реестра нужно открыть ветку
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols.
2. Создать подраздел TLS 1.2.
3. Внутри подраздела создайте по разделу с именами Client и Server.
4. В каждом из разделов Client и Server создайте по ключу типа DWORD (32 бита):
DisabledByDefault со значением 0,
Enabled со значением 1.
F. После внесенных изменений компьютер следует перезагрузить.
Источник: http://www.payhd.ru/

А у вас какая версия была windows?