Microsoft-Windows CAPI2 failed extract of third-party root list from auto update cab

I think a lot of the confusion surrounding this problem is becuase many of us are solving our individual cases of why/when the authrootstl.cab file is getting called. In have seen enough scenarios in this thread and others on the web to make me think that this authrootstl.cab file gets called/referenced many different times for different reasons. Therefore, many of the posted "solutions" that involve doing something on the client do not usually work for other users who are in a different situation. I still believe that there is a fundamental problem with the authrootstl.cab file itself (http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab). If you manually download this file, extract the contained authroot.stl file, double-click on it to view it, then you will see that it is "invalid".

I'm probably wrong, but it seems that if we (i.e. Microsoft) could fix this underlying issue, then maybe all of our individual problems would go away.

Thanks,

P.S . Here are the steps to download, extract, and view the file in question.

1) Go to http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab and download this CAB file to your local computer.

2. Open the CAB file and extract the authroot.stl file to your local computer.
3. Double-click on the STL file. I'm assuming, near the top, you will see the following: "This certificate trust list is not valid. The certificate that signed the list is not valid."

I think all the other solutions I've found ... except the one I posted about cleaning the root files and registry entries .... treat the symptoms, not the problem.  Turning off ISA restrictions, virus scans, etc, all create their own problems.  In fact, I had turned off McAfee for a short time to test the problem myself.  But that's not a realistic solution because it doesn't treat the root problem of bad certificate authority lists and creates real security threats.

I'm thinking that the root authority file itself may contain a corruption of some sort that MS definitely should fix.  My guess is that since it is not causing critical problems for folks and they are unlikely to remedy it.

If you are uncomfortable messing with the registry, you can probably ignore the error and move on.  This is probably no issue for home users of Vista.  If you like your machine logs to look nice and clean, the registry and file deletion may be the only remedy that you ever see.  Just make sure you do backups before you go down that road.  I don't have a lot of faith that MS is going to do anything about it since its been so long since the problem started.

I have a 2008 domain controller that is having this error and I'm hesitating to apply this remedy.  I will probably demote it from its role before attempting it, just to be safe.  It does not have any of the major FSMO roles, so I can do that.  But I don't want to see that error in reports for the next few years that server is running.

From another forum:

---

Based on my research, the issue can be caused by corrupted certificate data on the server. I suggest you try the following steps to test the issue:

1. Backup and delete the contents of the following folders:

C:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\ContentC:\Windows\System32\config\systemprofile\AppData\LocalLow\Microsoft\CryptnetUrlCache\MetaData

2. Backup and delete the certificates listed under "Certificates" key:

HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\AuthRoot\Certificates

Then, restart the server to check the result.

I did this on one of the servers on which I have an error.  

Let me stress this...  DO THE BACKUPs IT MENTIONS AS MESSING WITH THE REGISTRY CAN HAVE VERY SERIOUS SIDE EFFECTS.

I have been struggling with this issue for about 3 months on 4 2008 servers, some physical and some VMs. 

I deleted the folders as suggested by Kevin Zhao above.  After a reboot, I now get CAPI2 eventID 13 Informational messages stating:  Successful auto property update of third-party root certificate...etc.

I'm going to continue to monitor the server on which I attempted this remedy.  If it holds, I think we have a winner.

---

I can confirm that this indeed works (at least in my scenario). I've stumbled on the problem on 32-bit Vista SP2. According to CAPI2 log in the Event Log infocard.exe was responsible for the failed attempt to update the certificates. Every time I would start the Windows Cardspace service the error would be logged. The issue didn't occur on a fresh install of Windows Vista (SP2, root certificates updated to May 2009) on a virtual machine. I figure that even though viewing the STL file from the CAB does show that "it's not valid" - it's not the issue. After reboot the root certificates where automatically updated without any problem (just in case I've downloaded the root certificates from May 2009 as mentioned in this thread earlier)

I've tried the above solution. And it worked (at least so far).

Thank you very much for posting this.