Windows 7 не удалось проверить не был ли отозван этот сертификат

Не удалось проверить не был ли отозван этот сертификат rdp windows 7

Question

Ошибка «Не удалось подключиться к удалённому компьютеру, поскольку сертификат сервера шлюза удалённых рабочих столов отозван или просрочен».

При этом Windows 10 (8, 7) этот сертификат (выданный доменным Центром сертификации) не просрочен и подключение в этих ОC происходит без проблем. В хранилище Доверенные корневые центры сертификации (локальный компьютер) сертификат доменного ЦС есть.

Списки отзыва актуальные, серийного номера сертификата шлюза в них нет.

Пока нагуглил, что какие-то проблемы с Службой времени Windows в этой ОС. В Просмотре событий очень много 158 кодов про ошибку VMICTimeProvider. Вместе с тем, время в трее показывается актуальное, синхронизация с сервером времени time.windows.com происходит успешно.

Кто-нибудь сталкивался с подобной проблемой? Нашлось решение?

Буду признателен за любую помощь по существу проблемы.

Answers

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Скорее всего на WIN11 старый TLS запрещен или его можно включить.

Спасибо за наводку! Включил TLS v.1 согласно этой статьи (выполнил пункты 3.1 и 3.2) и тоже всё заработало. ОГРОМНОЕ Спасибо!
Конечно, со временем будем переходить новые серверные ОC.

Спасибо добрый человек, но чтоб долго не искать напишу тут, нужно создать reg файл с содержимым, добавить в реестр и перезагрузиться:

Спасибо, что ответили. Я уж думал, что я один с такой проблемой столкнулся. Я создал обращение в техподдержку MS, сегодня ко мне подключались специалисты, смотрели и недоумевали, обещали подключить спецов уровнем выше.
Можно поинтересоваться, а какая у Вас версия Windows на Шлюзе удалённых рабочих столов? У меня 2008R2.

Есть такая же проблема, шлюз 2008R2. На самом деле по ошибкам time-service мы ничего не определим т.к. на ОС Win10 они точно такие же, но при этом все прекрасно работает.

Как бы товарищи из Microsoft не предложили обновляться до 2016.

Как бы товарищи из Microsoft не предложили обновляться до 2016.

Спасибо Вам за Ваш вопрос.

2. Убедитесь, что URL-адрес rdweb работает нормально.

3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?

4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.

Спасибо Вам за Ваш вопрос.

2. Убедитесь, что URL-адрес rdweb работает нормально.

3. Выдан ли сертификат шлюза удаленных рабочих столов доверенным государственным органом, например Thawte, GeoTrust, Comodo, GoDaddy, DigiCert и т. Д., Или он из другого источника, например внутреннего центра сертификации?

4. Также это может произойти, если время клиентского компьютера и время RD Server не синхронизированы. Если у вас есть домен AD, они синхронизируют время с вашим контроллером домена PDC для всех ваших серверов и клиентских ПК.

Источник

Не удалось проверить не был ли отозван этот сертификат 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

Итак, сертификат 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

Frage

Antworten

Привет!, а Вас не смутило, то что Вы допустили две ошибки:

-вопросу уже более полутора лет;

-Автор вопроса, не Вы.

Правильнее задавать свой вопрос, указывая ссылкой на это обсуждение вопроса.

Начните с внимательного изучения серии статей, начав со статьи «Краткое руководство по Microsoft PKI». Особое внимание обратите на требование для Внешних Пользователей, и Корневой сертификат, должен быть подписан Доверенным корневым центром сертификации.

Да, я Жук, три пары лапок и фасеточные глаза :))

Alle Antworten

Да, я Жук, три пары лапок и фасеточные глаза :))

Да, я Жук, три пары лапок и фасеточные глаза :))

Сертификат запрашивал с компьютера с 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)

Источник

На компьютере поймал интересную ошибку, на новой установленной винде пытался подключиться к удаленному серверу но при подключении вылетала ошибка:

не удалось проверить не был ли отозван этот сертификат

И все бы ни чего, но сертификаты были прогружены на данной машине и помещены в корневые центры сертификации и тут ошибка была именно на стороне клиента, а не сервера потому как с других машин из сети все работало.

И может кому это пригодиться, но мне помогло только одна вещь!

Данную проблему я вылечил следующим способом:

1 вариант

1. На клиентском компьютере установить сертификаты не только с привязкой к конкретному пользователю, но и с привязкой к локальному компьютеру. Если пользуемся Windows 7, то оснастку mmc необходимо запускать от имени администратора.
2. На клиентском компьютере убедиться, что установлена вся цепочка сертификатов. И каждый — в нужное хранилище (в личные сертификаты, в доверенные корневые центры сертификации) и не забываем про п.1.
3. Убедиться в доступности всех CRL из цепочки сертификатов.

2 вариант

1. открываем реестра regedit
2. открываем ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaCredssp
3. создаем в ней значение UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors
4. типа DWORD — со значение 1
5. перезагружаем комп и проверяем

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

И сообщение: 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’ы были доступны и из интернета.

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

• Certificate Chaining Engine — как это работает
• Certificate chaining engine в PowerShell (часть 2)
• CRL Distribution Points и Authority Information Access
• Планирование расширений CDP и AIA

---

Купили сертификат для домена, загрузили в сервер Exchange 2016. А сервер пишет:

Не удалось проверить отзыв

Пример загрузки PFX сертификата Fabrikam.pfx с паролем «P@ssw0rd1»:

Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes('\FileServer01DataFabrikam.pfx')) -Password (ConvertTo-SecureString -String 'P@ssw0rd1' -AsPlainText -Force)

https://docs.microsoft.com/ru-ru/exchange/architecture/client-access/import-certificates?view=exchserver-2016

Почему это произошло?

Такая ошибка произошла потому, что Exchange сервер не имеет доступ в Интернет и не может проверить состояние сертификата, отозван он или нет.

Что делать?

Во-первых, можно ничего не делать. Ну не проверяется отзыв, да и ладно. При невозможности проверить отзыв сертификат считается действительным.

Во-вторых, можно дать серверу Exchange доступ в Интернет. Тогда Exchange сможет проверить списки отзыва. Но иногда нет возможности дать серверу доступ в Интернет, можно только открыть доступ к конкретным доменам. Для этого требуется определить, куда Exchange полезет, чтобы проверить отзыв сертификата.

CRL и OCSP

Если сертификат становится больше не нужен, если скомпрометирован закрытый ключ сертификата, если требуется отменить действие сертификата, то в этом случае сертификат отзывают. Exchange имеет механизм проверки сертификата на отзыв.

CRL и OCSP — это 2 модели, которые могут использоваться для проверки сертификата на предмет его отзыва.

Модель CRL используется с самого начала существования PKI и работает так. Сервер CA при отзыве сертификата помещает о нём запись в специальный файл CRL. При этом туда помещается серийный номер сертификата, дата отзыва и причина отзыва. Клиенты при проверки сертификатов скачивают эти CRL и проверяют есть ли серийный номер этого сертификата в CRL.

В OCSP используется немного иной принцип. Клиент OCSP отправляет на сервер OCSP Responder специальный запрос, в котором содержится серийный номер проверяемого сертификата. OCSP Responder отвечает клиенту откликом: отозван или не отозван.

Оба метода могут использоваться одновременно. Exchange не успокоится, пока не проверит их оба. Наша задача: найти все домены (ссылки) CRL и OCSP нашего сертификата и добавить их в Firewall, чтобы разрешить к ним доступ серверу Exchange. Точнее даже не сертификата, а цепочки сертификатов.

Открываем наш сертификат на просмотр. Я использую формат CRT.

Проверяем, что это именно тот сертификат, который нам нужен. Он действителен. Выдан RapidaSSL. Переключаемся на вкладку «Путь сертификации».

Корневой центр сертификации DigiCert. Но нам нужен промежуточный, тот что нам выдал сертификат (если их несколько, то понадобятся все). Выбираем его. Просмотр сертификата.

Переходим на вкладку «Состав» и выбираем «Доступ к информации о центрах сертификации». И видим протокол определения состояния сертификата через сеть, где указано дополнительное имя OCSP, в данном случае:

• http://ocsp.digicert.com

Разрешаем туда доступ серверу Exchange.

Выбираем «Точки распространения списков отзыва (CRL)». И видим все пути к CRL, у меня это:

• http://crl3.digicert.com/DigiCertGlobalRootCA.crl
• http://cr4.digicert.com/DigiCertGlobalRootCA.crl

Разрешаем туда доступ серверу Exchange. Выполняем на сервере Exchange в командной строке:

certutil -urlcache ocsp delete 
certutil -urlcache crl delete

Перезагружаем сервер Exchange и отправляемся пить чай.

Теперь сертификат «Допустимый».