On a Windows Server 2008 R2 the event log is showing error 4107 CAPI2. Previous tips always show the source of the issue to be an expired certificate, but that doesn't seem to be the case here: When I trace the certificate chain, I find this certificate: Name: Microsoft Certificate Trust List Publisher Status: The certificate is not enabled for this purpose (translation, German original: "Das Zertifikat ist für den angeforderten Zweck nicht zugelassen.") So the root certificate update that the server is routinely trying to install is invalid because it has been signed with the wrong certificate. What is the recommended action to clear this issue?Regards, AngusMac

Hi, Please refer to the KB article http://support.microsoft.com/kb/2328240 Hope it helps.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, Please refer to the KB article http://support.microsoft.com/kb/2328240 Hope it helps. No offense, but I believe I stated this quite clearly in my original question: This KB entry does NOT help. Regards, AngusMac

Hi, Sorry for the misunderstanding. Based on my research, the issue may occur if the computer cannot access the Internet. Is proxy being used in the environment? If so, please run the following command on the computer and check if the issue can be resolved: netsh winhttp set proxy "proxy-server" where "proxy-server" is the address of your proxy server without quotations. If it does not help, please enable the CAPI2 log for further research. These forums are geared to answer on the English version of the product. If the events are displayed in German, I suggest that you contact the local support for further assistance. If the issue is urgent to your business, it is recommended that you contact Microsoft Product Support Services via telephone so that a dedicated Support Professional can assist you recover the server in a more efficient manner. Please be advised that contacting phone support will be a charged call. To obtain the phone numbers for specific technology request please take a look at the web site listed below. http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS Thanks.

Thank you for your help. The network does in fact use a proxy server. The proxy is not mandatory, though - direct internet access is possible. The command "netsh winhttp show proxy" reports "direct access (no proxy)". Any ping or other direct internet access is working fine. Proxy access requires authentication. Can I pass this data to the winhttp setting? Is it possible that the machine tries to use the proxy automatically (proxy auto-detection via DHCP or DNS, both is being deployed in the network), but is failing because of the authentication? Still: The certificate is explicitly marked as "invalid for this purpose". How could internet access factor into this error? Regards, AngusMac

Proxy access requires authentication. Can I pass this data to the winhttp setting? Is it possible that the machine tries to use the proxy automatically (proxy auto-detection via DHCP or DNS, both is being deployed in the network), but is failing because of the authentication? It is possible. Please run the command I mentioned in my previous reply and check the result. As for the certificate status, it is marked as "invalid for this purpose" because the UI expects a different EKU rather than the one used by automatic root update. The CTL UI expects the signer to contain the Microsoft Trust List Signing EKU. However, the automatic root update mechanism uses a different EKU (Root List Signer) and as part of certificate chain validation, Windows checks for the presence of the Root List Signer EKU in the CTL signer chain. In this case, the chain is valid for the Root List Signer EKU. In addition, the information in the following article may help troubleshoot the issue: http://social.technet.microsoft.com/wiki/contents/articles/troubleshoot-root-certificate-update-failure-march-3-2011.aspx This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, How's everything going? If you need further assistance, please feel free to respond back. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi all, I haven't reported back because the error I was seeing simply vanished by itself. I'm not sure if the reason was a new auto-update of the root certificates, the timing didn't seem to be right, and there weren't any notices in event log pointing to such. On the other hand, successful updates usually aren't announced there, and the whole reasoning seems to suggest that this in fact was the problem (as Joson described, thank you for that.) So, indeed - solved for now. Thanks. Regards, AngusMac