Greetings,

SSL and DNN. Have you ever tried to implement it? If you have, then you're familiar with the pain that is properly implementing SSL in a DNN deployment. For that reason, I've developed this guide to discuss things that I think are important to consider and may help others build better, more secure communities without a lot of headache.

It should be noted that this guide was developed for use in configuring IIS 6.0 on a Windows Enterprise Server 2003 with SP1 installed and worked for both DNN 3.2.2 and DNN 4.0.3. I make no guarantees of success on system configurations different from the one above.

The critical question

When you consider the security of your site's data, ask yourself this question: Which is more important, that data be available over SSL, or that data not be available over non-SSL? Read the question carefully, because it's a critical question. Too many times site administrators look to SSL-implementing solutions that provide a method for enabling SSL, but then do nothing to ensure that access to the data by any other means is totally turned off.

Now I'm not one for calling names, but in particular, there are some third-party SSL modules and code-insertion hacks floating around that claim a large range of functionality from providing SSL redirects via embedded javascript or vbscript in Text/HTML modules loaded onto pages in the DNN site to having entire modules that can control and manipulate SSL access in many different ways. The pitfall of all of these solutions is that in almost every case, work-arounds can be found that allow for access to the raw data without passing over the triggers and events that are intended to protect the user from an unsecured channel.

Turning on true SSL protection

So if triggers and events aren't such a good idea, what can we do? Well, there is an option in IIS 6.0 that allows an entire site to be accessible via SSL and only accessible via SSL. It's a great little option.

Simply follow these steps to turn on true SSL protection.

1. Right-click on your website in the IIS 6.0 Manager.
2. Select "Properties."
3. Tab to "Directory Security."
4. Locate the "Secure communications" grouping and click on the "Edit" button. Note: this will only be available if you have installed a SSL certificate for this site.
5. Check the option "Require secure channel" on the next pop-up window.
6. Check "Require 128-bit encryption."
7. Click "Okay" twice to return to the IIS 6.0 Manager.
8. Restart the IIS 6.0 service for good measure if running user-mode SSL. If you are running kernel-mode SSL it is a requirement. Note: this is not the same as stoppingg and restarting your individual site. See below for more information.**

Give yourself a pat on the back, your site is now entirely SSL accessible and restricted without the mess of a code hack or third-party module.

You can also test the implementation. Try accessing any part of your site using the non-SSL method and you'll be greated with a nice 403.4 error. Neat huh? Best part is, we're going to take this error and use it to our advantage to add even more functionality to our site. Read on!

** In some applications, moving SSL processes and references from user-mode to kernel-mode can have serious benefits in terms of resources. There's a full write-up here on Microsoft's web site. I leave the implementation of this option to the user as it may or may not work for your unique set of needs. It is good to know about though.

Dealing with the 403.4 error

So now we're setup so any request to https://www.soandso.com takes us to our site, but this is going to be annoying. How many of us actually go to websites typing in https instead of http? Not a single one I bet. Wouldn't it be nice if the error display was actually our site?

It ends up that we can use the 403.4 error to remap the user from the nasty display of the 403.4 error details to our https://www.soandso.com address! This is a long procedure, so try to follow each step carefully:

Step 1: Reconfigure the default file served.

1. Right-click on your website in the IIS 6.0 Manager.
2. Select "Properties."
3. Tab to "Documents."
4. Write down somewhere the list of files named in the "Default Content Page" group. You'll need these later.
5. Remove the existing file names from the "Default Content Page" group, and then add a file name not yet in use on your site. Note: for my implementation I used Redirect.aspx since that is what this file will be doing: redirecting.
6. Click "Okay" to return to IIS 6.0 Manager.

At this point, if you try to browse your site using https, you're going to get a new error. This is because you've specified the use of a default file that doesn't exist. If you try to browse using http, you'll still get the 403.4 error. Check this to make sure you're on the right track.

Step 2: Create redirecting file and configure SSL to allow non-SSL transmission of redirecting file.

1. Browse to your site's file directory using a file browser, and create an empty file matching the name that you specified in step1. For now, leave it empty.
2. Go back to IIS 6.0 Manager, and refresh your view of the root directory. The new file should now be listed.
3. Right click on this file.
4. Select "Properties."
5. Tab to "File Security."
6. Locate the "Secure communications" grouping and click on the "Edit" button. Note: this will only be available if you have installed a SSL certificate for this site.
7. Uncheck the option "Require 128-bit encryption" on the next pop-up window.
8. Uncheck "Require secure channel."
9. Click "Okay" twice to return to the IIS 6.0 Manager.

At this point, if you try to browse your site using https, you're going to get a blank page. This is because the default file now exists but nothing is in it. If you try to browse using http, you'll still get the 403.4 error. Check this to make sure you're on the right track.

You might be wondering why we're making this new file and setting it to non-SSL as opposed to just setting Default.aspx to non-SSL and putting our redirecting code in it.

Well, it's a good question and here's the problem. If you turn on "Require secure channel" at the site level, whatever default files you have listed will ALWAYS be served using SSL if they're accessed using the default mechanism. Even if you turn off SSL for the default file itself and leave it on at the site level, behavior is messed up. You'll observe that http://www.soandso.com/Default.aspx is browseable, but http://www.soandso.com is not because the later address is bound to the site's settings, not the file's.

This is where most people struggle in implementing SSL. You'll also find that if you turn off SSL at the site level, turn it on for everything under the site manually (which is a big pain), and then turn it off for Default.aspx, weird stuff starts to happen because the preprocessor inserts what should be protected information into an unprotected file and then serves that over non-SSL, constituting a breach.

Step 3: Replacing 403.4's error file with the redirect file.

Serious DKP modules for serious DNN gaming communities.

I'll try my best to give worthy responses to these worthy questions.

1. Yes, this configuration is such so that all pages/data transferred between client and server is done so securely. In particular, this solution avoids URL hijacking (https to http cross-over due to improper URL construction) and it avoids preprocessor injection (secure content injected into non-secure documents). It is true that mixed-mode can be encountered, but I'll address that in question 3.

2. By "this" I guess you're referring to implementing the site security option, correct? I would say at the least its something for a hosting site to consider as an option to offer to their customers. I myself have subscribed to a webhost4life account from time to time and I've always been impressed by the array of options they offer to their customers. I imagine in the near future the option will be there if it is not already.

There's many reasons why they might not implement the option though. Certainly there's greater load on the processing and memory resources using SSL which basically equates to needing more money to services the same number of customers. Perhaps they don't see the economical advantage? Lack of client demand? Who knows.

One could say that if your data is so sensitive that it must be transported over SSL, then you have no sense hosting that data on a remote site owned by someone else in the first place. Knuckle down and get your own pipe and servers.

3. The definition of the "secure and nonsecure content" environment in IE 7.0 is very odd.

For starters, in the past, it's been bugged. IE 5.0 and earlier versions would actually display this message on pages that were secure but used odd language references for Vbscript and Javascript even though there were no non-secure references anywhere in the code. Case in point. You can also get this message if the secure page you are loading uses frames and for some reason a frame call fails to load. Since the failed frame can't be verified as secure since it failed to load, the mixed-mode error is tossed up. Case in point.

So far, on my sites which are a stock install with just the modifications in the guide, the only time I encounter the mixed-mode warning is when I bring up the FreeTextBox editor control. Suspicious of the activity, I monitored my network both accessing the site internally and externally. No connections were made to or from my servers on an unsecure port. My guess is that the control itself either contains malformed code that triggers the message with a false "footprint" or it is accessing a codebase reference somewhere that uses an inactive http reference. I am actively working on eliminating the message from the control display as I type this message.

The real question is this though. What exactly is going on when any site page is delivered in mixed mode? That's a bit harder to figure out. Clearly in this case port http is not being accessed, at least not on my server. A thorough packet log also shows no clear-text information being exchanged. My gues sis that the error is based on an uncertainty, not an actual breach, so I'll find what's causing that and recode it.

4. Not a question, but since it appears you take offense, I offer this comment. A pitfall is just that, nothing more. If properly configuring things means that you could miss something that would leave your data exposed, it's a pitfall. The more opportunities to miss something, the bigger the pit. In this guide you flip a switch at the site level and mandatory https is on. Yeah, you could say that one act is a pitfall, but its a pretty darn small pitfall compared to the gapping holes out there created by various "solutions."

My guess is that people have and continue to get use out of the modules you and others have provided. This guide is simply an alternative for those seeking mission critical SSL implementation without having to buy a module or inject code. You offer your solution, I offer mine. Granted, I do think my approach is better for the applications with which I am faced. I imagine you think yours is better for the customers you seek to serve. No harm in that aye?

5. Not a question.

Hope I answered your questions.

Serious DKP modules for serious DNN gaming communities.

I found out the blank html page is needed. Apparently using the browser's back button behaves differently when using this control in this configuration. It's at that time that the blank file is used. Why there is this difference, I am not sure, but the file is defintely needed.

Serious DKP modules for serious DNN gaming communities.