В различных интернетах всё ещё задают (и не мало) вопросы про проблемы подключения через 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'ы были доступны и из интернета.

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

Sunday, August 08, 2010 5:34:50 PM (FLE Daylight Time, UTC+03:00)   Comments [9]    

 

Wednesday, August 11, 2010 12:52:54 AM (FLE Daylight Time, UTC+03:00)
Вадим, спасибо за статью, но к сожалению она не полна :(
Всё ещё более запущено :)
Причина о которой говорится в статье, она действительно возникает из-за отсутствия корневого сертификата в доверенных. Решение не всегда такое тривиальное, добавил и всё.
Решение необходимо искать в том, чтобы пользователи (ПК пользователей) могли видеть корневой сервер сертификации (или его подчинённого).
В нашем случае (были такие же большие грабли), пользователи имели в доверенных сертификаты корневого сервера сертификации, но, но и не работало. Пока на активном оборудовании не было организован доступ на сервер сертификации (а он у нас в корневом домене был), пользователи получали такие сообщения.
Так же существует проблема в том, как подписать сертификат. Самоподписанный (самодоверенный) сертификат работает, но срок его мал. в добавок ко всему, в случае использования фермы, необходим сертификат выданный на имя фермы. Так ещё в свойствах его необходимо указать что выдан для "Проверки подлинности сервера". В некоторых документах указано что необходимо чтобы был подписан как Remote Desktop Connection (вот в названии могу ошибиться).
Так и этого мало, шаманство так ни к чему не привело, не знаем как правильно подписать :( чтобы при использовании credssp можно было пользоваться SSO.
Ещё нашли одну проблему, которая решена в других языках (англ, нем, и т.д.), но только не в русской версии. Для Windows XP SP3 при включении протокола CredSSP для работы с SSO, пользователи могут входить без доп ввода пароля в терминальные сервера, но только не в ферму серверов :((
Проблема в библиотеке kerberos.dll и ещё одной, точно не помню, которую решил мелкософт, выпустив патч который можно получить по запросу, для всех других языков ещё в мае 2009 года.
Борьба с протоколом и сертификатами сводит на нет всё преимущество данной технологии от мелкософта. Всё как то запущено. К сожалению и библиотеки в технете не полны, не раскрывают суть, а только поверхностно. Вот как найти информацию по сертификату? Как подписать, какие поля важны. Как решить проблему со входом в ферму и т.д.
RuStn
Wednesday, August 11, 2010 10:03:09 AM (FLE Daylight Time, UTC+03:00)
> Пока на активном оборудовании не было организован доступ на сервер сертификации

а зачем это? Сервер CA должен публиковать свои CRT и CRL файлы на публично доступный веб-сервер. Сам CA в данном случае не нужен, а нужны только его файлы для построения цепочек и проверки сертификатов на отзыв.
Wednesday, August 11, 2010 10:01:07 PM (FLE Daylight Time, UTC+03:00)
>Сервер CA должен публиковать свои CRT и CRL файлы на публично доступный веб-сервер.
Вадим, суть в том, что этот веб сервер он есть, и н подчинёный, и находится в корневом домене, из под поддомена где мы, его небыло видно через активное оборудование.
Пока служба (крутящая активное оборудование), не открыла на него доступ (на подчинёный) ничего не работало :( и это при большой домменой структуре. в то же время не позволено поднимать в своём домене подчинёный центр сертификации. А если учитывать что необходимо пользователям работать с фермой терминальных серверов, и проверка сертификата обязательна (Win2k8R2, credSSP, SSO), то и получали такую проблему. 700-800 человек не могли просто работать, как только ставили сертификат подписанный для фермы. Убрали и поставили по умолчанию самоподписанный, стали худо бежно входить.
В то же время, всем нужно SSO, не нравится им (да и кому понравиться) что в ферму необходимо авторизоваться дважды, первый раз чтоб переслали на сервер, второй, уже на сам сервер :(
Пробовал исправление англ на русскую ХР поставить, не получается, просто замена kerberos.dll не получается, необходимо чтобы эта библиотека была свободна.
Уж и не знаем, когда такую проблему исправят. На англ версию ХР патч ставится, и работает SSO на ура, как и должно, а вот на руссиш нет такого исправления :(
RuStn
Wednesday, August 11, 2010 10:17:58 PM (FLE Daylight Time, UTC+03:00)
в данном случае у вас проблема не технического, а административного характера. Без публичного веб-сервера вам не выкрутиться из сложившейся ситуации.

что касается SSO, тут я ничего не могу сказать, т.к. локализованные системы не использую нигде.
Thursday, August 12, 2010 9:13:50 PM (FLE Daylight Time, UTC+03:00)
Решение в принципе найдено: Доступ на сервера сертификации предоставлен, сертификат теперь проверяется и ошибок нет.
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.
Финт ушами, и никакого машеничества. Зато, нарушений в работе библиотеки не замечено, и проблемы с попаданием в ферму решены.
Но, самую главную роль играет опять же сертификат, который должен быть правильно подписан (ох уж он, сертификат)... Стоит ошибиться в нём, как всё снова не работает (но оно так и должно быть). Всё это потому, что главную роль играют уже сами сертификаты...
RuStn
Wednesday, August 18, 2010 5:25:40 PM (FLE Daylight Time, UTC+03:00)
>Версии самих dll в этих исправлениях лежат старые 5.1.2600.5615 версии QFE. Но после применения этих патчей, версии dll остаются какие были в системе (5.1.2600.5834 что ли), но содержимое в них уже изменено по сравнению с оригинальными GDR файлами (что идут с сервис паком 3).

возможно, здесь найдете объяснение сему факту: http://pronichkin.com/Lists/Posts/Post.aspx?ID=85
Friday, January 21, 2011 9:28:24 AM (FLE Standard Time, UTC+02:00)
Вадим, подскажите с чем может быть связана еще подобная ошибка?
Я свою проблему описывал на форуме TechNet - http://bit.ly/fBV4HU
В кратце: проверка сертификата ручками(certutil -url ...) дает положительный результат. и по OCSP и по CRL.
А RDP Win7 ругается... %)
Friday, January 21, 2011 2:02:58 PM (FLE Standard Time, UTC+02:00)
попробуйте на этом компьютере выполнить certutil -urlcache CRL delete
Tuesday, February 01, 2011 11:33:09 PM (FLE Standard Time, UTC+02:00)
В моём случае корневой сертификат где надо, CRL доступен по http, проверка сертификата сервера на клиентском компьютере командой certutil -veryfy -urlfetch cert.cer проходит, сниффером вижу, как клиент в этот момент лезет по http на ссылку, описанную в расширении CDP сертификата.
При коннекте к терминалу, однако, клиент выдаёт вышеозначенную ошибку, при этом сниффер попыток обращения к CDP не фиксирует. Т.е. клиент принимает решение о невозможности проверки на основе непонятно чего.
Я в растерянности и уже не знаю куда рыть.
OpenID
Please login with either your OpenID above, or your details below.
Name
E-mail
(will show your gravatar icon)
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):

Live Comment Preview
 · 

All content © 2008 - 2012, Vadims Podāns
"Spaces" Theme provided by: Vadims Podāns
About


E-mail - Send mail to the author(s)
Live Messenger -
For english language visitors
Библиотека
Календарик
<February 2012>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910

Карта расположения посетителей
Favorites





Fan list



Disclaimer
Вся информация на сайте предоставляется на условиях «как есть», без предоставления каких-либо гарантий и прав.

При использовании материалов c данного сайта ссылка на оригинальный источник обязательна.
Protected by Copyscape Online Plagiarism Scanner