Compartilhar via


SharePoint delays - CRL?

if your Sharepoint systems are hidden away, they may experience slowdowns due to CRL lookup. The problem is that when loading signed assemblies the .net Framework checks the Internet based Certificate Revocation List. As your servers have, like most secure environments, no outgoing connections to the public Internet, the connection to crl.microsoft.com times out. This takes far longer than you might have expected.

A quick fix / test to confirm - add this to HOSTS.

127.0.0.1   crl.microsoft.com

There are multiple "legitimate" ways to sort this out. Obviously - open a connection. Or set the registry key to kill the checking... or download the certs locally and add them. One that seems likely is for you to modify the exe.config file. Group Policy via "Certificate Path Validation Settings"is another option.

e.g. You can set the tag in Machine.config as per https://msdn.microsoft.com/en-us/library/bb629393.aspx

script sample to hammer this home

#Requires -RunAsAdministrator
Set-StrictMode -Version 4

#this is run on the box(es) needing to disable CRL checks.

$RegKeyPath = "\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"

$RegKey1 = "HKCU:" + $RegKeyPath
$RegKey2 = "REGISTRY::\HKEY_USERS\.Default" + $RegKeyPath

# CLEAR THE BIT
$BitIsSet    = 0x00023c00 # ‘Check for publisher’s certificate Revocation’ Checked
$BitIsClear  = 0x00023e00 # ‘Check for publisher’s certificate Revocation’ Unchecked

# set for Current User
Set-ItemProperty -path $RegKey1 -name State -value $BitIsClear
# set the Users .Default
Set-ItemProperty -path $RegKey2 -name State -value $BitIsClear

# cycle through all users and set them too!
Get-ChildItem REGISTRY::HKEY_USERS |
ForEach-Object {
Set-ItemProperty -ErrorAction silentlycontinue -path ($_.Name + $RegKeyPath)  -name State -value $BitIsClear
}

# now go into MACHINE.CONFIG and set the XML to disable checking for CAS publisher policy for an application.
Write-Host -ForegroundColor White " - Disabling Certificate Revocation List (CRL) check..."
ForEach($bitsize in ("","64"))
{
$xml = [xml](Get-Content $env:windir\Microsoft.NET\Framework$bitsize\v2.0.50727\CONFIG\Machine.config)
If (!$xml.DocumentElement.SelectSingleNode("runtime")) {
$runtime = $xml.CreateElement("runtime")
$xml.DocumentElement.AppendChild($runtime) | Out-Null
}
# Publisher evidence for code access security (CAS).
If (!$xml.DocumentElement.SelectSingleNode("runtime/generatePublisherEvidence")) {
$gpe = $xml.CreateElement("generatePublisherEvidence")
$xml.DocumentElement.SelectSingleNode("runtime").AppendChild($gpe)  | Out-Null
}
$xml.DocumentElement.SelectSingleNode("runtime/generatePublisherEvidence").SetAttribute("enabled","false")  | Out-Null
$xml.Save("$env:windir\Microsoft.NET\Framework$bitsize\v2.0.50727\CONFIG\Machine.config")
}

Comments

  • Anonymous
    June 25, 2014
    It would be nice to know how to go about doing the stuff mentioned in this blog and documenting it as part of the standard SharePoint documentation. Putting 127.0.0.1 crl.microsoft.com does not always fix the issue. I still see errors with CRL check in the event logs.

    Can you update this to provide a better step by step approach to fixing this?

    Thanks