Restless C#ding

I'm surprised at the changes I'm still discovering in IIS 7.5 in Windows Server 2008. I've managed quite a few Windows Server 2003 boxes over the years, and now I'm exclusively on 2008 boxes. One of the recent surprises I ran into was just how different it is to set up SSL on a hosted site in IIS 7.5 . This was not exactly a simple task on previous versions of IIS, but it had become comfortable if only by rote.

Getting close is intuitive enough -- open up Information Services Manager, and click on the site you want to work on. You should see an SSL settings icon, but if you click on it, you'll get a surprising message:

"The site does not have a secure binding (HTTPS) and cannot accept SSL connections."

While this seems like an annoyance, it's actually a very powerful addition to the functionality that can be hosted from IIS. You want to handle FTP? Add an FTP binding and a managed assembly. Your own proprietary protocol? Go for it!

Back to the issue at hand, how to enable secure binding for a website. All you need to do is right click the site to edit, and choose "Edit Bindings". From here, choose "Add", and select "HTTPS" from the list, assign to the IPs du jour, and pick your certificate. I won't get into certificate generation / purchasing in this article, but there's a self-signed one installed by default that can be used provided a browser warning is not too intrusive for your purposes. 

Keep in mind that for a client-facing site, you should always have a legitimate signed certificate to maintain a professional atmosphere.

Once this is done, you can optionally go back to the SSL settings, and force a site to only function over SSL if that's your ideal scenario.

Your site should now be functioning over SSL.

While recreating some boilerplate code that winds up getting created for every set of apps -- including a membership provider, roles provider, etc, I initially went right for setting hashAlgorithmType based right on the enum.

More info about membership properties here.

This enum only gives three values -- MD5, SHA1, and None. The problem here is that both of those algorithms have been proven broken for some time (hopefully ASP.NET 4.0 will resolve this!). The answer of course is to use something with a little more difficulty to it... say by using SHA512Managed() and a salt. This is just another one of those times when setting values to canned possibles can be a dangerous move. This is especially true with authentication / encryption.

It seems the cardspace team has been at work simplifying the user experience for Cardspace prompts. See codename "Geneva". This looks pretty good; they've even included the new Geneva server for creating managed cards, which is something I'd like to explore at some point. I'm very curious what work if any has been done to integrate OpenID in conjunction with cardspace.

I'm not sure just how far Cardspace is penetrating, as I've yet to run across a site (aside from Windows Live, and even that's in beta, and has been since at least August of 2007!), which actually uses cardspace for authentication. I have found many articles from the 2006/2007 timeframe purporting firefox 3.0 support of cardspace, however the plugins online don't show them. Windows live login requires IE to even attempt a cardspace login.