Hi,

We have web server behind Cisco Load Balancer with SSL termination. IIS setup to listen on port 81 (unencrypted http traffic). SSL is installed on Load Balancer.

We are using DNN 4.09.00. We have configured the site setting as below to enable the SSL.

Admin -> Site Settings -> SSL Settings
- Checked SSL Enabled
- Checked SSL Enforced
- Checked Page settings -> Other settings -> Secure for one of the page

Now when I browse the page it goes into redirect loop.

Also If I browse https://preprod-www.aruba.com/images/login.gif - It's working fine

I have placed a temp.aspx at the root of website when I browse it https://preprod-www.aruba.com/temp.aspx - It's working fine. Also all other non secure pages are working fine.

I found some posts with the similar problem but non of them provides any information to resolve the problem or any workaround. If anybody has any insight into (including the core DNN team) how to help us solve this I would be very grateful.

Thanks,
Mahesh

Hi,

I'm faced with the same problem. I have an SSL certificate installed on my server. when i browse to the site using http://www.mysite.com everything works fine; same result when i try accessing the site using https://www.mysite.com , i'm able to access the site fine.

But as soon as I log in, -> admin menu --> site setting --> advenced settings --> CHECK "SSL Enable" and click update. After that i can navigate to the site, except after a I log in using my host credentials, as soon as click on any options under the either the HOST, or ADMIN (Site Settings for example) i get a Redirect Loop error from Firefox and my url in the browser begins with https://...

I have DNN 4.9.2 installed.

Please someone has any idea what is causing this behavior? DNN Core Team HELP please!

Thanks.

I think I've sussed it after having the same problem myself. The clue is the very first part of the first post - SSL termination.

SSL termination is an infrastructure configuration I was unaware of until today. It involves having a server that receives incoming traffic and forwards it to the web server and is usually associated with a load balanced situation. In this situation the SSL certificate sits on the server up front and performs the decryption of the incoming request. As the decrypted data hits the web server, that web server is unaware of the SSL status of the connection. Under these circumstances the usual methods of checking whether SSL is in use all fail:

Request.IsSecureConnection returns False

Request.Url.Scheme returns "http"

Request.Url.ToString() returns a string starting with "http://"

This causes the UrlRewriter HttpModule to attempt a redirect to a secure page, but on the receipt of the redirect the same logic is fired again, hence the permanent redirect.

IF the hosting provider forwards the SSL traffic from the SSL terminating server to the web server using a different port from non-SSL traffic then you may be able to detect that and define SSL/non-SSL URL settings containing port numbers to get around the problem. In my case the SSL and non-SSL traffic all comes in on port 80, so I'm a bit stuffed.

The recommendation in this circumstance (outside of the DotNetNuke community) appears to be to get the SSL terminating server to add a custom header to the incoming request and then test for the existence of that header to identify whether SSL is in use or not. This code would require customisation of the UrlRewriter HttpModule. It's also a problem in a shared hosting environment because it depends on your hosting provider 'buying in' to your problem and making the change for you necessary to add the header. It's at this point that good hosting companies are likely to stand out from the crowd, because my guess is that many will not help in this way. After all, changing the infrastructure you use to serve all your customers based on a request from a single one is a tough position in which to be placed.

I hope this makes some sense and in some way helps a few people. I'll post more if I suss how to get round it in my situation. Good luck to everyone else!

ASH