More SSL Issues After Server Upgrade

I'm having similar troubles as discussed in this link, http://www.zen-cart.com/forum/showthread.php?t=184078&highlight=ssl+certificate, and have done the testing, been on the phone and online support w/host, so far the only answer is to change all the links to https on the buy buttons for products that are on ezpages (am using hidden categories module and all listings are through ezpages . . . some ezpages are html pages, some are the zencart category/product listing, depending on products and how they need to be displayed).

Had other recent issues (http://www.zen-cart.com/forum/showthread.php?t=183552), which was able to be resolved, but there is still something I've got wrong somewhere. I've also done the http and https versions of the ssltest.php recommended in 1st post. My question is, when I'm changing all links to https, if there is an image that is being referenced, for example, src="store/images/myimage_01.png, would I need to go back and put the full https://www...... path in front of store/?

It also seems to depend on what browser it's in. Example, Safari in a mac is giving me the error, but Firefox is not. On a PC, IE is not, and SeaMonkey is. Thank you for any help.

Um ... "Buy Now" buttons on EZPAGES?

EZ-Pages are for content, not for products/purchases.

Possibly I have not set this up right, am using a combination of html pages for some of the products, depending on the product and display needs, and using the EZ pages to link to them. Am using the Hidden Categories to hide the categories from the store and displaying ez pages links in sidebar to simulate the categories. That part of things was working well, gave alot of flexibility where needed, and the products/cart/ssl was working great until the server move. They keep telling me it's a zencart issue and they also tell me the ssl certificate is pointing to the right IP, but I'm not clear on any of this, anyway, I will keep checking things that could be a problem, thanks.

Does login and regular checkout (normal products from product listing/categories) work fine, with the whole checkout process running in SSL?

If so, then perhaps you've hardcoded some paths in your ezpages content and will need to change that.
But, adding complete URLs where they are NOT already present is a step backwards, and the wrong direction to take, especially since that's likely to cause more problems at a future date if you move "again".

No. Mostly this is surfacing in Mac's Safari and PC SeaMonkey, though I haven't tried alot of other browsers except IE8 on PC and an older Mac Firefox. Though SeaMonkey (I use it for the SeaMonkey composer feature) is probably not a popular one, Safari is, and there is no telling what set up the customers will have and sure don't know why such a difference in browsers. I can recreate it all the time in Safari by clearing cache (if I've accepted the error once I need to clear cache, close/reopen, as I'm trying to experience what a first time customer would)

In Safari, for example, if I'm in regular products/listings it says http at the top and I can add listings to the cart with no trouble, but as soon as I click 'go to checkout', the url changes to https and the warning pops up.

Thank you for your help.

Update, I found some links that say they diagnose SSL, such as https://www.digicert.com/help and https://www.sslshopper.com/ssl-checker.html, both seems to give ok checkmarks to everything, correct name matching, etc., so it must be something I have done in setting up the store somewhere.

Without an actual URL to see it in action, I can't offer anything further.

Thank you, sent link to you via PM, site still under construction.

Your configure.php file has an inconsistency:

HTTP_SERVER has a http://domainname.com URL
but your
HTTPS_SERVER has a http://www.domainname.com URL

Why do you have www. in one, but not in the other? You will have fewer problems if you maintain consistency.
Your certificate is issued primarily to the www. version, so probably best to settle with that.

Sorry, thought I had corrected that the other day when you helped me in another post about returning customers not being able to login, but I must not have done it right. Have corrected it now, and it didn't seem to change anything, possibly I still have not made the proper corrections.

I'm getting no issues when adding to cart from a non-SSL page, using Safari 5.1 on mac.

Thank you for checking. Could it be my machines? Am using a PC and a mac and it happens in SeaMonkey on the PC, and Safari on the Mac, have cleared the caches and restarted many times, is there something else I can do? If it's just my machine, that would be great news. Thank you again for your help.

Still not resolved - if I have an url directly to a product, I can change it to https and the product will open up in the store listing. If I click on the item to the larger/detailed view, it switches to http. On the 'click here for more information' link, it also says http. Host tells me to convert all my links to https, which I've previously done, however, the problem is opening the https link in some browsers. That is where the security error kicks in. If the SSL is correctly installed and all is well, shouldn't the back and forth from http/https be seemless to the customer or am I misunderstanding somewhere?

Tested the browsers that give security errors with an url that is https, such as bank. No problem, the https site opened right up, was able to login, no security messages anywhere. Should have thought to do that from the beginning, to me that seems to indicate the problem is the store/SSL configuration, not the browser's ability to handle https.

In light of that, I found some further info, hoping it will help:

"The web site is using a trusted SSL certificate but it is missing a chain/intermediate certificate. Most trusted certificates require that you install at least one other intermediate/chain certificate on the server to link your certificate up to a trusted source."

And a very good link here, http://blog.alagad.com/2005/10/31/getting-rid-of-web-site-certified-by-an-unknown-authority-messages/ , that looks promising, but is way over my head.

Would a re-install of the SSL take care of the authority chain problem if it is the cause?

I will provide the info to host that other https sites work ok on the browser. Would be most grateful for any further ideas, links or info to be able to provide them.

Thank you again.

sparrowce:

if I have an url directly to a product, I can change it to https and the product will open up in the store listing.Okay. Not usually much point in doing that, but it's interesting to note merely as a troubleshooting step.
sparrowce:

If I click on the item to the larger/detailed view, it switches to http.Entirely normal, and entirely expected.> sparrowce:

On the 'click here for more information' link, it also says http.Entirely expected. > sparrowce:

Host tells me to convert all my links to httpsThat's overkill, unless all your product pages contain highly sensitive information that must always be encrypted both ways (to the customer's browser and back again to your server) ... which is extremely rare on product pages.
sparrowce:

however, the problem is opening the https link in some browsers. That is where the security error kicks in. If the SSL is correctly installed and all is well, shouldn't the back and forth from http/https be seemless to the customer or am I misunderstanding somewhere?If the SSL cert is properly installed and your store is properly configured, then yes it should go back and forth just fine without errors. Zen Cart will use SSL only on login/account and checkout pages.

sparrowce:

In light of that, I found some further info, hoping it will help:

"The web site is using a trusted SSL certificate but it is missing a chain/intermediate certificate. Most trusted certificates require that you install at least one other intermediate/chain certificate on the server to link your certificate up to a trusted source."And what has your hosting company said in response to that?
sparrowce:

Would a re-install of the SSL take care of the authority chain problem if it is the cause?Maybe. It depends who's doing the install and how much permission they have on the server. Your server's main administrator should be well-skilled in that area and know exactly what to do with the message you posted.

Quote:

Originally Posted by sparrowce

In light of that, I found some further info, hoping it will help:

"The web site is using a trusted SSL certificate but it is missing a chain/intermediate certificate. Most trusted certificates require that you install at least one other intermediate/chain certificate on the server to link your certificate up to a trusted source."

And what has your hosting company said in response to that?

No answer to that, it was not addressed, only re-iterated that the SSL was installed correctly, and it's true, those web tests I mentioned previously also agree the SSL seems to be installed correctly but it does not make sense to me that another https site would work fine and this not on some browsers.

So I took a different path and called RapidSSL support. They also said the SSL was installed correctly, but when I asked them about the chain situation, they said I might want to try re-issuing the SSL, if I'm understanding them right. They said re-installing might not clean everything out, but re-issuing would overwrite and apply the right chains. When I try to explain what they said, I can see I need to go back and get more understanding before attempting anything so critical and also will discuss with host before attempting.

Hope this makes sense, and thank you for your help.

Installing an SSL Cert requires 3 files. Sounds like you have the first two but are missing the third - CA.crt (Certificate of Authority). Ask your Hoster if they installed the CA.crt that came with your SSL Cert. That is presuming you purchased the SSL Cert and sent it to your Hoster for installing.

Thank you, will do that and report back. Don't know the answer to your last sentence, it was purchased through host, and I recall doing what was sent by RapidSSL at the time, and will check with them.

Update, based on feedback here, I checked with RapidSSL, they provided potential solution and host is in process of installing, if anyone bumps into this type of thing, below might help, presumably depending on SSL company. It looks like there are times things can look right and still not be right!

Thanks to all for the help and ideas.

(From RapidSSL Support)

The certificate is passing our SSL checker tool. Its properly installed, however older clients/browsers/machines which do not have our new root "Geotrust global ca" will not trust the current certificate path.

Instead of a reissuance, simply install our cross-root intermediate, which is included in the "bundle"

This will chain the certificate back to the previous Equifax root.

Get the bundled intermediate (for Apache) here: https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=AR1549&actp=search&viewlocale=en_US

Ask the host to replace the current intermediate file with this file and restart apache.

All is well now, confirming after host installed cross-root intermediate and restarted apache server, no more security errors on either browser. Hope this will be helpful if someone else comes across similar issue, thank you!