Hello,

First let us state we've searched the forums, we've searched the web, and so far nothing we've found as solutions, actualy work for us, rather the issue we have is not the same as the ones we've found on DNN's Forums, or other sites.

So we have one of our customer sites..   http://www.testmyteen.com.    We have a permanent redirect from   testmyteen.com  to www.testmyteen.com.  This should not effect our issue.

If we simply try to browse to https://www.testmyteen.com  everything works and an HTTPS session is established. However when we enable SSL on the admin side of the portal (we simply turn on the SSL feature, we're not specifying any force option or entering servers),  then enable a page to be Secure, the page ends up in a permanent redirect loop.

I believe it's on account of how DNN is trying to force itself to HTTPS..   It's doing a   http://www.testmyteen.com:443  which I don't understand.  I know the port is 443 for SSL, however simply redirecting to  https://   not adding he port should be, (according to other sources), all that is required to change to a secure mode.

I believe even now with SSL settings in Admin turned off..  You can try to go to   http://www.testmyteen.com:443  and you won't get the redirect loop, however you will wait indefinately for the page to load.

We've tried to inspect with Fiddler and sure enough, when we have our page which is secured, and SSL on..   I can see a request made to change to https://www.testmyteen.com   however then immediately after another request to go to  http://www.testmyteen.com, hence the redirect loop. 

https://www.testmyteen.com WILL work when SSL is on as well if you type your way to it.  However   http://www.testmyteen.com:443  never works.

This is a fresh install of 5.x, we have few modules installed (Indoo and a couple Data Springs). 

I know this is not an issue with AJAX, as 1.0/1.1 framework or ASP.AJAX was never installed on the server. We've insured all settings in web.config where appropriate reference 3.5.0.0 (there is only that and 2.0.0.0 - no  1.x even exist).   I've checked and run the Windows Uninstall Cleaner, to ensure nothing is even remotely installed for the ASP.AJAX.

HELP!!!!!!!   

PS. We've asked our server guys who we host with, and they don't have a clue....   Also our certificate seems to be missing information, I'm hoping that's just the type of cert we have... and not an issue with the SSL.

I think I've sussed it after having the same problem myself. I think it is dependent upon a specific infrastructure configuration that some hosting companies may use called SSL termination.

SSL termination is an infrastructure configuration I was unaware of until today. It involves having a server that receives incoming web 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 (used by the current UrlRewriter HttpModule in DNN)

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 find a way around the problem; however as this is a hobby site I'm limited in the amount of time I can spend on resolving it.
 

Has anyone come up with a fix on this? I have a similar problem after investigating this VERY good, detailed information (below).  Is the DNN crew going to work on this? I traced it down to the UrlRewriter module and this gave more insight into it. I have now 5 customers that want DNN for their sites, however since all is behind https:// and we go through a Big IP device that does this, we need to readdress if we can use DNN or not. :(

--------------------------------------
"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."