Problems since host upgraded PHP to suPHP

I’m having real trouble with my webhost since they upgraded to suPHP a couple of weeks ago. I have put in a load of support tickets but they have not fixed the problem yet. I wonder if anyone has any ideas about what is going on?

I am running ZC 1.3.9h on a Linux server. Everything was fine under PHP 5.2.11. Now that the host has upgraded to suPHP my SSL pages don’t work. When a session ID is allocated (visible as session ID appended to the URL), the SSL session terminates. If I am in admin, I get booted out and sent back to the admin login page. If I am in the shop front making a purchase, I get the “Oops your session has ended” error.

The webhost said they did take care of folder and file permission changes as part of the upgrade to suPHP. I think they automatically set all folders to no higher than 755 and all PHP files 644. May that is something to do with it??

My web host does not seem able to sort this out, can anyone offer some advice that will either let me fix it or that I could pass to the webhost?

The only significant PHP mod I have made to the standard 1.3.9h files is the one suggested by Ajeh here

You might see if post #6 from:
http://www.zen-cart.com/forum/showthread.php?t=153143

Thanks.
RatMonkey

I've had a look at the ZenCart FAQ and I suspect that my webhosts PHP session settings are incompatible with ZenCart. I have temporarily set "enable SSL" to false in the configure.php files while I try to solve this.

Can anyone advise me what settings I need to ask the webhost to set to allow ZenCart SSL to work on suPHP?

Thanks.

I have checked the Zen Cart FAQ on session problems in suPHP environment and asked my webhost to confirm about file/folder ownership and file/folder permissions. Zen Cart requirement and the webhost replies are as follows.

Zen Cart requirement:
a) you will need to make sure that your files and folders are owned by your username and not root
b) you also need to make sure that any folder that has .php files in it is set to no higher than 755 and .php files are set to no higher than 644.

Webhost Answer:
I confirmed the username and the filer permission are correct on the server for your account. The issue is occurs because of the shared SSL , please ask Zen Cart help whether Zen Cart does support the shared hosting SSL in suPHP and suExec environment.

Can anyone comment on this please, especially Zen Cart development team.

Thanks.

Zen Cart works well with a large number of sites using Shared SSL. However, not all servers are configured appropriately to allow for it.
Sounds like your server can't properly support shared SSL in its current configuration.

Since SSL Certificates are very inexpensive nowadays, your fastest, easiest, smartest and best solution is to get your own dedicated SSL cert for your domain.

Thanks Dr Byte.

I have a number of Zen Cart stores hosted with the web host and I don't really want to be paying for dedicated SSL certs for all of them (especially as they are not making any money at the moment). I only take PayPal so I don't have to have SSL for the shop front - I only use it for the admin logon so shared SSL is enough.

I can either get my webhost to change its settings, or maybe look for a new host (certainly a cheaper option compared to paying for a load of dedicated SSL certs).

Can you advise me what server configuration settings I should be asking for / looking for to enable Zen Cart to work under shared SSL in an suPHP and suExec environment?

I'm compelled to share an observation that there's not currently a plethora of people posting here complaining about server problems when using suPHP/suExec ... so that suggests to me that your host has made a leap into a space they don't know very well. They are the ones who should be finding and fixing their problem.

As for specifics to offer you in order for you to tell them how they ought to do their job, I'm sorry I don't have any to share. The hosts I've used appear to have done the job correctly.

As an aside, in thinking about this more, I do recall that several years ago when several hosting companies were starting to get their feet wet in this area that many stores had problems. You might find information in some of the older forum discussions. But I suspect that the hosts have kept much of that information private perhaps because they think it gives them competitive advantage.

Thank you Dr Byte, I very much appreciate your time and wise counsel.

In early March my webhost sent the following message to me:

“Considering the security loopholes/threats within php(DSO) as Apache Module, we'd like to notify that, we will be upgrading to PHP suPHP and Apache Suexec security module”

Since this change was made the shared SSL sessions on my stores have been terminating. For example when I make a purchase and click on the “go to checkout” button I get a message that says “Opps, your session has expired” or something to that effect. I am running Zen Cart 1.3.9h in all stores. PHP version is 5.3.8.

I have checked the folder and file permission levels and they are all no higher than 750 and 644 respectively.

I have had a brief exchange on this forum with DrByte who noted that no other Zen Cart users are posting about this problem, so he suspects the web host is at fault. I have checked previous posts on the topic but they all seem to be around file permissions being set too high, rather than sessions expiring.

I have put in numerous support tickets in to the webhost which are going nowhere (no response for 6 days now).

So I’m really interested to know how many users are running a store using shared SSL (not dedicated SSL) under the suPHP / SuExec environment, whether you had similar problems and how you resolved them.

I am already aware of two obvious solutions: a) purchase dedicated SSL, or b) change web host. However doing either of those will not resolve the underlying issue. I am after a technical solution to the current issue, rather than avoiding it by one of the above.

Thanks for your help.

If DrByte can't advise you, then it is unlikely anyone else can.

A host that does not respond to tickets in 6 (or more) days is a guarantee that your business can fail...

So... given that your business is at risk, why are you still with that host?

If it can be fixed by using a dedicated SSL certificate, why not just fork out the 30-50 bucks and be done with it? Is it really worth the headache to get that working?

Plus in the future, you will have PCI Compliance issues with shared certificates and you will be forced to use a dedicated cert anyway.

Schoolboy, Qdixon,

Thank you for your responses. Those are the a) and b) responses that I'm already aware of, however I'm trying to find the technical solution rather then bypassing the issue.

Maybe I just want to prove my web host wrong conclusively before ditching them? I'm certainly not paying for dedicated SSL when shared SSL should work. It's like buying a new new car for full price and the salesman saying "Oh, you want to drive it? OK, you need to buy an engine then - that's extra".

What I'm looking for is:

• Zen Cart users who use shared SSL under suPHP / SuExec and have had no problems, and / or

• Zen Cart users who use shared SSL under suPHP / SuExec and have had this session problem but have found a solution.

Thanks.

To answer your question directly, a shared SSL Certificate will work on all configurations that were listed in your post.

You must be on the shared SSL ip address and not a dedicated ip; also your host must enable the ability in WHM.

The apache/php configuration has nothing to do with the way virtual host entries are made in the httpd.conf file.

Thank you Qdixon.

Just a thought - is there anything I can do myself to the session settings in the PHP.ini file to help fix this?

Rat M.

Qdixon,

I passed your comment to the web host who replied:

The shared IP address of the server is [xxxxx] and the hostname of the server is [yyyyy] and the A record for hostname i.e [yyyyy] is set to point to [xxxxx].
Also, the ssl installed on server is configured as shared ssl under WHM as well.

[xxxxx], [yyyyy] obscured were ip address and https url.

So host thinks it should work, but it does not.

I'm thinking:

a) Can I tweak PHP.ini? or
b) Shall I try a fresh Zen Cart install?

I really would like to know if others are (or are not) having this issue.

Thanks

Ratty.

No it wont help by any of that. The server administrator has a couple options in WHM to allow the use of the server's shared certificate.

In "Manage SSL Hosts" your account must be listed using the shared certificate. If it is listed then you will need to go into SSL/TLS in cpanel and chose to activate the shared certificate.

If SSL/TLS is not in your cpanel, your host will need to do it.

The best option if your host doesn't know how is just to have them submit a support ticket to cpanel and they will direct them to the right place.

Qdixon:

The best option if your host doesn't know how is just to have them submit a support ticket to cpanel and they will direct them to the right place.

:D a very polite way of hinting at a worrying level of incompetence at your hosting company. I wish I had this degree of tact !

I'm still hoping to hear from store owners who use shared SSL under suPHP and Apache Suexec to know if they have or have not had this problem.

Thanks.

The Sumatran RatMonkey

A week now... and no fix to the problem yet? (first post on 1 April).

A week's worth of sales (or rather no sales) ... ?

Why are you persisting with this? Are you not more concerned about running a profitable business?

schoolboy,

Thanks for your concern, however SSL is turned off and I only take PayPal, so transactions are secure anyway over PayPal's SSL servers and the stores are operating fine.

The only risk is that user log in details are not secured. A risk I can bear for the time being.

Rat

DrByte, may I seek your advice once more.

I changd my webhost. The new webhost is also running suPHP and Apache suExec. (Looks like they all are). I have the same problem with shared SSL sessions expiring. Taking the admin area as an example:

if ENABLE_ADMIN_SSL = true

Case A: All four server define entries are set to 'http//www.mysubdomain.com'
Result: Everything works fine.

Case B: All four server define entries are set to 'https//mysharedssl.com/~myaccount/www.mysubdomain.com'
Result: Everything works fine.

Case C:
Two http server define entries are set to 'http//www.mysubdomain.com'
Two https server define entries are set to 'https//mysharedssl.com/~myaccount/www.mysubdomain.com'
Result: Sessions expire. I can log into admin, but when a click a link I get logged out. A similar thing happens in the shop if checkout SSL is enabled. When you click on "go to checkout" then the session expires and I get the "oops your session has expired" message.

It looks like the problem happens when moving between https and http servers.

Any idea what is going on?