SharePoint SSL and MySites

1.1          MySites over SSL

Web applications in a SharePoint 2013 Farm that host user content are utilizing SSL.  MySites does not.  What are the options for migrating MySites to SSL?  Why do Office Web Apps functionality break when used in MySites where OWA was configured for SSL and MySites is not SSL?

1.1.1       Re-provision MySites as a site collection inside the main web application.

Move the MySites host to be a path based site collection underneath the https://intranet.domain.com web application.  Example: https://intranet.domain.com/sites/mysites

                    Steps:

1.      Perform a backup of the entire old MySites web application and all site collections within.
2.      Create a new content database for the new mysites host.
3.      Create a new site collection as a MySites Host under the https://intranet.domain.com web application using this new content database (with PowerShell commands).
4.      Go into the User Profile Service and change the default MySites host to point to the new one.  Migrate any MySites currently under use that have valid content.
5.      Remove the old MySites http://intranet.domain.com:20000 web application, including content and IIS site.

                    Cost/Benefits:

·        Pros
o   Uses the same SSL certificate as https://intranet.domain.com
o   Easier to maintain as you only have one web application to maintain and load balance.  (This is a very minor amount of ease).
·        Cons
o   From TechNet: Although you can use an existing web application, for optimal performance and security, we recommend that you create the My Site host site collection in a dedicated web application.  http://technet.microsoft.com/en-us/library/ee624362.aspx
o   You cannot use a separate URL, for example: https://me.domain.com.

1.1.2       Obtain a wildcard SSL certificate and re-provision MySites Web Application

With a wildcard certificate your web servers in SharePoint will be able to host multiple web applications all using SSL and port 443 and from a single IP address per web server.  Wildcard cert example: *.d51schools.org.

                    Steps:

1.      Load the new wildcard certificate with the private cert the Trusted Root Certification Authorities for the computer account using the MMC certificates and the IIS server certificates area, on each web server hosting SharePoint web applications.
2.      In Central Administration, navigate to Web Applications.  Select the current MySites web application (http://intranet.domain.com:20000) and select the ribbon command for Delete -> Remove SharePoint from IIS Web Site.  The web application and all content is not deleted, merely the IIS web site.
3.      Select the zone you wish to remove, most likely only the default zone.
4.      Once deleted, select the web application and choose Extend.
5.      Input the details.  Remember that to use a wildcard certificate you will need to use host headers on all sites that are combined on the same IP address and using the same port (443).  This will mean navigating the IIS site for the https://intranet.domain.com and adding in the host header and new wildcard certificate for it.
6.      Navigate to IIS, locate your newly created MySites site, and bind the new wildcard certificate.

                    Cost/Benefits:

·        Pros
o   All SSL sites utilize the same SSL certificate.  Easy to create new SSL sites.
o   Other web servers (non SharePoint) can use the same wildcard cert.
o   Can immediately create new web applications for the following:
§  https://ca.domain.com  (Central Administration)
§  https://community.domain.com  
§  https://staff.domain.com  
§  https://public.domain.com  
o   If load balancing web servers, there will be less IP address space consumed versus named certificates.
·        Cons
o   Wildcard certificates are more expensive than named certificates.  Can cost around 2-3 times more than a named cert.
o   Validating an authentic website is not as assured as named certificate.  Your domain name listed in the certificate includes an asterisk and may not fully assure users.
o   Less secure: If one server or sub-domain is compromised, all sub-domains may be compromised.
o   Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.
o   Protection: Some vendors will not provide as much warranty protection on wildcard certs.
1.1.3       Obtain a named SSL certificate and re-provision MySites Web Application
With a named certificate your web servers in SharePoint will be able to host multiple web applications all using SSL and port 443, but each website will require a separate IP address on each server.  Named cert example: me.d51schools.org.
                    Steps:
2.      In Central Administration, navigate to Web Applications.  Select the current MySites web application (http://intranet.domain.com:20000) and select the ribbon command for Delete -> Remove SharePoint from IIS Web Site.  The web application and all content is not deleted, merely the IIS web site.
3.      Select the zone you wish to remove, most likely only the default zone.
4.      Once deleted, select the web application and choose Extend.
5.      Input the details.  This site does not require a host header.
6.      Navigate to IIS, locate your newly created MySites site, and bind the new named certificate.
                    Cost/Benefits:
·        Pros
o   More secure.
o   Each cert is cheaper than the wildcard cert individually.
o   Validity (green checkmark in browser) is assured.  Some vendors offer more confidential verification as a service on named certs.
o   If the cert is compromised, only this web application must be taken down, new cert obtained, and reattached.
·        Cons
o   Will require more IP addresses and virtual NICs attached to each web server hosting SharePoint web applications.
o   Potentially more complicated load balancing, but minor.

1.1.4       Office Web Apps fails on MySites when not using SSL

When you configure Office Web Apps (OWA) to use HTTPS, and you still have a site that is using HTTP, you need to configure the Security Token Service to allow OAUTH to pass over HTTP.

                    Why?

SharePoint passes the request over to the OWA server using HTTPS but then OWA server access SharePoint over the calling web application’s URL.  If that URL is http://intranet.domain.com:20000, the communications fail, with some cryptic errors in the ULS logs of the OWA server.  Essentially the receiving HTTP site cannot authenticate the OWA encrypted HTTPS OAUTH because it doesn’t have a bound SSL cert to decrypt it with.

                    Fix:

In order for HTTP to work properly, you must make the following changes to the SharePoint farm.  And undo these if when you re-provision MySites to be SSL:
1.      From a SharePoint server, preferably the application server, open an elevated PowerShell with the SharePoint snapin loaded.
2.      Run the following commands in succession:
a.      $config = (Get-SPSecurityTokenServiceConfig)
b.      $config.AllowOAuthOverHttp = $true
c.      $config.Update()
3.      Test the connection in MySites again.  May want to run an IISreset on the servers just in case.
4.      Look to see if the errors in OWA ULS logs are resolved or disappear.

Comments

Popular posts from this blog

SharePoint Designer 2013 Approval Workflow with Comments

Change SharePoint server hostname and Web Application Names

SharePoint Search - Content Processing Pipeline Failed to Process the Item