SharePoint, SNI, and HTTP Redirect Issues

SNI, or Server Name Indication, now available with Windows Server 2012, provides the ability to have multiple SSL web applications without needing a wildcard certificate or multiple IP addresses.  In SharePoint terms – you may run into this scenario if you have separated your Intranet Web Application and your My Sites Web Application, but desire SSL Certificates on both.

You can find this setting in IIS.  Right click your web application and edit the bindings.  You’ll notice that if you change the “Type” drop down to https, that you have some additional options.  You can now select “Require Server Name Indication” as well as select your SSL certificate.  This bypasses your need for the extra IP or the wildcard since it sends the name of the virtual domain as part of the TLS negotiation.  This enables the server to select the correct domain and present the browser with the correct certificate.  That’s truly all there is to it.

052114_1400_SharePointS1.png

To learn more about SNI – you can read about it here: http://en.wikipedia.org/wiki/Server_Name_Indication

The story doesn’t end here folks.  Unfortunately… let me tell you my story of how I spent a Friday night troubleshooting a HTTP URL redirect that would.not.work and how that relates to SNI.  I would love to hear your comments if anyone has had a similar experience or if you know of a workaround!

To start things off…

I was working on SharePoint Server 2013 with Project Server migration from SP/Project 2010 – which to this point had gone extremely well.  Content databases merged and attached and things were cruising along.  Sites were up, visual upgrade complete. PWA was in good shape and we were gooooood.   We had the scenario described above, where we had SSL certificates on both the intranet site and the My Sites web applications.  I was pretty pumped to try out this new SNI functionality when I applied the SSL certs, wrap things up, and prepare for QA testing.  SNI was perfect since I had, admittedly, forgotten to ask ahead of time for that extra IP address and of course it was after hours.  So I enable SNI, test my intranet and things seem great!

Here’s the bad news….

Next up – the client has requested a HTTP redirect.  No sweat right?!   I added the URL rewrite module to IIS and set up the redirect.  And it would.not.work.   Let me be more clear – for the Intranet – it didn’t seem to be redirecting consistently?  And the search page wouldn’t load – I was receiving a user profile error. MySites also had a user profile error similar to search!   Oh GREAT – what did I do?!  Right?!   Surely that user profile error had nothing to do with those SSL and redirect settings.  I couldn’t find anything wrong with my user profiles and I tried every way of putting a redirect in that site that I could think of.  Nothing worked.   For those of you that are curious, here are the URL Rewrite settings I was using –

052114_1400_SharePointS2.png

052114_1400_SharePointS3.png

 

The real problem…

Finally…finally!  I gave up.  I removed the URL rewrite, put in a client side redirect and things came back up.  User profiles errors were not there on the search or My Sites pages   (oh, I know…I’m not proud of that client side redirect but it was working for QA testing in the morning) I waited until the next day and asked for the secondary IP address.  At that point, I removed SNI, added the secondary IP the ‘traditional’ way for SSL based sites, enabled the URL rewrite module redirect settings and everything worked perfectly.

Moral of the story…

SNI seems to work great with SharePoint unless you plan on redirecting your site from HTTP.  I would love to hear about your experience in case there’s something I missed!  Otherwise –  I hope someone gains a few hours of their day back from my pain J

Leave a Reply

Your email address will not be published. Required fields are marked *