SharePoint 2013: SSL policy errors have been encountered. Error code '0x2'

After configuring SSL for SharePoint 2013, you may get the blank screen when you open the site in the browser. 

After Investigating and checking the Logs in Event viewer, got the error for the SSL

Errors:  SSL policy errors have been encountered.  Error code '0x2'..

RESOLUTION

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

<settings>

<servicePointManager

checkCertificateName=”false”

checkCertificateRevocationList=”false”

/>

</settings>

That fixed for me... !!! 

Configuring SSL for SharePoint 2013

SharePoint 2013 supports use of SSL, and it is a requirement when integrating federated authentication. To establish a certificate for SSL, the process typically goes something like this:
For development purposes and demonstration, purchasing of an SSL certificate might seem overkill. Fortunately, we can generate self-signed certificates, via IIS. These self-signed certificates are untrusted, because a trust source has not signed them, but they provide a suitable free alternative for demonstration and development. 
The following steps detail how to create a self-signed certificate for SharePoint 2013, via IIS:

1. Open Internet Information Service Manager 7.
2. Click the server name in the left navigation tree and then double-click the Server
     Certificates icon on the right, under IIS section
3. Click the link to create a self-signed certificate.
4. Give the certificate a friendly name, and then click the OK button.
5. Double-click the Self-signed certificate to see the details.
6. Click the Details tab and then click the button to copy the certificate to a file.
7. Click the Next button.
8. Select the option to not export the private key, then click the Next button.
9. Choose the export format (I chose the default DER format) and then the Next button.
10. Give the certificate a file name and browse to a location on disk.
11. Click the Next button, then Finish button to export the certificate to the file.
12. Open the Microsoft Management Console (MMC.exe).
13. Add the certificates snap-in for the computer account and local machine.
14. Import the certificate into the Trusted Root Certificate Authorities node.
15. Import the certificate into the SharePoint node.

In the preceding steps, we have created a new certificate and allowed the local server to trust the certificate by adding it to the Trusted Root Certificate Authorities store. This avoids annoying messages in Internet Explorer about untrusted certificates. Even though we trust the certificate, we have to inform SharePoint it may trust the certificate also, via the steps that follow:

Note: Never use self-signed certificates in production or non-development environments.

16. Open Central Administration.
17. Click the Security header.
18. Click the link to manage trust.
19. Click the new icon from the ribbon.

20. Provide a friendly name and browse for the certificate (CER) file in the dialog

21. Click OK.

Now, we need to associate our new self-signed certificate with our web application in IIS, as follows:

22. Return to IIS Management.
23. Click the SharePoint application in the left navigation, under Sites.
24. Click the Bindings link (on the far right).

25. Click the Add button.
26. Choose HTTPS, and select the certificate to use

27. Click OK to complete the binding configuration.

Lastly, with the new SSL domain binding in place, we must create a new Alternate Access Mapping for the application so SharePoint understands requests coming in on the new SSL URL:

28. Open Central Administration.
29. Click the Application Management heading.
30. Click the link to configure alternate access mappings.
31. Click the button to edit public URLs.
32. Change the Alternate Access Mapping Collection for the correct web application.
33. Choose an empty zone and add the HTTPS URL (this should be the full domain name that

is listed for the self-signed certificate in IIS)
34. You can now access your web application on the new HTTPS/SSL URL

Sign in as Different User and SharePoint 2013

It’s been noted that the “Sign in as a Different User” menu command is missing in SharePoint 2013

This “Sign in as Different User” menu item is very useful when testing applications, but it can lead to problems especially when opening documents, say in Microsoft Word. So, it may be for these reasons that the option has been removed in SharePoint 2013.

You can add the menu item back in, but I would suggest only doing this on test or development SharePoint servers. To do this, repeat this edit on all servers in your SharePoint farm:

• Locate the file \15\TEMPLATE\CONTROLTEMPLATES\Welcome.ascx and open in a text editor.
• Add the following element before the existing element with the id of “ID_RequestAccess”:

1 2 3 4 5 6 7

<SharePoint:MenuItemTemplate runat="server" ID="ID_LoginAsDifferentUser"  Text="<%$Resources:wss,personalactions_loginasdifferentuser%>"  Description="<%$Resources:wss,personalactions_loginasdifferentuserdescription%>"  MenuGroupId="100"  Sequence="100"  UseShortId="true"  />

• Save the file.

Now, the menu item shall be displayed:

Service Application Windows PowerShell Commands

COMMAND	DESCRIPTION
Install-SPService	Installs the services in the farm. It runs once per farm.
Get-SPServiceInstance Start-SPServiceInstance Stop-SPServiceInstance	Operations related to managing the services instance for a specific server or the entire farm.
Get-SPServiceApplication Publish-SPServiceApplication Remove-SPServiceApplication Set-SPServiceApplication Unpublish-SPServiceApplication	Operations related to managing service applications deployed to a farm (such as sharing the specifi ed local service application outside the farm).
Get-SPServiceApplicationProxy Remove-SPServiceApplicationProxy Add-SPServiceApplicationProxy GroupMember	Operations related to managing service application proxies.
Get-SPServiceApplicationPool New-SPServiceApplicationPool Remove-SPServiceApplicationPool Set-SPServiceApplicationPool	Operations related to managing the logical architecture of service applications.

Renaming the SharePoint Admin Content Database to Follow SQL Server Naming Conventions

Solution

The SharePoint Central Admin database is a configuration database that stores site content and permissions for the Central Administration web application. DBA’s are very much concerned with backing up and restoring all of the SharePoint databases. While the Central Admin Content database is backed up when a SharePoint farm administrator performs a farm configuration backup, it doesn't get restored when a farm is restored. It can backup and restore the SharePoint Admin Content database separately using native SQL Server backup tools. The challenge here is dealing with a database name that has a GUID value.

Here is an example of the SharePoint database name.

If you have a corporate policy to standardize database naming conventions or use custom database maintenance scripts, it is imperative to rename the SharePoint databases to eliminate those GUID values, starting with the SharePoint Admin Content. While most recommendations will tell you to rename your SharePoint databases accordingly during creation, in most cases, DBAs are not included as part of the initial planning and deployment process. Thus, end up with SharePoint databases with such naming conventions. To accomplish this task, DBA’s will be using Windows PowerShell via the SharePoint 2010 Management Shell console. Remember to back up the database prior to performing the tasks below.

1. On the SharePoint web or application server, click Start, point to All Programs, and then click Microsoft SharePoint 2010 Products. In the list of available options, click SharePoint 2010 Management Shell.

2. In the SharePoint 2010 Management Shell, type the following command to create a new content database named SharePoint_AdminContent. This will replace the existing Central Admin content database that has a GUID value in its name. In my environment, the web application name for the SharePoint Central Administration web application is http://sp2010-web1:20376. The New-SPContentDatabase PowerShell cmdlet is described further in this tip on Managing SharePoint Content Databases with PowerShell.

PS C:\> New-SPContentDatabase -Name SharePoint_AdminContent -WebApplication http://sp2010-web1:20376

3. We need to retrieve the Id values assigned to the SharePoint Admin Content databases. Run the following command, using the Get-SPWebApplication and the Get-SPContentDatabase PowerShell cmdlets.

PS C:\> Get-SPWebApplication -Identity http://sp2010-web1:20376 | Get-SPContentDatabase | Select Id, Name, WebApplication | Format-List

4. To move the contents of the SharePoint Admin Content database from the one with the GUID value to the newly created one, run the following command, using the Get-SPSite and the Move-SPSite PowerShell cmdlets. Note that the you should pass the Id property values of the databases names instead of the Name property for the -ContentDatabase parameter of the Get-SPSite cmdlet. Type Y to confirm the prompts.

PS C:\> Get-SPSite -ContentDatabase 46410944-32c4-4e01-8390-22b693f4fcc2 | Move-SPSite -DestinationDatabase 86d8e579-fbd8-473e-867d-58b974ee0267

5. Run IISRESET to restart IIS on the web front end server. 
6. Verify that the SharePoint Central Administration web application renders properly without issues. Try navigating thru the different links to make sure that everything is working fine. 
7. To completely remove the GUID-valued SharePoint Admin Content database, run the following command, using theRemove-SPContentDatabase cmdlet. This will detach the content database from the SharePoint Central Administration web application and eventually deleting it from the SQL Server instance. Type Y to confirm the prompts.

PS C:\> Remove-SPContentDatabase 46410944-32c4-4e01-8390-22b693f4fcc2

8. Verify that you no longer have the GUID-valued GUID-valued SharePoint Admin Content database and that it is now using the newly created database

PS C:\> Get-SPWebApplication -Identity http://sp2010-web1:20376 | Get-SPContentDatabase | Select Id, Name, WebApplication | Format-List

You can also confirm this by checking the list of databases from within SQL Server Management Studio.

In this tip, we've renamed an existing GUID-valued SharePoint content database to remove the GUID value. In future tips, we will look at performing the same task but with the service application databases running on your SharePoint 2010 farm.

Problems Creating List Workflows in SharePoint Designer 2010 for Office 365 Sites

On a SharePoint Online site, when attempting to edit a previously created list workflow using SharePoint Designer 2010, I received the following error in Designer:

_{(SharePoint Designer cannot display the item…Most likely causes: The file has been deleted from the site. The site is encountering problems.)}

I had never encountered this error before, so instead of editing the workflow, I tried to create a new list workflow. After entering the name of the new workflow and clicking OK in the window shown below, the window closes and nothing happens.

I thought maybe it was an issue with Designer itself, so I closed the application and went to clear out all the related cache. I started in the SharePoint Designer folder located in the AppData directory. In the ProxyAssemblyCache folder, I noticed something very interesting – two folders with what looked like different version numbers as their names.

_{(c:\users\*username*\AppData\Roaming\Microsoft\SharePoint Designer\ProxyAssemblyCache)}

The 14.0.0.6120 version corresponds to the April 2012 CU for SharePoint 2010. The 15.0.0.4433 number corresponds to the ​December 2012 Hotfix for SharePoint 2013! I haven’t opened a SharePoint 2013 site from this computer, so I was perplexed why this version number was being used.

So, I went back into SharePoint Designer to see if I could find more information, and noticed that the SharePoint version was 4, BUT it was 4 (15.0.0.4433)! This is exactly how a site would report itself when it is hosted on a SharePoint 2013 server that is using the 2010 experience.

_{(SharePoint Designer site properties reporting version 4 (15.0.0.4433) )}

So, without notifying anyone, it seems Microsoft has started to rollout SharePoint ‘Wave 15′ (2013) in SharePoint Online, but it is keeping these existing tenants on the 2010 experience. So, there is no way of knowing when you are converted over, unless you start having issues creating or editing list workflows in SharePoint Designer 2010 or you happen to look at your version number.

The "solution" is to install SharePoint Designer 2013 (http://www.microsoft.com/en-us/download/details.aspx?id=35491), remove the ProxyAssemblyCache folders, and clear out any files in the C:\Users\dglenn\AppData\Local\Microsoft\WebsiteCache\ directory.

Ref link: http://knowsharepoint.com/problems-creating-list-workflows-in-sharepoint-designer-2010-for-office-365-sites/