3

Every morning I keep getting the following error in my ULS logs. When this error is occurring, pretty much nothing useful works inside our SharePoint farm:

An operation failed because the following certificate has validation errors: Subject Name: CN=*.domain.org, O=Organization, L=New York, S=New York, C=US Issuer Name: CN=Thawte SSL CA, O="Thawte, Inc.", C=US Thumbprint: 4267622D5043715AC0E1E3C59CF3F92E63EEF759 Errors: SSL policy errors have been encountered. Error code '0x2'..

If I do an IISReset, everything comes back fine and the server never runs into the problem again until the following morning.

I have the certificate loaded into SP's trust manager. I don't, however, have the entire chain loaded: i.e., the two intermediary certificates from Thawte are not loaded into the trust manager.

Do I need to add those as well? The certificate is loaded on all servers in the farm and when using the certificate in the browser, no errors are reported.

  • What authentication providers you using ? ? think the trust is not being establish with auth provider and sharepoint . – Nikhil J Aug 7 '14 at 17:31
  • @Nikhil Claims. Basically the default setup for 2013. – jkandiko Aug 7 '14 at 20:54
2

Check the trust between sharepoint and the auth provider .

OR try below option once

Go to your SharePoint site web.config and add the following line within
system.net tag:

<settings>
<servicePointManager
 checkCertificateName=”false”
 checkCertificateRevocationList=”false”
/>
</settings>
  • Would this be done on every server in the farm or only the WFE? Would this go in the Sharepoint web.config or the web services root web.config? – jkandiko Aug 7 '14 at 20:55
  • Sharepoint web.config on all load balancers . – Nikhil J Aug 7 '14 at 20:56
  • 1
    What's the consequence of turning the "checkCertificateName" to false? Isn't this like ignoring a possible error? I am having this same issue, but it makes no effect: everything is working perfectly so far, it's just a couple of lines in the event viewer every 15 minutes (as the search service) but it makes me wonder if there is something else going on... – garfield185 Jan 22 '16 at 8:01
1

couple of possible things, if sharepoint registered with short name in sharepoint while certificate having the FQDN.

The server is registered in SharePoint with its short name and this certificate subject contains the FQDN name.

Solution

  • Get another certificate with a matching subject name,
  • Rename server in SharePoint farm to its FQDN

http://www.lotp.fr/2013/05/sharepoint-event-8311-ssl-policy-errors-encountered-error-code-0x2/?lang=en

http://codeimprovements.wordpress.com/2012/03/23/reassigning-the-correct-ssl-certificate-to-sharepoint-2010-web-services-iis-site/

1

The SSL policy errors have been encountered. Error code '0x2'.. error text was (in my case) depending on that the user performing the certificate creation (either manually or through installation) didn't have permission to create the certificate. The horror is that the installation created the (local) certificates, but they aren't trusted.

To check, open up Microsoft Management Console [mmc] and add snapin certificates (with computer credentials). On the Certificates (Local Computer) > Personal > Certificates folder, right-click and select All Tasks > Request New Certificate.

enter image description here

Walk through the menu until you see the following screen:

enter image description here

If status i Available - this isn't your error. But if it's unavailable, you need to use an account with permissions to create the certificate.

enter image description here

Only then can the certificate be trusted in the domain.

  • 1
    I had the same issue error 0x2. In my case certificate from trusted root authority was used (even expiration date was in future) and it stopped working. Requesting new computer certificate, using steps described, helps and resolve the issue. – Lukas Nespor Jan 23 at 8:31
0

In my case we were getting a lot of errors like that and other similar because we were using wildcard certificate *.domain.com for mysites whose address was like https://my.portal.domain.com which was wrong (wildcard certificate *.domain.com won't work as ..domain.com), when we changed mysites to https://my-portal.domain.com problem gone. Also search couldn't crawl that resource.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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