HOWTO Resolve CAPI2 Event ID 4107 errors on SharePoint 2010 Servers

This problem has plagued me for a very long time. There are a multitude of web pages dedicated to resolving the issue, but because the CAPI2 event can be caused by so many different systems, and can affect so many different systems, it is still tough to pinpoint.

Microsoft Windows CAPI2 is part of the Public Key Infrastructure (PKI) that is used to prove that digital certificates are valid. Microsoft maintains several such certificates and certificate revocation lists on the Microsoft Windows download site (URLs below) and these are used by Microsoft Windows to ensure any certificates you use are valid and have not been created maliciously. With recent hacks of certificate providers, this becomes even more important.

SharePoint uses PKI to authenticate many components, in particular the DLLs that SharePoint uses – they are all signed by Microsofts’ code-signing certificates. SharePoint uses PKI to ensure the certificate used to sign these components is still valid. To do this, it regularly checks the Microsoft site for any changes to the valid certificate list and installs updates as required. The CAPI2 event errors occur when the Windows server has problems checking certificates, and this is particularly problematic when you have web servers that are behind firewalls and cannot connect to the Microsoft sites to get the latest certificate information.

Implications

One of the big complaints I have with this issue is around SharePoint spin-up times. If we need to do an IISRESET for any reason, all sites are offline for 5-10 minutes while SharePoint starts up. The evidence seems to say that it is .NET under the hood trying to validate the code-signing certificate by contacting Microsoft for the latest-and-greatest certificate list. If your .NET components can’t get to the Microsoft site, you get a timeout, a CAPI2 error, and a delay – for each and every DLL it tries to check. Resolving this issue in theory could speed up your SharePoint spin-up time!

Identifying Root Causes

The best way to isolate what the actual problem is is to enable CAPI2 logging. Using Windows Event Logger on Windows Server 2008, locate the CAPI2 application log via:

  1. Applications and Services Logs
  2. Microsoft
  3. Windows
  4. CAPI2
  5. Operational

When you select the “Operational” node, the list will normally be empty. In the Actions area on the right hand side, click ” Enable Log”. This will start logging any CAPI2 errors with more information. Data may not appear straight away – it can often take 30 minutes before you get any results, depending on when a CAPI2 error occurs. It took about 20 minutes for me.

If there are any issues with either retrieving the certificate updates, or processing the certificate updates, you should see them here. A common error I got was:

CAPI2 - Event ID 53 - Retrieve Object from Network

examining the details for this error (I prefer the XML View) noted:

<Security UserID="S-1-[MORE-STUFF-HERE]" />
...
<URL scheme="http">http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab<//URL>
...
This network connection does not exist.

The Security UserID is important here because it shows what user account is being used to try and make the connection to the Microsoft website. You can use this powershell command to find out the User ID (in a readable form!):

function ConvertTo-NtAccount ($sid) {(new-object system.security.principal.securityidentifier($sid)).translate([system.security.principal.ntaccount])}

which in this case told me the Network Service was unable to access the site.

In my case, the Network Service account did not have permission to use the Proxy Server. We added an exception to the server, and the CAPI2 error disappeared.

Proxy Server Configuration

Another issue I’ve had to address is when changes to the proxy weren’t valid, so I needed to ensure that the account trying to connect to the Microsoft site had the correct settings. Using the powershell above I identified a FAST for SharePoint 2010 service account (“my_fast_service”) could not get to the Microsoft download site to get the certificate revocation list.

To verify, I started Internet Explorer *on the server* using the  CTRL-SHIFT-RIGHT-CLICK combination so I could use “Run As…” on Internet Explorer. I entered the credentials for my user “my_fast_service” and tried to access the URL:

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

which after several seconds, came back with a network “not found” error. I checked the Internet Explorer proxy settings, and there was no proxy set and the “Automatically detect settings” had been set. So the network wasn’t setting the proxy correctly. I un-checked auto detec and entered my proxy settings, and after trying the link again that stopped the CAPI2 error for this user.

It is worth checking the event log for any other user accounts that do not have their proxy settings correct. Or of course you could just fix the auto-detect configuration 🙂

Other Options

  1. You can manually update the certificate list. I haven’t had a great deal of success with this – there are quite a few certificates that need to be installed (the full list will be in the details of the CAPI2 Operational event log)
  2. You can create your own Microsoft download site! Either via DNS entries or using a “hosts.” file change, you can set the update sites to point to 127.0.0.1 which will make them instantly fail and not try to download anything. Or, you could even point them to your own internal website (as long as the URL is the same) and get them to download a pre-created copy of the certificates (which of course you would need to keep up-to-date yourself!). There may be flow-on implications as well, such as the URL www.download.windowsupdate.com could be used by your servers to download windows updates. Take care with this option!

I wouldn’t recommend either of the above options in preference to fixing the root cause (i.e. network access to the Microsoft sites) but they are options in some cases where there is no connection at all, such as in DMZ or secure/hardened sites.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: