Suddenly getting SSL Security Warning

I still don't understand "search your site". Was searching it through the developers toolkit a suffcient way to do that?

I recieved this from my hosting company. Only trouble is, I don't understand it.

"I have checked the url http://www.mydomain.com/shop/ and when I clicked 'login' option, it is redirecting to following url.

https://xxxxxx.nocdirect.com/~user/mydomain/shop/index.php?main_page=login

If you move the mouse over the links on left side, you can clearly see that your script is calling those links using http. For example, when you move the mouse over the link 'African Violets', exact url is pointed to as follows:

http://www.mydomain.com/shop/index.php?main_page=index&cPath=12

This is why you're getting warning like 'This page includes other resources which are not secure'.

You have to update all links in your code to use 'https' instead of 'http' to prevent this warning.

I have created a test page in 'shop' folder and I'm calling a secure url using the following code.

---

root@xxxxx [/home/sitefolder/public_html/mydomain/shop]# cat test.php

test

<body>

    <li> <a href="https://secure.jaguarpc.com/clients/">  Client Login </a> </li>

</body>

---

You can access it without any warning using the following url.

https://xxxxx.nocdirect.com/~user/mydomain/shop/test.php

If you replace 'https' with 'http' in the above code, you will get the same warning message."

Again, I really don't understand what they are telling me here. And I do not understand where I should replace the http with https.

Sorry, I know I have been a real pain here in trying to get this straight. I'm usually pretty good at reading through the posts and figuring stuff out for myself but this one has just got me stumped all the way around.

katco:

I still don't understand "search your site". Was searching it through the developers toolkit a suffcient way to do that?Forget it. It's a waste of your time. Things were working fine before, and until your host fixes the real root cause problem there's no need bothering with "checking images".
katco:

I recieved this from my hosting company. Only trouble is, I don't understand it.
The reason neither of you understands it is because you're both looking at the wrong things. It feels like neither are listening to any of the technical stuff I've said. Have you pointed your host to this discussion? or are you merely relaying partial comments to them?

Your host is entirely correct AND entirely wrong both at the same time.

Yes, your site needs to call its images using HTTPS addresses.

But what your host is completely ignorant of is the fact that the software you're running on your website, Zen Cart, will AUTOMATICALLY use those HTTPS links when your visitors click on links that need to be secured, such as login, create-account, checkout, etc.

What's BROKEN on your server is your server's configuration which allows PHP (and therefore Zen Cart) to properly detect that the page presently being displayed is in SSL mode, ie: an HTTPS address in the browser address bar. Once your host fixes that server configuration problem, THEN you'll immediately find that Zen Cart properly sets the <base href> link in your page source, and then ALL your product/template images will immediately be served with the HTTPS address exactly as your host is saying they need to be.

So ... go back to your host (give them the link to this discussion) and tell them they need to fix PHP so that your site can properly detect that it's in SSL mode. That SSLTEST.PHP script I pointed you to shows exactly how PHP is looking for about 20 different conventional ways in which SSL can be detected ... and ALL of them are clearly failing on your site. And that can only be fixed by your hosting company.

So, here is the outcome of their followup on your above post. I understand less and less as this goes along so I will just copy and paste it here:

"I have checked the ssltest.php and its shows as 'NOSSLL' detected. I have checked the script code and found that it is using '_SERVER' array which is actually created by web server not by the PHP and it heavily depends upon how web server is managing things in itself. I have found the mod_ssl is already installed on the server and we are running Apache 2.2.19 version. Please have your developer or vendor check their application and make sure that their application is compatible with it.

Secondly, you can verify that shared SSL Certificate is installed in the following URL:

https://xxxxx.nocdirect.com/

You can have your developer or vendor add the above URL in the configuration file so that scripts can use it instead of detecting the URL at runtime. "

From what I understand about zencart, none of the above really applies, but I don't really know how to explain that to them, I guess.

Zen Cart definitely relies on the $_SERVER array being present. Zen Cart receives that information from what PHP detects from the webserver software running on your server.

You said this DID work right up until recently right? So, your server WAS capable of sharing the $_SERVER contents just fine .. until recently.

Sort out with your hosting company why your server's PHP is unable to read the $_SERVER data from your server's Apache processes. After that your Zen Cart site will resume working normally again.

If they won't help you further, then you need to find another hosting company who will.

Thanks.

I suspect that the only way I will solve this is to install another store in a nearby directory and see what happens when I do that. It will either fix the issue (and then hopefully I can just move the new install over) or it will prove to them that there really is a problem. (I did write to them about your last response but I doubt it will solve anything)

It would be difficult for me to change hosts but yes, I suppose if I cant figure it out I will have to.

Would it be possible for someone to edit my posts above and remove my URL info from them? I dont see as how that is going to help anyone in the future and I feel the need to have it out of there for my clients sake.

Thanks for your time. If I ever figure out what the exact problem was, I will come and post it here in the hopes it could help someone in the future.

Well, I did a brand new fresh install and still have the same problem. If that does not convince them that there is a problem on there end, nothing will. (considering I run several other zencarts on the same server but different domains).

katco:

host:

I have checked the script code and found that it is using '_SERVER' array which is actually created by web server not by the PHP and it heavily depends upon how web server is managing things in itself.
Exactly what I've been saying all along. The problem is with the webserver configuration. It's not sharing the required information to PHP, or PHP is not picking it up.
Your Zen Cart site is simply a victim in that it can't get the information it needs.
And, since your server did give it previously, and apparently gives it fine for your other sites, something is amuck with whatever has been changed on the server, either for that specific domain, or for the server in general.

Can you put the ssltest.php file up on the site someplace, test it, and then PM me with a link to it so I can look at what it is showing?

Exactly, yes, I was totally agreeing with you.

I still think its in the php changes they made to my server. I was still running on php4 (with 5 available). I finally ran into a situation where I needed 5 on one domain and 4 on one and either on the one we have been discussing. So they changed the htaccess files on each domain to give me what I needed. and it worked for every domain except this one (still, I cannot say for sure that is when the problem happened just because I had not checked in a few weeks). So again, I think its in htacces somehow but I only understand enough about the htaccess to be dangerous.

PMing you the link right now. Thanks!

If you look at the output of that script, and compare the output of the http version and the https version, you'll see a few anomalies:

http version:
[DOCUMENT_ROOT] => correctly points to the same folder as your store's DIR_FS_CATALOG (see your configure.php file)
[SERVER_PORT] => 80 --- which is correct, since the page is on an http URL ("http" means port 80)

https version:
[HTTPS] ... is never mentioned
[SERVER_PORT] is 80, which MEANS http, instead of 443 (https means port 443)

[DOCUMENT_ROOT] => /usr/local/apache/htdocs ... which is completely incorrect since your site is actually in a completely different folder. Granted, this may be an anomaly of using a shared cert instead of a dedicated cert

If they can make the server properly show SERVER_PORT=443 or HTTPS have a non-blank/non-zero value, you'll be fine. Those are easily done with conventional server configurations.

Ok, will send this on to them. but to make sure, this is not possibly something I might have wrong in my config file?

Nothing to do with your configure.php files.

You said you/they changed the .htaccess files.
What's in the .htaccess files? ie: what changes did they make?

Ok cool, just wanted to make sure, because I did have problems with my configure.php that did involve my SSL URLs file during the new install and i had to adjust it manually. (clearly I typed something in wrong, or in the wrong place)

Thanks! Hopefully we will now have enough info for them to fix this! You've been terrific and extremely patient. :)

I'm not sure what was changed from how it had been previously. So I am no real help with that. But I did point that out to them and asked them specifically to double check it so I am assuming they did so.

They changed them, not me.

In your .htaccess the AddHandler line is all that's needed to force the PHP version.

The RewriteXXXXX lines are all to do with forcing a www. prefix etc. Try removing them temporarily and see what happens. (Can just add a # to the beginning of the lines to disable them).

If that doesn't help, then ...

The problem might be with inadequately-configured shared-SSL vhost. http://www.markandleah.com/misc/secureVhostsOnSameIp.php
So, that suggests that a dedicated SSL cert might help. But, if the problem is other misconfigurations then the dedicated cert won't fix it.

Again, if you've got other stores/domains on the same server, using the same shared cert, and they work fine, something's amuck with whatever they've got set up in your domain config.

I will try that, but they told me that the Rewrite was because either of a redirect I have or because this is a domain off of a main domain. When the Rewrite was gone, the shop was not accessible, if I remember correctly.

Ok, that didn't make a difference either way.

No, my other zencarts have a purchased SSL, not a shared one (and it would be different anyway cuz its a different domain). I would certainly buy one for this domain if I was sure it would fix it, but I hate to pay for it only to have it not work also. Know what I mean?

If they told me that would fix it, I would buy it tomorrow. But I know for a fact that this shared cert did work fine cuz I tested it 6 ways to Sunday.

My thinking also.

Ball's back in their court to configure the server correctly