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
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
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:
- 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
- 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
Thanks for this, the asterisk trick saves me a lot of time.
Pingback: Tin Isles : Subject Alternative Names for SSL
Thank you 🙂 Solved a big issue for me.
you rock ty!!!
Pingback: TechNullogy » SSL Host Headers in IIS7 WITHOUT appcmd
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!
Great solution! I still think it’s strange behavior from IIS, though. Thanks for the information.
thank you! This helped us out immensely!
Pingback: How to configure/import SAN certificate in IIS 7.x? « TechOnTip Weblog
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
I think you may have just saved my company. No, I’m not kidding.
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.
Suggestion though it might be too late, please correct the text “SLL” to “SSL” in the article’s title.
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
You Sir, are a gentleman and a scholar.
Thanks, this was the thing I was looking for!!
Awesome – thanks!
Brilliant. Thank you for this
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?
Thank you very much, it’s very useful !
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!
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.
Thanks, really helped me
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 !!!
This is simply amazing! I was struggling with workarounds for this problem for quite some time. Thanks a lot!
YOURE A GENIUS!!!!!
This post saved me a lot of time. Thank you!
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).
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.
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.
Thanks, this was the thing I was looking for!!
This concerns any multi domain site, not only sharepoint.
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. 🙂
Great! I’ve never seen anywhere that mentions friendly name begin with *. Definetely you solved my problem, appreciate it, thanks so much!
You just saved my bacon, brilliant!
This is not working for me. The IIS7 site binding host name is still greyed out. Any ideas?
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?
Awesome when you can write content and have it used almost 5 years later. Thank you for putting it out there!
Article is very much informative and clear. Thank you for the steps. It saved my time and fixed my issue as well.
Thanks a lot
THANK YOU VERY MUCH!!!
Solved a big problem my.
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?
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).
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
Amazing – thank you!!!! One question … the first site shows green lock but second doesn’t? Any ideas?
We have no idea on the green lock. Usually that is a factor of the browser and the SSL certificate.
This is working fine Thanks **
Thank you SO much ‘ArmgaSys’ for sharing this. It really helped me out.
Really appreciate it!
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
Thank you very much for sharing this! It solved my problem 🙂
This is a perfect solution for fixing the DotNetCore bug (feature) that affects HTTPS bindings w/o a specified Host Name!
It’s useful and very details. Thanks again.
Pingback: IIS HTTPS Host Headers - Boot Panic