Develop Reference

Docusign OAuth getAccessToken failing for Java app

I have a Java application which has been Docusigning away nicely until it broke sometime last week (might have been anytime in the last couple of weeks) .
Nothing has changed on my side, so I suspect some change on the Docusign front.
The symptoms are very puzzling and are as follows :
Sign-in with OAuth works fine up to the stage when it attempts to get the access token, at which point it hangs until it times out. The initial phases (log in, call callback with generated oauth code which then calls the getAccesCode component ) work fine, and here's the kicker - if I plug the exact values from the hanging getAccessToken call into curl and execute it from the same server, it works fine.
Here are the details of the hanging call :
getAccessToken request location='https://account-d.docusign.com/oauth/token'
getAccessToken request body=grant_type=authorization_code&code=<many characters>'
getAccessToken Request header : Authorization:Basic Y2E1ZWM3N2UtMGQ4 + MORE
So it is definitely something to do with the Java libraries, however it is not possible to get a debug trace of the OAuth part on the Docusing server (although I know you can trace the actual API calls by enabling the Docusign logs it does not appear to trace the oauth steps )
What is puzzling is that it was working fine for months. And now works fine with curl, but just hangs in Java. I suspected SSL , but if that were the case why do the initial steps work ?
This is the Java stacktrace , interestingly does not always get dumped (but the hang always happens)
java.net.SocketException: Connection timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:275)
at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:658)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
at org.apache.oltu.oauth2.client.URLConnectionClient.execute(URLConnectionClient.java:98)
As mentioned , running curl against https://account-d.docusign.com/oauth/token with parameters grant_type=authorization_code and the generated code=blah with the appropriate auth header works fine, returning the correct json response.
Any ideas anyone ? How can I trace the Docusign side to find out why it is hanging ? What has changed of late ? New SSL certs ? I'm stumped.

Per Amit and DS Support, DocuSign has ended support for TLS1.0 in Demo from May 29th, 2018 and will soon end the support in PROD as well. Please test the connection on your end if you are using TLS1.0, if yes then you need to upgrade it to TLS1.1+ to again start using DS APIs. I am assuming if you have not done any code changes then this is the issue which you are seeing in your application.

AIX java.net.SocketException: A system call received a parameter that is not valid

I am really stuck with an AIX java issue. I have an issue here that doesn't match other issues on SO and on the Web.
My application code runs fine on another AIX server with the same exact JRE - IBM AIX Java 1.8, but does not run on the server that I need it to.
Both servers are AIX 7.1, running the same JAR and same JRE from the same tarball.
I'm getting the following error when using a Spring RestTemplate.exchange() to retrieve and unmarshal some JSON.
It must be a server configuration issue, but I'm very stuck and would appreciate any help!
Caused by: java.net.SocketException: A system call received a parameter that is not valid.
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
at java.net.SocketInputStream.read(SocketInputStream.java:181)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at com.ibm.jsse2.a.a(a.java:209)
at com.ibm.jsse2.a.b(a.java:41)
at com.ibm.jsse2.a.a(a.java:193)
at com.ibm.jsse2.as.a(as.java:268)
at com.ibm.jsse2.as.a(as.java:745)
at com.ibm.jsse2.e.read(e.java:56)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:257)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:297)
at java.io.BufferedInputStream.read(BufferedInputStream.java:356)
at sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:564)
at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:621)
at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:708)
at java.io.FilterInputStream.read(FilterInputStream.java:144)
at sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:3352)
at java.io.FilterInputStream.read(FilterInputStream.java:144)
at java.io.PushbackInputStream.read(PushbackInputStream.java:197)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.loadMore(UTF8StreamJsonParser.java:178)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.parseEscapedName(UTF8StreamJsonParser.java:1749)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.slowParseName(UTF8StreamJsonParser.java:1654)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._parseName(UTF8StreamJsonParser.java:1484)
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.nextToken(UTF8StreamJsonParser.java:700)
at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:120)
at com.fasterxml.jackson.databind.deser.std.ObjectArrayDeserializer.deserialize(ObjectArrayDeserializer.java:149)
at com.fasterxml.jackson.databind.deser.std.ObjectArrayDeserializer.deserialize(ObjectArrayDeserializer.java:18)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:2993)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2158)
at org.springframework.http.converter.json.AbstractJackson2HttpMessageConverter.readJavaType(AbstractJackson2HttpMessageConverter.java:222)

It's probably a firewall issue.
Communication is cut abruptly by some sort of firewall, so the socket is closed by the OS, which gives error when you try to read from it.

HTTP transport error: java.net.SocketException: Connection reset

A client application has been built using Jdeveloper 10.1.3.2 and it is running on OC4J server. This application is sending data to external server application. It is working for quite long time without any issue. Lately a connection issue occurred and the following stack trace is generated:
com.sun.xml.ws.client.ClientTransportException: HTTP transport error: java.net.SocketException: Connection reset
at com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:133)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:153)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:93)
at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:629)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:588)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:573)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:470)
at com.sun.xml.ws.client.Stub.process(Stub.java:319)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:157)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:109)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:89)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:140)
at $Proxy44.sendRem(Unknown Source)
After goggling I found out a good discussion about the error sockets - What's causing my java.net.SocketException: Connection reset? .One answer in this link says that the issue mostly from the client side because if it is from the server side the exception will be (SocketException reset by peer).
What I did:
I tried out to increase the socket time out for the OC4J with the help of this form How to change OC4J HTTP Timeout. What I did is I changed the propriety oracle.j2ee.http.socket.timeout to be 5000 instead of 500 (10 times longer)
But the error still there. So, any suggestion to over come this issue?
Note: I able to use telnet command for external server IP and Port and it is working fine.
-------------------------------------------------------- Update 1 --------------------------------------------------------
I increase the server clock skew where the client application is running using the following command on server start up:
-Dweblogic.wsee.security.clock.skew=72000000
-Dweblogic.wsee.security.delay.max=72000000
But no luck, problem is not resolved.
-------------------------------------------------------- Update 2 --------------------------------------------------------
I realized that the problem is not from application at all; I test the external URL using SoapUI and I got the same error Connection rest. I think this new update clreay shows that there is nothing wrong with program code. But I need to know where to go or check now. Where is the starting point now to overcome the issue. Any clue will be helpful.

As you can see from Update 2 in the question, the problem was not from the client application because same error occurred from SoapUI.
The problem was that the machine where the client application was running have low bandwidth which was not enough for APIs communication. Using simple speed test , I found out that the upload bandwidth was low comparing to minimum requirements given by server application team.
I concluded this fact by monitoring the network resource using Resource Monitor in Windows while the client application was running and by using online speed check
To solve the issue, the machine bandwidth has to be increased where the client application is running.

SSL error while connecting to Openfire from java-smack client

I am recently working on Openfire client. I've got this strange issue that I couldn't figure out so far (i've got some clues, but still no solid solution).
We've got 2 openfire servers:
first that we were using for testing it was hosted on normal pc conected to the internet through adsl, server was behind NAT, everything configured smoothly, working perfect. Our client was connecting without any issues.
second (let's call it production) professional dedicated server located somewhere in germany with OF instaled, same OS as on the testing one, OF set up in exactly the same way
Now when connecting to production from our client we experianced following issue when trying to authenticate:
javax.net.ssl.SSLException: Received fatal alert: internal_error
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at org.jivesoftware.smack.XMPPConnection.proceedTLSReceived(XMPPConnection.java:806)
at org.jivesoftware.smack.PacketReader.parsePackets(PacketReader.java:267)
at org.jivesoftware.smack.PacketReader.access$000(PacketReader.java:43)
at org.jivesoftware.smack.PacketReader$1.run(PacketReader.java:70)
java.lang.IllegalStateException: Not connected to server.
at org.jivesoftware.smack.XMPPConnection.sendPacket(XMPPConnection.java:445)
at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication.java:69)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:352)
at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:203)
at Main.connectToJabber(Main.java:31)
at Main.main(Main.java:16)
Exception in thread "main" java.lang.IllegalStateException: Not connected to server.
at org.jivesoftware.smack.XMPPConnection.sendPacket(XMPPConnection.java:445)
at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication.java:69)
at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:362)
at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:203)
at Main.connectToJabber(Main.java:31)
at Main.main(Main.java:16)
Now the funniest part: when I connect to the production server using our client from my flat i don't see that error, when we are connecting to the production from other developer flat we've got this error, we've got different internet providers (i don't know if that may have something to do with that).
We've spent all night looking at it and so far no clue.
We wrote basic code just to check the connection:
public static void connect() {
ConnectionConfiguration cc = new ConnectionConfiguration("prod ip",
5222);
cc.setCompressionEnabled(true);
cc.setSASLAuthenticationEnabled(true);
Connection connection = new XMPPConnection(cc);
try {
connection.connect();
connection.login(login, pass, "resource");
System.out.println(connection.isSecureConnection() + " " + connection.isUsingCompression());
} catch (XMPPException e1) {
e1.getStackTrace();
}
}
Some observations:
When line connection.login(...) commented, there is no error, so whatever is causing the error is there
When connecting the testing server System.out... writes true false,
When connecting the production server System.out... writes false false
Tried with all combinations of: cc.setCompressionEnabled() cc.setSASLAuthenticationEnabled(); (true, true, false true, true false, false false)
despite the error, user is logged in
To sum up:
Connection with testing environment works always, with production: from my location - no problem, other location - mentioned error,
we use SMACK API 3.2.1
One of the ideas was that it has to do something with the certificates.
Any hints or ideas highly appriciated

Bad bad solution! because u don't know connection speed and also u stop your app from continuing to login if connection established at early moments.
A solution that I can offer for now is to addConnectionListener and call login() in 'reconnectionSuccessful()' function, and I hope this function will call for the first time not just after connection dropped and connected again! if not, It shows the bad architecture of smack library.

Maybe a sleep(x) between the connect() and the login() call could fix this. A few seconds for the sleep() should be enough.
Source

I also use a sleep after connect() also... it's not ideal sure, but it's a reliable workaround.

Trouble with securing a Tomcat/Axis2 web service via SSL

I have successfully built a working web service, client, and .jsp-driven UI. I did this with Eclipse, Axis2, Tomcat 7, and Java 7.
The basic flow is that the user visits the .jsp and submits a form with input data. The JSP forwards the "request" object to the Java client. The Java client consumes the web service and submits the user input. The service connects to a SQL Server database via JDBC to retrieve information, which is displayed back to the user.
This all works perfectly over HTTP, but now I want to secure the process, and this is where I'm running into problems. I'm able to create a cert and get Tomcat to use it. I can connect to the web UI via HTTPS and submit the form and get data back just fine. The problem is that this is only securing the front-end. The web service client code is still connecting to the service via HTTP in the background.
According to this page, all I really need to do to enable my service for connections via SSL is to update the axis2.xml file and include a new "transportReceiver" node for HTTPS. I did that and regenerated my client code to use the secure endpoint. It doesn't work.
I have configured Tomcat to listen on ports 8081 for http and 8443 for https. But after changing axis2.xml to match, and starting up Tomcat, I get the following:
[INFO] Listening on port 8443 [ERROR] Terminating connection
listener
org.apache.axis2.transport.http.server.DefaultConnectionListener#16d60567
after 10retries in 0 seconds. java.net.BindException: Address already
in use: JVM_Bind at java.net.DualStackPlainSocketImpl.bind0(Native
Method) at java.net.DualStackPlainSocketImpl.socketBind(Unknown
Source) at java.net.AbstractPlainSocketImpl.bind(Unknown Source) at
java.net.PlainSocketImpl.bind(Unknown Source) at
java.net.ServerSocket.bind(Unknown Source) at
java.net.ServerSocket.(Unknown Source) at
java.net.ServerSocket.(Unknown Source) at
org.apache.axis2.transport.http.server.DefaultConnectionListener.run(DefaultConnectionListener.java:80)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I have tried changing the port number in axis2.xml (for example, to 8445), and that sort of works. The server is able to start cleanly, but eventually, the same errors start showing up. For example, when I retrieve the WSDL, I see the error via the console (though the WSDL does show up). Also, if I try to actually use the service when on port 8445, I get the following error:
org.apache.axis2.AxisFault: Connection has been shutdown:
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext
connection?
I can only assume this is because Tomcat is configured to handle HTTPS on 8443, not 8445, but I honestly don't know.
If I leave the port as 8443 and ignore the errors at startup, I get the following message when I connect to the service:
org.apache.axis2.AxisFault: Connection has been shutdown:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
I followed these steps to try to get it to recognize my certificate, but when importing it into my JRE7 keystore, I get the following:
keytool error: java.lang.Exception: Certificate reply and certificate
in keystore are identical
Basically, that cert is already there. Which makes sense, because it's the one that Tomcat is already using successfully.
So, I'm pretty clueless at this point. I'm really not sure what I'm supposed to be doing. Any general guidance, or a link to a step-by-step how-to would be really helpful.
But for a specific question... What, exactly, am I doing when I set the transportReceiver nodes in axis2.xml? Am I telling it what ports Tomcat is running on and that it should use, or does Axis2 have its own servers that will start on those ports? It seems to be the latter, but that doesn't make a whole lot of sense to me.

The correct way to configure the servlet transport is described in the Axis2 documentation. The symptoms you are describing suggest that you have a transportReceiver that refers to org.apache.axis2.transport.http.SimpleHTTPServer. Please also make sure that you use a recent version of Axis2 (1.5.6 or 1.6.1).

See Andreas's response for the port issue. As for the certificate issue, it was a misunderstanding on my part over the distinction between a keystore and truststore. The JVM defaults to using JAVA_HOME\lib\security\cacerts as its trust store, rather than the USER_HOME\.keystore file. Once I imported my certificate there, the errors went away.
I was also able to resolve the certificate problems by explicity setting the trust store to be the key store file, via code. I did this before importing the certificate into the cacerts store. It goes in the client code, right before invoking the service:
System.setProperty("javax.net.ssl.trustStore","C:\\path\\to\\.keystore");
System.setProperty("javax.net.ssl.trustStorePassword","password");

One of the way to connect to HTTPS is using jax-ws
E:\WSDL>wsimport -keep -p com.mypack.webservice https://domain:port/ws/MyService?wsdl
This will generate package structure under the wsdl folder. Use it.
Now all you have to do is put trust store in run.bat or use System class to set property.
It will work fine.