Using AAAR with honeycomb from a remote server

[digcat]

After investigating, the main issue when using AAAR from a separate VM, is how to run AAAR_extract.sh when running over a self cert or full certificated web service. Honeycomb incorporates SSL out the box, which is fine with CMIS, or when hitting the urls directly from a browser. However, AAAR_Extract.sh complains about the SSL and wont connect to the service.

[fcorti]

Hi Daren,

Here I'm with new tests about this issue.

Below you can find a Pentaho Data Integration job, developed to test the issue in a way not depending on AAAR (because the issue seems to be in the certificate verification developed by the standard java libraries, according to the RFC 2818).

I have found a lot of questions about similar issues in java and everything is confirmed also in my tests.
The issue seems so be generated from the standard verifications that allows self-generated certificate to be used, only under some conditions or with an "insecure" request.
The "insicure" request is the one developed using a browser (and this is why it works).
By default (as it is in the case of Pentaho and AAAR) the standard verification is used (and this is why it doesn't work).

I have developed also the easy test below:
Test n.1(insicure call that works)
curl https://192.168.1.6:443/alfresco/service/api/audit/query/%7Bapplication%7D?fromId=0 --insecure

Test n.2 (standard call that doesn't work)
curl https://192.168.1.6:443/alfresco/service/api/audit/query/%7Bapplication%7D?fromId=0
With the result below:
curl: (60) SSL certificate problem: self signed certificate More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

Coming to the possibile solutions I can see now (please, feel free to comment or suggest others).

Solution n.1 - Work on the self generated certificate to make it acceptable from standard validation tasks.
I'm not so expert on certificates to be sure if this is possibile or not with a self-generated certificate.
Waiting for an opinion (or contribution) I share the answer from Bruno below.
http://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found
What I understand from this read is that the self-generated certificate could be created to be accepted from a standard validation task.
Please confirm.

Solution n.2 - Act on the Pentaho JVM truststore (to establish a chain of trust).
In the spoon.sh script I could define the -Djavax.net.ssl.trustStore=... and -Djavax.net.ssl.trustStorePassword=..., according the option 1 described below:
http://stackoverflow.com/questions/2893819/telling-java-to-accept-self-signed-ssl-certificate
And here:
http://stackoverflow.com/questions/5871279/java-ssl-and-cert-keystore
Please, share the path of the keystore file containing the collection of CA certificates trusted and the password to access to it.
After this I could test it again.

Cheers.

-F

[digcat]

Howdy, thanks for looking into this, I kind of came to a similar conclusion, but after discussing with Martin, we may be better off putting all the connections for pentaho into a private network, so remove the need for ssl on the AAAR_extract.sh call. Anyways will be looking into this more next week, so will report back when I have more info.

[fcorti]

Just a brief update:
I have developed the solution n.2 (Act on the Pentaho JVM truststore) but error still there.

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching found

[digcat]

Hi Francesco

Haven't pushed ahead on this much, will be in Spain this week and will
work with Martin on this, this http://nacl.cr.yp.to/ might be a better
way, but will see how we get on.

cheers

Daren

On 13/09/15 09:35, Francesco Corti wrote:

Just a brief update:
I have developed the solution n.2 (Act on the Pentaho JVM truststore)
but error still there.

javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException: No name matching found

—
Reply to this email directly or view it on GitHub
#102 (comment).

[fcorti]

Ciao Daren,

Mine was just another test I would like to share with you. ;-)
Thank you for the update and we are in touch.

Cheers,

-F

PS: http://nacl.cr.yp.to/ seems to be nice.

[fcorti]

Hi Daren,
Hi Martin,

Today I have released the brand new AAAR v4.0 (http://fcorti.com/2015/11/04/aaar-v4-0/).
The major release includes a complete re-design of the ETL process to use REST services instead of CMIS libraries.
In my opinion this should solve the issue naturally.
Please let me know when (and how) can we test it.
As usual... consider me available for support.

Cheers,

-F

[digcat]

Hi Francesco

Thats great news, will check it out when I return, Im currently in
Sicily, back end of next week,

cheers
Daren

On 04/11/15 06:55, Francesco Corti wrote:

Hi Daren,
Hi Martin,

Today I have released the brand new AAAR v4.0
(http://fcorti.com/2015/11/04/aaar-v4-0/).
The major release includes a complete re-design of the ETL process to
use REST services instead of CMIS libraries.
In my opinion this should solve the issue naturally.
Please let me know when (and how) can we test it.
As usual... consider me available for support.

Cheers,

-F

—
Reply to this email directly or view it on GitHub
#102 (comment).

[fcorti]

Ehi, so happy cannolo for all of us. ;-)