I was asked recently to look at a couple of support cases that had been logged where installations of our Application Manager and Performance Manager products were failing. The logs from the failed installations, obtained from invoking msiexec with the /l*vx syntax, gave the following error:
(Error code 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.)
A web search for the error gave many matches which didn’t really help so I then tried to reproduce the error in a Windows Server 2003 x86 virtual machine but the installation worked fine, as it usually does. Analysis of the msiexec log from the failing system indicated that the error was occurring when installing our signed device drivers. So next I ran the great Process Monitor tool from SysInternals, now Microsoft, to try and understand what was happening, file system and registry wise, during the installation, particularly around the area where the msiexec process installs the device drivers.
What this showed me was immediately before our driver catalog (.cat) file was read, the “State” registry value in the following key was being read:
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing
Given the error text from the failed installation, this looked relevant. A quick web search threw up a number of interesting articles, namely:
http://msdn.microsoft.com/en-us/library/aa388201(VS.85).aspx
and
http://blogs.msdn.com/spatdsg/archive/2006/06/05/618082.aspx
which led me to try changing the “state” value in the registry in my test VM from 0x23c00 to 0x40000 (WTPF_ALLOWONLYPERTRUST as per the MSDN link above and the wintrust.h header file so effectively much more restrictive than what was in this value by default).
Retrying the previously successful installation in my test VM then gave exactly the same error that our customers had been experiencing. On passing this information on, both customers confirmed that their “state” registry values were either not as per the default or were missing, due to the parent key being absent, and that setting the “state” value to the default allowed the drivers to be successfully installed.
Case(s) solved! But this leaves me with the desire to know what caused this to happen, particularly as we have had two cases from different customers logged so closely together, given that I stopped believing in coincidences many years ago. This is the main reason for me blogging about this issue – I hope that by the power of search engine indexing that if others suffer this issue then they will be brought here and their problem solved.
Guy Leech
10th Feb 2010
AppSense 
We’ve been experiencing the same issues with our own drivers. We are trying to repackage things into MSIs so we can deploy via Group Policy… in the past we had no issues going through the installer executable. But Now we are trying to self-sign our driver, then just use the certificate to allow our domain to trust ourselves, and then build the MSI to install the driver via the inf file.
No go. We get this error. But our registry has the proper, more permissive value. Regardless of which VM we try on, it isn’t allowing it with that error.
So can you give me a pointer in the right direction? Here’s our certificate generation/signing information:
1) Make the catalog file from the inf:
Inf2Cat.exe /driver:”c:\PathToDriver” /os:XP_X86
(the inf file worked always, so we used it to make our cat file)
2) Make the self-signed certificates:
makecert.exe -r -n “CN=OUR_NAME” -b 05/10/2010 -e 05/10/2099 -eku 1.3.6.1.5.5.7.3.3 -sv selfcert.pvk selfcert.cer
cert2spc.exe selfcert.cer selfcert.spc
pvk2pfx.exe -pvk selfcert.pvk -spc selfcert.spc -pfx selfcert.pfx
Then I import in the .cer, .spc, and .pfx files into the (auto found) certificate stores.
3) Sign the .cat file for the driver
“%SDK_Path%\signtool.exe” sign /fmycert.pfx /d “” /t “http://timestamp.verisign.com/scripts/timestamp.dll”
4) Verify the .cat file (signtool verify /pa myfile.cat)
and all looks good up to this point.
So I then manually check the .cat file and it all looks great, certificate lists our info, etc. Nope. Won’t work. Always gives me the error you listed in your article.
So my question is, concerning the .cat file and signing the drivers, are we missing a step? Our drivers are just a dll and a .sys file (again, the inf has worked for years). So it MUST be how we are signing it. Any suggestions? Surely there is a way to sign a driver without PAYING someone for a spc! (and no, this is in house drivers… otherwise we’d by the spc and get it WHQL certified to ship out…)
Thanks so much!