locked
SP 2007: Web-Frontendserver try to access crl.microsoft.com (IP-address 84.53.175.26) and block for 40 seconds RRS feed

  • Question

  • If I watch in sysinternal's process explorer any w3wp.exe process (linked to a SharePoint 2007 application pool), I recognice TCP-connection trials to ip addresses 84.53.175.26 and 84.53.175.27. Access to such Internet addresses aren't allowed for processes running on our intranet servers and therfore they don't succeed. The w3wp.exe process tries two times, timing out after 20 seconds during each attempt. The w3wp.exe process doesn't answer incoming requests in this time period.

    nslookup solves these FQDN to the above mentioned ip addresses:

    crl.microsoft.com: CName = crl.www.ms.akadns.net

    crl.www.ms.akadns.net: CName = a1363.g.akamai.net

    a1363.g.akamai.net: A-Record = 84.53.175.26, 84.53.175.27

    How can I deactivate those requests to Microsoft's certificate revocation list server?

    I am thankful for every piece of information you are able to give to me.

    • Moved by Mike Walsh FIN Monday, July 18, 2011 6:20 AM not general (From:SharePoint - General Question and Answers and Discussion (pre-SharePoint 2010))
    Sunday, July 17, 2011 9:32 PM

Answers

  • The common language runtime (CLR) tries to verify the Authenticode signature at load time to create Publisher evidence for the assembly. However, by default, most applications do not need Publisher evidence. Standard CAS policy does not rely on the PublisherMembershipCondition. You should avoid the unnecessary startup cost associated with verifying the publisher signature unless your application executes on a computer with custom CAS policy, or is intending to satisfy demands for PublisherIdentityPermission in a partial-trust environment. (Demands for identity permissions always succeed in a full-trust environment.)


    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
     <runtime>
      <generatePublisherEvidence enabled="false"/>
     </runtime>
    </configuration>

    If your application is hosted in IIS, change one of the following:
      C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config
      C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
    Note On x64 machines, you must also change one of the following:
      C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet.config
      C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config
     
     reference http://msdn.microsoft.com/en-us/library/bb629393.aspx
      
    Or

    Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Create a GPO to help  modify the registry:
    [HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
    “State”=dword:00023e00

     

    -Ivan


    Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.
    Sunday, July 17, 2011 11:13 PM

All replies

  • The common language runtime (CLR) tries to verify the Authenticode signature at load time to create Publisher evidence for the assembly. However, by default, most applications do not need Publisher evidence. Standard CAS policy does not rely on the PublisherMembershipCondition. You should avoid the unnecessary startup cost associated with verifying the publisher signature unless your application executes on a computer with custom CAS policy, or is intending to satisfy demands for PublisherIdentityPermission in a partial-trust environment. (Demands for identity permissions always succeed in a full-trust environment.)


    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
     <runtime>
      <generatePublisherEvidence enabled="false"/>
     </runtime>
    </configuration>

    If your application is hosted in IIS, change one of the following:
      C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config
      C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
    Note On x64 machines, you must also change one of the following:
      C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet.config
      C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config
     
     reference http://msdn.microsoft.com/en-us/library/bb629393.aspx
      
    Or

    Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Create a GPO to help  modify the registry:
    [HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
    “State”=dword:00023e00

     

    -Ivan


    Ivan Sanders My LinkedIn Profile, My Blog, @iasanders.
    Sunday, July 17, 2011 11:13 PM
  • Ivan, thank you for this hint! I will try it tomorrow and come back to this thread to report success or failure.

    Mathias

    Monday, July 18, 2011 5:50 PM
  • Hello Ivan,

    sorry that it lasts so long for me to answer.

    I changed the file machine.config on out test-sharepoint-server but I am not able to sniffer all the network traffic on this server.

    Therefore all I can tell is that when the app-pool starts and the browser accesses the website for the first time, the w3wp.exe process no longer tries to access the ip-address mentioned in my first post.

    On the other hand the access-times to our sharepoint frontend still are lousy.

    May be there is more than one reason for those delays.

    Mathias


    Saturday, July 30, 2011 10:04 AM