I'm trying to configure SSL on my local development machine so my adapters will be able to connect to the Bank-end service.
Our Back-end service team provided us with the following information:
ssl.keystore.path=conf/mobile.p12
ssl.keystore.type=PKCS12
ssl.keystore.password=PASSA
SSL ALias = AlIAS
SSL Password = PASSA
They send to use the "mobile.p12" file.
I added those configuration to my worklight.propeties:
# Worklight SSL keystore
#######################################################################################################################
ssl.keystore.path=conf/mobile.p12
#SSL certificate keystore type (jks or PKCS12)
ssl.keystore.type=PKCS12
#SSL certificate keystore password.
ssl.keystore.password= PASSA
In my Adapter.xml I added the following:
<sslCertificateAlias> AlIAS </sslCertificateAlias>
<sslCertificatePassword> PASSA </sslCertificatePassword>
When I deploy the project on my local Machine and try to login in the app through one of our adapters, I'm getting this error:
[ERROR ] FWLSE0152E: Unable to find certificate chain with alias: 'AlIAS' [project MobileBanking]
I tried to import the certificate to the default.keystore inside server > config by:
keytool -importkeystore -srckeystore mobile.p12 -destkeystore default.keystore -srcstoretype PKCS12
the result is :
Import command completed: 0 entries successfully imported, 0 entries failed or cancelled
which indicated it didn't work since 0 entries.
after running the keytool command, the error changed when I click login in our application to be :
Http request failed: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
which indicated that my configuration is wrong.
What am I missing?
thanks.
Based on the type of your certificate (un-signed, self-signed, CA-issued), make sure you are following the instructions from: Configuring Worklight Server
Specifically:
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.installconfig.doc/admin/t_configuring_SSL_WL_adapters_backend_servers_certificates.html
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.installconfig.doc/admin/c_ssl_config.html
Related
When executing an openstack command, it is failing to verify a certificate that was signed by an internal CA.
CentOS 7
Root CA installed in /etc/pki/ca-trust/source/anchors
openstack 3.3.0
$ openstack server list
Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. SSL exception connecting to https://XXXXX :13000/v2.0/tokens: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:765)
I hit the url from a browser and downloaded the certificate. Then ran openssl verify successfully.
$ openssl verify -CAfile /etc/ssl/certs/ca-bundle.trust.crt 10.92.50.11.crt
10.92.50.11.crt: OK
Does the root CA need to be placed in another area for the command line to pick it up?
Explicitly pointing at the CA certificate by setting OS_CACERT did the trick. Other people in my environment didn't have to do this. I'm not sure why it was necessary, but that's what fixed my issue.
export OS_CACERT=/path/to/ca.crt
Reference: http://docs.openstack.org/user-guide/common/cli-set-environment-variables-using-openstack-rc.html
I have a xmpp server (openfire 3.9.3) and trying to secure my non-ssl connection to ssl connection.
that's why i have created a self-signed certificate using java keytool as
keytool -genkey -keystore keystore -alias example.com
and i filled the several pieces of information required for the certificate.
the certificate successfully created. and i configured my server to access the keystore file but when restart my xmpp server it says
Unable to access certificate store. The keystore may be corrupt
what should i do for fixing the same issue ?
thanks in advanced
You can :
Delete certs in AdminWEB interface.
Restart openfire
Delete /opt/openfire/resources/security/keystore file
Generate new cert from web interface.
References : http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/ssl-guide.html
Hope this help...:)
Followed steps to integrate Worklight with backend system. In 5.0.6 adapters should support mutual SSL.
Import cert into default.keystore with alias named cert1
Modified adapter's sslCertificateAlias as cert1
When using Worklight Studio to run deployed adapter connecting with server, it is complaining about "Unable to find certificate chain with alias: 'cert1'".
What are the steps missing?
Check "ssl.keystore.*" properties in "worklight.properties" file, after it check if the cert exists in the keystore file using keytool:
keytool -list -keystore default.keystore
Here is are steps to configure mutual SSL between adapter and backend server with self signed certificates:
generate adapter's private key in "default.keystore" and export its public certificate
import adapter's certificate into backend truestore file
in case backend hasn't CA signed certificate:
generate backend's private key in its keystore file and export public certificate
import backend's public certificate into "default.keystore" file on WL server
Check worklight.properties file. Make sure that ssl related setting point to a default.keystore.
Figured out yesterday. Have to config certificate chain in proper way.
All certifications (server cert, first level cert and root cert) have to combine into one in special order and import with private key into keystore. Then use one alias name so that Worklight adapter could find it.
We are developing an application using tomcat and jersey.
Within this webapplication we need to connect to a https Website with a valid, not expired certificate.
If I do connect to this website locally via my chrome browser, everything works fine!
Unfortunately the tomcat server with our webapp throws an exception. We are using the Apache HttpClient (4.0) to connect to the https site:
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
The server certificate is absolutely valid and from thawte.
Three different online tools validated the certificate successfully.
Openssl has an issue, too and showing me three certificates but throwing a simple error:
Verify return code: 20 (unable to get local issuer certificate)
The problem with openssl seems to be that it uses the wrong path /usr/lib/sslinstead of /etc/ssl/certs. If I use the CApath argument pointing to the proper path, openssl works fine so may this be an issue with the httpClient?
So our code for the default client is quite simple:
client = new DefaultHttpClient();
response = client.execute(url); //this throws the exception
EntityUtils.consume(response.getEntity());
It's not an option to allow any certificates by implementing a custom TrustedManager!
Futher I read, that some CA's are not part of the JDK/JRE and so it's certificates should be imported manually into the keystore or use a custom one, but thawte is a well known CA and shouldn't it work on default?
EDIT
I did set the javax.debug properties in catalina.sh so that I have further information about the problem:
http-bio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: basic constraints check failed:
pathLenConstraint violated - this cert must be the last cert in the certification path
I would appreciate any help!
Thanks in advance!
Okay, I got it working!
Although thawte is a well known CA it seems that Java SSL did have some problems with it.
After downloading the ssl Certificate via openssl:
echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
and saving it into an pem file, I did the manual import into the java keystore:
keytool -import -alias myAlias -file theCert.pem -keystore lib/security/cacerts
I have no idea why java ssl was not able to validate the thawte certificate properly.
Listing the keystore showed me, that there are 7 thawte trusted certificates in the standard keystore but bizarrely it did not work until I manually imported the pem file
I am trying to understand your setup. You have a SSL certificate (issued by Thwate), installed in tomcat and you can access your site just fine over SSL using say IE or Firefox or Chrome.
But when you try to access it using HttpClient, you receive the above error ?
Is that correct ?
The error clearly indicates that your client does not trust the CA. But if the cert is signed by Thwate (and is installed correctly and is acessible via IE/Firefox etc), then it should work fine.
I followed the instructions given on this page to import the server certificate.
When I use keytool -list, I can see that the certificate is actually in the keystore. If I try to import the .crt file, keytool warns me that the keystore already contains the certificate.
Then I updated wrapper.conf with the two ssl options. I can see them on the command line of the Nexus process after a restart.
But when I try to add a proxy repo for the remote server, I always get sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
What did I miss?
You have to import the custom CA certificate into the 'trustStore' and not into the 'keyStore'.
The procedure for creating a 'trustStore' is the same as the one for the 'keyStore'.
Once you have your *.jks file then link it using the following system properties:
javax.net.ssl.trustStore=<file>
javax.net.ssl.trustStorePassword=<password>
Error message means the JVM cannot properly authenticate the remote server's SSL cert. Very common if the remote server is using a self-signed cert instead of one signed by an official certificate authority (like verisign).
Your message is confusing. You've enabled SSL on your Nexus instance, however you talk about a proxy repo implying the problem SSL cert might be on another server.