Integration and Testing

[Lilith Administrator]

@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/

[wilgeno]

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

[Lilith Administrator]

That's really good news, thanks!

[wilgeno]

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

[tomemedia]

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?

[Lilith Administrator]

@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.

[Lilith Administrator]

@wilgeno You are a gentleman and a scholar. Thank you for putting this together!

[karenb]

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

[alkskd33]

We have updated our server to disable SSLv2 and SSLv3 and most effective use TLS1.0 however we preserve to get a "Unknown Error" whilst posting transactions thru AIM. We have examined the website online/server using the Poodlescan and SSLlabs websites and they say we're appropriate.