AbleCommerce Shopping Cart Software

Hi,
We have a valid SSL certificate installed for the site we're building. (When I check in IIS manager on the server, Properties\Directory Security\Server Certificate shows it as being valid and you can view all its properties, etc.)

When I try to enable SSL in the AbleCommerce admin\Configure > Security > General, when I click Change and then click on the link https:// link it opens a new browser window that shows the correct address (https://www.highwaymedia.com/Default.aspx) but it is a blank page. I can connect to http://www.highwaymedia.com/Default.aspx with no problem, but the https:// link just shows an empty window.

IIS is current configured not to allow anonymous users since the site isn't live yet and is password protected. I've tried enabling anonymous users and then re-trying to enable SSL in AC but I get the same result.
Also, IIS Properties\Directory Security\Server Certificate\Edit "Require secure channel (SSL)" is current unchecked. I've tried checking it and re-trying to enable but then AbleCommerce gives me a "Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code retuned from the server was: 403: as soon as I clicke the Change button in admin\Configure > Security > General.

If anyone has any suggestions (or has solved the same problem) I'd appreciate any information you can give me.
Thanks,
Paul

I don't know if this is part of the same problem, but our issue is that as soon as we check to enable the SSL in AbleCommerce none of the styles or images in the administration will resolve correctly, so the page is unreadable.

The host says it is not them, AC says is is not the software, the only modifications we have made were through the online interface and were cosmetic.

we are experiencing a similar situation.

ssl goes, and the login screen and the checkout looses their css. We just transfered an ablecommerce site and the same problem started occuring on the new server. We've been fighting it for a couple days.

Ryan

What builds are you all running? Do you have a dedicated ip for the site? Is there a firewall involved or a non-standard port #?

I'm running 7.0 b10152. It is heavily customized, but it was running stable on our development enviroment, and on a previous staging server.

I've been working with our network admin, and he doesn't think it is ablecommerce specifically. He had seen the ssl error before the ablecommerce site was put on the server. Adding ablecommerce site to the server caused it to happen far more frequently, and the ablecommerce site is affected to a larger degree than the other sites.

It is a really strange problem because it doesn't cause any errors in the event logs, memory looks stable, and the processor doesn't spike. I have some legacy classic asp pages that are on the same site and those pages will be unavailable at the same time when the css is not rendering. The non-ssl pages will load correctly, but when you get the the login or checkout screens the css is not applied. The login still functions. It just looks like 1994.

The ssl can go down and come back in the span of a few seconds or a few minutes. Then eventually the ssl connectivity goes down and it won't come back up.

The server is Windows Server 2003, SQL Server 2005 back end and IIS 6 or 7 (not sure which). This box was stable for a long time and this type of error happened once, then it slowly started happening more and more. The temporary fix has been to cycle the app pools, but that doesn't fix it, it just brings the sites back up until it happens again. Our network admin has seen it happen with the firewall disabled, so it is not a firewall issue. Each site on the box has a dedicated IP. and ssl is runnign through port 443 for each site.

I have had the non-CSS display problem from time to time not related to SSL. It was always when there was a real slowdown on a network somewhere. I have seen it in other non-Able sites occasionally also when I am just browsing the internet.

We removed our 301 redirect software and we have not had the problem for a couple of days. We were using Isapi ReWrite 3.0. We are not entirely sure it was the problem, but the server has not gone down over the weekend. We will see if it goes down in the next couple of days while the load is higher.

"What builds are you all running? Do you have a dedicated ip for the site? Is there a firewall involved or a non-standard port #?"

Well Judy, I'm embarrased to say you solved our problem--the https port wasn't allowed through the firewall. It is now and everything works as expected. Thanks!
Paul

PLATFORM: ASP.NET
VERSION: 7.0
BUILD: 8272

I have made inquiries to the host as to any firewall or unusual port #'s.

This is what happens when a client decides to "save money" by not hosting with us. : )

Katie, it could just be a performance issue with the hoster as you know. And you're stuck in the middle because they might be blaming it on the software. You are on an older build, but I don't know if that would be a problem.
The only reason I asked is that because there were three of you posting and I was trying to see if it was a certain build.
Paul, I'm glad that helped. It was a shot in the dark. I'm allergic to firewalls and don't want to learn!

Both the host and AC are blaming "store customization" which doesn't make sense to me at all. We have only worked through the online interface doing the cosmetic work and have not even had access to the actual store files.

I really think it is an SSL issue with this directory...

http://www.mdseintl.com/App_Themes/AbleCommerceAdmin/

When I input:

https://www.mdseintl.com/App_Themes/Abl ... s/logo.gif

it flips over immediately to:

http://www.mdseintl.com/App_Themes/Able ... s/logo.gif

Does this give anyone a clue?

Hi,

I represent the hosting company involved with mdseintl and we are equally baffled. We have completely removed the entire site, all firewall rules and even the SSL cert. Then setup everything from scratch AND installed clean AC 7.0 version. Same problem.

If you visit any page on the site, with ssl disabled inside of AC, the page loads, the cert is valid and all looks perfect.
For example, you can visit this:
https://www.mdseintl.com/App_Themes/Abl ... s/logo.gif
and all is well. No redirect done to
http://www.mdseintl.com/App_Themes/Able ... s/logo.gif
as mentioned in the previous post. If you turn on SSL inside of AC then going to the SSL version of the link above, as previously stated, redirects to a non-SSL link.

In the exact same manner, with SSL OFF you can visit the Admin pages by using SSL links and images / css load just fine. Cert appears fine, pages load fine with all content.

The very second you turn SSL on inside of AC it all blows up.

As a hosting provider we are not the norm. We will admit ill configurations without hesitation. We just can't find any reason for any of this. We have another SSL enabled AC site running on same server even though it is in fact a different version of AC.

To test the certificate itself, which is from Comodo, I applied the working site's SSL cert to this clients site. The expected result of warning that cert doesn't match domain name being viewed was had. What wasn't expected, if SSL cert itself is faulty, was that the exact same results are had with this cert in use.

This customer is so frustrated and so are we. We can't make any progress on this. Can someon PLEASE advise what they think should be done or checked? We are not, as a hosting provider, finger pointers for blame. In fact, I would like nothing better than for someone to point the problem to us. We could then fix it.

Did you get the cert for http://www.domainname.com or domainname.com ? That would cause a problem.
Also, you might benefit by using software like Fiddler from http://www.fiddler.com to check the page requests/responses.

In your App_Data/ablecommerce.config file you will find something like this It defines the directories and files which are to be accessed securely via SSL.
Try adding the files/directories here.

SSL was issued for www, not the non-www url, which is in fact what is being used.

Sohaib,

Thanks for that.

I changed their config file from
<add path="Admin" recurse="true" />

to

<add path="Admin" recurse="true" state="Off"/>

and it worked.

Might I ask, why is a default install, with default ablecommerce.config file, incorrectly set to work with SSL?
As well, why is setting the requirement to OFF actually allowing AC's use of SSL?

I did the same change with the login.aspx page and the images/css now appear correctly.

I am waiting on customer to verify what I am seeing and will post back here.

Thanks SO very much.

Well this is strange. I don't think this is the normal behavior...
May be Logan can comment on this...

tannerjohn wrote:Might I ask, why is a default install, with default ablecommerce.config file, incorrectly set to work with SSL?
As well, why is setting the requirement to OFF actually allowing AC's use of SSL?

The securepages section of the config file tell our HttpModule which resources should only be accessed under SSL context. This configuration has no impact if SSL is not enabled through the AbleCommerce admin. As soon as you enable the admin side SSL setting, when the request is initiated we check the request details against this table. If we find a mismatch, we redirect the request to enforce SSL/non-SSL as specified.

When you set it to off, do your pages still get served under SSL context? That would seem odd. Also, in your case are the SSL and non-SSL domains different? (like domain.tld and secure.domain.tld)?

In reading this thread, I am imaginging we should include the "App_Themes" folder into the default configuration with a value of ignore. In other words, when CSS files are requested we should not care whether the request comes in SSL or not. There are a handful of other directories where it also does not make sense to enforce rules:

Ok, as you can tell, I was so happy to see images and CSS show up I didn't even pay attention to the fact that the pages were NOT being displayed in ssl. Duh.

Ok, I took original config file and placed your suggested changes. Now, all image and style sheets show, page IS in SSL and all seems well.

Is this something that should be in a default config file? What circumstances would a default AC v. 7.0 install NOT want those settings made?

Thanks, it appears now that all is well. I will still report if otherwise determined by the site owners.

Just to be thorough. I failed to answer our other question. The secure domain and non-secure domain are one in the same. Just straight http://www.Domain.tld

Thanks again.

We have been able to fix our problem as well, but it was not as simple as updating a config file. It turned out to be a server issue.

We were seeing the same issues as katiebruno with the ssl where css and images were not loading. One of the differences for us was that using a browser I could access most of the stylesheets directly over ssl. The larger css files and images would not display. Style.css was the only css file on the ablecommerce site I could not get to. It was not unique to the ablecommerce site either. When the ssl would not work for the ablecommerce site, other sites on the box would experience similar problems where large images would not be available over ssl.

We escilated the problem to microsoft and they ended up sending us a new ssl dll and changed some flags in the boot.ini file. Our network admin simplified the description for me. So my understanding is that the problem turned out to be a resource problem where the page file on the server was over taxed, and it would then cause the sites to be unable to access large files (I was able access 15k files but not 75k files) over ssl. At first glance it looked the same as katiebruno's issue, but turned out very different.

tannerjohn wrote:Is this something that should be in a default config file? What circumstances would a default AC v. 7.0 install NOT want those settings made?

I will be registering a bug report and these changes I suggested will become part of the default config. There is no reasonable circumstance I can think of where it would not be the desired setting.

Logan,

We have confirmed, even after restoring a previously customized site that had the same problem, the config file was the culprit.

I sincerely appreciate it, and so do our clients.