I have the same problem for the last 2 days. The issue appears to begin exactly on April 1st. Now trying to debug the .php fullfilment script using FastSpring's editor. I found that curl_exec() fails for some reason. curl_error() returns this: "Received fatal alert: handshake_failure". Looks like something is wrong with SSL/TLS/certificates on either FastSpring or LimeLM servers.
Licenses no longer get generated through FastspringSolved
Hello,
We have made no changes to any of our systems, but all of a sudden, there have been no license keys generated through the php code provided with the WebAPI Pack for Fastspring any more.
The only error message we get through Fastspring is:
License generator did not have results. (dispenser=LicenseDispenser[o7mMQLFHQy6AChenCjnR5Q,])
Uncommenting the two lines to get an error message as mentioned in this article:
https://wyday.com/limelm/help/automate-license-generation-with-fastspring/
Does not lead to any printouts in the log.
We have had multiple orders with processed payments to which no license has been sent out.
Need help to get this sorted quickly, please!
There appears to be an issue with Java apps not being able to correctly handshake with our servers. (Yes, FastSpring uses a Java emulator of PHP.)
We're aware of the issue and digging into it. Also, contact FastSpring and alert them of the problem.
This is also affecting me (as Wyatt and Sam already know all too well). I've just spent the first few hours of my morning triaging both new and rebill orders, contacting folks who have placed orders to let them know the status and manually updating expiration dates on renewed licenses.
I have also contacted FastSpring to make them aware of the issue. As Wyatt said above, I recommend you all do the same so that they know to expect stuck orders for your accounts until this is resolved.
I'm hoping that wyDay is treating this as the blocker-level service outage that it is for those of us who integrate with their APIs via FastSpring and (at least speaking for myself) external custom services implemented in Java.
> There appears to be an issue with Java apps not being able to correctly handshake with our servers
Yes, but what side has been broken, LimeLM or FastSpring? That's the question.
I checked the version numbers in the FastSpring's PHP editor (using curl_version() and phpversion()). Here's what I got:
PHP version: 5.5.0
CURL version: 7.16.0
OpenSSL version: OpenSSL/0.9.8g
Seems pretty old and outdated. Not sure if it could even support TLS 1.2 or TLS 1.3. And, according to this online scanner https://hackertarget.com/ssl-check/ wyday.com allows only TLS 1.2 or TLS 1.3 connections. Could it be the source of the problem?
That version of OpenSSL is ancient. It is not supported.
However, there's the question of whether that's actually what FastSpring is using. Maybe, maybe not. They're definitely not using PHP (it's an emulator of some sort). So, you might just be getting “fake values” that don't actually reflect reality.
Step 1 is for your to reach out to FastSpring and tell them to upgrade their network stack to use PCI compliant security. Because you're a direct customer of theirs they will listen to you. (We don't use them for payment processing.)
If they're really using that ancient version of OpenSSL, then they're out of compliance and could lose their ability to process credit cards.
We are still investigating the Java-side issue of TLS (SSL) handshakes with our servers (attempting to reproduce, finding workarounds, etc.).
Same here…we have 2 FS accounts and they behave the same.
Same answer:
- We're investigating.
- Did you reach out to FastSpring?
Same problem here since around April 1. Yes, we have contacted them. Just had to spend an hour manually emailing customers there activaiton codes, etc…
This is what FastSpring sent me:
This appears to be an issue with the third-party license generator LimeLM by https://wyday.com/. I would advise you to contact their support
:(
Top notch support. 🙄
same here, contacted fastspring, same answer… :-/
march 31rd, looks like release date / maintenance window to me…
We've got meltdown and loads of unhappy users. Please resolve ASAP. We've been here before with unannounced changes, come on Wyatt!!!!
Same answer:
- We're investigating.
- Did you reach out to FastSpring?
Answer
We've enabled compatibility with broken Java TLS implementations. This should also fix FastSpring while also ensuring higher security with proper TLS implementations.
If possible switch from using Java for any web API calls. Also, if possible switch from using FastSpring as a payment processor. Java's TLS implementation is less secure than all other mainstream implementations.
Thanks Wyatt, sorry for earlier outburst! All working well again at my end. To be honest haven't got the energy to move away from FastSpring right now although it is something I have thought about more recently. What are the best alternatives now - any suggestions?
Thanks Wyatt. It's really distasteful to have to expend so much effort to fix someone else's issues. Much appreciated.
Thanks Wyatt. It's really distasteful to have to expend so much effort to fix someone else's issues. Much appreciated.
No problem. It's the nature of this business. You'd be shocked how often we have to workaround odd network, driver, and kernel bugs (in all levels of the stack – and in all operating systems).
Thanks Wyatt, sorry for earlier outburst!
That's OK, I understand how frustrating it can be when things are broken.
What are the best alternatives now - any suggestions?
Honestly, Authorize.Net. It's a slightly higher learning curve, but you pay lower fees and they're responsive to problems. It's what we use.
Back when we started our business them and one other (now defunct) company were really the only games in town. And there was PayPal too, but that reeked of free-for-all-libertarianism that we didn't want to touch.
But, even give the many choices today, we'd still choose Authorize.Net for the control we have over it, and for the lower fees and higher reliability.