Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Setting up my test farm I have a scratch server that i've set up everything on except office web apps, i have that running on another server. I was finally able yesterday to configure a connection between the two servers with SSL, for testing i'm creating my own self-signed certs.

So i have a primary web application i set up yesterday that hosts my community portal, i was able to ensure that it was using SSL over 443 and communicating with the Office web app server to open documents. No problem.

Today i decided to provision in my User Profile service and the mysites, so i created another web application using SSL on 443 and setup a mysite collection in it for UPS to use. Provisioned the service and ran a full sync with AD, was abe to get into my profile site with little issue all looked well.

I moved on to Search and did the same for a search center web application over SSL on 443, had a bunch of issues with search being able to index the https sites. Ran an IIS reset and noticed that 2 of the web applications are not starting...one did but now i have problems with being able to assign certificates that i had created for SSL use to the web app they belong to in IIS, it keeps assigning it but overwriting all of the web apps that use SSL. Stating that i cannot bind more than one web app to 443....

This is my first go round with using SSL and SharePoint...in the past it was all HTTP 80 stuff and i was able to create several web apps on one IP address point them to 80 and all was well.

Is this not the case with SSL and SharePoint? Is there away to have multiple web apps running on a single server/IP using SSL? I hear wildcard certs...but i also hear harbar say they are evil....why?

share|improve this question

4 Answers 4

up vote 5 down vote accepted

When you have several different websites routing to the same IP/port then the only way IIS knows where they should go is using the host header (the site address)

Incoming             Host Header    Send to Web Application
192.168.0.1 : 80     websiteA.com   A
192.168.0.1 : 80     websiteB.com   B

However if you're using SSL then

  • The SSL certificiate is particular to the web application (A / B)
  • The host header can't be read before it's decoded with the SSL cert
  • BUT IIS doesn't know which cert to use until its got the host header - which it can't read without the cert!

Your solution to this is either :-

a) Use different IP addresses or Ports so IIS knows what goes where (SSL isn't restricted to 443, that's just convention - but using non-default ports is probably not an option if you have a non techie audience)

c) Use the same certificate for all sites so IIS already knows which cert to use before it knows what goes where. This can be a wildcard certificate if everything shares the same domain (*.yourdomain.com) or a Unified Communication Certificate (UCC) if it doesn't - but don't know much about these so your on your own.

share|improve this answer

Just to add what punchingInApepper already stated.

SNI is a wonderful thing and is available in IIS 8.0. It has been around for some time like punchingInApepper stated but I have runned into some issues with SNI and multi-webapplication farms which I have not seen documented before so a bit of a warning;

WebDAV (open with file explorer) will not function on a environment where all sites are SNI enabled. I circumvented this by unchecking SNI on one web application and after that it works.

Spence Harbar talks briefly about SNI in his blogpost about adding SSL to the Central Admin site which explains it quite nicely

http://www.harbar.net/archive/2013/02/13/Using-SSL-for-Central-Administration-with-SharePoint-2013.aspx

share|improve this answer

Actually,

The reason you can't use one IP was a fault of IIS. There is an extension of TLS that allows a hostname to be specified. This has been around for years and is supported by all major browsers. The good news is that the latest version of IIS that comes with Windows Server 2012 supports this.

So if you are running IIS 8, then good news, you can use 1 IP and differentiate the certificates by hostname.

To enable this all you have to do is go into IIS -> edit bindings, and check "Require Server Name Indication". This will switch the cert binding from IP:Port to Hostname:port, allowing for multiple web applications to use ssl with the same ip and port.

See: http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability

share|improve this answer

as ryan stated but there is a vital part missing for ssl! you need to add dns record for ssl aswell as adding the host header!

start -> admin tools -> dns

when the app loads, go into the server or add it in, expand "forward lookup zones" , expand the domain e.g. mydomain.com

if you click on the domain name, you will see to the righ some folders and files like _tcp , _udp ext.

what you want isto add a host, right click on an empty space and select "New Host(a)".

a new popup will appear, if your webapp is called "hello.mydomain.com" than in the first text box you add "hello" now add the ip address that its using!

in your hosts file on the server:

C:\WINDOWS\system32\drivers\etc

open up "hosts" (open with notepad++ or any other text document reader)

add in the IP and the name like so:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost
192.168.1.13      hello.mydomain.com
192.168.1.13    hellome.mydomain.com

save and exit, goto iis manager and enable the web application and it should complain about same ip address, do an iis reset.

if you havent already, before you do all of the above you need to change some settings in IIS manager:

in IIS manager goto "web sites" (expand) select the web app you want to change to ssl, right click and goto properties.

under the website tab, add the description if not there (mine is "hello"), the ip , tcp port (80) amd ssl port (443), click on advanced. If there is nothing in the "multiple ideentites for the web site" than click add. Select from the list of ip that you want, TCP (80) and add the host headder (full url (hello.mydomain.com)). click ok save and exit. the webapp will not run due to conflicting ip addresses and thats where you need todo as iv outlined above :)

as ryan noted that you need an ssl sert:

within directory security within IIS manager you need to add in the server certificate under secure communitcations. On my dev box I have different certs for different web applications (due to different langues). On the production server (int) we have a wild card cert and works well!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.