Installation failed with error code: (0x800B010B), "Generic trust failure”
Microsoft .NET Framework 4.0 Updates/Patches might fail during installation with the following error message "Generic trust failure."
As per the install failure log:
c:\4048b65f65ff4dcceb\NDP40-KB2656405.msp - Signature verification for file NDP40-KB2656405.msp (c:\4048b65f65ff4dcceb\NDP40-KB2656405.msp) failed with error 0x800b010e (The revocation process could not continue - the certificate(s) could not be checked.)
[8/9/2012, 9:55:26] c:\4048b65f65ff4dcceb\NDP40-KB2656405.msp Signature could not be verified for NDP40-KB2656405.msp
[8/9/2012, 9:55:26]No FileHash provided. Cannot perform FileHash verification for NDP40-KB2656405.msp
File NDP40-KB2656405.msp (c:\4048b65f65ff4dcceb\NDP40-KB2656405.msp), failed authentication. (Error = -2146762482). It is recommended that you delete this file and retry setup again.
[8/9/2012, 9:55:26]Failed to verify and authenticate the file -c:\4048b65f65ff4dcceb\NDP40-KB2656405.msp
Final Result: Installation failed with error code: (0x800B010B), "Generic trust failure. "
The above error code indicates the below information:
# for decimal -2146762482 / hex 0x800b010e
CERT_E_REVOCATION_FAILURE
# The revocation process could not continue - the
# certificate(s) could not be checked.
First, make sure that the following registry key is set on the system:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State
The DWORD State value is 23c00.
The above value indicates that revocation checks occur when validating the Authenticode digital signatures on downloaded programs and ActiveX controls. You can find the settings from IE browser:
ToolsàInternet OptionsàAdvanced tab, you will find the two options which control revocation checking. Check for server certificate revocation controls whether revocation checks occur for HTTPS connections. Check for publisher’s certificate revocation controls whether revocation checks occur when validating the Authenticode digital signatures on downloaded programs and ActiveX controls.
Next Step,
It is possible that the system does not have a cached CRL for this certificate if it has never seen the certificate before or if the URL cache was explicitly deleted. So running signtool /verify will populate the cache with the CRL for the cert and allow the install to proceed.
Try running the below command:
C:\WINDOWS\system32> signtool.exe verify /pa C:\Users\NDP40-KB2656405-x64.exe
In my scenario, I received the below error message:
SignTool Error: WinVerifyTrust returned error: 0x800B010E
The revocation process could not continue - the certificate(s) could not be checked.
I did CAPI2 Diagnostics; CAPI2 Diagnostics is a feature in Windows Vista + OSs that utilizes the event logging and Event Viewer to provide better logging and troubleshooting capabilities for PKI applications based on the CAPI2 API set. This link https://technet.microsoft.com/en-us/library/cc749296(WS.10).aspx shows all the details of enabling CAPI2 logs.
After analyzing the log, I found that it was due to incorrect or missing CDP URLs. In order to resolve the issue, try running the below commands:
C:\Windows\System32\certutil.exe -urlcache -f https://crl.microsoft.com/pki/crl/products/CodeSigPCA.crl temp.crl
C:\Windows\System32\certutil.exe -addstore CA temp.crl
The chain building/verification code looks in the machine context intermediate CA cert store for relevant CRLs. The above commands fetch the current CRL from the target URL and install it in this cert store to make it available for cert chain verification.
If the CDP URLs in a cert are incorrect or absent, then this is the only way to make the CRL available.
If there is a cert being verified that has incorrect or missing CDP URLs, and if the cryptographically correct CRL is stored at the below http URL, then certutil –urlcache with the –f option can be used to fetch the CRL currently available at that URL so it can be added to the intermediate CA cert store as a workaround for the incorrect or missing CDP URLs.