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.