Я обновил некоторые из моих тестовых хостов до обновления 1 (KB2919355).
Теперь они больше не могут сканировать WSUS (0x80072F8F)
ОК, легко говоришь! Microsoft исправила эту проблему и предупредила об этом.
Теперь о более сложном. Мой сервер WSUS работает на 2012 R2 и имеет включенный TLS 1.2 - меня это не коснется.
Что еще более странно, я установил исправленное обновление который должен устранить проблему. На всякий случай попробовал установить Обновление KB2959977 Указанная в вышеуказанной КБ ст. Результат: это обновление уже установлено.
Итак, я здесь в недоумении :) У кого-нибудь такая же проблема? Какие-либо предложения? Неужели Microsoft облажалась?
Это действительно было связано с сертификатами.
После установки KB2919355 похоже, что сертификаты изучаются более внимательно, особенно CRL.
Нам пришлось диагностировать это с помощью:
Очистите кеши отзыва, выполнив эти команды от имени администратора
certutil.exe -urlcache * delete
reg delete "HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate" /v DisallowedCertEncodedCtl /f
reg delete "HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\AutoUpdate" /v DisallowedCertLastSyncTime /fcertutil.exe -setreg chain\ChainCacheResyncFiletime @now
net stop cryptsvc
net stop wuauserv
ipconfig /flushdns
Запустите трассировку сети, выполнив эту команду от имени администратора:
netsh trace start scenario=InternetClient
Включите ведение журнала CAPI2 из средства просмотра событий:
Откройте "Просмотр событий"
Перейдите в «Журналы приложений и служб»> Microsoft> Windows> CAPI2> Operational.
Щелкните правой кнопкой мыши на «Operational» в дереве каталогов и выберите «Enable log».
Сканируйте общедоступный Центр обновления Windows с помощью пользовательского интерфейса (апплета панели управления или настроек ПК) и дайте ему потерпеть неудачу.
Выполните эту команду от имени администратора, и она создаст файл NetTrace.cab:
netsh trace stop
Вернитесь в средство просмотра событий и экспортируйте события CAPI2, нажав «Сохранить все события как…»
Привет, MichelZ, твой случай отличается от других. Это был фактический сбой отзыва, не связанный с сетью. Похоже, произошла неправильная конфигурация сертификата или CRL. Наличие события 42 с ошибкой в Call_CertIsValidCRLForCertificate указывает, что «IDP в CRL недействителен для сертификата субъекта». Видеть http://technet.microsoft.com/en-us/library/cc749296(v=ws.10).aspx.
Мы предполагаем, что поле «Точка распространения сертификатов» (CDP) в вашем конечном / конечном сертификате не содержит того же URL-адреса, что и в поле «Точка распространения выдачи (IDP) списка отзыва сертификатов». Надеюсь это поможет. Спасибо.
Действительно, я взглянул на CDP CRL сертификата и поле IDP в CRL:
CDP URL: http://some.host.com/pki/company Enterprise CA1 - G1.crl
IDP URL: http://some.host.com/pki/company%20Enterprise%20CA1%20-%20G1.crl
Один сбежал, а другой нет.
(Любезно предоставлено этот ветка на форумах TechNet)
Решение в моем случае было довольно простым. Я восстановил сертификат WSUS IIS, и он волшебно получил правильный URL CDP CRL.
Собственно, теперь в нем есть оба URL:
[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://some.host.com/pki/company Enterprise CA1 - G1.crl (http://some.host.com/pki/company%20Enterprise%20CA1%20-%20G1.crl)
После этого сканирование с использованием WSUS снова работает отлично.
Проверьте свою цепочку сертификатов на наличие сертификатов с помощью алгоритма подписи MD5 или SHA512. TLS 1.2 больше не поддерживает MD5. Реализация TLS 1.2 Microsoft не поддерживает SHA512 по умолчанию. Посмотри: