fcorti
commented
9 years ago 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
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.