One of my Cloudsearch Upload Batch server is throwing this error message. I checked all configuration but not able to resolve it. Please help.
javax.net.ssl.SSLException: Server key
at sun.security.ssl.Handshaker.throwSSLException(Handshaker.java:1274)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at com.a9.cloudsearch.service.util.CSDataUploader.sendData(CSDataUploader.java:184)
I got this error when using Java 1.7. It seems that Cloud Search Tools seem to require Java 1.6.
Check you Java Version number.
Related
I am trying to set up jira as a task server in IDEA IntelliJ.
I am getting handshake_failure error when I try to test my connection.
Reading about it in SO and Atlassion forums, I tried several things but none worked:
downloading the certificate from jira server and installing it in intellij
adding -Dhttps.protocols="TLSv1" to my .vmoptions IDEA startup config file
It happens both to my corporate jira instance and to external public jira servers.
In addition, it also happened with IntelliJ 2016.
Has anyone managed to get this working?
The problem was that the server used a cipher that was disabled in my jvm.
In order to fix, I uncommented
crypto.policy=unlimited
in my jre <jre-home>\lib\security\java.security
see this SO question or this one for more details about security policies
I am trying to hit the third party webservice using SOAP UI and getting below exception:
ERROR:Exception in request: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
I dont have cacert or keystore from the third party webservice but I have signature.By using signature I'm able to hit the third party webservice through my application.
How to configure this signature in SOAP UI?
Adding below parameter to C:\Program Files\SmartBear\SoapUI-5.2.1\bin\SoapUI-5.2.1.vmoptions worked for me.
-Dsoapui.https.protocols=TLSv1.2,SSLv3
Check this link
Quick fix: Upgrade to SoapUI version 5.4.0. This will fix the SSL handshake issue.
After i put below line in file SoapUI-5.2.1.vmoptions. It worked fine for me.
File Path : SoapUI-5.2.1\bin\SoapUI-5.2.1.vmoptions
Add below Line:
-Dsoapui.https.protocols=TLSv1.2,SSLv3
I had 5.5 SOAP UI and calling an gateway API hosted in https URL.
I tried all the java versions , TLS protocol nothing worked for me.
I downloaded the certificate (for me it was truststore.jks) which I was using to connect to API , use certificate password ( used to see all the certificates in your ) and check the Check box as shown in image. I am able to make a https connection.
This is an old thread but my solution might help someone.
In SoapUI version 5.3.0 I solved this problem by removing line:
if exist "%SOAPUI_HOME%..\jre\bin" goto SET_BUNDLED_JAVA
from the soapui.bat and then using soapui.bat for program execution. It seems that Java embedded with SoapUI is a different version than mine which is JRE 1.8.0_131.
For me, only ssl changes did not work.
Check your
java version
it may differ from SOAP-UI jre
at his case got to smartbear\SoapUI-5.2.1\bin directory open soapui.bat
update with compatible java version like:
REM set JAVA=%SOAPUI_HOME%..\jre\bin\java
set JAVA=D:\Program Files\java\jdk1.8.0_162\bin\java
close the first line with rem and update java dir.
run soapui.bat
The problem it's the compatibility between your Java installed on your computer and the Java who is used by soap (for me it's SOAPUI-5.5.0)
SOAP UI was not supporting very well the last version installed of Java.
Modify the file soapui.bat in (usualy installed here)
C:\Program Files (x86)\SmartBear\SoapUI-5.4.0\bin\soapui.bat
You can see there two lines :
if exist "%SOAPUI_HOME%..\jre\bin" goto SET_BUNDLED_JAVA
if exist "%JAVA_HOME%" goto SET_SYSTEM_JAVA
First line SoapUi is setting the jre directory to the one in is own folder
Second line SoapUi is saying than if you have java installed, use this one instead.
So you just have to comment the second line like that :
if exist "%SOAPUI_HOME%..\jre\bin" goto SET_BUNDLED_JAVA
rem if exist "%JAVA_HOME%" goto SET_SYSTEM_JAVA
And for me it's works where whith all other kind of action (permitting TLS1.1 etc) dont.
I'm receiving the following message on server log in IBM Mobile First 6.3 every time an Adapter is getting called:
Stacktrace
[ERROR ] Error sending bulk request: java.lang.RuntimeException:
failure in bulk execution: [2]: index [worklight], type [devices], id
[b2deefe7-0d15-4ed4-b199-7e42440fc372], message
[VersionConflictEngineException[[worklight][1]
[devices][b2deefe7-0d15-4ed4-b199-7e42440fc372]: version conflict,
current [58], provided [57]]] at
com.ibm.elasticsearch.servlet.DataReceiver.processData(DataReceiver.java:132)
at
com.ibm.elasticsearch.servlet.DataReceiver.processDataLegacy(DataReceiver.java:85)
at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown Source) ...
The adapter is executed correctly and the response is returned to the app.
Any idea why this error is happening?
Help will be appreciated.
Thanks.
This is an internal error in analytics. The error itself is actually harmless, however the analytics platform should be catching it... A defect will be logged for the message. In the meantime, if you're not using analytics, you can disable it by removing the WAR files from the Liberty server.
If you are using analytics, then I would recommend clearing out the analytics data folder and restarting the IMF platform (this would remove any data you have stored in analytics). This is assuming that you are running in development mode. The analytics data folder can be in the same directory as the server.xml file for your Liberty server.
I have implement Encrypted Cache in my application. When testing is in the Mobile Web environment using the mobile browser in my device, I get the following exception:
[ERROR ] FWLSE0048E: Unhandled exception caught: SRVE0190E: File not
found: /apps/services/BMA_app/apps/services/random
java.io.FileNotFoundException: SRVE0190E: File not found:
/apps/services/BMA_app/apps/services/random at
com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:496)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:127)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:88)
at
com.worklight.core.auth.impl.AuthenticationFilter$1.execute(AuthenticationFilter.java:191)
at
com.worklight.core.auth.impl.AuthenticationServiceBean.accessResource(AuthenticationServiceBean.java:76)
at
com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:195)
at
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:85)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:949)
at
com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1029)
at
com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:4499)
at
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.handleRequest(DynamicVirtualHost.java:282)
at
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:954)
at
com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:252)
at
com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:584)
at com.ibm.ws.threading.internal.Worker.executeWork(Worker.java:439)
at com.ibm.ws.threading.internal.Worker.run(Worker.java:421) at
java.lang.Thread.run(Thread.java:701) [project BMA_app] SRVE0190E:
File not found: /apps/services/BMA_app/apps/services/random
When testing in other environments, the error does not occur.
EDIT: I just saw that, this service allows to get a key for encrypted cache. It allows to open it. Given that, the service is 404, I got a failure for opening cache.
Moreover, the Worklight Console gives me this URL for mobile web app:
http:/my-server:port/BMA_app/apps/services/www/BMA_app/mobilewebapp/
the app tries to get a key for encrypted cache and send to http:/my-server:port/BMA_app/apps/services/BMA_app/apps/services/random
^ 404 error
If we cut this previous url to http://my-server:port/BMA_app/apps/services/random, it works.
It seems that in the URL "BMA_app/apps/services" is repeated twice instead of once.
Why and how to resolve it ?
Looks like you may have encountered a defect.
Testing in 6.1.0.1 with the Encrypted Cache sample project and adding to it the Mobile Web environment, if you use the link provided by the "Get App URL" button - then when you try to "open cache" from the app, it will fail with status code 10. This status code means that the app was unable to connect to the Worklight Server's Random generator service.
Indeed, when inspecting the console log, the app tries to connect to the following URL, where "EncryptedCache/apps/services" is repeated twice...:
http://192.168.1.101:10080/EncryptedCache/apps/services/EncryptedCache/apps/services/random?isAjaxRequest=true&x=0.18816258828155696
There is no workaround for this defect as it is the framework that generates the URL.
I have opened a defect.
If you are an IBM customer or business partner and require a fix, you can open a PMR and mention this Stackoverflow question.
Moving forward, the fix will be available in an iFix and any future fixpack released.
Basic put object calls suddenly stopped working (sometimes it succeds). It has been working since long.
Looks like a SSL cert issue.
Stack Trace snippet.
org.jets3t.service.S3ServiceException: S3 PUT connection failed for '/s3_request_message-38afbd8e-7d65-428a-a708-5d34104ded95-4912660956668093023.xml'
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:516)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRestPut(RestS3Service.java:800)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.createObjectImpl(RestS3Service.java:1399)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.putObjectImpl(RestS3Service.java:1317)
at org.jets3t.service.S3Service.putObject(S3Service.java:1661)
at org.jets3t.service.S3Service.putObject(S3Service.java:1914)
at com.amazon.lm.utils.aws.S3Box.putFile(S3Box.java:111)
at com.amazon.lm.engine.LMEngine.copyRequestS3(LMEngine.java:350)
at com.amazon.lm.engine.LMEngine.run(LMEngine.java:165)
at com.amazon.lm.engine.discover.DiscoveryEngine.run(DiscoveryEngine.java:156)
at com.amazon.lm.engine.discover.GoogleBaseSearch.run(GoogleBaseSearch.java:25)
at com.amazon.lm.ui.UIDiscoverTask.run(UIDiscoverTask.java:41)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.net.ssl.SSLPeerUnverifiedException: HTTPS hostname invalid: expected 'lm-requests-prod.s3.amazonaws.com', received '*.s3.amazonaws.com'
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.verifyHostname(StrictSSLProtocolSocketFactory.java:293)
at org.apache.commons.httpclient.contrib.ssl.StrictSSLProtocolSocketFactory.createSocket(StrictSSLProtocolSocketFactory.java:215)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
at org.jets3t.service.impl.rest.httpclient.RestS3Service.performRequest(RestS3Service.java:342)
... 12 more
Looks like Java does not like the wildcard domain presented as '*.s3.amazonaws.com'
per Can Java connect to wildcard ssl... wildcards can be problematic with java.
But as said earlier, we have been using it since long time and suddenly started facing this issue, that too intermittently.
We are using following versions:
jdk: 1.6
jets3: 0.7
openssl:1.0
Has anyone faced this issue? If Yes, Is there any workaround?
This wasn't an issue with the AWSS3JavaClient code, based on the fact that the this problem was happening both with S3 library and with other Java S3 libraries, and the fact that SSL cert verification is done inside the JVM platform library code, not inside our S3 library code.
The problem is that our JVM's keystore didn't have the most recent certificate authorities (CAs) that allow the JVM to form a chain of trust for whatever cert we're getting from the S3 SSL endpoint. This is a fairly common problem with Java and SSL, since the JVM maintains it's own keystore (i.e. it doesn't use certs from the OS).
If you face this problem, try reproducing this issue with other JVMs. Whenever customers have seen this issue in the past, it's been because their local JVM keystore (the keystore ships with the JVM and contains the most recent certs and CAs) has been out of date. Upgrading to the latest JVM version has always fixed this in the past.
Try upgrading your JVM version to recent one, it should help because your keystore must have been expired! :)