Добрый день.
Есть сервер, котором поднят RemoteApp и приложения в нем.
На стороне клиента на Windows 10 поставил мелкософтовскую прогрумму «Удаленные рабочие столы», в которой можно собирать в кучу сервера для удаленного доступа, Azure приложения и Remoteapp.
Так вот,при попытке подключится к серверу RemoteApp (указывается путь https://ip_server/RDWeb/Pages/ru-RU/Default.aspx)
Если заходить через браузер то тоже ругается на сертификат.
Все настройки по умолчанию,сертификат никакой не выпускал.
Сервера сертификации в сети нету.
Возможно как-то проигнорировать сертификат или создать как-то для него, чтобы ошибку исправить?
Спасибо
-
Вопрос заданболее трёх лет назад
-
1190 просмотров
Пригласить эксперта
Выгрузите сертификат с сервера и добавьте в доверенные.
По уму нужно развернуть свой ЦС (можно на базе openssl там проще), выпускать для серверов сертификаты руками и устанавливать их. Тогда можно будет в сети распространить один сертификат ЦА и все другие сертификаты будут валидными автоматически.
-
Показать ещё
Загружается…
06 июн. 2023, в 08:55
2000 руб./за проект
06 июн. 2023, в 08:29
3600000 руб./за проект
06 июн. 2023, в 07:46
1000 руб./за проект
Минуточку внимания
Windows, Windows Server
Исправляем ошибку: «сертификат проверки подлинности просрочен или недействителен»
- 24.02.2015
- 27 030
- 2
- 19.01.2020
- 6
- 4
- 2
- Содержание статьи
- Описание
- Комментарии к статье ( 2 шт )
- Добавить комментарий
В данной статье пойдет речь об ошибке «сертификат проверки подлинности просрочен или недействителен», которая может возникать при попытке запуска опубликованного приложения RemoteApp и о том, как эту ошибку можно исправить.
Описание
Удаленное приложение RemoteApp отключено
Удаленному рабочему столу не удалось подключится к данному удаленному компьютеру, поскольку полученный от него сертификат проверки подлинности просрочен или недействителен. В некоторых случаях эта ошибка также может быть вызвана большим расхождением в значениях времени на часах клиента и сервера.
Как и написано в тексте ошибки, все дело в том, что компьютер, на котором запускается RemoteApp приложение считает сертификат просроченным или недействительным. Если с сертификатом проблем нет, то дело скорей всего именно в неверной дате на сервере или на клиенте. Если проблема на всех клиентах, то значит смотрим в сторону сервера (проверяем, что установлена текущая дата).
В интернете встречал информацию о том, что даже после выставления правильной даты на сервере, ошибка не пропадала. Помогала лишь перезагрузка самого сервера. Если проблема только на единичных клиентах, то смотрим установленное на них время и меняем его на нужное.
Особенно внимательно смотрим, чтобы год был указан правильно, а то часто бывает что стоит правильная дата, правильное время и год 2002
Hello,
I’m using Server 2012 r2 with RDS installed. I chose a Quick start configuration, because I will use it only for home/test purposes. All of the roles Connection Broker, session host, Web access and RD Gateway are on the same machine.
I have SSL certificate from trusted authority assigned to all roles. The subject alternative name in the certificate match with the server name and the external FQDN. Everything with the certificate looks OK.
When I open the RDWeb site internally I’m able to start the published applications with no problems.
If I try to use the Remoteapps externally, I open the https://FQDN/RDWeb (No certificate warnings here), Log in with domain user credentials, but when try to start application I receive:
» Your computer can’t connect to remote computer because the remote deskto gateway server address requested and certificate don’t match.»
When click View certificate, I found that it use different certificate, not that one that I set for my RDS Gateway!
For example I have set rds.exampleFQDN.com issued by StartCom, but I is trying to use certificate from RapidSSL CA issued *.domain.com
My question is why the RDP is trying to use this wrong certificate instead of this that I have set ?
- Remove From My Forums
-
Question
-
I’m doing an emergency deployment of a program using RemoteApp and I’m getting a certificate error on the two WinXP SP3 computers at the remote site. I can login to the farm through Remote Desktop fine, but as soon as I launch RemoteApp I get a yellow certificate error.
The same icon works on a local test system fine and I have it working at another remote site. The error in more detail states:
Your remote desktop connection failed because the remote computer cannot be authenticated
The remote computer could not be authenticated due to problems with its security certificate. It may be unsafe to proceed.
Name mismatch
Requested remote computer:
<farm.domain.local>Name in the certificate from the remote computer
<servername.domain.local>Certificate errors
The following errors were encountered while validating the remote computer’s certificate:
The server name on the certificate is incorrect.
And it would not allow me to proceed. The problem is that I’m not using certificates at all and no certificate warning comes up at my other locations or on the test station.
Right now, I’m installing a slew of updates. Could this be the problem?
According to MS, all RemoteApp requires is Windows XP SP3 and I believe RDC 6.
-
Edited by
Thursday, July 30, 2009 3:52 PM
spelling error
-
Edited by
Answers
-
Hi,
Can you please check the «authentication level» rdp file property in remote apps. Please add «authentication level:i:2» to custom rdp file settings in Remote App manager.
Thanks.
Regards,
Rajesh.-
Marked as answer by
frivers, MCP, MCTS
Thursday, July 30, 2009 4:57 PM
-
Marked as answer by
Ошибка:
Подключение было разорвано, поскольку был получен непредусмотренный
сертификат проверки подлинности сервера от удаленного компьютера.
Повторите попытку подключения. Если проблема сохранится, обратитесь к владельцу
удаленного компьютера или к сетевому администратору.
Удалил на пк ветку
[HKEY_CURRENT_USERSOFTWAREMicrosoftTerminal Server ClientServers]
Все заработало.
PS: Ошибка появилась после замены сертификата на ферме rds rdp. После перезагрузки брокеров ошибка пропала.
Similar Posts:
- None Found