Even worse, it charged the customers credit card each time, so a persistent customer could wind up with multiple charges which you would need to undo!

Continue reading for the fix:

The Fix

Cart32′s support was not particularly helpful (both the Knowledge Base and their phone support), but fortunately the fix was not very hard. The error basically means that it had trouble opening some file.

In our case the name of the file that orders were saved in (Orders > Order Setting > Order Output File) had gotten goofed and was set to the url of the website. The fix was to change it back to “orders.txt“.

Did it work for you?

Please leave comments if you found this helpful. If you have some other website issue, cart 32 related or not, I may be able to help.

Doing impossible things with JavaScript and AJAX is my specialty.  Get in touch with me here.

As it turned out,  the server had been upgraded to TLS only for PCI-compliance, and some users had TLS disabled.

This article goes in to the how, they why, and the solution to fix https websites that aren’t showing up for some users.

The Change

Recently a client of mine made some changes to their secure server in order to comply with PCI regulations.

The rather cryptic error the PCI compliance scan gave was

Synopsis : The remote service supports the use of weak SSL ciphers.
Description : The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all.
See also : http://www.openssl.org/docs/apps/ciphers .html
Solution: Reconfigure the affected application if possible to avoid use of weak ciphers.
Risk Factor: Medium  / CVSS
Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)
Plugin output :
Here is the list of weak SSL ciphers supported by the remote server :
Low Strength Ciphers (< 56-bit key) SSLv3 EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
The fields above are : {OpenSSL ciphername} Kx={key exchange} Au={authentication} Enc={symmetric encryption method} Mac={message authentication code} {export flag}

They disabled SSL 3.0 and lower in IIS and set it to only accept TLS connections. (TLS is essentially SSL 4.0). This allowed them to pass the PCI compliance, but brought on new issues.

The Problem

Immediately after making this change, they began to get complaints from a few users who could no longer see the secure sections of their website.

Most of these users were on older versions of Internet Explorer, so they were first asked to upgrade to the latest version. This didn’t fix the issue for most of them.

The Fix

After some digging around, I learned the IE has settings for disabling SSL & TLS.

1. In Internet Explorer on the Tools menu, choose Internet Options.
2. Go to the Advanced tab.
3. Scroll all the way to the bottom and check ‘Use TLS 1.0‘
4. Click Ok. You may need to restart your browser.

I have no idea why that would ever get unchecked, but apparently it happens.  It’s also worth noting that upgrading to a newer version keeps the old settings intact.

Need help with a secure website?

I have significant experience in e-commerce and other security heavy areas.  If you need secure web development, I can probably help you out.  I understand https from the high level implementation right down to the bits and bytes (.doc file).