Skip to main content

Installing a Unified Communications SSL certificate in Microsoft IIS 6.0

Just another working day in Redmond

Being placed in the dire situation where my project has to go live and is being served by a Windows server that has no administrator I was forced to open up my RDP client and venture back in time to the days of dinosaurs and IIS.

Unified Communications SSL Certificates are pretty much the only solution I could find to allow a single installation of IIS to share a single certificate that is valid for multiple domains that don't conform to a wildcard.  Whew, what a mouthful.  In other words if you have the domains http://www.ihatemicrosoft.com , http://www.apacheisfree.com, and http://www.graphicalinterfacesareforpansies.com you can use a SSL single certificate to secure them by setting up Subject Alternate Names.

Getting them up and running was a cinch for me made only slightly more complicated by previous failed installation issues which I had to identify and undo.

Firstly if somebody else has tried to install the certificate and failed it's not a bother.  Just get the exact details that were used and rekey it (if the issuer allows this).  GoDaddy allowed me to instantly request a new certificate which I was quickly able to install onto the "master" domain (the one that is not a Subject Alternate Name). Thus I was working from a clean canvas, without incorrect or expired certificates lurking around.

I really don't feel like replicating the bazillions of articles written for Microsoft IIS 6.0 so I'll link to an article that is pretty useful and is on a site full of useful articles - How To Install a Certificate in IIS 6.0 .  I personally had to remove the old (expired) certificate and issue a new CRF but hopefully you won't have to go through all that.

Now that you have it installed for your master the next issue is to set up the SSL bindings, which is the clever bit and the whole point of using Subject Alternate Names.  Basically the issue with using the same IP and port (443) for different sites causes an issue with other sorts of certificates for obvious reasons.  However the Unified Communications SSL certificate is able to validate a number of domains quite happily, we just need to get IIS 6.0 to bind the SSL 443 ports correctly to the host names.

You have probably already noticed that you can't set host headers for SSL in the IIS manager.  That's okay, there is a DOS tool to do this.  For non-Linux people the this might be very very scary, but you need to just drop to a command prompt and do a few things.  Before you do that, however, click on the root node of your domain list to view a list of domains.  Make a note of the long number and host header values that identify the site(s) you want to add as Subject Alternate Names.

Now pop to a DOS prompt and follow the advice given at Digicert which helps you to configure the IIS 6.0 SSL host headers using a VB script.  Basically the important thing is to run the following command from c:\Inetpub\AdminScripts (assuming a default IIS installation):

cscript.exe adsutil.vbs set /w3svc/site identifier/SecureBindings ":443:host header"

If you get an error when browsing that refers to an Invalid Host Header just check that you have correctly matched the site identifier number to the hostheader in the command above and rerun with the correct values to fix it.  You may need to stop and start (why does IIS not have a restart option Steve Ballmer?)  to get everything happy.

Labels:

Comments

  1. SSL Cert News21 March 2012 at 06:21

    Nice Blog!

    Your Blog has really core information about USS SSL certificate installation at IIS 6.0. We were looking for installation process for Subject Alternate Names (SAN) and your blog helped us for the same. We appreciate your efforts and Thanks for sharing it on your blog.

    Thanks - Cheap EV SSL Certificate

    ReplyDelete
  2. Unknown23 March 2012 at 10:19

    it's really valuable information about SAN SSL Certificate which supports multiple domains using single server certificate. Thanks for sharing it with US!

    Cheap SSL | RapidSSL

    ReplyDelete
  3. Sarah Whitehead4 April 2012 at 15:18

    Even after reading endless articles, the intricacies of ssl certificates still seem to be incredibly confusing to me.

    ReplyDelete

Post a Comment

Popular posts from this blog

Using Fail2Ban to protect a Varnished site from scrapers

I'm using Varnish to cache a fairly busy property site.  Varnish works like a bomb for normal users and has greatly improved our page load speed. For bots that are scraping the site, presumably to add the property listings to their own site, though the cache is next to useless since the bots are sequentially trawling through the whole site. I decided to use fail2ban to block IP's who hit the site too often. The first step in doing so was to enable a disk based access log for Varnish so that fail2ban will have something to work with. This means setting up varnishncsa.  Add this to your /etc/rc.local file: varnishncsa -a -w /var/log/varnish/access.log -D -P /var/run/varnishncsa.pid This starts up varnishncsa in daemon mode and appends Varnish access attempts to /var/log/varnish/access.log Now edit or create /etc/logrotate.d/varnish and make an entry to rotate this access log: /var/log/varnish/*log { create 640 http log compress ...
Post a Comment
Read more

Translating a bit of the idea behind domain driven design into code architecture

I've often participated in arguments discussions about whether thin models or thin controllers should be preferred.  The wisdom of a thin controller is that if you need to test your controller in isolation then you need to stub the dependencies of your request and response. It also violates the single responsibility principal because the controller could have multiple reasons to change.   Seemingly, the alternative is to settle on having fat models. This results in having domain logic right next to your persistence logic. If you ever want to change your persistence layer you're going to be in for a painful time. That's a bit of a cargo cult argument because honestly who does that, but it's also a violation of the single responsibility principal.   One way to decouple your domain logic from both persistence and controller is to use the "repository pattern".   Here we encapsulate domain logic into a data service. This layer deals exclusively with imple...
Post a Comment
Read more

Separating business logic from persistence layer in Laravel

There are several reasons to separate business logic from your persistence layer.  Perhaps the biggest advantage is that the parts of your application which are unique are not coupled to how data are persisted.  This makes the code easier to port and maintain. I'm going to use Doctrine to replace the Eloquent ORM in Laravel.  A thorough comparison of the patterns is available  here . By using Doctrine I am also hoping to mitigate the risk of a major version upgrade on the underlying framework.  It can be expected for the ORM to change between major versions of a framework and upgrading to a new release can be quite costly. Another advantage to this approach is to limit the access that objects have to the database.  Unless a developer is aware of the business rules in place on an Eloquent model there is a chance they will mistakenly ignore them by calling the ActiveRecord save method directly. I'm not implementing the repository pattern in all its ...
Post a Comment
Read more