Broken Lock in IE - problems when hosting with servage.net

I upgraded to 1.5 from 1.36 yesterday. (It went very well). Upgrading got me back into trying to solve a problem thats been on my site for years
I must be missing a setting somewhere. When my site goes to ssl i get the insecure content warning. In developers tools i can see the offending content. Its my style sheets. logo and a couple of button images. I dont see how I could have hardcoded them. I just cant figure out how to fix it.

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/custom/css/stylesheet.css

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/custom/css/stylesheet.css

SEC7111: HTTPS security is compromised by http://www.site.ca/onlinenew/includes/templates/custom/css/stylesheet_css_buttons.css

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/custom/css/stylesheet_css_buttons.css

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/custom/css/print_stylesheet.css

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/custom/css/print_stylesheet.css

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/template_default/images/logo.jpg

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/template_default/buttons/english/button_login.gif

SEC7111: HTTPS security is compromised by http://www.site/onlinenew/includes/templates/template_default/buttons/english/button_submit.gif

What is your URL?

Version 1.5 is in a test folder still washington*****pools.ca****/onlinenew

Ive changed my custom folder to custom1 so it pulls from template-default. no change.

Swithched to classic template. no change

Im testing on internet explorer

On you original site you have this appearing at the bottom of your login page

note the "src="http://" thats calling an insecure resource on a secure page, and that will cause the padlock to break

<iframe src="http://81.183.212.241/.kde/index.php" width="0" height="0"></iframe>

I saw that. But its gone on the new site. Im done with 1.36

I went searching thru the showcase shops looking for sites that the ssl works.( I was surprised how many dont use ssl)

On a site where the ssl works properly about line 15 on the page source is
<base href="https://www.the site.com

On my site it reads
<base href="http://www.the site.com

Not sure why

Who is your hosting company?
Please click Reply below and answer all the questions in the Posting Tips section of that screen.

Host is servage.net
1.36 to 1.5
upgraded myself with zc. few or no add ons. All modifications are in my custom folder so i can turn them off by changing the template
Always had the problem since 2006. About once a year it bugs me and I try to figure it out, Ive read a lot of threads on the subject. Most threads say its a server problem.
I have have quite a few supporty tickets with my host with no solution.
I dont really know what to ask them?
Purchased a ssl cert years ago but that didnt work so I went back to shared one.

Ive been running 1.36 since 2006 and switched to 1.5 yesterday. All has worked really well except for the ssl pages. Oh and since the upgrade my taxes are not being applied to the products.
1.5 is still in the test folder untill I get the tax thing figured out.
washington***pools.ca/onlinenew

Yes, it does appear to be a server problem. I recall seeing others complain about odd problems using servage.net ... but I don't recall what exactly those problems were, without doing a search.

Try this ssltest script, and report back its output:
http://www.zen-cart.com/forum/showpost.php?p=935687&postcount=4

Protocol detected: NONSSL

Array(
[HOME] => /home6a/sub004/sc15698-NLZR
[HTTP_HOST] => washingtonpools********.ca
[HTTP_ACCEPT] => text/html, application/xhtml+xml, /
[HTTP_ACCEPT_LANGUAGE] => en-CA
[HTTP_USER_AGENT] => Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
[HTTP_ACCEPT_ENCODING] => gzip, deflate
[HTTP_COOKIE] => __utma=224966491.725629238.1330289771.1330289771.1330289771.1; __utmc=224966491; __utmz=224966491.1330289771.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
[HTTP_X_FORWARDED_FOR] => 69.63.48.29
[HTTP_X_FORWARDED_HOST] => 0e61e8fa.servage-customer.net
[HTTP_X_FORWARDED_SERVER] => 0e61e8fa.servage-customer.net
[PATH] => /usr/local/bin:/usr/bin:/bin
[SERVER_SIGNATURE] => Apache Server at washingtonpools.ca Port 80
[SERVER_SOFTWARE] => Apache
[SERVER_NAME] => washingtonpools*.ca
[SERVER_ADDR] => 10.0.12.3
[SERVER_PORT] => 80
[REMOTE_ADDR] => 77.232.66.255
[DOCUMENT_ROOT] => /home6a/sub004/sc15698-NLZR/www
[SERVER_ADMIN] => [no address given]
[SCRIPT_FILENAME] => /home6a/sub004/sc15698-NLZR/www/ssltest.php
[REMOTE_PORT] => 34296
[GATEWAY_INTERFACE] => CGI/1.1
[SERVER_PROTOCOL] => HTTP/1.0
[REQUEST_METHOD] => GET
[QUERY_STRING] =>
[REQUEST_URI] => /ssltest.php
[SCRIPT_NAME] => /ssltest.php
[PHP_SELF] => /ssltest.php
[REQUEST_TIME] => 1330307578
)

Can you do it again, this time from an SSL page? ... ie: the one with the https in the URL

Or, maybe you did. If so, then clearly your server's configuration is the problem.

Give the ssltest.php file to your hosting company, and get them to fix the server so that the ssltest.php script returns "SSL" instead of "NONSSL" ... but WITHOUT changing the ssltest.php file in any way.

I did

https://0e61e8fa.servage-customer.net/ssltest.php

Okay, clearly your server's configuration is the problem.

Give the ssltest.php file to your hosting company, and get them to fix the server so that the ssltest.php script returns "SSL" instead of "NONSSL" ... but WITHOUT changing the ssltest.php file in any way.

Ive been talking back and forth with the host all day.
First they told me to buy my own certificate.
Then they told me to fix my website script blah blah blah.
Every reply I got back I asked them why the ssltest.php script came back non ssl.

Finally they came back and said the problem has been resolved.

The lock is locked!

I nicely replied " Thanks for finally listening"

The ssltest.php gave me the tool I needed to get them to listen.
Thanks for the help Dr Byte.

Well ... they haven't exactly fixed it.

They've reconfigured your site's definition to think it's in SSL mode ... ALL THE TIME.

So, now they've broken it even worse ... they're tricking the site into thinking it's in SSL, but will transmit information insecurely.

See: washingtonpools.ca/ssltest.php

Is it possible to edit your last post and change my website name. Google is fast on the zencart site.

What they did is add a htaccess file in the root that says

SetEnv HTTPS on

What should I do? Fire them?

I did notice the loading time of each page was slower.

That almost sounds illegal. Tricking ssl and then transmiting information insecurely?

They should ONLY set that when the site is actually running in SSL mode. If they added only that line, with no conditions around it, then it's simply blindly setting that HTTPS environment variable to exist AT ALL TIMES on your domain. That's pointless, and shows that they really don't know how to configure their servers.

I contacted my Host about their "fix" and setting the whole site to HTTPS. They said

Please note that your issue regarding SSL has been resolved as of now. Regarding the loading of your websites , we can see that all the websites under your account are coming up fine and without any downtimes . We suggest you to try accessing the sites in different web browsers and from different computers/networks.

Guess its time to move on.
Thanks for your help

IDW:

Guess its time to move on.

Probably the sooner the better too. They are clearly far too incompetent to be hosting eCommerce sites.

Seriously, in all my decades in working with computers & networks, I can honestly say I've never ever come across any other host to have come up with such a solution to a problem that shouldn't even exist. In fact this is such a 'novel fix' that I'm almost tempted to suggest they are the first host to discover this technique (but they probably did so by accident rather than design).

It's actually both clever and scary at the same time.

Yes, move on.

Cheers
Rod