SSL and SharePoint 2013

A new best practice emerges in SharePoint 2013 that will change how some companies are deploying SharePoint today. That new best practice is to ensure that every single web application is SSL encrypted with said SSL now terminated on the SharePoint web front ends.

Why

Secure Sockets Layer (SSL) is a requirement for web applications that are deployed in scenarios that support server-to-server authentication and app authentication. This is such a scenario. As a prerequisite for configuring Task Synchronization, the computer that is running SharePoint Server must have SSL configured.
Source 

What does it mean?

Simply put that means that…

  • You want to use apps? You must have SSL!
  • You want to use Exchange tasks and Exchange site mailbox features? You must have SSL!

Even more importantly the HTTPS URL must be the default Zone (not a secondary zone). Additionally, you should terminate the SSL on your SharePoint servers and not offload the SSL on your load balancers as you may be doing today.

EDIT: I’ve had a number of questions as to why I am recommending to terminate SSL on the SharePoint servers instead of offloading. Because the OAuth token is passed in a cookie on the request you could be subject to a man-in-the-middle attack where the token is re-played during the lifetime of the cookie. Is it a high risk? Probably not… but you should make an educated decision based on your architecture. If you do decide to terminate SSL on the SharePoint servers then do consider using client affinity or sticky sessions so users do not have to renegotiate the SSL session.

This requires some additional planning around how requests are routed to SharePoint and how the IIS bindings are configured. Where you used to be able to get away with a single IP on your SharePoint server and utilize Host Header binding you will now want to utilize IP bindings instead.

What you’ll need to plan for in SharePoint 2013

  • A new IP address for each web application (you can get away with less but this is easier to plan in case you need host named site collections)
  • A wildcard SSL certificate for your web applications
  • A new domain name for your apps ex: contosoapps.com (best practice)
  • A wildcard SSL certificate for your apps domain

Additional Resources

I'm a public speaker and the Chief SharePoint Architect for Eastridge, a Microsoft Gold Partner specializing in SharePoint and custom application development in Winston-Salem, NC. I focus on the SharePoint platform with a specialty in Information Architecture, Publishing and Best Practices.

Got something to say? Go for it!