Thread for follow-up questions related to POODLE blog post at http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-POODLE-Inform...
11-04-2014 12:27 PM
@wilgeno -- for clarity's sake, you're asking for the root CA public keys, used for signing domain certificates, from developers using CF 8.0 or earlier, if they're running into connection issues after we decommissioned SSLv3, correct?
If you need Authorize.Net's instead, we use Entrust's 2048-bit root CA public key:
http://www.entrust.net/developer/
11-25-2014 09:04 AM
Sorry for not being clear, it's the Entrust Root CA I was asking about. Thank you for that link.
I did run some tests on CF8.0.1 (fully patched) running on JDK 1.6.0_45 (with the default CA Root Certs) and tried several tests from this setup and each test worked. In fact I could not even force a failed connection. So I am very certain that ColdFusion 8.0.1 with JVM 1.6.0_45 works fine even after Authorize.net disabled SSLv3. Please do not take this as a reason not to upgrade to a new version of ColdFusion. CF8 and older are no longer supported by Adode. CF9 reaches end of life at the end of 2014.
The issue our client was having on one server node in a cluster has been resolved. Another party altered the network default gateway thus the "connection failure" error we were seeing made sense.
However, the issue of having the JVM under ColdFusion potentially fall back to SSLv3 for some SSL connections (not Authorize.net of couse because you have that disabled) is still a concern that I am working on.
If others want help with ColdFusion connection to Authorize.net issues feel free to respond in here. I can usually help troubleshoot ColdFusion/JVM issues. (If the moderator doesn't mind.)
I'll update in here when I have a solution in place to prevent fallback at the JVM level.
Regards,
Wil Genovese
Sr. Web Application Developer/
Systems Administrator
CF webtools
11-25-2014 11:47 AM
That's really good news, thanks!
11-26-2014 08:56 AM
I've completed my research on how ColdFusion uses CFHTTP and the underlying Java layer to make SSL calls such as those to Authorize.net. Here is my blog post on our company blog that details my research, results and findings.
http://www.coldfusionmuse.com/index.cfm/2014/12/8/colfusion-jvm-versions-sslv3-tls
Regards,
Wil Genovese
Sr. Web Application Developer/
Systems Administrator
CF Webtools
12-08-2014 11:15 AM
A few months ago, I had a C++ routine using authorized.net in a sandbox account. I used WINHTTPCLIENT and Winhttp.lib to allow SSL communication. Now it does not work. What has changed? Any pointers on how to fix it?
12-08-2014 02:12 PM
@tomemedia It's hard to say without more details, but which version of Windows are you running this on?
Prior to Windows Server 2008 R2, there was no support for TLS, which we now require.
12-09-2014 02:52 PM - edited 12-09-2014 02:52 PM
@wilgeno You are a gentleman and a scholar. Thank you for putting this together!
12-09-2014 02:52 PM
Someone at Authorize.net ought to check the following links to see what grade is currently being reported for their servers with regard to the POODLE attack against TLS servers:
https://www.ssllabs.com/ssltest/analyze.html?d=secure.authorize.net&hideResults=on
https://www.ssllabs.com/ssltest/analyze.html?d=account.authorize.net&hideResults=on
More information is available here: https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
12-12-2014 04:51 PM