I am getting ERROR:
java.net.SocketException: Connection reset.
I have followed the below link to resolve the issue. But no luck..
SOAPUI Certificate authentication
http://geekswithblogs.net/gvdmaaden/archive/2011/02/24/how-to-configure-soapui-with-client-certificate-authentication.aspx
I have given the error logs below. Can any one look this and let me know how to resolve this issue?
Thu Mar 23 16:11:51 IST 2017:ERROR:java.net.SocketException: Connection reset
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.writeRecord(Unknown Source)
at sun.security.ssl.AppOutputStream.write(Unknown Source)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flushBuffer(AbstractSessionOutputBuffer.java:131)
at org.apache.http.impl.io.AbstractSessionOutputBuffer.flush(AbstractSessionOutputBuffer.java:138)
at org.apache.http.impl.conn.LoggingSessionOutputBuffer.flush(LoggingSessionOutputBuffer.java:95)
at org.apache.http.impl.AbstractHttpClientConnection.doFlush(AbstractHttpClientConnection.java:270)
at org.apache.http.impl.AbstractHttpClientConnection.flush(AbstractHttpClientConnection.java:275)
at org.apache.http.impl.conn.AbstractClientConnAdapter.flush(AbstractClientConnAdapter.java:197)
at org.apache.http.protocol.HttpRequestExecutor.doSendRequest(HttpRequestExecutor.java:258)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$SoapUIHttpRequestExecutor.doSendRequest(HttpClientSupport.java:113)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:633)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:454)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport$Helper.execute(HttpClientSupport.java:247)
at com.eviware.soapui.impl.wsdl.support.http.HttpClientSupport.execute(HttpClientSupport.java:362)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.submitRequest(HttpClientRequestTransport.java:324)
at com.eviware.soapui.impl.wsdl.submit.transports.http.HttpClientRequestTransport.sendRequest(HttpClientRequestTransport.java:237)
at com.eviware.soapui.impl.wsdl.WsdlSubmit.run(WsdlSubmit.java:127)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
WINDOWS
Option 1:
find the following file on your computer (make sure you have write access to the file): C:\Program Files\SmartBear\SoapUI-5.2.1\bin\SoapUI-5.2.1.vmoptions
Add the following line to the file:
-Dsoapui.https.protocols="SSLv3,TLSv1.2"
Run SoapUI with the .exe file (SoapUI-5.2.1.exe)
Option 2: (if option 1 does not work for you).
Edit the following batch file on your computer (make sure you have write access to the file): C:\Program Files\SmartBear\SoapUI-5.2.1\bin\soapui.bat
Add the following line to the file (after: if "%SOAPUI_HOME%" == "" goto START):
set JAVA_OPTS=%JAVA_OPTS% -Dsoapui.https.protocols="SSLv3,TLSv1.2"
Run SoapUI with the batch file (soapui.bat)
MAC (OSX)
The default install location for Mac is in the root Applications folder, and the vmoptions.txt file is in there. Right-click the SOAPUI .app file (in the /Applications folder), and choose "Show Package Contents" to get to the internal files.
/Applications/SoapUI-X.X.X.app/Contents/vmoptions.txt
Add the following line to the vmoptions.txt file:
-Dsoapui.https.protocols=TLSv1.2
LINUX
Edit: bin/SoapUI-5.3.0.vmoptions in SoapUI directory
Add the following line to the file:
-Dsoapui.https.protocols=TLSv1.2
I hope it helps.
Tried all solutions but nothing worked. It started to work after ignoring jre directory in SoapUI. So if above solutions won't work for you then try this:
Close SoapUI
Go to SoapUi directory for example: C:\Program Files\SmartBear\SoapUI-5.3.0\
Rename directory "jre" to "jre.ignore"
Done. Open SoapUi and it should work now.
I think you are using company connection and company firewall is blocking the connection.
In my case, none of the suggestions above were worked, except for this one. (I've added only this line to SoapUI-X.X.X.vmoptions file located in SergiSPN's answer above)
-Djava.net.preferIPv4Stack=true
There must have been some sort of restriction for IPv6 in our company's infrastructure, which I had no idea what it was.
By removing protocols TLS 1.0 in the registry works fine.
Invoke-WebRequest SSL fails?
this post is useful to resolve this issue.
For testing purposes only: If all else fails, you can also just use http instead of https. Just edit the url in the SoapUI window for the request.
Related
My Log Detected server admin port: 4848
Detected server http port: 8080
java.nio.file.AccessDeniedException: C:\Program Files\glassfish4\glassfish\domains\domain1\logs\server.log.lck
Attempting to start domain1.... Please look at the server log for more details.....
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
at sun.nio.fs.WindowsFileSystemProvider.newFileChannel(Unknown Source)
at java.nio.channels.FileChannel.open(Unknown Source)
at java.nio.channels.FileChannel.open(Unknown Source)
at java.util.logging.FileHandler.openFiles(Unknown Source)
at java.util.logging.FileHandler.<init>(Unknown Source)
at com.sun.enterprise.admin.launcher.GFLauncherLogger.addLogFileHandler(GFLauncherLogger.java:99)
at com.sun.enterprise.admin.launcher.GFLauncher.setup(GFLauncher.java:192)
at com.sun.enterprise.admin.servermgmt.cli.StartDomainCommand.createLauncher(StartDomainCommand.java:228)
at com.sun.enterprise.admin.servermgmt.cli.StartDomainCommand.executeCommand(StartDomainCommand.java:124)
at com.sun.enterprise.admin.cli.CLICommand.execute(CLICommand.java:322)
at com.sun.enterprise.admin.cli.AdminMain.executeCommand(AdminMain.java:366)
at com.sun.enterprise.admin.cli.AdminMain.doMain(AdminMain.java:300)
at org.glassfish.admin.cli.AsadminMain.main(AsadminMain.java:56)
There is a lock file on the server.log. GlassFish won't start if it can't write to that log. Try deleting the lock file: C:\Program Files\glassfish4\glassfish\domains\domain1\logs\server.log.lck
This is because of the path for your installed Glassfish server:
C:\Program Files\glassfish4
This directory in Windows need admin permission in order to perform edit to server.log
Relocate Glassfish server directory to get rid of the error, for example move it to:
C:\glassfish4
As a notice don't forget to edit configuration of Glassfish server inside IntelliJ IDEA.
I have a Java 8 project that creates about a dozen JNLP applications. I have built and run them on Windows successfully. The JNLP launches correctly through javaws. I then transfer it as a .tar to a Solaris machine via FTP (in binary mode) and my SA deploys via Tomcat.
When I visit the URL to launch the JNLP over the network, I get an Application Error.
The Exception is:
com.sun.deploy.net.FailedDownloadException: Unable to load resource: https://example.com/webstartdev10g/dev/apps/libs/xerces.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
The Wrapped Exception is:
java.util.zip.ZipException: invalid entry size (expected 19075 but got 11917 bytes)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:287)
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:360)
at java.util.zip.DeflaterOutputStream.close(DeflaterOutputStream.java:238)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:377)
at com.sun.deploy.net.HttpDownloadHelper.download(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
All of my JNLP apps that depend on xerces have this same error. The apps that don't require xerces seem to be working fine. I checked that the xerces.jar file is the same size on my Windows machine and the Solaris machine. I visited https://example.com/webstartdev10g/dev/apps/libs/xerces.jar directly and was able to download the file and open it. I even replaced my local copy with the downloaded version and ran the app locally without any errors. Based on this, it doesn't seem like there is actually anything wrong with the file.
Any ideas to help me narrow this down?
EDIT:
I turned on the javaws -verbose flag to get more details into what is happening when I launch the JNLP locally with the downloaded jar. As it turns out, I am still getting the error, but it isn't preventing the application from launching. It is just being logged in the console silently, with a different size listed.
java.util.zip.ZipException: invalid entry size (expected 19075 but got 16384 bytes)
I'm still not sure how only this file has this problem or why it reports itself as being the same size on both machines.
I rebuilt, retransfered, and redeployed the apps. They seem to be working now. I am still confused about how the symptoms presented themselves and would be interested in any theories on what happened (other than "the file was somehow corrupted during the transfer").
In any case, using javaws -verbose helped me get some clues about the problem and redeploying the tar file resolved the issue.
I am getting this below error when trying to access an WSDL endpoint.
First I have created the client jar using cliengen ant task and then created a simple java class to test the wsdl end point and I am getting below error-
javax.net.ssl.SSLKeyException: FATAL Alert:BAD_CERTIFICATE - A corrupt or unuseable certificate was received.
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireException(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.fireAlertSent(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.fireAlert(Unknown Source)
at com.certicom.tls.record.handshake.HandshakeHandler.handleHandshakeMessages(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.interpretContent(Unknown Source)
at com.certicom.tls.record.MessageInterpreter.decryptMessage(Unknown Source)
at com.certicom.tls.record.ReadHandler.processRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readRecord(Unknown Source)
at com.certicom.tls.record.ReadHandler.readUntilHandshakeComplete(Unknown Source)
at com.certicom.tls.interfaceimpl.TLSConnectionImpl.completeHandshake(Unknown Source)
at com.certicom.tls.record.WriteHandler.write(Unknown Source)
at com.certicom.io.OutputSSLIOStreamWrapper.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
at java.io.FilterOutputStream.write(FilterOutputStream.java:80)
at weblogic.webservice.binding.soap.HttpClientBinding.writeToStream(HttpClientBinding.java:430)
at weblogic.webservice.binding.soap.HttpClientBinding.send(HttpClientBinding.java:219)
at weblogic.webservice.core.handler.ClientHandler.handleRequest(ClientHandler.java:37)
at weblogic.webservice.core.HandlerChainImpl.handleRequest(HandlerChainImpl.java:143)
at weblogic.webservice.core.ClientDispatcher.send(ClientDispatcher.java:231)
at weblogic.webservice.core.ClientDispatcher.dispatch(ClientDispatcher.java:143)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:471)
at weblogic.webservice.core.DefaultOperation.invoke(DefaultOperation.java:457)
at weblogic.webservice.core.rpc.StubImpl._invoke(StubImpl.java:303)
Can anyone help?
I was able to get resolve the exception by updating \Oracle\Middleware\user_projects\domains\my_domain\bin\setDomainEnv.cmd with below commands
set JAVA_OPTIONS=%JAVA_OPTIONS% -DUseSunHttpHandler=true -Dssl.SocketFactory.provider=sun.security.ssl.SSLSocketFactoryImpl -Dssl.ServerSocketFactory.provider=sun.security.ssl.SSLSocketFactoryImpl
Fixed this issue by adding following lines in JVM arguments.
-Dweblogic.security.SSL.nojce=true
-Dweblogic.ssl.JSSEEnabled=true
-Dweblogic.security.SSL.enableJSSE=true
Don't forget to recycle JVM. :)
I was getting similar when trying to upload a file to an S3 Bucket on AWS from a WebLogic application. I added the following lines
JAVA_OPTIONS="${JAVA_OPTIONS} -DUseSunHttpHandler=true -Dssl.SocketFactory.provider=sun.security.ssl.SSLSocketFactoryImpl -Dssl.ServerSocketFactory.provider=sun.security.ssl.SSLSocketFactoryImpl"
just before this command
JAVA_OPTIONS="${JAVA_OPTIONS}"
export JAVA_OPTIONS
in
\Oracle\Middleware\user_projects\domains\my_domain\bin\setDomainEnv.cmd
and my issue was resolved. Just make sure to restart WebLogic after the amendment.
Add this in startup params
-DUseSunHttpHandler=true
-Dssl.SocketFactory.provider=sun.security.ssl.SSLSocketFactoryImpl
-Dssl.ServerSocketFactory.provider=sun.security.ssl.SSLSocketFactoryImpl
I have a Java servlet application developed and on my develpment PC everything works as expected including using SFTP programmatically to copy over a PDF using HTTPS on port 8443 etc and with SSL certificates in place too.
However, when I attempt to run the application on the Live server I receive the error;
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
On investigation, some are suggesting check the jce.jar. But I have ensured the jce.jar is present and also created a "lib" folder in my project and copied the jar there and placed the jar on my build path but still the problem exists.
How do I resolve this please? Thanks in advance. Here is the console output from right after Tomcat has started the application;
#
08-Jan-2014 10:45:44 org.apache.catalina.startup.Catalina start
INFO: Server startup in 12715 ms
08-Jan-2014 10:47:42 org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run
SEVERE:
java.lang.NoClassDefFoundError: Could not initialize class javax.crypto.SunJCE_b
at javax.crypto.Cipher.getInstance(DashoA13*..)
at com.sun.net.ssl.internal.ssl.JsseJce.getCipher(Unknown Source)
at com.sun.net.ssl.internal.ssl.RSAClientKeyExchange.<init>(Unknown Source)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Unknown Source)
at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:285)
at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap
(SecureNioChannel.java:343)
at org.apache.tomcat.util.net.SecureNioChannel.handshake
(SecureNioChannel.java:193)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run
(NioEndpoint.java:1642)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The jce.jar must be inside the folder WEB-INF/lib of the deployed web application.
I've seen this problem pop up very often and there seems to be a lot of confusion around it. The actual reason this is happening is because the JRE you are using to run your application has been set up with the unrestricted JCE policy jars inside its jre/lib folder (inside your jdk install folder).
If your current project does not need these, then you can move then out of this folder temporarily. This will remove the requirement on the jce libraries and you will no longer see this error.
Hope this helps.
I'm trying to implement Sun Tutorials RMI application that calculates Pi. I'm having some serious problems and I cant find the solution eventhough I've been searching the entire web and several javaskilled people.
I'm hoping you can put an end to my frustrations.
The crazy thing is that I can run the application from the cmd on my desktop computer. Trying the exact same thing with the exact same code in the exact same directories on my laptop produces the following errors. The problem occures when I try to connect the client to the server.
I don't believe that the error is due to my policyfile as I can run it on the desktop. It must be elsewhere. Have anyone tried the same and can you give me a hint as to where my problem is, please?
POLICYFILE SERVER:
grant
{
permission java.security.AllPermissions;
permission java.net.SocketPermission"*", "connect, resolve";
};
POLICYFILE CLIENT:
grant
{
permission java.security.AllPermissions;
permission java.net.SocketPermission"*", "connect, resolve";
};
______________________________________________
SERVERSIDE ERRORS:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\STUDENT>cd\
C:\>start rmiregistry
C:\>java -cp c:\java;c:\java\compute.jar -Djava.rmi.server.codebase=file:/c:/jav
a/compute.jar -Djava.rmi.server.hostname=localhost -Djava.security.policy=c:/jav
a/servertest.policy engine.ComputeEngine
ComputeEngine bound
Exception in thread "RMI TCP Connection(idle)" java.security.AccessControlExcept
ion: access denied (java.net.SocketPermission 127.0.0.1:1440 accept,resolve)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkAccept(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.checkAcceptPermi
ssion(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.checkAcceptPermission(Unknown Sour
ce)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Sou
rce)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Sour
ce)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source
)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
_______________________________
CLIENTSIDE ERRORS:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\STUDENT>cd\
C:\>java -cp c:\java;c:\java\compute.jar -Djava.rmi.server.codebase=file:\C:\jav
a\files\ -Djava.security.policy=c:/java/clienttest.policy client.ComputePi local
host 45
ComputePi exception:
java.rmi.UnmarshalException: Error unmarshaling return header; nested exception
is:
java.io.EOFException
at sun.rmi.transport.StreamRemoteCall.executeCall(Unknown Source)
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(Unkn
own Source)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(Unknown Source)
at $Proxy0.executeTask(Unknown Source)
at client.ComputePi.main(ComputePi.java:18)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(Unknown Source)
... 6 more
C:\>
Thanks in advance
Perry
Your server didn't have permission to accept a connection from that client.
Ergo your policy file wasn't where you said it was, or wasn't loaded for some other reason.
Run it with -Djava.security.debug=access,failure and you will see what protection domain you were in when the security exception occurred, and what permissions it had.
java -cp c:\java;c:\java\compute.jar -Djava.rmi.server.codebase=file:/c:/java/compute.jar -Djava.rmi.server.hostname=localhost -Djava.security.policy=c:/java/servertest.policy engine.ComputeEngine
NB a file: codebase cannot work if it refers to a local filesystem, unless the client is also in the same machine, which makes RMI fairly pointless. Codebase URLs need to refer to locations that are accessible by the client. You can use shared file systems but you must provide a URL that is usable by the client. The server doesn't use its own codebase URL at all.
I tried the same and I found that Java simply ignored the policy file, no matter where I put it or what I put into it or which option I used to make the VM pick it up.
In the end, I create my own SecurityManager in the code and did everything manually.