Using Host Headers and SSL in IIS 7 (without the ugliness of appcmd)

56 Replies

Microsoft SharePoint is an amazing tool for collaboration and information sharing. At AIS, we make extensive use of SharePoint portals to serve up a variety of informational goodies.

For those of us using SharePoint, we love the support for sub-domains for each SharePoint Web Application. It is very common to see SharePoint URLs such as

http://hr.mycompany.com
http://development.mycompany.com
http://portal.mycompany.com

Using Host Headers in IIS, implementing SharePoint Web Applications on a single IIS server using a single IP is a trivial mater. So trivial that the SharePoint Application Management wizard sets it all up for you!

Trivial; until you start to see sub-domains such as

http://payroll.mycompany.com
http://secure.mycompany.com

For secure data, such as payroll, most companies will start thinking about SSL to encrypt the data between the server and the browser. And so begins the trouble.

IIS, by default, only supports binding of an SSL certificate to ONE SharePoint web application (or any website on the server). Under default conditions, you must choose between securing the payroll or the secure site using SSL. You cannot bind the SSL certificates to both.

Of course, there are several well documented methods for binding SSL certificate(s) to multiple host headers. The problem is they require using the arcane command line function appcmd. Doable, but not trivial.

Fear not, there is an easier way!

IIS 7 supports what appears to be an undocumented feature for SSL and Host Headers. You simply preface the SSL certificate’s friendly name with an asterisk.

Here is how you do it:

Assumptions

You have a valid SSL certificate already installed on your IIS server
The SSL certificate matches your sub-domain URL
You have access to the IIS Manager
Coffee is brewing, ready to go when you are done

Instructions

Open Internet Information Services (IIS) Manager
Edit the Site Bindings for the website you which to assign an SSL certificate to
(right click, select Edit Bindings
Select the HTTPS port and select Edit
Note that the Host Name (Host Header) field is unavailable for editing
Launch the Microsoft Management Console (MMC)

Select Start –> Run
Type in “MMC” and hit enter
From the console, select File –> Add / Remove Snap-in
Select Certificates from the Add / Remove dialog
Select Computer Account when prompt for which certificates the snap-in will manager.
Select Local Computer when prompted
Click OK to add the Snap-in to the MMC

Locate your SSL certificate

For self-signed (SELFSSL), look in Personal
For installed / purchased, look in the appropriate folder the certificate was originally installed in

Right click on the certificate and select properties
Edit the Friendly Name field so the name starts with an *
Repeat steps #1 – 3 above
Note that the Host Name (Host Header) field is now available for editing

Happy Bindings!

(Coffee Time)

56 thoughts on “Using Host Headers and SSL in IIS 7 (without the ugliness of appcmd)”

russ August 1, 2010 at 5:25 pm

Thanks for this, the asterisk trick saves me a lot of time.
Pingback: Tin Isles : Subject Alternative Names for SSL
John September 5, 2010 at 9:24 pm

Thank you 🙂 Solved a big issue for me.
Shaune November 10, 2010 at 3:24 pm

you rock ty!!!
Pingback: TechNullogy » SSL Host Headers in IIS7 WITHOUT appcmd
Mike January 31, 2011 at 10:33 pm

You are a god! I was pulling my hair out for the last hour trying to figure this out. I was creating the cert w/ a wild card in the common name and not the friendly name.

Thanks a bunch!
Josh M. April 7, 2011 at 12:26 pm

Great solution! I still think it’s strange behavior from IIS, though. Thanks for the information.
Ken S. April 26, 2011 at 10:08 am

thank you! This helped us out immensely!
Pingback: How to configure/import SAN certificate in IIS 7.x? « TechOnTip Weblog
Alex F July 8, 2011 at 7:45 pm

You Sir, are a Saint. I was under tons of pressure to get this fixed and was stressing out (boss getting anxious). You have allowed me to accomplish my task, sip on my coffee, and surf Slashdot for the rest of the evening. 🙂
Pingback: Maximilian Krauß | Gewusst wie: IIS 7 und Wildcard SSL Zertifikate
Nearly Dead July 13, 2011 at 9:23 am

I think you may have just saved my company. No, I’m not kidding.
Ank September 7, 2011 at 2:26 pm

This was a life saver. Found it and is very useful documentation. Microsoft should make sure that this gets documented and published and provide a link to this website as an acknowledgement if not reward.
Ank September 7, 2011 at 2:30 pm

Suggestion though it might be too late, please correct the text “SLL” to “SSL” in the article’s title.
ArmgaSys Post authorSeptember 9, 2011 at 9:44 am

Ank,
Thank you for the heads up on our spelling faux pas. Over one year has passed since the articles original publication and you are the only person (that we know of) who has caught the error (ourselves included). The error has been fixed!

Signed: Embarrassed editorial staff who are overly reliant on F7
Stian October 28, 2011 at 3:50 am

You Sir, are a gentleman and a scholar.
Nicolás December 5, 2011 at 3:13 am

Thanks, this was the thing I was looking for!!
Jay January 3, 2012 at 11:55 pm

Awesome – thanks!
Norbert January 8, 2012 at 2:01 pm

Brilliant. Thank you for this
Dave January 25, 2012 at 8:08 am

Hi I am experiencing a problem. I had a https site running under my IIS. The root was the name of my computer. I used above method to rename my site. the name of the certificate and the name of my site match, but I am not able to access the webservice anymore. if I want to open the webservice in a browser. The browser asks for a certificate. After installing the client certificate I get the following message:

403 – Forbidden: Access is denied.

You do not have permission to view this directory or page using the credentials that you supplied.

Did anybody encounter the same problem, and more importantly does anyone have an solution?
gilax May 29, 2012 at 2:24 am

Thank you very much, it’s very useful !
MAS July 24, 2012 at 7:50 am

Excellent!
As for everyone else here, was struggling with a different “solution” to the appCMD (not that I mind working from the command line, just that it’s inconvenient for something like this).
Worked great and solved my problem!
Mark August 2, 2012 at 9:12 am

Excellent tip! I stumbled upon this but couldn’t figure out how to replicate it on another server. Changed the friendly name on the cert and it worked perfectly.
Parthasarathy K October 8, 2012 at 3:09 am

Thanks, really helped me
Alexandre S October 30, 2012 at 2:41 pm

This is really uncrediable. I think this is a bug of IIS, where the “Friendly Name” field was checked instead of the “Object” field.
Could explain why all of this is working wrong or with ugly command lines …
thank you !!!
Konstantin December 17, 2012 at 12:45 pm

This is simply amazing! I was struggling with workarounds for this problem for quite some time. Thanks a lot!
Bogdan May 1, 2013 at 7:45 pm

Just fantastic…
jordan May 5, 2013 at 5:33 pm

YOURE A GENIUS!!!!!
Grant Emsley May 22, 2013 at 7:06 pm

This post saved me a lot of time. Thank you!
Chris Means August 29, 2013 at 10:42 pm

Been looking for a way to do this for a long time (appcmd wasn’t working for us).

Pity I hadn’t found this article earlier (probably because I thought it was SharePoint specific).

Thanks!
Chris Means August 30, 2013 at 1:04 am

Ooops, spoke too soon. Though the change to the friendly name works for 1 certificate on one site, if we try the same thing on another site (on the same server) with a different certificate, we run into the exact same problem…it sees that the binding is already in use, and it changes the first site’s associated certificate to the new one.

Any idea how to get around this? 2 different domains, 2 different sites, 2 different SSL certificates, but HTTP & HTTPS binding required.

Our current approach is to assign a different IP to each domain, thus allowing us to simply bind to the IP address, but we’d like to avoid having to do that for each site.
ArmgaSys Post authorAugust 30, 2013 at 5:34 pm

Chris,

The solution we present only works for a single certificate. It works because the stream is decrypted by a known certificate which exposes the URL for host header processing.

In a scenario where more than one certificate is used, the URL is unknown (or more specifically, encrypted) which prevents host headers from working. Therefore, you cannot use host headers to select the certificate to perform the decryption step (the classic chicken and egg).

If multiple certificates are required, the only solution we are aware of is to map a certificate to an IP address.
Olivier September 23, 2013 at 8:53 am

Thanks, this was the thing I was looking for!!
This concerns any multi domain site, not only sharepoint.
Thom October 25, 2013 at 5:13 pm

I work for a cloud services group that hosts a client who recently expanded their operations globally. As part of that expansion, they needed to add a sub-domain for each and every country in which they did business. Had I not seen this article in my research, I was doomed to write a verrrrrrrrrrry long appCMD script long hand.

I thank you for the many, many hours of my weekend you just gave back to me. 🙂

Sincere thanks,
~Thom
Emrah February 17, 2014 at 2:17 pm

Great! I’ve never seen anywhere that mentions friendly name begin with *. Definetely you solved my problem, appreciate it, thanks so much!
Shedman July 17, 2014 at 12:03 pm

You just saved my bacon, brilliant!
Dave September 5, 2014 at 7:17 pm

This is not working for me. The IIS7 site binding host name is still greyed out. Any ideas?
Arut November 11, 2014 at 10:19 pm

Hey….thnx for the tip. I’ve tried this on the development server and it works fine. However, I’m trying to understand the basics behind how this works. After renaming the friendly name for the SSL certificate, I observed the other site that was set up to SSL with this certificate automatically associated itself to the new name of this certificate and both the site were up & running just fine.

Any idea whether IIS considers two different copies of the same certificate? Or is it just one of the cases where IIS displays the certificate name as same for both the sub-sites, but internally handles them the right way?
Duke March 11, 2015 at 1:11 am

Awesome when you can write content and have it used almost 5 years later. Thank you for putting it out there!
Saravanan S June 19, 2015 at 9:41 am

Article is very much informative and clear. Thank you for the steps. It saved my time and fixed my issue as well.
Naginder June 20, 2015 at 6:20 am

Thanks a lot
Daniel Macário August 11, 2015 at 2:41 pm

THANK YOU VERY MUCH!!!
Solved a big problem my.
mitzi September 23, 2015 at 12:12 pm

This worked for me, except the one site still throws a certificate warning. I can still get to the site after confirming that is what I want to do. Any idea why this might be happening?
The Error:
There is a problem with this website’s security certificate.
The security certificate presented by this website was issued for a different website’s address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.
Continue to this website (not recommended).
mitzi September 23, 2015 at 1:37 pm

Never mind my questions – cert was issued for single web site only. I am working on getting a multi-domain certificate now. Thanks.
Pingback: IIS7: can't set host name on site with SSL cert and port 443 – segmentfault
Pingback: IIS HTTPS Host Headers – segmentfault
Takwirira Rinomhota December 2, 2015 at 5:48 pm

Amazing – thank you!!!! One question … the first site shows green lock but second doesn’t? Any ideas?
ArmgaSys Post authorDecember 2, 2015 at 11:11 pm

Takwirira,
We have no idea on the green lock. Usually that is a factor of the browser and the SSL certificate.
Vijay September 26, 2016 at 10:24 am

This is working fine Thanks **
Dave February 17, 2017 at 6:24 pm

Thank you SO much ‘ArmgaSys’ for sharing this. It really helped me out.

Really appreciate it!
Raphael July 5, 2017 at 11:02 pm

Look that guy!!

Seems like me. He loves beer and coffee, I sayd.

Tks for support!
Pingback: Configuring a host name with a SSL Certificates in IIS 7 - James Callaghan
Ferdi Eenkhoorn August 2, 2019 at 12:08 am

Thank you very much for sharing this! It solved my problem 🙂
Beefydog October 22, 2019 at 5:45 am

This is a perfect solution for fixing the DotNetCore bug (feature) that affects HTTPS bindings w/o a specified Host Name!
Eddy December 12, 2019 at 5:34 pm

Thank you.

It’s useful and very details. Thanks again.
Pingback: IIS HTTPS Host Headers - Boot Panic