I’ve been continuously frustrated when working with the IIS tools for managing SSL certificates. There are issues when the two servers you are using are on different versions of Windows, or are on different Active Directory Domains. The best way that I have found to get around all of this is to export the certificate as a .pfx file and copy the file over to the other machine. This option can be hard to find because depending on how the cert was created and your version of Windows you may or may not have the option to export a .pfx from within the IIS admin tool.

There is a little known alternative method for exporting the SSL certificate that can help you get around these problems, so I’m going to give you a quick walkthrough tutorial about how to do this:

First, you will need to open the Certificates MMC snap-in. Click Start > Run and then type MMC and click Ok. Then click on File > Add/Remove Snap-in. In the window that pops up click on Add, and scroll down until you see the Certificates snap-in (not the Certificate Templates, or Certification Authority ones), then highlight it and click Add. A new window will ask you if you want to manage certificates for your user account, a service account, or the computer account. Choose Computer account and click Finish. Then click Close and Ok, etc. until you are back to the MMC main screen.

You will now see a tree menu that has Console Root at the top and “Certificates – Current User” beneath that. Beneath here you will see a number of folders. The certificate you are hoping to export could be in a number of places depending on your situation. The certs that I wanted to move were created by the Microsoft SelfSSL tool (which I will be covering in a later post) and they appeared under Trusted Root Certification Authorities > Certificates. Find the certificate you are looking for, right click and go to All Tasks > Export. You will be asked if you want to export the Private key, and you need to say yes in order to have a fully functioning cert on your new server that you want to serve web pages with. If the Yes option is ghosted out then that means that the MMC can’t find the private key. This happens with certs that you have installed from visiting web pages with Internet Explorer, and similar things. If the cert was one that you purchased from someone like Thawte or Verisign, or one that you created with SelfSSL it should be fine. After you click next it will ask you about the format you want to export. You want to choose .pfx, and make sure that Enable Strong Protection is checked and the other two are not. Click next, and it will ask you to choose a password. This is used to encrypt the cert, and you will be asked for this when you import the cert on the new machine. Enter a password and click next. Choose a file name and location and click next, then click Finish. If all goes well then you should see a pop up that says the export was successful.

Now use your favorite method to move the .pfx file over to the other server and use the IIS admin tool to import the key. Open the IIS manager, navigate to the web site that you want to import the cert into, right click and choose Properties, click on the Directory Security tab, click “Server Certificate…”, click next, choose Import a certificate from a .pfx file and click next, chose the path of the .pfx file that you copied over and click next, enter the password you choose when you exported it and click next, choose the port that IIS should use to serve SSL (this will almost always be 443) and click next, click next, click finished.

If this worked then when you go back to the “Directory Security” tab the “View Certificate” button will no longer be ghosted out. You can test to see of IIS is serving pages securely by opening up any web page in your site and add an “s” in front of the http. For example http://www.mysite.com/default.aspx would become https://www.mysite.com/default.aspx. If your browser shows the little lock icon (or whatever your particular browser shows for secure pages) then you are good to go. In Internet Explorer this will be near the bottom right of the browser window. If you mouse over the lock it should say “SSL Secured (128 bit)”, and if you double click on it, it should show you the details of the certificate that you installed on your server.

I hope that helps! In another article I’ll be explaining how you can create and install your own certificates for IIS using a tool called SelfSSL.

This is a little registry and event log issue that had me scratching my head before I finally figured it out.

I kept seeing messages like this one in my event log:

“The description for Event ID ( some number ) in Source ( some program ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: blah..blah…”

After that it would give a short line with a little bit of the kind of information that I would expect in an event log error.

What is happening here is that the sometimes the details of the errors that you see in an event log are actually stored in application’s dll on the system somewhere. You can see the message above if the event log viewer doesn’t have read access to that dll, or if the dlls don’t exist on the machine you are on.

For example, let’s say you have a server running MS SQL server and there are some event log errors you want someone to take a look at. You export the event log and send it to your co-worker to look at. The co-worker opens up the event viewer on their machine to take a look at the errors, but since they don’t have SQL Server installed locally, instead of the detailed error they just see “the description cannot be found”. The co-worker remembers he has access to a development SQL box so he copies the event log file over there and tries it again. Like magic, he can now see the full description of the errors!

There are other situations that can make this happen, but as far as I know this is the most common.

The starter site that Microsoft provides with the Commerce Server product is a pretty good model to follow, so the basic site functionality was not extremely difficult to produce. However, performance tuning was a very long and painful process.

To begin with we used normal Commerce Server objects to populate an ASP.NET menu control, without any caching at all. Predictably this approach brought the server to its knees as soon as even a light load was placed on it.

Next we tried using the Commerce Server caching objects. When a user visits the page the code would check to see if there was an object for the menu in the chache, and if not then it would hit the Commerce Server objects to pull the information and place it in the cache.

This method looked great at first, and we thought we had the problem solved. The performance was fantastic. But then we started noticing that the menu was dissapearing! It would be fine for a while but would start acting up when the load increased. Performing an IISreset would solve the problem, at least temporarily.

We tried a number of code driven approaches to solve the problem, including adding checks to examine the cache to make sure there were values there. Nothing seemed to work.

Finally someone had a bright idea after reviewing the code again. The cache code we had in place was reading the data, then creating the menu, and then storing the whole menu object in the cache. Instead, we started chaching only the raw data and then building the menu fresh on the page.

Performance was not quite as good as the previous solution, but has almost completely solved the dissapearing menu problem. I have seen the menu dissapear a couple of times since then, but it is very rare.

The only thing I can guess is that someone the cache was getting corrupted and not acting like it should after that. Our servers are in a web farm, so perhaps something gets borked when a user gets switched from one server to the next in the middle of a shopping session.

I’m going to be posting about Microsoft’s Commerce Server 2007. The company that I work for was part of the Microsoft TAP program to beta test the product and we were one of the first companies to launch a production web site on the product.

There are good and bad things about the product so I plan on sharing my rants about things that bug me with it, as well as tips about what I’ve done to get past common problems that I’ve encountered.

If you have questions for me about Commerce Server 2007, or have your own experiences to share, use the contact page to email me.

Have you ever needed to edit your hosts file (and if you don’t know what a hosts file is, this post is not for you) on a Windows machine ? You have probably noticed that because it doesn’t have a file extention, Windows Explorer won’t let you accociate an application with it so you are forced to go through the list and choose notepad every time.

It’s something that I have to do painfully often, and after a while I got tired of having to dig into that deep directory structure to open the file so I made shortcut on my desktop. A few days ago I clicked my link and was prompted to choose the application yet again when it occurred to me that a simple edit to the shortcut would solve the pain for good.

Right click on the shortcut and choose “properties”. In the box that lists the target file, it will say something like “c:\windows\system32\drivers\ect\HOSTS”. All you have to do is pipe that path into Notepad by changing that box to read ‘notepad “c:\windows\system32\drivers\ect\HOSTS”‘. Simple eh? Now it opens quite happily in Notepad and I don’t have to mutter at the screen when it asks me if I want to “search the web” to find an appropriate application with which to open the file.

Enjoy!