CAPI2 event ID 11 retake
A customer put the following questions to one of my colleagues:
On a lot of our Windows 7 clients we've noticed they periodically try to download a CAB file from Windows Update, but as our workstations are required to access the Internet via Proxy and they aren't able to authenticate against it the download fails and we see Event ID 11 being logged on the clients.
We've downloaded the CAB file and extracted it and we see an error message within the CTL GUI that states "This certificate trust list is not valid. The certificate that signed the list is not valid."
1. Is Microsoft aware of this issue and if so why isn’t the .stl fixed or re-signed?
2. *OR* if the CTL is OK but we have a problem in our environment how do we fix it?
3. Is the CTL update actually needed?
a. If so, why can’t it be distributed on WSUS as every other update?
b. If not, how do we stop computers (clients and servers) from attempting the download?
CAPI2 Event ID 11 is a very generic error message, I wrote http://blogs.technet.com/b/instan/archive/2010/08/12/capi2-event-id-11-errors-on-machines-that-don-t-have-access-to-the-internet.aspx concerning CAPI and Event ID 11 errors some months ago but this particular aspect we're looking at in this case is more related to the CTL GUI than to the actual CAPI2 part.
In short; there are two EKU's that can be used for signing CTL's (from http://support.microsoft.com/kb/287547) - both of them are valid from an RFC-perspective:
szOID_ROOT_LIST_SIGNER
1.3.6.1.4.1.311.10.3.9
Signer of a CTL containing trusted rootsszOID_KP_QUALIFIED_SUBORDINATION [also sometimes referred to as Microsoft Trust List Signing: msCTLSign]
1.3.6.1.4.1.311.10.3.10
Can sign cross-cert and subordinate CA requests with qualified subordination (name constraints, policy mapping, etc.)The problem here is that the CTL GUI expects the EKU 1.3.6.1.4.1.311.10.3.10 to be used while the chain verification code recognizes both 1.3.6.1.4.1.311.10.3.9 and 1.3.6.1.4.1.311.10.3.10 as valid.
The net result of this is a cosmetic issue where the CTL GUI gives an error message that has no other functionality impact or relevance for the OS besides confusing the human observer.
So the net answer to the above questions is No, there is not an issue with the STL file in the cab - the error message is bogus and is caused by the CTL GUI not recognizing 1.3.6.1.4.1.311.10.3.9 as a valid EKU for trust list signing.
....I.e. its a non-issue that is not related to what is causing the actual Event ID 11 to be logged.
The other issue in this case with the error message when attempting to download the CTL is related to the Update Root CA feature of Windows Vista and Windows 7. If the client is unable to download or extract the updated CTL it will log the error message.
The CAB file referenced contains a list of Root CA's that are part of the Microsoft Root CA program - whenever a Windows 7 or Vista client encounters an untrusted Root CA certificate they check with Windows Update if the hash in it is present in the CTL and if it matches they add it to the relevant Trusted Root store on the client.
NOTE! The fetching of the CAB from Windows Update is performed in the security context of the Computer account using WinHTTP - *not* the security context of the User account logged on to the machine. The user being able authenticate to the proxy and log on to the website does not mean that the computer account is able to do the same - Kerberos authentication for the computer account would be required as the computer account will always be presented as Anonymous when accessing other systems over the network when NTLM is involved.
If the clients are going through a proxy that requires authentication then the alternatives are to either allow anonymous access to a subset of sites or to try and determine why the clients are unable to authenticate. For Vista+ clients there were some changes to the way WinHTTP authenticates when retrieving PKI objects from the network which will effectively mean that by default the machine will not attempt to authenticate outside of its own domain.
The Update Root CA feature can be turned off by disabling the Update Root CA feature via Group Policy, the negative aspects of disabling it are that those clients will not become aware of new Root CA's in the program nor will they become aware of Root CA's that have been removed from the updated CTL (in case of a compromise of a Root CA certificate that is part of the program for example).
Concernng why WSUS cannot distribute the CTL - WSUS distributes security hotfixes... the updated CTL is not a security hotfix and therefore it cannot be distributed by WSUS.
Details:
Windows root certificate program members
http://support.microsoft.com/kb/931125
Windows Vista, Windows 7
Root certificates on Windows Vista and later are distributed via the automatic root update mechanism – that is, per root certificate. 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 Microsoft Update for the root certificate. If it finds it, it downloads the current Certificate Trust List (CTL) containing the list of all trusted root certificates in the Program, and verifies that the root certificate is listed there; it then downloads the specified root certificate to the system and installs it in the Windows Trusted Root Certification Authorities Store. If the root certificate is not found, the certificate chain is not completed, and the system returns an error. To the user, a successful root update is seamless. The user does not see any security dialog boxes or warnings. The download happens automatically. In addition, Windows Vista and later client SKUs support weekly pre-fetching from Microsoft Update to check for updated root certificate properties (for example, extended validation (EV), code signing or server authentication properties, which are certificate properties added to a root certificate).
For detailed technical information about how Windows updates root certificates in Windows Vista and in later versions, visit the following website:
http://technet.microsoft.com/en-us/library/cc749331(WS.10).aspx
Troubleshooting Event ID 11:
http://social.technet.microsoft.com/wiki/contents/articles/windows-server-2008-troubleshoot-event-id-11-automatic-root-certificates-update-configuration.aspx
Link to download the updated CTL manually for testing:
http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab
Object IDs associated with Microsoft cryptography
http://support.microsoft.com/kb/287547
Description of the changes to network retrieval of PKI objects in Windows Vista Service Pack 1 and in Windows Server 2008
http://support.microsoft.com/kb/946401
Automatic Root Certificates Update Configuration [using Group Policy]
http://technet.microsoft.com/en-us/library/cc734054(WS.10).aspx
Comments
Anonymous
January 01, 2003
Purging the cache will remove the error if the error was originally caused by something in the cache - the error is very generic and there is no single operation that will resolve all potential causes for it. However, this entry is more about how the CTL UI misinterprets the EKU on the cert used to sign the CTL :)Anonymous
September 27, 2011
support.microsoft.com/default.aspx You need to delete the cert cache and then it will get rid of this error.