12

I have a SharePoint 2013 Farm which is behind a secure firewall and has no internet access which includes a Web Application running over SSL.

We keep seeing the following error in the SharePoint ULS logs (A certificate validation operation took milliseconds and has exceeded the execution time threshold). The timeout is anytime from 10 - 70 seconds and every time causes the page load to pause (and sometimes timeout completely).

I have performed all of the following:

  • Added the following certificates into the Trusted Certification Authorities store on all servers:
    • SharePoint Root Authority (extracted from SPCertificateAuthority using PowerShell)
    • SSL Certs for Web App (both the wildcard cert and the parent chain certs)
  • Added the "generatePublisherEvidence" attribute to the machine.config on all web servers (value set to "False")
  • Set the Registry Key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing to 146944 (certificate revocation check disabled)
  • Modified the local security policy and disabled "Network Retrieval" under Public Key Policies
  • Use NETSH commands to add the IIS SSL bindings with certificate revocation checks disabled
  • Added "127.0.0.1 crl.microsoft.com" to the HOSTS file on each server
  • Servers have all been rebooted

This is very slowly driving me mad. Does anyone have anything else I can try?

Improve this question
2
  • Did you ever manage to solve this problem?
    – Dribbel
    Commented Jul 28, 2014 at 10:51
  • 3
    No .. I ended up doing some registry hacks to set the timeout to 1 second .. not brilliant but stopped the catastrophic page errors. Just meant a longer page load when it did happen
    – Martin Hatch
    Commented Jul 29, 2014 at 13:29

3 Answers 3

Reset to default
8

I also tried to disable it on the server but in the end I solved it by using another method. What's curious is that the timeouts took 90 seconds instead of the 15 seconds that is the timeout specified for requesting the revocation status of the certificate.

Activate the CAPI2 log in event viewer to enable logging for the actual validation requests that are send from your server.

I was able to remove the errors and more importantly, the delay by adding the contacted server hostnames to the hosts file. In my case it was a certificate by digicert. I had to add the following.

127.0.0.1 ocsp.digicert.com

127.0.0.1 crl3.digicert.com

127.0.0.1 crl4.digicert.com

  • Errors in CAPI2 log tell me the server is offline

  • No more error messages in Windows Logs - Application

Update:

I had both the 15s delay and a 60 ~ 90s delay.

The 15 delay is actually gone after following the solution described in the article Site slowness because of SharePoint STS certificate CRL checking*. It's different from the 60 ~ 90s delay, I presume since this is coupled to the standard sharepoint self-signed root authority certificate. The 60 ~ 90s delay was caused because of the DigiCert certificate.

Likewise, by editing the hosts file first, I got rid of the 60 ~ 90s delays, but not the 15s delay.

If you use an imported certificate you might have to follow the solution described in this post.

*) If link fails in Chrome, use IE

Improve this answer
2

I solved this Problem thanks to this articles: http://support2.microsoft.com/kb/2625048 and http://www.ilikesharepoint.de/2014/04/sharepoint-event-id-8321-how-to-fix/

Maybe you have to (re-)add the certificate to the Local Trust Store in your SharePoint Installation.

Central Administration > Security > Manage Trust

Improve this answer
-1

http://hkhawaja.wordpress.com/2013/05/28/sharepoint-2013-performance-and-certificate-validation-errors/

In the Local Group Policy Editor, we changed the Certificate Path Validation Settings to disallow automatic updating of certificates, but this did not help. [ Computer Configuration > Windows > Security Settings > Public Key Policies > Certificate Path Validation Settings]

In the Hosts file, we added an entry for crl.microsoft.com to point to the localhost, 127.0.0.1. That also didn’t seem to have any effect on the problem, as we continued to see those errors.

We then installed SharePoint root certificate on all the SharePoint servers, in the Certificate Root Authority Store. We exported the out-of-the-box SharePoint certificate using PowerShell, and then manually installed on each server. After that we rebooted all the servers, and observed the problem reoccurrence –however no further issues were seen in the event logs anymore. The following PowerShell commands were used: $rootCertSP = (Get-SPCertificateAuthority).RootCertificate $rootCertSP.Export(“Cer”) | Set-Content C:\rootCertSP.cer –Encoding Byte

Improve this answer
7
  • 2
    You didn't read the question did you? I already tried those
    – Martin Hatch
    Commented Apr 28, 2014 at 14:20
  • 1
    Martin -- did you try the HOST/DNS entry for crl.microsoft.com? If the server does not have access to the internet, that can cause timeouts.
    – Paul Schaeflein
    Commented Apr 28, 2014 at 19:29
  • Paul - Yes I actually already have that setting .. I'll add it to the original post.
    – Martin Hatch
    Commented Apr 29, 2014 at 14:44
  • 1
    Enabling the CAPI2 logs shows that even after i did the same thing as @MartinHatch, the server is still attempting to connect to this particular url to get a list of revoked certificates, ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/… i've tried to add ctldl.windowsupdate.com to 127.0.0.1 in hosts file and it doesn't help as well. Anyone have better findings? pastebin: pastebin.com/Gw5mcDPH
    – Lee Gary
    Commented Jun 6, 2014 at 8:52
  • 1
    @TempaC i fixed my farm by installing the SP root cert on all servers
    – Lee Gary
    Commented Apr 9, 2015 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.