To anyone having trouble with CCBill and Cloudflare

I’ve been going back and forth with CCBill Merchant support for the last week, because our webhooks are not being called when people make purchases on our site. They kept telling me it was CloudFlare’s fault, and fed me all sorts of things to try that all involved removing security measures from the site I am working on. I did some searching and saw that many others were having issues with their webhooks going through CloudFlare, but none of the things the support staff was suggesting fit my case. I kept pressing them, and they said they were getting a 503 error back from our webhook, meaning that CloudFlare could not reach our server. The thing is, if someone couldn’t reach our server, then they wouldn’t have been able to make a purchase, and I could see them getting redirected back to our thank you page after the order was complete. After a little while, I convinced them to send me the body of the 503 response so I could see whether or not it was from CloudFlare. It turns out, it was generated from their own internal proxy server, and the error message was this:

“This proxy and the remote host failed to negotiate a mutually acceptable security settings for handling your request. It is possible that the remote host does not support secure connections, or the proxy is not satisfied with the host security credentials.”

This means that their proxy server either doesn’t support TLS 1.2, SNI, have an up to date CA list, or all of the above. Even after I pointed out that the message was from their proxy, and explained what it said, they continued to tell me that I needed to white list their IP and a bunch of other stuff. I ended up calling into the corporate office to talk to someone higher up than the normal email support. This person still didn’t seem to grasp what I was explaining to him, but said he would escalate it to the developers to look at. Now, today, I got an updated email saying that they have a known issue communicating with servers that utilize SNI. He said they were hard at work to fix it, but had not ETA on when it would be done. My guess is, they are dragging their feet getting software updated. I plan on calling back to talk to their management tomorrow, because everything about this is being handled poorly. I’m not happy with the fact that their system started getting errors back when we started forcing HTTPS use on our site, and they didn’t let us know. They don’t even seem to reply the transactions if there is an error. They do apparently log it, but it doesn’t trigger any alarms for anyone to look into it on their end.

If you use CCBill and have issues with their WebHooks, I encourage you to contact their staff and ask them to actually look into your issue, because it’s probably related to SNI.

That is quite the issue, the oldest browser that doesn’t support SNI is IE8 on Windows XP I also doubt their software is PCI compliant if it’s not fully updated, but maybe they’re backporting security updates.

The error they sent me reported that it was generated by Squid 3.1.23, which doesn’t support SNI. I believe SNI support was added in 3.5. I know 3.1.23 is what is shipped with RHEL/CentOS 6. If that is what they are using, then yeah, they would get bug fixes back ported to 3.1.23, but not the new features to support SNI. If RHEL/CentOS 6 is what they are using, it will reach EOL in November of this year, unless they pay for EUS support, and even then, all they will get is security related fixes. It all does make me question their PCI compliance, which will be brought up when I get someone in their administrative offices on the phone tomorrow.


This topic was automatically closed after 14 days. New replies are no longer allowed.