I would like a secure login, but I don't want my customers to see the IE "This page contains both secure and non-secure..." dialog box. That scares them more that a non-secure login does.  When I tries setting up DNN with secure login via s 3rd party product a while ago I had to make sure that all of the images came from a https url.

Now I see that the DotNetNuke sites suffers from the same dialog when I come here. I hope you will have ways to make that work when DNN 4.5.4 ships

This really does not have anything to do with the way that SSL is implemented in DNN... it's simply a function of site content and configuration.  In our case, we serve the sourceforge.net image on nearly every page in our site (via the skin)... except for the Login page and the User Profile (also Registration) page.  It was removed from these two SSL pages specifically to avoid a warning on the secure page itself, which is particularly confusing.  However, upon login you are redirecting to a page which is then displaying an "insecure" image (the sourceforge.net image served from another domain).

In this particular instance (for us) serving that image locally is not an option as this is the primary means by which our rank is determined with SourceForge.  The only options would be to configure a specific post-login landing page (which can be frustrating when you're trying to navigate directly into secure content) or to give up serving the sourceforge indicator.

If you'd like to try a little test here to verify this:

1) Log out.
2) Click the Register button.
3) While on the register page (which is SSL enabled), click on the Login page.
4) When login is completed you're redirected back to an SSL enabled page (but more importantly, one not serving the sf.net image)

Cheers

Scott Willhite, Co-Founder DNN

Since the sourceforge logo is just about the very last thing on the page, an ad earlier on the page (if served from another domain) will trigger it first.  However the sourceforge logo will also cause that to happen as well (for most users), there is no difference between it and an off domain ad file.   There is also some variation in behavior depending upon your specific browser and version as well your personal (local) security settings.

I'm unsure if there is a particular reason why we're not serving all of those ads locally (most are).

To reaffirm the answer to the original question, DNN is properly handling SSL.  But you must determine what the appropriate security configuration is for your site depending upon your needs.

Scott Willhite, Co-Founder DNN