Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Issues

Select view

Select search mode

 
6 of 6

Security provider list update for CFHTTP PayPal API SSL compatibility

Won't Fix

Description

REQUEST:

Addition of JsafeJCE cipher suite to the security provider list in Lucee.
This would bring the Lucee security provider requirement in line with Adobe Coldfusion 11.

ENVIRONMENT:

Lucee 4.5.2.018 on Windows 2008R2 with IIS7

ISSUE:

Affects OAuth2 via CFHTTP to https://api.sandbox.paypal.com/v1/oauth2/token endpoint
For many months this endpoint has been issueing tokens without any problems.

PayPal upgraded their certificates and SSL ciphers requirement in January 2016:

https://www.paypal-knowledge.com/infocenter/index?page=content&widgetview=true&id=FAQ1766&viewlocale=en_US&direct=en

All the relevant certificates [Verisign Class 3 G5 SHA-1] have been updated, using keytool to the cacerts keystore.
The error below still persists.
So I believe this is not a certificate problem.

I believe it is a problem with the security provider list bundled with JRE.
It does not contain the required cipher suite.

Interestingly, I updated my local testing environment from Adobe Coldfusion [ACF] 10 to ACF 11, and the problem dissappeared.
I noticed that the security provider list is much more extensive in ACF11, and includes a beefed up JsafeJCE cipher suite.
JsafeJCE is the default security provider in ACF11.

Test code:

<cfset clientid = "***">
<cfset secret = "***">

<cfhttp method="post" url="https://api.sandbox.paypal.com/v1/oauth2/token" result="test" throwonerror="yes">
<cfhttpparam type="header" name="Content_Type" value="application/json">
<cfhttpparam type="formfield" name="grant_type" value="client_credentials">
<cfhttpparam type="header" name="Authorization" value="Basic #ToBase64(clientid & ":" & secret)#">
</cfhttp>

<cfdump var="#test#" />

I am getting the following error:

Cause
string javax.net.ssl.SSLHandshakeException

url
string https://api.sandbox.paypal.com/v1/oauth2/token

Detail
string

ErrorCode
string 0

Extended_Info
string

ExtendedInfo
string

Message
string Received fatal alert: handshake_failure

StackTrace
string Received fatal alert: handshake_failure at sun.security.ssl.Alerts.getSSLException(Alerts.java:192):192 at sun.security.ssl.Alerts.getSSLException(Alerts.java:154):154 at

sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959):1959 at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077):1077 at

sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312):1312 at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339):1339 at

sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323):1323 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket

(SSLConnectionSocketFactory.java:394):394 at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353):353 at

org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134):134 at

org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353):353 at org.apache.http.impl.execchain.MainClientExec.establishRoute

(MainClientExec.java:380):380 at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236):236 at org.apache.http.impl.execchain.ProtocolExec.execute

(ProtocolExec.java:184):184 at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88):88 at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110):110 at

org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184):184 at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82):82 at

lucee.runtime.tag.Executor41.execute(Http41.java:1494):1494 at lucee.runtime.tag.Executor41.run(Http41.java:1482):1482

Details

Assignee

Reporter

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Priority

Created 4 February 2016 at 15:54
Updated 7 February 2016 at 22:00
Resolved 7 February 2016 at 18:58

Activity

Show:

Charles Robertson7 February 2016 at 22:00

Scratch that last comment. I am using Windows Server 2008R2. I see YUM is Linux...

Charles Robertson7 February 2016 at 21:54

Also, if I get the yum package manager, does it check for JVM updates automatically and install them automatically. If so, this sounds like the most efficient solution for my VPS.

Charles Robertson7 February 2016 at 21:36

Thanks for the JVM information. Very useful for future reference.

As far as the Railo/Lucee issue goes.

  1. PayPal updated its security policy in January 2016

  2. I was using Railo 4.2 [most up to date version]

  3. PayPal OAuth endpoint refused handshake

  4. I imported the latest Verisign root certificate into cacerts, as advised by PayPal

  5. The problem persisted and I have evidence that it was not a certificate related problem

  6. I updated Railo to Lucee, using the steps provided in:
    http://cfsimplicity.com/98/migrating-from-coldfusion-to-railo-to-lucee

  7. The problem persisted

  8. I uninstalled Railo & did a clean install of Lucee

  9. Problem solved

Andrew Dixon7 February 2016 at 21:14

- Updating from Railo to Lucee would have no bearing on this, it would have been a problem in Railo on an older JVM as it would in Lucee on the same JVM. It sounds like you are saying this wasn't the case and that it worked on Railo and then didn't on Lucee after updating, which I'm sure can't have been case, but please advise if that was the case as that would suggest a different underlying issue (not sure what).

How you go about updating the JVM depends on your OS and what type of install of Lucee you have, e.g. installed via the installer, custom install, express, etc... With the installer version, it comes bundled with a copy of the JVM, which is normally updated with each new installer release, and it is contained within the directory into which you install Lucee, e.g. on my Linux install, via the installer, it is here:

/opt/lucee/jdk/jre

Then in the control file, which the installer placed in /etc/init.d/lucee_ctl it sets the JVM path at the top of the script:

JRE_HOME=/opt/lucee/jdk/jre; export JRE_HOME JAVA_HOME=/opt/lucee/jdk; export JAVA_HOME

However I also have a JVM installed via the yum package manager that lives in /usr/lib/jvm/jre and if I wanted I could update the above settings to that location, e.g.:

JRE_HOME=/usr/lib/jvm/jre; export JRE_HOME JAVA_HOME=/usr/lib/jvm; export JAVA_HOME

and then restart Lucee (Tomcat) and it would use that JVM instead. Then when that JVM was updated by the yum package manager it would update the JVM on which Lucee is running.

Hope that helps.

Charles Robertson7 February 2016 at 20:02

OK. I understand what you are saying, but I am just trying to work out whether there is a way we can notify the average CF developer that updating from Railo to Lucee, may have implications in relation to this issue. It took me a few days before I found a solution, but I think the idea is to make the transition as seamless as possible, assuming we want current Railo users to migrate to Lucee, in the long term. I am not sure all developers understand the fact that the JVM needs to be updated separately. Sometimes, it is not practical for developers to use the clean install option, so I guess a proportion will try and update from Railo.
But, I do see your point about the two modules being separate entities.
For future reference, is it possible to update the JVM with an installer or will I need to use the command line?

Flag notifications