Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

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:


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 …”


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.

share|improve this answer

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:


share|improve this answer
It did work before the KB2919355 update. All certs in the path are sha1 –  MichelZ Apr 23 '14 at 12:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.