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

Обновлено: 24.01.2025

Не удается установить соединение с удаленным помощником, не удается сопоставить DNS-имя удаленного компьютера.
Здравствуйте.Пытаюсь подключиться к другому компу через приглашение по удалённому помощнику и в.

Как проверить подлинность Windows?
Добрый день. Извиняюсь, возможно поместил не в ту тему. Работаю программистом, реального.

Как проверить подлинность Windows 7
Всем доброго времени суток!Можно ли узнать что за ОС стоит на ноутбуке.Чистая или какая-то.

Покупка оригинальной зарядки, но б\у. Как проверить на подлинность?
Здравствуйте. Недавно я потерял портфель, в котором было зарядное устройство для моего телефона.

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

Проблема в сертификате, точнее в том, что он самоподписанный.
Компы проверяют все сертификаты по цепочке: Выданный Вам сертификат -> Промежуточные центры сертификации -> Доверенный корневой центр сертификации.
Сертификаты выдаваемые простым людям подписываются сертификатами промежуточных центров, а их сертификаты - корневыми центрами.
Вы можете любой сертификат добавить в доверенные корневые центры сертификации через certmgr.msc
В Вашем случае можно добавить этот сертификат в доверенные корневые и, чисто теоретически, он перестанет спрашивать о нём.
Либо развернуть в домене, если он есть, центр сертификации и использовать сертификат, подписанный им. Работать это будет только в этом же домене, так как в нём сертификат Вашего центра сертификации будет добавлен в доверенные.

В любом случае, я считаю, что работа не стоит того.

Не удаётся запустить Windows из-за испорченного или удалённого файла
При включении компьютера пишет мол не удаётся запустить виндовс из за испорченного или удалённого.

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

7.7 Имя удаленного компьютера
Добрый день. Подскажите, как можно определить имя компьютера при работе с 1С через удаленный.

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

Отключение от удалённого компьютера
Не получается окончательно отключиться от удалённого компьютера. для начала в cmd подключусь.

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

У RDC 7-й версии отключить проверку сертификата сервера на отзыв нельзя, но можно с помощью указания опции "enablecredsspsupport:i:0" в rdp-файле определить игнорирование проверки отзыва. Отзыв клиентом RDC проверяется по той же схеме, что и все прочие сертификаты (читает CDP, пробует загрузить по URL списки отзыва), но с той лишь разницей, что сертфикат УЦ, выпустившего "проверяемый" сертификат, должен находиться в хранилище компьютера доверенных УЦ ("Trusted CA").

Предложено в качестве ответа Vadims Podans MVP 11 марта 2010 г. 17:54
Помечено в качестве ответа Nikita Panov 12 марта 2010 г. 10:24

Все ответы

Предложено в качестве ответа Vadims Podans MVP 11 марта 2010 г. 17:54
Помечено в качестве ответа Nikita Panov 12 марта 2010 г. 10:24

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

Предложено в качестве ответа Vadims Podans MVP 11 марта 2010 г. 17:54

Спасибо,
по ссылкам выполнил все что написано, но вот почему-то внутри домена проверка отзыва OCSP работает из контекстного меню (certutil), а в PKI показывает что ошибка
также из интернет не удается проверить( за ISA шлюзом), все правила настроены, в логах запросы не блокируются, но проверка из контестного меню (certutil) показывает, что ошибка
уже по разному пробовал, и сертификаты выпускал без проверки всеравно ошибку при подключении выбрасывает, придется наврноей параметр указывать чтобы не проверял целостность цепочки

поставил параметр enablecredsspsupport:i:0, все заработало (подключение)

Вадим, доброго времени суток.

Подскажите, если можете, пожалуйста, по аналогичному вопросу.

Из локальной сети с клиента win xp sp3 подключение происходит на ура; из интернета - ошибка "не удалось проверить, не был ли отозван сертификат", имя в сертификате от удалёного компьютера - domain.local. Удалённый клиент Windows 7.

Как сделать, чтобы не было такой ошибки на этом клиенте и при этом не добавлять параметр enablecredsspsupport?

с клиента Windows 7 проверка "внешнего" сертификата:

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000)

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

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

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)

---------------- OCSP сертификата ----------------
Отсутствуют URL "Нет" Время: 0
--------------------------------
Application[0] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера

аналогично, с самого сервера:

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 19 Hours, 46 Minutes, 22 Seconds

--------------------------------
CRL 0d:
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
20 66 59 46 78 b3 c1 60 fd f5 67 c2 80 bd b6 14 85 92 67 1a
Delta CRL 0e:
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
4d 66 78 f2 4b 74 c1 d0 ce 1a 92 d9 04 e5 5b c1 bf 7c a6 99
Application[0] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера

Exclude leaf cert:
ed 4d 51 e0 d0 41 0c 6d b9 f4 6e 9c c4 8a e6 63 18 96 42 8e
Full chain:
d4 ba db 35 1a 6e 7f 50 f1 8d 0d 66 c9 1a c4 62 2c e7 42 03
------------------------------------
Проверенные политики выдачи: Нет
Проверенные политики применения:
1.3.6.1.5.5.7.3.1 Проверка подлинности сервера
Проверка отзыва сертификата выполнена
CertUtil: -verify - команда успешно выполнена.

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 19 Hours, 45 Minutes, 46 Seconds

---------------- OCSP сертификата ----------------
Отсутствуют URL "Нет" Время: 0
--------------------------------
CRL 0d:
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
20 66 59 46 78 b3 c1 60 fd f5 67 c2 80 bd b6 14 85 92 67 1a
Delta CRL 0e:
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
4d 66 78 f2 4b 74 c1 d0 ce 1a 92 d9 04 e5 5b c1 bf 7c a6 99
Application[0] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера

Exclude leaf cert:
a5 b6 1b 08 d3 55 43 7d 33 42 57 db 7f 33 5a a1 35 9c 09 cc
Full chain:
ba 98 77 84 18 a3 32 52 b5 18 cc 34 a3 d0 59 6c ce e7 ad 19
------------------------------------
Проверенные политики выдачи: Нет
Проверенные политики применения:
1.3.6.1.5.5.7.3.1 Проверка подлинности сервера
Проверка отзыва сертификата выполнена
CertUtil: -verify - команда успешно выполнена.

Итак, сертификат 61619b9c000000000013

а что у вас ссылка на CRT делает в расширении OCSP? Как минимум из-за этих ошибок у вас неполная цепочка сертификатов.

корневой сертификат этой цепочки (сервера DGET-CA) у вас не установлен в доверенные центры сертификации компьютерного хранилища.

61619b9c000000000013 — нужно удалить. Корректно настроить расширение AIA на издающем CA и выпустить новый сертификат.

61fb04be000000000017 — сертификат сервера DGET-CA нужно установить в доверенные центры сертификации компьютерного хранилища.

на самом деле, не знаю, чего она там делает =) сертификат сервера стоял и стоит в доверенных центрах удалённой машины.

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

Вопрос у меня был в том, что можно ли что-то сделать, чтобы клиент Windows 7 подключался к Server 2008 R2 без ошибок без OCSP и без ключа enablecredsspsupport ?

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

---------------- OCSP сертификата ----------------
Отсутствуют URL "Нет" Время: 0
--------------------------------
Application[0] = 1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
Application[1] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера

В различных интернетах всё ещё задают (и не мало) вопросы про проблемы подключения через remote desktop к серверу терминалов защищённому SSL сертификатом. При подключении пользователи видят вот такое:

Причины здесь может быть 2:

Корневой сертификат цепочки сертификатов не установлен в Trusted Root CAs в *компьютерном* хранилище сертификатов;

Эта проблема встречается примерно в 60-70% случаев появления этой ошибки. Многие привыкли устанавливать корневые сертификаты по двойному клику в пользовательское хранилище. Но, новый mstsc.exe проверяет цепочку сертификатов так, чтобы она заканчивалась на доверенном корневом сертификате установленном в компьютерном хранилище. Поскольку сертификат недоверенный, certificate chaining engine даже и не пытается проверить что-то на отзыв. Как установить сертификат туда:

Войдите в систему с правами локального администратора.
На рабочем столе нажмите Start и Run… (в случае с Windows Vista/7 можете выделить поле Search programs and files) и в окне наберите MMC. Если появится окно UAC, подтвердите выполнение операции или введите пароль администратора.
В открывшейся консоли нажмите File и Add/Remove Snap-in.
В списке выделите Certificates и нажмите Add. В появившемся диалоговом окне переставьте переключатель в Computer account и нажмите Next.
В следующем окне нажмите Finish.
В расскрывшейся оснастке Certificates выделите папку Trusted Root CAs, нажмите правой кнопкой и выберите All Tasks –> Import. Следуйте инструкциям мастера для добавления корневого сертификата в компьютерное хранилище.

Какие-то CRL'ы в цепочке недоступны.

Что бы почитать?

Categories: Security | PKI | Tips & Tricks
Posted at: 08.08.2010 17:34 (GMT+2) by Vadims Podāns | Permalink | Comments (10)

Comments:

> Пока на активном оборудовании не было организован доступ на сервер сертификации а зачем это? Сервер CA должен публиковать свои CRT и CRL файлы на публично доступный веб-сервер. Сам CA в данном случае не нужен, а нужны только его файлы для построения цепочек и проверки сертификатов на отзыв.

>Сервер CA должен публиковать свои CRT и CRL файлы на публично доступный веб-сервер. Вадим, суть в том, что этот веб сервер он есть, и н подчинёный, и находится в корневом домене, из под поддомена где мы, его небыло видно через активное оборудование. Пока служба (крутящая активное оборудование), не открыла на него доступ (на подчинёный) ничего не работало :( и это при большой домменой структуре. в то же время не позволено поднимать в своём домене подчинёный центр сертификации. А если учитывать что необходимо пользователям работать с фермой терминальных серверов, и проверка сертификата обязательна (Win2k8R2, credSSP, SSO), то и получали такую проблему. 700-800 человек не могли просто работать, как только ставили сертификат подписанный для фермы. Убрали и поставили по умолчанию самоподписанный, стали худо бежно входить. В то же время, всем нужно SSO, не нравится им (да и кому понравиться) что в ферму необходимо авторизоваться дважды, первый раз чтоб переслали на сервер, второй, уже на сам сервер :( Пробовал исправление англ на русскую ХР поставить, не получается, просто замена kerberos.dll не получается, необходимо чтобы эта библиотека была свободна. Уж и не знаем, когда такую проблему исправят. На англ версию ХР патч ставится, и работает SSO на ура, как и должно, а вот на руссиш нет такого исправления :(

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

09.07.2020

Windows 10, Windows Server 2016, Групповые политики

комментариев 18

В этой статье мы покажем, как использовать доверенные SSL/TLS сертификаты для защиты RDP подключений к компьютерам и серверам Windows в домене Active Directory. Эти сертфикаты мы будем использовать вместо самоподписанных RDP сертификатов (у пользователей появляется предупреждение о невозможности проверки подлинности при подключению к RDP хосту с таким сертификатом). В этом примере мы настроим специальный шаблон для выпуска RDP сертификатов в Certificate Authority и настроим групповую политику для автоматического выпуска и привязки SSL/TLS сертификата к службе Remote Desktop Services.

Предупреждение о самоподписанном сертификате RDP

По умолчанию в Windows для защиты RDP сессии генерируется самоподписанный

сертификат. В результате при первом подключении к RDP/RDS серверу через клиента mstsc.exe, у пользователя появляется предупреждение:

При этом отпечаток RDP сертификата сохраняется на клиенте в параметре CertHash в ветке реестра с историей RDP подключений (HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers\). Если вы скрыли уведомление о невозможности проверить подлинность RDP сервера, чтобы сбросить настройки, удалите ключ с отпечатком сертификата из реестра.

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

Создаем шаблон RDP сертификата в центре сертификации (CA)

Попробуем использовать для защиты RDP подключений доверенный SSL/TLS сертификат, выданный корпоративным центром сертификации. С помощью такого сертификата пользователь может выполнить проверку подлинности RDP сервера при подключении. Предположим, что у вас в домене уже развернут корпоративной центр сертификации (Microsoft Certificate Authority), в этом случае вы можете настроить автоматическую выдачу и подключение сертификатов всем компьютерам и серверам Windows в домене.

Н на вашем CA нужно создать новый тип шаблона сертификата для RDP/RDS серверов.

Настройка групповой политики для выдачи RDP сертификатов

Теперь нужно настроить доменную политику, которая будет автоматически назначать RDP сертификат компьютерам/серверам согласно настроенного шаблона.

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

Откройте консоль управления доменными групповыми политиками gpmc.msc, создайте новый объект GPO и назначьте его на OU с RDP/RDS серверами или компьютерами, для которых нужно автоматически выдавать TLS сертификаты для защиты RDP подключения;
Перейдите в раздел GPO: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security. Включите политику Server Authentication Certificate Template. Укажите имя шаблона CA, который вы создали ранее (RDPTemplate);
Затем в этом же разделе GPO включите политику Require use of specific security layer for remote (RDP) connections и установите для нее значение SSL;
Для автоматического продления RDP сертификата, перейдите в раздел GPO Computer configuration -> Windows settings -> Security Settings -> Public Key Policies и включите политику Certificate Services Client – Auto-Enrollment Properties. Выберите опции “Renew expired certificates, update pending certificates and remove revoked certificates” и “Update certificates that use certificate templates”;
Если вы хотите, чтобы клиенты всегда проверяли сертификат RDP сервера, вам нужно настроить политику Configure Authentication for Client = Warn me if authentication fails (секция GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client);
Если нужно, можете через политики файервола открыть входящий RDP порт TCP/UDP 3389;
Осталось обновить политики на клиенте, запустить консоль сертификатов компьютера (Certlm.msc), и проверить, что в разделе Personal -> Certificates появился сертификат для Remote Desktop Authentication, выданный вашим CA.

Если политики не применились, для диагностики GPO воспользуйтесь утилитой gpresult и этой статьей.

Для применения нового RDP сертификата, перезапустите службу Remote Desktop Services:

Get-Service TermService -ComputerName msk-dc01| Restart-Service –force –verbose

Также можете в консоли Certification Authority в секции Issued Certificates проверить, что по шаблону RDPTemplate был выдан сертификат определённому Windows компьютеру/серверу. Также проверьте значение Thumbprint сертификата:

Теперь сравните полученные данные с отпечатком сертификата, который используется службой Remote Desktop Service. Вы можете посмотреть значение отпечатка сертификата службы RDS в реестре (ветка HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations, параметр TemplateCertificate) или командой PowerShell: Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices|select SSLCertificateSHA1Hash

Теперь, при подключении к удаленном столу любого сервера или компьютера, на который действует эта политика, вы не увидите предупреждения о недоверенном RDP сертификате.

Подписываем RDP файл и добавляем отпечаток доверенного RDP сертификата

Если у вас отсутствует CA, но вы хотите, чтобы при подключении к RDP/RDS серверу у пользователей не появлялось предупреждения, вы можете добавить сертификат в доверенные на компьютерах пользователей.

Как описано выше получите значение отпечатка (Thumbprint) RDP сертификата:

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices|select|select SSLCertificateSHA1Hash

Используйте этот отпечаток для подписывания .RDP файла с помощью RDPSign.exe:

rdpsign.exe /sha256 65A27B2987702281C1FAAC26D155D78DEB2B8EE2 "C:\Users\root\Desktop\rdp.rdp"

Теперь через GPO добавим этот отпечаток сертификата в доверенные у пользователей. Укажите отпечатки (через точку с запятою) в политике Specify SHA1 thumbprints of certificates representing trusted .rdp publishers (Указать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP) в секции Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Settings -> Remote Desktop Connection Client.

Чтобы работал прозрачных RDP вход без ввода пароля (RDP Single Sign On), нужно настроить политику Allow delegation defaults credential и указать в ней имена RDP/RDS серверов (см. статью).

8 мая 2018 г. Microsoft выпустило обновление, которое предотвращает удаленное выполнение кода с помощью уязвимости в протоколе CreedSSP.

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

Рисунок 1 - Ошибка проверки подлинности RDP

Появление ошибки обусловлено установкой данных обновлений безопасности:

Windows Server 2016 — обновление KB4103723
Windows 10 1609 — обновление KB4103723
Windows 10 1703 — обновление KB4103731
Windows 10 1709 — обновление KB4103727
Windows 10 1803 — обновление KB4103721
Windows 7 / Windows Server 2008 R2 — обновление KB4103718
Windows 8.1 / Windows Server 2012 R2 — обновление KB4103725

В данной статье мы рассмотрим варианты исправления данной ошибки.

Вариант №1: Убираем проверку подлинности.

Заходим в свойства компьютера, переходим на вкладку Удаленный доступ и снимаем галку с чекбокса.

Рисунок 2 - Проверка подлинности

Вариант №2 (рекомендуемый): Обновление клиентских и серверных ОС.

Устанавливаем специально выпущенные патчи обновления, которые закрыли уязвимость в RDP-клиенте. Данные обновления можно посмотреть на сайте Microsoft. После установки данного обновления, мы обновляем CredSSP.

Вариант №3: Через групповые политики.

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

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

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

Вариант №4. Редактирование реестра.

Локально заходим на устройство, к которому пытаемся подключиться и нажимаем Win+R. Вводим regedit. После того, как откроется редактор реестра идем по следующему пути:

Затем находим параметр AllowEncryptionOracle, открываем его и ставим значение 2.

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

Читайте также: