Клиенты не могут проверить подлинность на сервере после получения нового сертификата для замены просроченного сертификата на сервере

В этой статье приводится решение проблемы, из-за которой клиенты не могут проверить подлинность на сервере после получения нового сертификата для замены просроченного сертификата на сервере.

Исходная версия продукта: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 822406

Симптомы

После замены сертификата с истекшим сроком действия на новый сертификат на сервере с запущенной службой Microsoft Internet Authentication Service (IAS) или маршрутизацией и удаленным доступом клиенты, для которых настроена проверка подлинности на сервере с помощью EAP-TLS Protocol-Transport, перестают проверять подлинность сертификата сервера. При просмотре системного журнала в средствах просмотра событий на клиентских компьютерах отображается следующее событие.

Если включить подробное ведение журнала на сервере под управлением IAS, маршрутизации и удаленного доступа (например, с помощью команды), в файле Rastls.log, который создается при проверке подлинности клиента, отображаются сведения, аналогичные netsh ras set tracing * enable следующей.

Если вы используете IAS в качестве сервера Radius для проверки подлинности, это поведение будет видно на сервере IAS. Если вы используете маршрутизация и удаленный доступ, а маршрутизация и удаленный доступ настроены для проверки подлинности Windows (не для проверки подлинности в радиусе), это поведение будет по-разное на сервере маршрутизации и удаленного доступа.

[1072] 15:47:57:280: CRYPT_E_NO_REVOCATION_CHECK не будет игнорироваться

[1072] 15:47:57:280: CRYPT_E_REVOCATION_OFFLINE не будет игнорироваться

[1072] 15:47:57:280: корневой сертификат не будет проверяться на отзыв

[1072] 15:47:57:280: сертификат будет проверен на отзыв

[1072] 15:47:57:280: EapTlsMakeMessage(Example\client)

[1072] 15:47:57:280: >> Received Response (Code: 2) packet: Id: 11, Length: 25, Type: 0, TLS blob length: 0. Флаги:

[1072] 15:47:57:280: EapTlsSMakeMessage

[1072] 15:47:57:280: EapTlsReset

[1072] 15:47:57:280: изменение состояния на initial

[1072] 15:47:57:280: GetCredentials

[1072] 15:47:57:280: имя в сертификате: server.example.com

[1072] 15:47:57:312: BuildPacket

[1072] 15:47:57:312: > Received Response (Code: 2) packet: Id: 12, Length: 80, Type: 13, TLS blob length: 70. Флаги: L

[1072] 15:47:57:452: EapTlsSMakeMessage

[1072] 15:47:57:452: MakeReplyMessage

[1072] 15:47:57:452: перераспределение входного буфера BLOB-данных TLS

[1072] 15:47:57:452: SecurityContextFunction

[1072] 15:47:57:671: изменение состояния на SentHello

[1072] 15:47:57:671: BuildPacket

[1072] 15:47:57:671: > Received Response (Code: 2) packet: Id: 13, Length: 6, Type: 13, TLS blob length: 0. Флаги:

[1072] 15:47:57:702: EapTlsSMakeMessage

[1072] 15:47:57:702: BuildPacket

[1072] 15:47:57:702: > Received Response (Code: 2) packet: Id: 14, Length: 6, Type: 13, TLS blob length: 0. Флаги:

[1072] 15:47:57:718: EapTlsSMakeMessage

[1072] 15:47:57:718: BuildPacket

[1072] 15:47:57:718: > Received Response (Code: 2) packet: Id: 15, Length: 6, Type: 13, TLS blob length: 0. Флаги:

[1072] 15:48:12:905: EapTlsSMakeMessage

[1072] 15:48:12:905: MakeReplyMessage

[1072] 15:48:12:905: SecurityContextFunction

[1072] 15:48:12:905: изменение состояния на SentFinished. Ошибка: 0x80090318

[1072] 15:48:12:905: не удалось согласование

Если сертификат имеет несколько доверенных путей сертификации в корневые ЦС, проверка сертификата не происходит

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

Исходная версия продукта: Windows 7 Пакет обновления 1, Windows Server 2012 R2
Исходный номер КБ: 2831004

Симптомы

Когда пользователь пытается получить доступ к защищенного веб-сайта, он получает следующее предупреждение в веб-браузере:

Возникла проблема с сертификатом безопасности этого веб-сайта.

Сертификат безопасности, представленный на этом веб-сайте, не был выдан доверенным органом сертификации.

После того как пользователь нажмет кнопку «Продолжить на этом веб-сайте» (не рекомендуется), он сможет получить доступ к защищенного веб-сайта.

Причина

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

Например, предположим, что клиентский компьютер, который вы используете, доверяет сертификату корневого ЦС (2). Веб-сервер доверяет сертификату корневого ЦС (1) и сертификату корневого ЦС (2). Кроме того, сертификат имеет два следующих пути сертификации к доверенным корневым ЦС на веб-сервере:

1. Путь сертификации 1: сертификат веб-сайта — сертификат промежуточного ЦС — сертификат корневого ЦС (1)
2. Путь сертификации 2. Сертификат веб-сайта — сертификат промежуточного ЦС — сертификат корневого ЦС (2)

Когда компьютер находит несколько доверенных путей сертификации в процессе проверки сертификата, Microsoft CryptoAPI выбирает лучший путь сертификации, вычисляя оценку каждой цепочки. Оценка рассчитывается на основе качества и количества информации, которую может предоставить путь к сертификату. Если показатели для нескольких путей сертификации одинаковы, выбирается самая короткая цепочка.

Если путь сертификации 1 и путь сертификации 2 имеют одинаковый показатель качества, CryptoAPI выбирает более короткий путь (путь сертификации 1) и отправляет путь клиенту. Однако клиентский компьютер может проверить сертификат только с помощью более длительного пути сертификации, ссылаясь на сертификат корневого ЦС (2). Поэтому проверка сертификата не удась.

Обходной путь

Чтобы обойти эту проблему, удалите или отключите сертификат из пути сертификации, который вы не хотите использовать, вы можете сделать следующее:

Войдите на веб-сервер с учетной записью системного администратора.

Добавьте оснастку «Сертификат» в консоль управления Майкрософт, вы предприняв указанные ниже действия.

1. Нажмите >кнопку «Начните запуск»,введите mmc и нажмите ввод.
2. В меню «Файл» выберите пункт «Добавить или удалить оснастку».
3. Выберите «Сертификаты»,«Добавить»,«Учетная запись компьютера» и «Далее».
4. Выберите локальный компьютер (компьютер, на который запущена консоль) и нажмите кнопку «Готово».
5. Нажмите кнопку ОК.

Разойдите сертификаты (локальный компьютер) в консоли управления и найдите сертификат по пути сертификата, который не нужно использовать.

Если сертификат является корневым сертификатом ЦС, он содержится в доверенных корневых цс сертификации. Если сертификат является промежуточным сертификатом ЦС, он содержится в промежуточных сертификационных органах.

Удалите или отключите сертификат одним из следующих способов:

• Чтобы удалить сертификат, щелкните его правой кнопкой мыши и выберите «Удалить».
• Чтобы отключить сертификат, щелкните его правой кнопкой мыши, выберите «Свойства», выберите «Отключить все назначения для этого сертификата» и нажмите кнопку «ОК».

Перезапустите сервер, если проблема еще не возникла.

Кроме того, если параметр групповой политики «Отключить автоматическое обновление корневых сертификатов» отключен или не настроен на сервере, сертификат из пути сертификации, который вы не хотите использовать, может быть включен или установлен при построении следующей цепочки. Чтобы изменить параметр групповой политики, выполните следующие действия.

Нажмите > кнопку «Запустить», введите gpedit.msc и нажмите ввод.

Раз развернуть систему управления подключениями к Интернету для конфигурации компьютера и щелкнуть > > > «Параметры подключения к Интернету».

Дважды щелкните «Отключить автоматическое обновление корневых сертификатов», выберите «Включено» и нажмите кнопку «ОК».

Закроем редактор локальных групповых политик.

Статус

Такое поведение является особенностью данного продукта.

Как устранить ошибку “Windows не может найти сертификат для вашей регистрации в сети” в Windows XP?

Когда вы пытаетесь войти в беспроводную сеть, ваша попытка может завершиться получением сообщения об ошибке следующего содержания: “ Windows не может найти сертификат для вашей регистрации в сети хххх ”

Такая ошибка обычно связана с авторизацией в беспроводной сети, потому что Windows ошибочно ищет соединение 802.1 x . Эту проблему можно устранить следующим образом.

Шаг 1 Зайдите в меню Пуск —> Панель управления

Шаг 2 Дважды щелкните на во всплывающем окне.

Шаг 3 Правой кнопкой мыши щелкните на беспроводное сетевое подключение, затем нажмите Свойства.

Шаг 4 Теперь выберите закладку Беспроводные сети и выберите сеть из списка внизу. Нажмите Свойства, выбрав беспроводную сеть, с которой у вас наблюдается проблема.

Шаг 5 Перейдите на закладку Авторизация и снимите галочку в окошке Включить авторизацию IEEE 802.1 x для данной сети. Если в этом окошке стоит галочка, то вы будете получать сообщение “не найден сертификат для вашей регистрации в сети”, потому что Windows ищет его, однако ваш беспроводной маршрутизатор не настроен на безопасность с помощью сертификатов.

Шаг 6 Зайдите на закладку Подключение и поставьте галочку в окошке Подключиться, когда данная сеть доступна.

Шаг 7 Перейдите на закладку Ассоциация и снимите галочку в окошке Ключ для меня предоставляется автоматически, затем выберите Авторизация в сети и Шифрование данных и введите Network key (сетевой ключ ), который вы настроили на вашем беспроводном маршрутизаторе.

Шаг 8 Нажмите ОК, затем еще раз ОК, чтобы сохранить ваши настройки.

Теперь проблема устранена. Windows может сразу автоматически регистрировать вас в сети.

Если проблемы остались, обратитесь к FAQ или свяжитесь со службой поддержки TP — LINK .

Неожиданная особенность проверки сертификатов в Windows

Немного затянул с публикацией, но лучше поздно чем никогда. В начале рабочей недели появились задержки при подключении по RDP ко всем компьютерам, оно подвисало на несколько секунд в стадии «Securing remote connection. », которая отвечает за установку шифрованного канала для безопасной передачи реквизитов.

Оснастка показала, что всё OK, но напротив обоих CA несколько секунд держался статус Verifying, что странно, так как все данные для проверки доступны внутри домена через LDAP и HTTP. Проверка через certutil -verify также подвисала на 10-15 секунд в стадии CERT_CHAIN_POLICY_BASE, причем с любыми сертификатами — не только от внутренних, но и от внешних CA (StartCom, Comodo и т.д.).

Проблема не ушла и после перерегистрации сертификатов с CRL в CDP и AIA. Отчаявшись, захватил сетевой дамп во время выполнения certutil -verify и увидел там следующее:

Трейс до ctldl.windowsupdate.com показал zapret.comcor.ru в пути, а его IP-адрес (CDN Akamai) оказался добавлен 01.08.2016 в реестр блокировки РКН.

Посмотреть содержимое и проверить состояние CTL можно командами certutil -f -verifyCTL AuthRoot и certutil -f -verifyCTL Disallowed. Также этими командами можно восстановить содержимое хранилища сертификатов.

Списки загружаются с адреса ctldl.windowsupdate.com, но у провайдера сломалась страница-заглушка и соединения к запрещённым ресурсам блокировались по IP-адресу, что вызывало таймаут в 15 секунд при установке каждого соединения.

Подробное описание нового механизма есть на TechNet, для обходного решения таймаут можно задать через групповые политики в разделе Public Key Policies > Certificate Path Validation Settings > Network Retreival:

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

Не удается проверить сертификат windows

Итак, сертификат 61619b9c000000000013

а что у вас ссылка на CRT делает в расширении OCSP? Как минимум из-за этих ошибок у вас неполная цепочка сертификатов.

корневой сертификат этой цепочки (сервера DGET-CA) у вас не установлен в доверенные центры сертификации компьютерного хранилища.

61619b9c000000000013 — нужно удалить. Корректно настроить расширение AIA на издающем CA и выпустить новый сертификат.

61fb04be000000000017 — сертификат сервера DGET-CA нужно установить в доверенные центры сертификации компьютерного хранилища.

на самом деле, не знаю, чего она там делает =) сертификат сервера стоял и стоит в доверенных центрах удалённой машины.

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

Ошибка подключения к удаленному рабочему столу из-за невозможности проверить подлинность удаленного компьютера. Не удалось проверить подлинность удаленного компьютера из-за проблем с сертификатом безопасности. Продолжение может быть небезопасным. Имя в сертификате от удаленного компьютера: msk-db01.msk.dget.ru. Не удалось проверить, не был ли отозван сертификат. Продолжение невозможно из-за серьезных ошибок сертификатов.

msk.dget.ru — это внутренний локальный домен.

Вопрос у меня был в том, что можно ли что-то сделать, чтобы клиент Windows 7 подключался к Server 2008 R2 без ошибок без OCSP и без ключа enablecredsspsupport ?

Поставщик:
CN=DGET-CA
DC=msk
DC=dget
DC=ru
Субъект:
CN=compas.myftp.org
Серийный номер сертификата: 613796c600000000001d

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
——— CERT_CHAIN_CONTEXT ———
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

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)

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
NotBefore: 24.03.2010 11:15
NotAfter: 04.03.2012 11:55
Subject: CN=compas.myftp.org
Serial: 613796c600000000001d
Template: WebServer
2d d5 1a 7b af 6a 66 02 46 a7 0e 4a 22 cc 92 b7 90 cd 6f 30
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
—————- Сертификат AIA —————-
Проверено «Сертификат (0)» Время: 15
[0.0] http://compas.myftp.org/cert/msk-db01.msk.dget.ru_DGET-CA.crt

—————- OCSP сертификата —————-
Отсутствуют URL «Нет» Время: 0
———————————
Application[0] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=20
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
NotBefore: 04.03.2010 11:45
NotAfter: 04.03.2012 11:55
Subject: CN=DGET-CA, DC=msk, DC=dget, DC=ru
Serial: 410e1b7a88eeccb24fc2967adf48eaa4
ff 56 d0 f0 6f 2b 68 68 0c ec 90 9b ee e6 fd 4d 8b 4b 58 78
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)
Element.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)
—————- Сертификат AIA —————-
Отсутствуют URL «Нет» Время: 0
—————- Сертификат CDP —————-
Отсутствуют URL «Нет» Время: 0
—————- OCSP сертификата —————-
Отсутствуют URL «Нет» Время: 0
———————————

Exclude leaf cert:
2d d5 1a 7b af 6a 66 02 46 a7 0e 4a 22 cc 92 b7 90 cd 6f 30
Full chain:
37 2b 3d 2f 0b 4f a6 ba 63 cf 8d 5d de ac cc 9c f7 60 f8 ad
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
NotBefore: 24.03.2010 11:15
NotAfter: 04.03.2012 11:55
Subject: CN=compas.myftp.org
Serial: 613796c600000000001d
Template: WebServer
2d d5 1a 7b af 6a 66 02 46 a7 0e 4a 22 cc 92 b7 90 cd 6f 30
Цепочка сертификатов обработана, но обработка прервана на корневом сертификате, у которого отсутствует отношение доверия с поставщиком доверия. 0x800b0109 (-2146762487)
————————————
Проверка через НЕ ДОВЕРЕННЫЙ корень
Проверка отзыва сертификата выполнена
CertUtil: -verify — команда успешно выполнена.

Поставщик:
CN=DGET-CA
DC=msk
DC=dget
DC=ru
Субъект:
CN=msk-db01.msk.dget.ru
Серийный номер сертификата: 613f693700000000001e

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
——— CERT_CHAIN_CONTEXT ———
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwErrorStatus = CERT_TRUST_IS_UNTRUSTED_ROOT (0x20)
ChainContext.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)

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)

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040
Issuer: CN=DGET-CA, DC=msk, DC=dget, DC=ru
NotBefore: 24.03.2010 11:23
NotAfter: 24.03.2011 11:23
Subject: CN=msk-db01.msk.dget.ru
Serial: 613f693700000000001e
SubjectAltName: DNS-имя=msk-db01.msk.dget.ru
Template: Machine
0e ed f0 fb c0 24 c8 63 ba d1 37 d4 fc 9f f4 83 cf d6 b3 3b
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40)
Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000)
—————- Сертификат AIA —————-
Проверено «Сертификат (0)» Время: 5
[0.0] http://compas.myftp.org/cert/msk-db01.msk.dget.ru_DGET-CA.crt

—————- OCSP сертификата —————-
Отсутствуют URL «Нет» Время: 0
———————————
Application[0] = 1.3.6.1.5.5.7.3.2 Проверка подлинности клиента
Application[1] = 1.3.6.1.5.5.7.3.1 Проверка подлинности сервера