Microsoft`s Silent Trusted Root Authority update is Invalid?

I was going though my Event Log today and spotted over 5000 CAPI2 (Crypto API) Errors, generating anywhere from 5-20 new errors every hour going back to November it seems...

After some quick checking it seems the Trusted Root Certification Authority list is not updating correctly :huh:

For anyone who doesn't understand what the Trusted Root Certification Authority List is about or why this list is a crucial cornerstone of everyday internet use heres a excerpt from Microsoft`s documentation:

Root certificates are updated on Windows XP, Vista and all earlier versions of Windows automatically. When a user visits a secure Web site (by using HTTPS SSL), reads a secure email (S/MIME), or downloads an ActiveX control that is signed (code signing) and encounters a new root certificate, the Windows certificate chain verification software checks the appropriate Microsoft Update location for the root certificate. If it finds it, it downloads it to the system. To the user, the experience is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically, behind the scenes.
Root certificates are also delivered for Windows XP and earlier. Root Updates are cumulative, so it should only be necessary to install the latest one to receive all root certificates in the Program.
Whether a user, or “relying party”, should trust a root certificate for any particular purpose can be a difficult question. CAs must be on guard against issuing certificates to people who put them to bad use, such as signing malicious software to make it seem more acceptable. CAs should have effective revocation policies and procedures to adequately deal with such certificates. Also, users are expected to scan a CA’s Certificate Practice Statement (CPS) before deciding to trust a certificate - to ensure that acceptance would not cause undue risk to a user’s security, for example. Such documents can be hundreds of pages long though, making user trust decisions complex. Microsoft’s role is to assess CAs and qualify them according to the Program requirements before enabling distribution of their root certificates.

Basically, Microsoft periodically updates the list with the latest Certificate Authorities used for Verifying the SSL certificates used by your bank, ebay, paypal and thousands of other websites using SSL certificates and also updates the list of banned certificates being used for Malware, fraudulent websites or other certificates being misused (Like these two: VeriSign issues false Microsoft digital certificates)


The latest Update can be downloaded here (URL from the Event Log): http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

After opening the AuthRootstl.cab file you can see the Authroot.stl update list where you can see the latest Trust List Update information...

It seems however that the last Certification update Microsoft released on the 4th of November 2008 was signed using an invalid Internal Windows Code Signing certificate :eek:

Not only did Microsoft use the wrong Certificate to sign the Update, the Trust list of updated certificates itself (viewable from the second tab then under Certificate list) has a few hundred invalid and missing CA entry's :eek:

Interestingly, when I downloaded this list on Windows 7 it had an equally destroyed Update List signed at 11:50PM the night before the Vista Update List was signed the next day at 9:50AM, they both have the same hash and thumbprint but have different signing dates (How is that even possible? ) There is also no information about the CAPI2 errors found in the Windows 7 event-Log...

It begs the following questions:

1: Why hasn't this problem be reported by anyone, anywhere else before I spotted it?

2: If the Trusted Root Update did manage to update your local system is it safe to assume the entire system`s Root Certification Store is more or less 'compromised' meaning every website using SSL, every e-mail using signing, encrypted file or anything and everything using a certificate issued by a Trusted Root Certification Authority can no longer be guaranteed or verified on your system? (affecting every Version of Windows including Windows 7)

3: Since its accumulative does that mean all current entries are overwritten with each new update? (incase a system did get this failed update is it ok to continue using without having to format the system?))

4: How does the certificate signing timestamp change between Windows 7 and Vista for the same download?

5: Why does the latest Manual update only support XP? (It seems to install but it doesn't display any information about Vista support or even if it installed sucessfully) (https://www.microsoft.com/downloads...0e-ee7e-435e-99f8-20b44d4531b0&DisplayLang=en)

6: Since theirs no CAPI2 related event-log information on Windows 7 does this mean this update is being installed on Windows 7 successfully or failing silently?

7: How did this pass their internal testing guidelines before whomever reasonable was able to release it and why hasn't it been fixed in nearly two months?

Can anyone else confirm what I have mentioned or does anyone have some more information, thoughts or ideas about this problem so I can report this to Microsoft?

Steven

(P.S. Merry Christmas for yesterday and Happy New Year for next week )

 

[jgveill]

Hi,

I'm still searching ... I set my clock back to April 28th 2009. As expected, no more errors and very fast boot. Then I dowloaded the authroot.stl file with the link we have in the CAPI2 errors.

- I clicked on the file. A window opened with " this certificate trust is not valid. The certificate that signed the list is not valid. ". I did nothing with the file and I'm informed it's not valid. Something must really be wrong with the file.

- I clicked on "View Signature". We see that Signing time is May 1st 2009. We can also see : "this certificate is not valid for the requested usage". It's valid from April 11th 2009 to July 11th 2010.

- I clicked on "view certificate". The information we have here is certainly relevant : " the certificate is not valid for the selected purpose ". We have that message for the second time ! It's like we are trying to do something with the wrong file ! Anyway, I decided to click "install certificate". A wizard opens.

- I clicked next

- As I'm not an expert, I took the default choice (Automatically select the certificate store based on the type of certificate). I Clicked next

- We then see the choices we made. I Clicked "finish".

- Surprise : The import was successfull.

I was not too confident that the problem was solved because I was told I didn't have the right file. Boot without changing the date gave no errors. As soon as I set today's date .. CAPI2 errors were back. Il will find what is the trigger date between April 28th and today, it could be usefull.

As the file was properly imported, we can think it should work.

I would be curious to see someone not having CAPI2 errors doing this exercise (do a system restore point before just in case). Will he have the same information on the fact that it's not the right file ???

Meanwhile, for us having the errors, I can see few options :

1- If the file is the good one, then we have other wrong settings somewhere that corrupt the install or validation process.
2- We have other certificate(s) somewhere that was/were not updated and the update process we are using is not the good one. We are just trying to update the wrong certificate(s). No surpise that we are not successfull ...

By the way, following the certificate update, other errors appeared in the CAPI2 log : 2 additional errors related to Microsoft Certificate Trust List Publisher are coming from rundll.32. Some certificates seemed to be accepted, others are not valid for the required usage.

Other thoughts ?

Thanks Jean