У меня есть ферма удаленных рабочих столов Server 2012, которая отлично работает, если настроена с самозаверяющими сертификатами, сгенерированными диспетчером сервера, но не с сертификатами из нашего внутреннего центра сертификации.
С помощью самоподписанных сертификатов наши удаленные клиенты могут подключаться, но, конечно же, получать предупреждения безопасности из-за ненадежных сертификатов. Клиенты действительно доверяют нашему корневому ЦС, поэтому мы сможем устранить их, используя вместо этого сертификаты из нашего внутреннего ЦС.
Однако, когда я настраиваю ферму для использования сертификатов из нашего внутреннего центра сертификации (который запускает AD CS на Server 2008 R2), клиенты могут входить на веб-сайт удаленных рабочих столов, но не могут открывать сеансы RDP. Они получают такие ошибки в Windows 7 (ни один из клиентов не новее 7, поэтому я не пробовал 8):
Ваш компьютер не может подключиться к удаленному компьютеру, потому что на удаленном компьютере, к которому вы хотите подключиться, произошла ошибка. Обратитесь к сетевому администратору за помощью.
или
Ваш компьютер не может подключиться к удаленному компьютеру, потому что шлюз удаленного рабочего стола и удаленный компьютер не могут обмениваться политиками. Это могло произойти по одной из следующих причин:
- Удаленный компьютер не может обмениваться политиками со шлюзом удаленных рабочих столов.
- Конфигурация удаленного компьютера не разрешает новое соединение.
- Соединение между шлюзом удаленного рабочего стола и удаленным компьютером разорвано.
Обратитесь к сетевому администратору за помощью.
В свою очередь, они появятся в журналах сервера:
(Источник: Schannel; идентификатор события: 36874) [sic] Запрос на соединение TLS 1.2 был получен от удаленного клиентского приложения, но ни один из наборов шифров, поддерживаемых клиентским приложением, не поддерживается сервером. Запрос на соединение SSL не удался.
(Источник: Schannel; идентификатор события: 36888) Было создано критическое предупреждение, которое было отправлено на удаленную конечную точку. Это может привести к разрыву соединения. Код фатальной ошибки, определенный протоколом TLS, - 40. Состояние ошибки Windows SChannel - 1205.
И наш корневой ЦС, и выдающий ЦС используют хеши SHA512 и 4096-битные открытые ключи. Я заметил, что самозаверяющие сертификаты из диспетчера сервера, делать работают с использованием SHA256 и 2048-битных ключей, поэтому мне интересно, не поддерживается ли более сильное шифрование RDP в Windows 7.
(Я не могу это легко проверить, так как я не могу заставить наш ЦС выдавать сертификат с использованием SHA256, я предполагаю, что собственный открытый ключ ЦС слишком велик. Даже если бы это было так, клиенту все равно потребуется SHA512 для проверки выдающий ЦС против корневого ЦС.)
Странно то, что это делает работать с нашими сертификатами кроме «Посредник подключений к удаленному рабочему столу - включить единый вход». Если я оставлю этот набор для самозаверяющего сертификата, но использую наш для остальных трех, все будет работать в основном нормально (кроме пользователей, которые должны вводить свой пароль три раза).
В этом случае Internet Explorer на клиенте без проблем доверяет одному из наших сертификатов, даже если он имеет SHA512. Это заставляет казаться довольно странным, что более сильное шифрование может сбить с толку RDP - я бы предположил, что они оба будут использовать поставщика, встроенного в Windows.
Ориентировочно мне кажется, что ответ - нет, Windows 7 не может получить доступ к ферме удаленных рабочих столов (по крайней мере, к серверу 2012), если сертификат «Посредник подключений к удаленному рабочему столу - включить единый вход» использует сертификат, подписанный с использованием хэша SHA512. .
Я установил новые корневые и выдающие полномочия очень похоже на то, как были настроены наши существующие, за исключением того, что я дал и 2048-битные ключи, и хэши SHA256. Я применил сертификат от этого нового органа выдачи в качестве сертификата «Посредник подключений к удаленному рабочему столу - включить единый вход», и проблема исчезла.
Единственная реальная разница в настройках CA Кроме как Криптостойкость заключалась в том, что новый орган выдачи был установлен в Server 2012 вместо Server 2008 R2, но я ожидаю, что это не будет иметь никакого значения.
Я все еще был бы рад более определенному ответу.