Call Us 203.687.6053

Blog with a focus on DotNetNuke news, tips and tricks, DNN SEO, and insights and opinions about the DNN community at large.

Securing DNN with SSL

Posted by Tom on Tuesday, February 20, 2007 to DotNetNuke, SEO, DNN Module Reviews, DNN Tips and Tricks

Since the early days of DNN, the forums have been littered with questions on how to secure (https://) a DotNetNuke website. Until this day this feature does not come “out of the box,” meaning you’ll have to reach out to 3rd party implementations in the form of modules or write your own add-on.

In this post I’m attempting to give a brief overview of what it takes to provide secure communication between a web browser and a web server hosting a DNN-based website. I do this by sharing my experience in utilizing the two most widely know SSL modules on the market today: SSL_Module by Thomas Thorp and SSL Redirect by Sanibel Logic LLC. Since both modules include comprehensive documentation, I’m not going into detail on how to install or configure either one of them, but rather focus on unique characteristics each solution brings to the table.

My quest securing DotNetNuke started back in the DNN 2 days. Besides running an ecommerce site, I have maintained a car dealership website over the course of DNN 2, 3 and now 4. This site is a perfect example for the need of securing individual pages of a website as opposed to the entire site. For example, this page contains a credit application which screams for security due to the nature of the information being collected. Other common scenarios include securing the login as well as registration page.

SSL_Module SetupWhen I first put the credit application live, the site was running DNN 2 and SSL_Module, which was the only module available at that time as far as I remember. The module installation was painless and after setting a few options, selective pages of my website were able to securely exchange information with the web server. Back then life was good.

Just recently however, I rebuild the dealership site on DNN 4 and ran into a road block with the SSL_Module. Technically the module still performs as advertised, but on secured pages you will end up with “unfriendly” URLs in the old style https://www.mysite.com/default.aspx?tabid=xx format. You may say “What’s the big deal?” and I agree, it’s better than an unsecured page. But as a web marketer I strongly focus on SEO and human friendly URLs.

A second issue I noticed is that the first page you request after navigation away from the secure page will also be served by an unfriendly URL in the above tabid=xx format, which will ultimately create duplicate content in the eyes of Google and company. I took my dilemma to Thomas Thorp via the Snowcovered Help Desk, but have yet to hear from him.

SSL RedirectMy search for a solution led me back to Snowcovered to take a closer look at SSL Redirect by Sanibel Logic LLC. This module runs completely off web.config and an additional XML configuration file called SSLRedirect.config. I personally prefer this approach as opposed to storing settings in the database. So besides adding a few lines to web.config and placing a .dll into your bin directory there is nothing to install. To specify pages to be secure you add the URL to the "UrlsIn" section of SSLRedirect.config. This is exactly the flexibility I was looking for and it eventually solved the issue of unfriendly URLs I encountered with the SSL_Module.

To wrap things up, both modules will get the job done. And after Mr. Thorp takes care of those “unlawful” URLs, it will be a matter of whether you prefer “click and save” setup and configuration over diving head first into XML files.

One last point I would like to make is that most problems that you may encounter while setting up SSL on your site are not caused by DNN or the modules mentioned in this post. Make sure you purchase a reputable certificate and install it properly on your IIS server (or have your hosting company take care of it.) Start installing either one of the above solutions only after you are able to successfully browse your site using https://www.mysite.com.

What have you learned while putting a lock on DotNetNuke? Let me know in the comments.


Permalink Permalink      Comments 7 Comments      RSS feeds RSS feeds      Email updates Email updates

email it!  |  it's del.icio.us!  |  digg it!  |  reddit!  |  kick it!  |  live it!
 

Comments

Comment By Chris on Thursday, February 22, 2007 at 2:27 AM

Hi Tom,

Thanks for taking the time to share your experience.

I'll be setting up SSL on a site next week and didn't know which module to choose. This is just the review I was looking for.

I'll let you know how it goes.

Chris

Comment By Tom Kraak on Thursday, February 22, 2007 at 8:44 AM

Thanks Chris, keep me posted.

Comment By Will Ballard on Monday, April 30, 2007 at 2:37 PM

We've gone around the whole "ssl" module and just added a little script to the skin code:


< %
If NOT Page.Request.IsSecureConnection Then
Response.Redirect("https://www.yourwebsite.com" & Page.Request.RawUrl.ToString)
End If
% >

(spaces were added to the script blocks here for safety sake).

I use a Server Side Include on every skin - one to redirect away from SLL if it's not needed and the above code to make the skin secure.

Then if the user wants a page to be secure - they just select the appropriately named "secure" skin and they're off and running.

Comment By Tom Kraak on Monday, April 30, 2007 at 3:38 PM

Clever. But with this approach you'll get mixed content warnings in IE, don't you?

Comment By Will on Monday, April 30, 2007 at 5:01 PM

Only if things aren't root relative in the skin (and any text html modules).

So far it's really not been an issue. When it has been I've been able to find whatever was hard url'd and fix it in minutes.

Comment By Cynthia Steck on Monday, April 28, 2008 at 4:25 PM

Nice job on the credit application page. I have a question about your credit application. Other than the SSL piece, did you have the application submit to any sort of credit verification process? Or was that just assumed to be handled upon receipt of the application in the dealership?

I am working on a quote for something similiar and was just curious how you have implemented yours.

Comment By Tom Kraak on Monday, April 28, 2008 at 5:58 PM

Thanks Cynthia.

No, the app does not submit to any credit verification process or similar. Dealership personal simply pulls the applications off the website for further processing.

Add a comment