Contents of this directory is archived and no longer updated.

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

A revocation check could not be performed for the certificate

И сообщение: A revocation check could not be performed for the certificate. Или в русском варианте — не удалось проверить не был ли отозван этот сертификат. А если нажать на View certificate… выясняется, что всё в порядке, сертификат доверен и цепочка построена правильно. Что это такое и как с этим жить?

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

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

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

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

Когда сертификат выдаётся внутренним CA, но пользователи подключаются к серверу через интернет (например из дома подключаются к RemoteApp по https), очень часто файлы сертификатов и CRL'ы издающего CA недоступны из интернета. В данном случае необходимо связаться с системным администратором, чтобы он переконфигурировал расширения CDP так, чтобы CRL'ы были доступны и из интернета.

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


Share this article:

Comments:

RuStn
RuStn 11.08.2010 00:52 (GMT+3) Remote Desktop Client 7 и revocation checking

Вадим, спасибо за статью, но к сожалению она не полна :( Всё ещё более запущено :) Причина о которой говорится в статье, она действительно возникает из-за отсутствия корневого сертификата в доверенных. Решение не всегда такое тривиальное, добавил и всё. Решение необходимо искать в том, чтобы пользователи (ПК пользователей) могли видеть корневой сервер сертификации (или его подчинённого). В нашем случае (были такие же большие грабли), пользователи имели в доверенных сертификаты корневого сервера сертификации, но, но и не работало. Пока на активном оборудовании не было организован доступ на сервер сертификации (а он у нас в корневом домене был), пользователи получали такие сообщения. Так же существует проблема в том, как подписать сертификат. Самоподписанный (самодоверенный) сертификат работает, но срок его мал. в добавок ко всему, в случае использования фермы, необходим сертификат выданный на имя фермы. Так ещё в свойствах его необходимо указать что выдан для "Проверки подлинности сервера". В некоторых документах указано что необходимо чтобы был подписан как Remote Desktop Connection (вот в названии могу ошибиться). Так и этого мало, шаманство так ни к чему не привело, не знаем как правильно подписать :( чтобы при использовании credssp можно было пользоваться SSO. Ещё нашли одну проблему, которая решена в других языках (англ, нем, и т.д.), но только не в русской версии. Для Windows XP SP3 при включении протокола CredSSP для работы с SSO, пользователи могут входить без доп ввода пароля в терминальные сервера, но только не в ферму серверов :(( Проблема в библиотеке kerberos.dll и ещё одной, точно не помню, которую решил мелкософт, выпустив патч который можно получить по запросу, для всех других языков ещё в мае 2009 года. Борьба с протоколом и сертификатами сводит на нет всё преимущество данной технологии от мелкософта. Всё как то запущено. К сожалению и библиотеки в технете не полны, не раскрывают суть, а только поверхностно. Вот как найти информацию по сертификату? Как подписать, какие поля важны. Как решить проблему со входом в ферму и т.д.

Vadims Podāns
Vadims Podāns 11.08.2010 10:03 (GMT+3) Remote Desktop Client 7 и revocation checking

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

RuStn
RuStn 11.08.2010 22:01 (GMT+3) Remote Desktop Client 7 и revocation checking

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

Vadims Podāns
Vadims Podāns 11.08.2010 22:17 (GMT+3) Remote Desktop Client 7 и revocation checking

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

RuStn
RuStn 12.08.2010 21:13 (GMT+3) Remote Desktop Client 7 и revocation checking

Решение в принципе найдено: Доступ на сервера сертификации предоставлен, сертификат теперь проверяется и ошибок нет. SSO на CredSSP.dll работает с фермой: необходимо установить два патча - kb953760 и kb953760-v2 которые патчат (впервые такое вижу) kerberos.dll и msv1_0.dll. Версии самих dll в этих исправлениях лежат старые 5.1.2600.5615 версии QFE. Но после применения этих патчей, версии dll остаются какие были в системе (5.1.2600.5834 что ли), но содержимое в них уже изменено по сравнению с оригинальными GDR файлами (что идут с сервис паком 3). Впервые вижу чтобы содержимое патча одно, после применения его, версионность библиотек остаётся той же самой (меняется только версия QFE с GDR). Были в системе 5.1.2600.5834 GDR, так и остались 5.1.2600.5834 но уже QFE. Финт ушами, и никакого машеничества. Зато, нарушений в работе библиотеки не замечено, и проблемы с попаданием в ферму решены. Но, самую главную роль играет опять же сертификат, который должен быть правильно подписан (ох уж он, сертификат)... Стоит ошибиться в нём, как всё снова не работает (но оно так и должно быть). Всё это потому, что главную роль играют уже сами сертификаты...

shss.wordpress.com
shss.wordpress.com 18.08.2010 17:25 (GMT+3) Remote Desktop Client 7 и revocation checking

>Версии самих dll в этих исправлениях лежат старые 5.1.2600.5615 версии QFE. Но после применения этих патчей, версии dll остаются какие были в системе (5.1.2600.5834 что ли), но содержимое в них уже изменено по сравнению с оригинальными GDR файлами (что идут с сервис паком 3). возможно, здесь найдете объяснение сему факту: http://pronichkin.com/Lists/Posts/Post.aspx?ID=85

www.google.com/accounts/o8/id?id=AItOawkxLgTGiY3eYPnzg1bvILuAGmNn6LCrxPU
www.google.com/accounts/o8/id?id=AItOawkxLgTGiY3eYPnzg1bvILuAGmNn6LCrxPU 21.01.2011 09:28 (GMT+3) Remote Desktop Client 7 и revocation checking

Вадим, подскажите с чем может быть связана еще подобная ошибка? Я свою проблему описывал на форуме TechNet - http://bit.ly/fBV4HU В кратце: проверка сертификата ручками(certutil -url ...) дает положительный результат. и по OCSP и по CRL. А RDP Win7 ругается... %)

Vadims Podāns
Vadims Podāns 21.01.2011 14:02 (GMT+3) Remote Desktop Client 7 и revocation checking

попробуйте на этом компьютере выполнить certutil -urlcache CRL delete

www.google.com/accounts/o8/id?id=AItOawkxLgTGiY3eYPnzg1bvILuAGmNn6LCrxPU
www.google.com/accounts/o8/id?id=AItOawkxLgTGiY3eYPnzg1bvILuAGmNn6LCrxPU 24.01.2011 07:25 (GMT+3) Remote Desktop Client 7 и revocation checking

очистка реестра + ребут помогли. Спасибо! Бился с этим месяц... %)

Alexander Druzhin
Alexander Druzhin 01.02.2011 23:33 (GMT+3) Remote Desktop Client 7 и revocation checking

В моём случае корневой сертификат где надо, CRL доступен по http, проверка сертификата сервера на клиентском компьютере командой certutil -veryfy -urlfetch cert.cer проходит, сниффером вижу, как клиент в этот момент лезет по http на ссылку, описанную в расширении CDP сертификата. При коннекте к терминалу, однако, клиент выдаёт вышеозначенную ошибку, при этом сниффер попыток обращения к CDP не фиксирует. Т.е. клиент принимает решение о невозможности проверки на основе непонятно чего. Я в растерянности и уже не знаю куда рыть.

Comments are closed.