Running Multiple SharePoint SSL Websites on Separate SSL Certificates Using Server Name Indication
As anyone with generic webserver + HTTPS knowledge will tell you, traditionally, running multiple SSL websites on a single box as always been a bit tricky if you have only one network interface on the webserver machine.
This is due to historical limitation in TLS/SSL in that a single certificate has needed to be associated with all application requests to the IP address as there wasn’t a way in TLS to specify a “hostname” for the traffic, which we’re used to be able to do in standard HTTP. Given TLS is the transport layer for HTTP traffic it needs to work before HTTP chatter can work (and therefore before HTTP host-headers can be taken into account), hence this rather frustrating historical limitation.
This isn’t something specific to IIS either; rather this is a SSL/TLS issue of which IIS has been impacted by alongside any other WWW server or TLS/SSL service that shares a single TCP port.
There have been workarounds though; wildcard certificates or “alternative certificate names” + reusing the same single certificate for any site that needs SSL has been it so far, but some in the WWW crowd consider a bit of a hack (I’ll not comment either way).
Now there’s a better way in IIS8+ (that’s Windows Server 2012 R2+) thanks to a new TLS standard called Server Name Indication. In short, this lets you have a different certificate per IIS website, thanks to some advancements in TLS that we can leverage.
In other words, finally SharePoint can have several SSL sites with several different SSL certificates on the same IP address and the SPWorld in SSL is a nicer place to be in. Hurrah.
Introducing Server Name Indication (SNI)
As mentioned already, SNI is a new extension to TLS that handily lets us specify the hostname for which the traffic is intended – something normally handled at the HTTP layer, which again, being application traffic wouldn’t work until a SSL connection is established. It’s quite a new extension to TLS; so new in fact that many clients don’t support it yet (for example the WebDAV client in Windows 8.0 doesn’t, apparently – fixed in 8.1) so there are some caveats.
SNI Client Supportability – Important!
As server name indication is fairly new some clients just don’t support this new TLS extension yet which needs to be taken into account if you want them to use SharePoint. Windows XP for example just won’t play with this new feature, and even the WebDAV client in Windows 8.0 doesn’t support it (Windows 8.1 does).
Any client software that doesn’t work with SNI will need a “default” SSL site otherwise they won’t be able to connect at all.
Default sites work ok if you have X IIS sites for x1 SharePoint application – you just extend the application one more time without a host-header & assign a certificate without SNI enabled – any non-supporting client will just transparently use that.
However if you have 4 applications with a single zone each, suddenly the idea of having a “default” IIS site looks more complicated – which SharePoint application should non-SNI clients use? That’s for you to decide, Mr Admin.
Just bear in mind that without a default SSL site of some kind, any non-SNI enabled clients just won’t be able to connect to SharePoint.
SharePoint Server Supportability with SNI
Lot’s of people have already asked me about if this is a supported scenario as far as SharePoint is concerned. The short answer is “yes” but the longer answer is “almost certainly”.
To explain; when a configuration is “supported” by the SharePoint product-group that means that the scenario in question has been exhaustively tested internally for which SharePoint operated within the acceptable operating bounds and we rubber-stamp the scenario to say “we know this definitely works”. At the time of writing, to the best of my knowledge, SharePoint has not yet been specifically tested with SNI.
That said, SNI is a transport-level technology and SharePoint itself isn’t tested with every transport-level configuration as that’s a platforms/IIS problem domain. SharePoint is built on-top of IIS; IIS is tested with & does support SNI & other transport-level technologies, with SharePoint processing HTTP requests once they’ve been passed on by the platform (IIS).
In the same way, SharePoint isn’t specifically tested with SHA-256 or RSA 2048 certificates for example, because those too are a transport-level supportability problem. The net result is always the same however; the web-browser in question will either successfully negotiate a HTTPS connection to IIS (and therefore SharePoint), or not.
So yes, Server Name Indication almost certainly is supported by SharePoint by extension of being supported by IIS 8.0.
How to Setup Multiple SSL Sites in SharePoint
The first step is to create/extend all your sites from SharePoint that’ll need SSL from Central Administration.
Important: make sure you give a hostname for any site you want to enable SNI for here.
If you need x1 SPWebApplication with x3 extentions, create all of them now – each one with a hostname. Same for if you need x4 SPWebApplications with a single default zone each.
Also, as mentioned above you’ll probably want a default zone extended too in you want non-SNI enabled clients to work with your application.
A default SSL site is just an SSL site with SNI enabled or with a host-header – any non SNI aware clients will connect to this endpoint instead.
Enable Server Name Indication for SharePoint IIS SSL Websites
It’s trivial – edit the properties of the website binding in IIS and select the checkbox “require server name identification”. Now you can assign a unique certificate to the binding – job done.
Please for goodness sake, don’t manually change the host name field in IIS – if you have to do that, you’ve probably not set the zone up right in the 1st place. IIS should be driven as much as possible by SharePoint as a best practise for all sorts of reasons, and that includes hostnames.
But anyway, with server name indication enabled + a host header, you can now pick a different certificate for the binding without affecting the other sites.
And configuring multiple certificates for a single IP address, dear SharePointers, is as easy as that.
Here we have two SSL sites, each one with its own certificate, on the same IIS box. Hurrah.
What Alternatives to SNI Are There for Running Multiple SSL Sites?
Good question – maybe you don’t want to risk the client incompatibilities with Server Name Indication and can’t implement a default website for whatever reason, maybe because you’re trying to run multiple SharePoint applications so don’t have a “default” option.
The alternatives are just as before. Either a single certificate with a wildcard common-name for all IIS sites, a single certificate with alternative names for all sites, or one IP address + DNS A-record + certificate per IIS site you want SSL for.
Cheers,
Sam Betts