не удалось проверить не был ли отозван этот сертификат rdp windows 7
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
General discussion
Прочитал похожие темы и «тот самый блог Вадима.»
Все сделал как описано.
Пытаюсь из одной подсети(2008R2) подключится к терминальному серверу на 2008R2 в другой подсети, через интернет.
Результат и там и там одинаков » не удалось проверить не был ли отозван этот сертификат».
Серийный номер сертификата : 428d050d0000000001de
dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 16 Hours, 59 Minutes, 32 Seconds
CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
NotBefore: 12.04.2011 9:46
NotAfter: 11.04.2012 9:46
SubjectAltName: DNS- имя =MO1TS01.kaventdom.local
ca 63 de 3a 08 cd 49 a7 bb e0 56 9a 49 49 60 75 c9 18 d3 b6
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Проверено «Сертификат (0)» Время: 4
Проверено «Базовый CRL (20)» Время: 4
Проверено «Разностный CRL (20)» Время: 4
ОК «Разностный CRL (20)» Время: 4
Отсутствуют URL «Нет» Время: 0
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
64 1c 33 49 43 47 29 98 7d 7c b6 a0 93 2c 7e d1 80 6e b5 5a
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
ad f4 63 27 bd 1f 3e 47 09 e9 4c a1 57 45 ec ff ff b0 f1 06
Application[0] = 1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
Application[1] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера
CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
NotBefore: 18.03.2011 18:29
NotAfter: 18.03.2031 18:39
Subject: CN=kaventdom-MO1DC01-CA, DC=kaventdom, DC=local
ff d2 72 dd e5 19 d8 ae 71 b1 cb 42 43 b5 8b cd d5 3d 06 ea
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Отсутствуют URL «Нет» Время: 0
Отсутствуют URL «Нет» Время: 0
Отсутствуют URL «Нет» Время: 0
e0 99 12 cd 1f 0a bf f8 4e cd de 65 79 62 29 b6 d6 fd ee e9
fb 6e 1e e0 73 68 ba 3e 78 a7 08 24 a6 9b 65 d8 29 ca e4 6e
Проверенные политики выдачи: Нет
Проверенные политики применения:
1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
1.3.6.1.5.5.7.3.1 Проверка подлинности сервера
Проверка отзыва сертификата выполнена
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Пробуем настроить проверку подлинности на уровне сети для терминального сервера (по статье http://interface31.ru/tech_it/2010/11/zashhita-rdp-soedineniya-pri-pomoshhi-ssl.html)
Терминальный сервер и автономный центр сертификации одна и та же машина. AD нет.
После всех действий сохраняется ошибка при подключении:
Сертификат ЦС на клиентском ПК добавлен в Хранилище компьютера «Доверенные корневые центры сертификации».
И еще вопрос: можно ли настроить RDS так, чтобы подключение было невозможно, если есть какие-либо ошибки сертификата? В настройках rdp подключения на клиенте можно указать «Не соединять», а есть ли способ сделать это со стороны терминального сервера?
Ответы
Да. Пришли к тому же сами))
Почему-то не стояла галочка «Включать в CDP-расширение выданных сертификатов» для http на вкладке Расширения. Как поставили, заработало как надо.
А файл file://nitrix-server/CertEnroll/NITRIX-SERVER-CA.crl с клиента доступен, но проблема оставалась. Вот только это непонятно почему.
Все ответы
покажите cdp сертификата?
>> И еще вопрос: можно ли настроить RDS так, чтобы подключение было невозможно, если есть какие-либо ошибки сертификата?
Как это правильно сделать?
Поставщик:
CN=NITRIX-SERVER-CA
Хэш имени (sha1): c3eea829304e0d2d0d89a6cb9f4fee5c8df1151e
Хэш имени (md5): c0a0560ba792702c9f78d159a051bfa7
Субъект:
CN=NITRIX-SERVER-CA
Хэш имени (sha1): c3eea829304e0d2d0d89a6cb9f4fee5c8df1151e
Хэш имени (md5): c0a0560ba792702c9f78d159a051bfa7
Серийный номер сертификата: 71ed0e9bc191ddb748eeb2162452d4a6
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)
То ли не туда смотрю, то ли их там просто нет.
Просматриваю на клиенте свойства сертификата ЦС, который лежит в хранилище компьютера «Доверенные корневые центры сертификации»
не, корневой не надо, у корневого нет cdp. надо тот который в свойствах соединения терминального севрера выставлен, с именем nitrix-server
Причем файл по этому пути с клиента доступен и я могу его открыть и просмотреть, на вкладке Список отзыва, естественно нет ни одного отозванного сертификата:
Поставщик:
CN=NITRIX-SERVER-CA
Субъект:
E=astvas@gmail.com
CN=nitrix-server
OU=IT
O=nitrix
L=stavropol
S=SK
C=RU
Серийный номер сертификата: 61120647000000000002
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
Вопрос
Ответы
Привет!, а Вас не смутило, то что Вы допустили две ошибки:
-вопросу уже более полутора лет;
-Автор вопроса, не Вы.
Правильнее задавать свой вопрос, указывая ссылкой на это обсуждение вопроса.
Начните с внимательного изучения серии статей, начав со статьи «Краткое руководство по Microsoft PKI». Особое внимание обратите на требование для Внешних Пользователей, и Корневой сертификат, должен быть подписан Доверенным корневым центром сертификации.
Да, я Жук, три пары лапок и фасеточные глаза :))
Все ответы
Да, я Жук, три пары лапок и фасеточные глаза :))
Да, я Жук, три пары лапок и фасеточные глаза :))
Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты. Сейчас в личном хранилище кроме него больше нет сертификатов. На компьютере с Windows 7 только добавлен сертификат ЦС предприятия в доверенные корневые ЦС компьютера.
На всякий случай упомяну, при подключении «сервер» с Windows 8 выдает для проверки именно сертификат от ЦС, а не самоподписанный. Для этого подправил групповую политику, чтобы RDP использовал сертификаты с шаблоном Machine.
Запрос на создание Сертификата, должен создаваться на том компьютере, для которого он предназначен. Этот сертификат должен быть в Личных, этот Сертификат компьютер должен предъявить Серверу, и этот Сертификат должен проверяться на отзыв. Корневой доверенный Сертификат, как правило, не проверяется на отзыв.
Ваша цитата: «Да, на клиентском компьютере с Windows 7.», что входит в противоречие с Вашей же цитатой: «Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты.».
Дополнительно, воспользуйтесь серией статей:
Да, я Жук, три пары лапок и фасеточные глаза :))
Я лично под клиентом понимаю компьютер с Windows 7, у него нет никаких своих сертификатов. Свой сертификат есть у компьютера с Windows 8 ( «Сертификат запрашивал с компьютера с Windows 8 через оснастку сертификаты.» ), я его экспортировал в файл, проверил на клиенте ( «Да, на клиентском компьютере с Windows 7.») и выложил лог в 1 сообщении. Но когда я подключаюсь с клиента к компьютеру с Windows 8, получаю ту самую ошибку, что не удается проверить, не отозван ли сертификат. Я тут же открываю сведения о сертификате, копирую оттуда URL на список отзыва и без проблем скачиваю этот самый список отзыва, в котором у меня уже штук 5 отозванных сертификатов.
За статьи спасибо, но не нашел в них решения своей проблемы.
https://www.dropbox.com/sh/y3qr6f34sf7ip5o/BgQLYhzgQr по данной ссылке выложил сертификаты ЦС, компьютера с Windows 8 и списки отзыва. Само собой, клиент может разрешить имена, указанные в сертификате.
Из статей, ссылки на которые Вам дал ранее, следует, что для того что бы Клиент мог проверить легитимность предъявляемого ему Сертификата, необходимо или в ручную установить СОС (Список Отзыва Сертификатов) или обеспечить Клиенту, OCSP проверку Сертификата.
Установите на Клиенте вручную, СОС сертификата, которого проверяет Клиент, проверьте и напишите результат.
Да, я Жук, три пары лапок и фасеточные глаза :))
СОС необходимо устанавливать в Промежуточные центры сертификации.
Да, я Жук, три пары лапок и фасеточные глаза :))
Руководствуясь разделом Q9 справки, загрузите в общедоступную папку SkyDrive, публичный Сертификат (cer-файл) компьютера Windows 8.
Да, я Жук, три пары лапок и фасеточные глаза :))
По 2 части я не понял, что это за СОС. Знаю только СОС, который публикуется ЦС в соответствии с настройками CDP.
1. Сертификат sysadmina, если он выпускался Вами для компьютера Windows 8, выпущен как корневой:
Минимум же, первым в цепочке в Путь сертификации, должен быть SERVER-CA.TC-SOTKA.INT.
2. Список отзыва данного Вами сертификата, не доступен по указанному в сертификате адресу:
Выпущенный Вами сертификат для Windows 8, на этом компьютере в таком случае должен быть установлен в Корневые центры сертификации и Личные Сертификаты.
На компьютере Клиенте с Windows 7, он должен быть установлен в Корневые центры сертификации, список отзыва сертификатов для которых, не проверяется. Что неправильно.
Да, я Жук, три пары лапок и фасеточные глаза :))
1. Меня тоже сначала это смутило, но на компьютере с Windows 8 (сразу) и на компьютере с Windows 7 (после добавления сертификата ЦС в корневые доверенные) путь сертификации выглядит вот так https://www.dropbox.com/s/bxiyskoa0kgmvdy/2.jpg Как писал ранее, сертификат для Windows 8 запрашивался через оснастку сертификаты, там небыло иного выбора как запросить сертификат по шаблону Компьютер (Machine).
2. Он недоступен у Вас, потому что это внутренний адрес. В данный момент решил вопрос добавлением записи в файл hosts. У клиента доступ к сайту по имени работает.
Внимательно изучите серию статей:
Да, я Жук, три пары лапок и фасеточные глаза :))
Именно по этой статье я настраивал публикацию СОС.
Сегодня установил онлайн ответчик, с ним проверка сертификата отрабатывает корректно. Очень жаль, что так и не получилось довести до ума проверку СОС по HTTP, придется что-то делать с клиентами на Windows XP.
Жук, спасибо за желание помочь и с наступающим.
Ради интереса попробуй следующие:
В IIS manager, в настройках сайта для CRL, найдите Request Filtering:
Зайдите туда и справа будут Actions, нажмите там Edit feature settings. Откроется окно как на картинке, выставите там галку Allow double escaping
И посмотрите изменится ли что-то для машин с Win XP.
Именно по этой статье я настраивал публикацию СОС.
Сегодня установил онлайн ответчик, с ним проверка сертификата отрабатывает корректно. Очень жаль, что так и не получилось довести до ума проверку СОС по HTTP, придется что-то делать с клиентами на Windows XP.
Жук, спасибо за желание помочь и с наступающим.
Взаимно, так же с наступающим новым годом.
У нас, есть хорошее правило: «Никогда не опускать лапки. «. Так что, могу только порекомендовать, передохнуть, выпить чашечку кофе, принять ванну :)), и засучив рукава, с новыми силами, всё же постараться разрешить эту проблему.
Да, я Жук, три пары лапок и фасеточные глаза :))
Жук, привет. Есть вопрос.
Сразу скажу что пока силен в вопросе слабо, но головняк уже поймал:
Есть пара машин вне домена + RDS доменный. вопрос вот о чем:
1я машина (ipsec + WIN 8.1) DNS конечно не понимает, поэтому по ip к RDS(генерированный фаил с rds), предлагает убедится в надежности издателя и дает запрос на лог/пас домена. Далее сертификат RDP, предупреждение:
«Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности». И вот проблема: «Не удается проверить не был ли отозван сертификат». В целом не велика, так как это всего лишь предупреждение и жить бы можно. НО хочется по уму. Сертификат тот же самый что предлагается вначале всего для того чтоб убедиться что подключение доверенное(ну зрительно, CA добавлен в доверенные корневые центры сертификации).
Как я и говорил и сам не ас. Поэтому буду очень рад ответам. И если заодно посоветуешь где на клиенте более подробные логи этого всего посмотреть буду очень благодарен?
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
Итак, сертификат 61619b9c000000000013
а что у вас ссылка на CRT делает в расширении OCSP? Как минимум из-за этих ошибок у вас неполная цепочка сертификатов.
корневой сертификат этой цепочки (сервера DGET-CA) у вас не установлен в доверенные центры сертификации компьютерного хранилища.
61619b9c000000000013 — нужно удалить. Корректно настроить расширение AIA на издающем CA и выпустить новый сертификат.
61fb04be000000000017 — сертификат сервера DGET-CA нужно установить в доверенные центры сертификации компьютерного хранилища.
на самом деле, не знаю, чего она там делает =) сертификат сервера стоял и стоит в доверенных центрах удалённой машины.
переделал сертификаты. собственно, ничего не поменялось, ошибка та же:
Ошибка подключения к удаленному рабочему столу из-за невозможности проверить подлинность удаленного компьютера. Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным. Имя в сертификате от удаленного компьютера: msk-db01.msk.dget.ru. Не удалось проверить, не был ли отозван сертификат. Продолжение невозможно из-за серьезных ошибок сертификатов.
Поставщик:
CN=DGET-CA
DC=msk
DC=dget
DC=ru
Субъект:
CN=compas.myftp.org
Серийный номер сертификата: 613796c600000000001d
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)
Поставщик:
CN=DGET-CA
DC=msk
DC=dget
DC=ru
Субъект:
CN=msk-db01.msk.dget.ru
Серийный номер сертификата: 613f693700000000001e
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)
Не удалось проверить не был ли отозван этот сертификат rdp windows 7
В Интернете встречаются вопросы про проблемы подключения через RDP к серверу терминалов защищённому SSL сертификатом. При подключении пользователи видят:
И сообщение: A revocation check could not be performed for the certificate. В переводе — Не удалось проверить не был ли отозван этот сертификат. А если нажать на View certificate… выясняется, что всё в порядке, сертификат доверен и цепочка построена правильно. Что это такое и как с этим жить?
Причины здесь может быть 2:
1 Вариант
•Корневой сертификат цепочки сертификатов не установлен в Trusted Root CAs в *Компьютерном* хранилище сертификатов;
Эта проблема встречается примерно в 70-80% случаев появления этой ошибки. Многие привыкли устанавливать корневые сертификаты по двойному клику в пользовательское хранилище. Но, новый 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. Следуйте инструкциям мастера для добавления корневого сертификата в компьютерное хранилище.
2 Вариант
•Какие-то CRL’ы в цепочке недоступны.
Когда сертификат выдаётся внутренним CA, но пользователи подключаются к серверу через интернет (например из дома подключаются к RemoteApp по https), очень часто файлы сертификатов и CRL’ы издающего CA недоступны из интернета. В данном случае необходимо связаться с Системным Администратором, чтобы он переконфигурировал расширения CDP так, чтобы CRL’ы были доступны и из интернета.