SSL Sites with Hostnames in SharePoint 2010 and SharePoint 2013
As you implement SharePoint in your security-conscious enterprise, you'll run into a scalability issue: IIS 7.5 (Windows 2008 R2) requires dedicated IP addresses for each SSL site on each Web Front End. Remember that SAML claims require end-to-end SSL – if you're using SAML, you're affected!
Why is this a problem? Consider the most basic SharePoint architecture with a single Web Application:
This architecture uses 4 IP address: 1 for the VIP and 3 for the Web Front Ends. Next, you've followed the Best practices for My Sites article, and deployed MySites to a dedicated Web Application and you require SSL. Your architecture is now:
The IP footprint has grown from 4 to 8. If we added another web application requiring SSL, this would need a total of 12 IP addresses and there-in lines our scalability problem: In SharePoint on IIS 7.5 (Windows 2008 R2), the traditional IP address footprint is calculated with the formula
(Number of Web Servers + Number of Network Load Balancer Devices) * Number of Web Applications
A bigger, hypothetical network of 5 servers, 3 web applications and 1 NLB, your IP footprint would be a whopping 18 IP Addresses! In a non-SSL environment, you would just configure hostnames, but when you try to select the certificate in IIS 7.5, the hostname header gets grayed out:
So, what do we do? NetSH.exe! With NetSH, we can tell the machine to "encrypt traffic on <x> port with <y> certificate". Combine it with a wildcard certificate and all IIS traffic will be encrypted with the port, but you can still use hostnames. To execute, from an elevated command prompt, execute:
Certutil –store My
Location the applicable certificate on the output and notate the hash value (we're going to need it!). My hash is b063314fab008a45b5a1afb0f0dee45b59eb2584
Now execute the NETSH command:
netsh http add sslcert ipport=0.0.0.0:443
certhash=b063314fab008a45b5a1afb0f0dee45b59eb2584
appid={00112233-4455-6677-8899-AABBCCDDEEFF}
The command's breakdown:
add sslcert is self-explanatory
ipport=0.0.0.0:443
is telling NetSH the command applies to "all traffic from this machine on port 443"
certhash=b063314fab008a45b5a1afb0f0dee45b59eb2584
is the applicable certificate
appid={00112233-4455-6677-8899-AABBCCDDEEFF}
is an arbitrary GUID for identification. Pick anything you want for this value!
Or to summarize "Encrypt all traffic on port 443 with this cert" .
Now we can create a web application in SharePoint, choosing an applicable host header and port 443:
Create your site collection and browse it. Pull up the Certificate and wala! You've had the certificate applied (Note, I did NOT go into IIS and choose the certificate!).
This approach only works if you have one-and-only-one certificate per server, usually in an extranet/intranet environment. In a hosting environment, this may not be applicable unless all your sites are sharing an SSL certificate.
Question: Isn't this Server Name Indication, newly available in Windows 2012 / IIS8?
Answer: No. SNI is a many (certificates)-to-many (sites) solution. IIS7.5 cannot do SNI, but SNI can fulfill the same user scenario of this approach. If you're running Windows 2012, use SNI. If you're on Windows 2008 R2, use the above approach.
Question #2: I'm using dedicated IPs and want to switch to this approach. How do I do it?
Answer: If you have sites currently using 443, netsh will give you an error. To fix it, you need to remove all your 443 bindings and re-add them without certificates. If you use the IIS Admin GUI to do it:
- Change the current port 443 binding to a new port (4433 for example)
- Create a new binding on 443 with the specified hostname (but do not select a certificate!)
- Delete the 4433 binding and proceed with your netsh commands
As an alternative, you could use APPCMD or PowerShell to do the same thing; the end result is what's needed: no bindings on 443 with specified certificates.