Windows 8.1/2012 Update 1 & WSUS

▲
2
▼

I've updated some of my test hosts to Update 1 (KB2919355).

Now, they cannot scan against WSUS anymore (0x80072F8F)

OK, easy you say! Microsoft patched that issue, and warned about it.

Now to the harder part. My WSUS Server is running on 2012 R2, and has TLS 1.2 enabled - I should not be affected.

Even weirder, I've installed the corrected update which is supposed to have fixed the issue. To be safe, I tried installing the Update KB2959977 mentioned in above KB Article. Result: This update is already installed.

So, I'm at a loss here :) Does anyone else have the same problem? Any suggestions? Did Microsoft screw this really up?

wsus
windows-server-2012-r2
windows-8.1
asked on Server Fault Apr 18, 2014 by MichelZ

2 Answers

▲
1
▼

Check your certificate chain for certificates with signature algorithm MD5 or SHA512. TLS 1.2 no longer supports MD5. Microsoft implementation of TLS 1.2 does not support SHA512 by default. Have a look:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/857c6804-8ce1-4f09-b657-00554055da16/tls-12-and-sha512/

answered on Server Fault Apr 23, 2014 by st.he
▲
1
▼

It had indeed to do with Certificates.
After installing KB2919355 it seems that certificates are more closely examined, especially the CRL.

We had to diagnose this using:

Diagnostics

Clear revocation caches by running these commands as 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

Start network tracing by running this command as admin:

netsh trace start scenario=InternetClient

Enable CAPI2 logging from Event Viewer:

Open 'Event Viewer'
Browse to 'Application and Services Logs' > Microsoft > Windows > CAPI2 > Operational.
Right click on 'Operational' in the directory tree, and select 'Enable log'

Scan against public Windows Update using UI (Control Panel applet or PC Settings) and let it fail.

Run this command as admin, and it will produce a NetTrace.cab file:

netsh trace stop

Go back to Event Viewer and export CAPI2 events by clicking “Save All Events as …”

Analysis

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.

Indeed, I had a look at the CRL CDP of the Certificate, and the IDP field of the 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

One was escaped, and one wasn't.

(Courtesy this thread on TechNet Forums)

Solution aka TL;DR

The Solution in my case was pretty simple. I regenerated the WSUS IIS Certificate, and it magically got the correct CRL CDP URL.
Actually, it now has both URL's in it:

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

After this, scanning against WSUS works perfectly fine again.

answered on Server Fault May 8, 2014 by MichelZ

User contributions licensed under CC BY-SA 3.0