Windows 8.1 / 2012 Atualização 1 e WSUS

Question

Atualizei alguns dos meus hosts de teste para a Atualização 1 ( KB2919355 ).

Agora, eles não podem mais verificar o WSUS ( 0x80072F8F )

OK, fácil você diz! A Microsoft corrigiu esse problema e avisou-o .

Agora, para a parte mais difícil. Meu servidor WSUS está sendo executado no 2012 R2 e tem o TLS 1.2 ativado - não devo ser afetado.

Ainda mais estranho, eu instalei a atualização corrigida que supostamente consertou o problema. Por segurança, tentei instalar a atualização KB2959977 mencionada no artigo KB acima. Resultado: esta atualização já está instalada.

Então, eu estou perdido aqui :) Alguém mais tem o mesmo problema? Alguma sugestão? Será que a Microsoft estragou tudo isso?

    

Answer 1

Tinha realmente a ver com Certificados.
Depois de instalar KB2919355 , parece que os certificados são examinados mais de perto, especialmente a CRL.

Tivemos que diagnosticar isso usando:

Diagnóstico

Limpar caches de revogação executando esses comandos como admin

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

Inicie o rastreamento de rede executando este comando como admin:

netsh trace start scenario=InternetClient

Ativar o registro CAPI2 do Visualizador de Eventos:

Abrir 'Visualizador de Eventos'
Navegue para "Registros de aplicativos e serviços" > Microsoft > Windows > CAPI2 > Operacional.
Clique com o botão direito do mouse em 'Operacional' na árvore de diretórios e selecione 'Ativar registro'

Analise o Windows Update público usando a interface do usuário (miniaplicativo do Painel de controle ou Configurações do PC) e deixe-o falhar.

Execute este comando como admin e ele produzirá um arquivo NetTrace.cab:

netsh trace stop

Volte para o Visualizador de Eventos e exporte os eventos do CAPI2 clicando em "Salvar todos os eventos como ..."

Análise

Hi MichelZ, your case is different from others. It was an actual, non-network related, revocation failure. There seems to be a misconfiguration on either the certificate or CRL. Presence of event 42 with error on Call_CertIsValidCRLForCertificate indicates that "IDP in the CRL is Not Valid for the Subject Certificate". See http://technet.microsoft.com/en-us/library/cc749296(v=ws.10).aspx.

Our guess is that the Certificate Distribution Point (CDP) field in your end/leaf cert does not contain the same URL as the one in CRL's Issuing Distribution Point (IDP) field. Hope this helps. Thank you.

De fato, eu dei uma olhada no CDP da CRL do certificado e no campo IDP da 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

Um foi escapado e um não foi.

(Cortesia este tópico nos fóruns do TechNet)

Solução também conhecido como TL; DR

A solução no meu caso foi bem simples. Eu regenerado o WSUS IIS Certificate, e ele magicamente tem a URL correta do CDP da CRL.
Na verdade, agora tem as duas URLs:

[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)

Depois disso, a verificação contra o WSUS funciona perfeitamente bem novamente.

    

Answer 2

Verifique sua cadeia de certificados em busca de certificados com o algoritmo de assinatura MD5 ou SHA512. O TLS 1.2 não suporta mais o MD5. A implementação da Microsoft do TLS 1.2 não suporta o SHA512 por padrão. Dê uma olhada:

link