I'm getting no issues when adding to cart from a non-SSL page, using Safari 5.1 on mac.
Printable View
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/ge...rity-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.
Okay. Not usually much point in doing that, but it's interesting to note merely as a troubleshooting step.
Entirely normal, and entirely expected.Entirely expected. That'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.
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.
And what has your hosting company said in response to that?
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.
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.Quote:
Quote:
And what has your hosting company said in response to that?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."
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.
Quote:
(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/suppo...ewlocale=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!