SSL Redirect Loop

[HonnDawg]

I am having problems securing my site. I am using ver 7.02. If I enable SSL, any attempt to go to an SSL page gets stuck in a redirect loop. I have read other forums of people having problems, but most of those are related to different host-headers (http://www.mysite.com; https://secure.mysite.com). That is not my issue, and I can't image that bug persisting into 7.02.

In Setting up the SSL, I have left the optional "SSL Domain" field blank, and I have specified the "SSL Domain" field as the same name as the non-SSL URL (my Secure and my non-secure domain are the same Uri). Both produce the same behavior.... Redirect Looping. It is as if a response.redirect is called on every page load (despite the fact that it has been properly redirected).

After the SSL is enabled, the only way to access the admin (as it is in the ablecommerce.config file as a secure page) is to open the ac_StoreSettings table and Set the SSLEnabled row = False.

What can I do to enable the SSL and prevent looping? Can someone please help me.

Thanks!!

[HonnDawg]

Any update on this... It is crucial that I get it up and running, and I am stuck without it.

Thanks Again!!!

[SteveHiner]

I'm having exactly the same issue. Any chance you found a solution or does anyone else know what is causing this?

We're really close to completing the site and releasing it to the public and this is a total roadblock since we can't test card processing.

I can browse the whole site just fine using https but we can't get to the Login.aspx page or the Admin site if SSLEnabled is True. I ran Fiddler2 on it and found there seems to be this infinite 302 redirect going on. I couldn't find any reference to SSLEncryptedUri in the code so I'm not totally sure how it should be set. Right now it's http://www.ourdomain.com - should it have "https://" in front of it? I added it and it doesn't seem to fix this issue.

Firefox sheds a smidge more light on the issue. Instead of redirecting forever it gives this error message:

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
* This problem can sometimes be caused by disabling or refusing to accept
cookies.

Any ideas? I feel like it's a really simple thing, I'm just not sure what's gotten out of whack.

Thanks in advance for any suggestions you might have.

[jmestep]

Have you done anything else, like switched from a temporary ip to the domain name? Does the domain in your license match that? Try adding demoMode="True" to the first line in your App_Data/ablecommerce.config file and if the site is OK after that, you have a licensing issue.

[SteveHiner]

First of all, thank you Judy for taking the time to help me out. I really appreciate it.

Ok, I just had some time to work with this again.

No, we have not recently switched domains at all. I checked the license and the domain name matches our site.

I added demoMode="True" as the first line in the config file and it appeared to make login work with ssl enabled, however it didn't automatically switch to https for the login page so I'm not sure if it indicates anything.

I updated our license key as well. The original license key was expired and though we had purchased another subscription I had never bothered to install it. Since you were thinking it might be caused by a license issue I figured I'd update the license. Unfortunately it does not seem to have any effect on the problem at hand. I looked at the commercebuilder.lic file and verified that the license expiration was updated and once again verified the domain name in the license.

Any other ideas?

[jmestep]

The only thing I would know to do would be to test a combination of SSL and demoMode in turn and see what breaks it. You could also try turning on debug and trace to see of you will get a message.
I think the last time I ran into the problem setting up a site had something to do with the SSL on the server, but I don't handle that and the sys admin fixed it. I just can't remember what he did, but I remember prior to that, we could get in with demoMode on. But with demoMode off, we couldn't with SSL. So in that case, it wasn't a licensing issue like I said earlier. (maybe)

[SteveHiner]

From the data I see while running Fiddler2 it appears that when a user goes to:
https://www.domain.com/Login.aspx
the server sends back a 302 redirect to:
https://www.domain.com/Login.aspx.

Note, those are the same URLs. IE will sit there for a few minutes following the redirects like an gullible child. Firefox is smart enough to immediately give me an error telling me that the server is redirecting in a way that will never work.

Can you give me any guidance on what part of AbleCommerce handles that redirection? Maybe I can track it down that way. If I can figure what does redirection it might help me figure out why it's redirecting back to the same URL. There must be something it doesn't like about our URL or our configuration that is making it think it needs to redirect when it doesn't.

I know SSL in general works on the site because I can browse the whole site using https just fine. It appears to only be pages that Able wants to force into https where it doesn't the wrong thing.

Thanks for the help.

[SteveHiner]

Able tech support just figured out what the problem is - we're hosting with Mosso and they use clustering servers. I guess the SSL features in Able don't work with clustered hosting.

I guess I'll talk to Mosso and see if they can help figure this out.

This really sucks. I don't want to go through the hassle of moving the site but at least we aren't in production yet.

[jmestep]

Have you put a machinekey in your web.config file? That might not be the answer to this, but you might need to do that on clustered servers- I know you need to do it with load balancing.

[Alan Rich]

<snip>
...
I know SSL in general works on the site because I can browse the whole site using https just fine. It appears to only be pages that Able wants to force into https where it doesn't the wrong thing.

I have a similar issue. Can navigate my site with either http:// or https:// directly. However, turning on SSL causes a redirect loop on all files and directories listed in the securepages section of the App_Data/ablecommerce.config. During the process of enabling SSL, the test url of https://www.mydomain.com works just fine. But after saving the setting to the database, all SSL pages cause the redirect looping. (including the Administration interface) The only way I found to regain admin access was to edit the Ablecommerce.config file to set securepages enabled="false" (Although Steve's suggestion of editing the value in the database seems to work as well).

I narrowed the problem down by playing with the settings in my ISA server. (I use SBS 2003, so ISA, Exchange, IIS, DNS and SQL 2000 are all on the same box, using two nics) The web server is on an internal ip. My SSL certificate and my AbleCommerce license are tied to "www.mydomain.com". I have a listener on ISA that send both http (80) and https (443) requests to my internal site on http (80) only. So a request for "http://www.mydomain.com/login.aspx" gets intercepted by the AC redirector and re-requested as "https://www.mydomain.com/login.aspx". The ISA listener then picks it up with the https protocol at port 443 and forwards to the web server on port 80 as http. AC intercepts again and converts back to https and an endless loop ensues. When I change the ISA listener to forward both http (80) and https (443) protocols, I get an "Invalid name on target principle" error due to the internal ip not matching the ip of my domain from the SSL certificate.

Is there an ISA expert that can help me structure some publishing rules to resolve this issue?

I purchased AC in June 2009 and spent then until now tweaking content. Just now started testing SSL in what will be the production environment and discovered this issue...long after my free support time and over 50% of the way through my license term. (My own fault) but I would like to use this $1000 purchase at some point. Any help is greatly appreciated.
Alan Rich

[Jeffr_ca]

Greetings all,

I'm having the same issue.

I got our new site operational in the past few days, which was working well. I just had an SSL Certificate installed last night. The site is hosted by Network Solutions and I'm also using them for the SSL Certificate provider. The site is http://www.woodessence.com. I switched on the SSL toggle in Admin and the test page worked fine. I had no value entered into the SSL Domain field. Followed through confirming that the link was accessible and then the Admin became stuck.

Manually Browsing to https://www.woodessence.com works fine, but pages requested by the AC 7.0.3 BUILD: 12458, CommerceBuilder: 7.3.12912.0 don't go anywhere....just a spinning "processing" window and ultimately a time-out by the browser.

To get the site oerational again, I manually adjusted the "securePages enabled=true" to "false" in the admin.config file as mentioned by the other user. Browsing to "https" pages still works.

I had not installed the Networks Solutions "Seal" onto the pages yet, but I don't suspect that to be the problem.

Any ideas on the solution would be appreciated.

Thanks,

-Jeff

[igavemybest]

Let me ask you this. I know you want the real answer to this problem, but maybe I can offer a solution instead. Is there a specific reason you are using cloud hosting? There is a LOT of misinformation out there about it's advantages. If you don't need cloud for a specific reason, you should just cancel and move to another host. I went through all the good hosts including discountasp.net, and eventually found arvixe.com . I have nothing to do with them, they are awesome and have real live people 24x7 and the servers never get maxed out and boot abusive ones. They have deticated also.

So, while I can sympothize, I thought this might work too.

[Jeffr_ca]

No, didn't choose it because of cloud hosting.

Had been using Network Solutions for various services for many years, including the previous static site. So I just kept it there....

-Jeff

[igavemybest]

Well, I certianly think this is an issue that needs to be resolved, but if you cant find the answer quick enough, there are always other options

[Jeffr_ca]

Not sure if this is helpful...but maybe is a clue for the AC folks.

While SSL was turned on in Admin, an attempt to use the "Contact Us" function recorded a failure in the error log:

Failure sending mail.; The remote name could not be resolved: 'smtp.g_youknowwho_mail.com'

The Contact Us email was never sent through. Switching the SSL function off again (by way of modifying the ablecommerce.config file), allows the Contact Us functions to work again.

-Jeff

[Jeffr_ca]

Another bit of information, if this helps....

I spoke with a tech at NS to discuss the problems and because the certificate appears to be working (i.e. https works throughout the site), he wasn't able to provide much assistance....although in conversation he mentioned that once the certificate is installed, the requests pass through a proxy server. I'm not sure exactly how this works or if this is typical with other hosting services or certificate installations.

But, this might explain why prior to installing the SSL Certificate on the host, if I used the Admin "Who's Online" report, I would get a list of anonymous users, showing a wide variety of IP addresses, from across North America (and overseas).

After the certificate was installed, running the same report, shows a list of anonymous users, but they are all within a very small range of IP addresses that point back to Network Solutions. I suspect that the couple of IP addresses that are being reported by AC are a proxy server at NS.

Despite AC listing the addresses from NS, my google analytics report for today is still showing "cities" from around the world. So it appears that the google page tracker is able to assess and submit the proper IP addresses, but AC is doing something different?

The only IP addresses outside of the tight NS range that show up in the report now, are returning visitors that had created their user credentials prior to installing the certificate. Anyone that creates a new login since the certificate was installed gets assigned the IP address pointing back to NS. They still appear to be able to create a new login, but their IP address is not accurate.

Any suggestions to getting this over the "hump"?

-Jeff