Learn More





DNN Community Blog

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Securing your DotNetNuke site in 5 simple steps

Let’s first look at the performance overhead of using SSL. There are a couple of great questions on this subject on Stackoverflow, here and hereOlder research seems to point to a reasonable amount of overhead, but a more recent interesting anecdote points to the opposite. In general, using current, modern hardware, there should be not a large impact on performance, however, for large and busy sites, it is always a good idea to include SSL in the load testing.

Pricing of SSL certificates should also not be an issue. If you are really on a low budget there are a number of free SSL providers available. This of course depends of the importance of the site you are working on, as you may not want to use a free certificate.

Now, for the topic of this post: how to set up a secure login for your DotNetNuke site. This walkthrough is largely based on a blog post by Troy Hunt, OWASP Top 10 for .NET developers part 9: Insufficient Transport Layer Protection. In this post Troy explains in great detail that it is not enough to just have a secure (SSL) login, but all subsequent requests also need to be secure, otherwise the authentication cookie can still be hijacked in certain situations (such as insecure WiFi connections).

Luckily, ASP.NET provides a very simple solution for this: modify the forms authentication setting in web.config to require SSL for authentication cookies. Once you do this, the authentication cookie will no longer be sent out over an insecure (HTTP) connection. This means that you can only log on to a site over an SSL connection, and once you change back to a non-SSL connection, you will be logged off automatically.

In order to set this up for your DotNetNuke site, you have to change this:

<authentication mode="Forms">
  <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies"   />
< /authentication>

in this:

<authentication mode="Forms">
  <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" requireSSL=”true” />
< /authentication>

This means that from now on, all authentication cookies will only be sent if the transport layer is secured. So hold of on making this change right away, as doing this will prevent you to log on!. First you will have to prepare DotNetNuke to work with an SSL only logon.

Step 1: Enable SSL for your website in IIS

I am not really going to explain that here, since this is a very common procedure in IIS. Seehere for more information about how to do that.

Step 2: Enable SSL for your site in DotNetNuke

DotNetNuke offers a comprehensive way to enable and enforce SSL per website (portal). For this task, it is enough that SSL is enabled for the site. In order to do that, go to Admin > Site Settings, to the Advanced tab, and open the SSL Settings section. In this section, check the option “SSL Enabled?”, and update the settings.


Step 3: Create a secure Login Page

By default the automatically generate login page (or popup) for DotNetNuke is not secure. In order to provide a secure login option, you will have to create a separate page, that has a Account Login module on it and that is marked as secure. Whilst you can create this page at every level, and give it any name, most logical would be to create this page at the root level and give it the name “Login”. Although DotNetNuke will handle everything automatically once you make every necessary adjustment, it gives me peace of mind knowing you are overwriting the automatic URL for the logon page.

In full, the new Login page needs these properties set:

  • Page name: Login
  • Root level (no parent page)
  • Permissions: view permissions for all users (or for unauthenticated users)
  • Secure: Secure flag must be set (this will ensure the page is only viewable using the HTTPS protocol, and DotNetNuke will automatically switch to HTTPS for this page)


  • Finally, put an Account Login module on the page.

Step 4: Use the new login page

Without “telling” DotNetNuke to use this new Login page, it will keep using the automatic login option. The Login page is a so called special page which means that the location of this page is stored per Site and can be used by any other process in any module or extension. In order to change the special Login page, go to Admin > Site settings, and open the “Advanced Settings” tab, and select the Page Management section. In this section, at “Login Page” select your newly created Login page, and update the settings.


Step 5: enable RequireSSL

Open up the web.config file for your application, and change the Forms Authentication node to look like this:

<authentication mode="Forms">
  <forms name=".DOTNETNUKE" protection="All" timeout="60" cookieless="UseCookies" requireSSL=”true” />
< /authentication>


There is one large caveat here. Since the Forms Authentication Cookie setting is done at the application level, in web.config, this solution assumes that you either have just one site configured in DotNetNuke, or that all sites can be secured with the SSL certificate that you applied to the IIS website. This means that potentially you would have to apply multiple SSL certificates to one IIS website.

SSL certificates are usually only valid for one domain, or for one domain and all its sub domains (the latter are so called Wild Card SSL certificates). Or you may be able to obtain a certificate for multiple unrelated domains (so called (UCC or SAN Certificates). The best solution though would be to run under Windows 2012, as this supports Server Name Indication (SNI), which allows you to apply multiple SSL certificates to one website (using different host headers). That is material for another blog post though!

Final remarks

I cannot begin to stress how important it is to secure your site for authenticated users. I love to read the blog posts by Troy Hunt, as he never ceases to amaze me how easy it is to infringe on the privacy of others, and how easy it is to break into other sites. Securing your site is just one small, but important step, towards the goal of a safer net.

Since there are a lot of SSL providers out there that even provide free SSL certificates, really no one should have a valid reason not start using one.

(this post is cross posted from my personal blog)


Gail Lampinen
What is the proper way to secure a site in DNN if you have a SAN certificate and your parent and child portals have the same IP but different domains?
Gail Lampinen Monday, June 02, 2014 8:31 PM (link)
Gail Lampinen
Could you please remove or edit my comment? That should have read, the proper way to secure a site in DNN if you have a SAN certificate and two different parent portals on two different domains, same IP address, IIS 7.5
Gail Lampinen Thursday, June 05, 2014 12:30 PM (link)
Alan murray
I was wondering if I set this up on my site and then later create other parent sites within the same DNN install (completely different urls) will they still use the SSL certificate if I don't use a custom logon page for the other parent sites? If it makes a difference our SSL certificate is a UCC certificate.
Alan murray Friday, April 17, 2015 8:54 AM (link)
Richard Harris
Here's a question: If you only give your site a TLS binding (IE so it's only reachable via SSL/TLS) then other than the cookie setting do the others even do anything?
Richard Harris Tuesday, May 03, 2016 6:30 PM (link)

Comment Form

Only registered users may post comments.


2sic Daniel Mettler (124)
Aderson Oliveira (15)
Alec Whittington (11)
Alex Shirley (10)
Andrew Nurse (30)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (21)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (203)
Chris Paterra (55)
Clinton Patterson (28)
Cuong Dang (21)
Daniel Bartholomew (2)
Dave Buckner (2)
David Poindexter (3)
David Rodriguez (2)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (74)
Geoff Barlow (6)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (269)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matthias Schlomann (15)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Mike Horton (19)
Mitchel Sellers (28)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Peter Donker (52)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (37)
Will Strohl (163)
William Severance (5)
Try Evoq
For Free
Start Free Trial
a Demo
See Evoq Live
Need More Information?