The company I work for creates software that crawls and indexes various sources for use in search, in this case we're completely stuck on attempting to connect to Lotus Notes over SSL. This is a classic case of "it worked in dev, but failed in prod".
The problem is further compounded by the fact that we're devs and techies, not Lotus Notes experts.
Basically we have a piece of Java software that connects to Lotus to grab the DIIOP IOR text file using this command:
String ior = NotesFactory.getIOR(host, userIOR, pwdIOR);
Now, this is a non-SSL connection and requires username and password to connect. This works perfectly every time.
Then we attempt to create a session using this:
session = NotesFactory.createSessionWithIOR(ior, args, this.user, this.pwd);
where:
args[0] = "-ORBEnableSSLSecurity";
When connecting we consistently receive this stack trace:
NotesException: Session closed due to communications failure
at lotus.domino.cso.ORBCallback.make_error(Unknown Source)
at lotus.priv.CORBA.iiop.Generic.make_error(Unknown Source)
at lotus.priv.CORBA.portable.ObjectImpl._invoke(Unknown Source)
at lotus.domino.corba._IObjectServerStub.createSession(Unknown Source)
at lotus.domino.cso.Session.initSession(Unknown Source)
at lotus.domino.cso.Session.<init>(Unknown Source)
at lotus.domino.cso.Session.createSession(Unknown Source)
at lotus.domino.NotesFactory.createSessionUP(Unknown Source)
at lotus.domino.NotesFactory.createSessionWithIOR(Unknown Source)
[ ... ]
Caused by: org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset: Connection closed: Host: <redacted> Port: 63149 vmcid: 0x0 minor code: 1 completed: Maybe
at lotus.priv.CORBA.iiop.IIOPConnection.purge_calls(Unknown Source)
at lotus.priv.CORBA.iiop.ReaderThread.run(Unknown Source)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:154)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at lotus.priv.CORBA.iiop.Message.readFully(Unknown Source)
at lotus.priv.CORBA.iiop.Message.createFromStream(Unknown Source)
at lotus.priv.CORBA.iiop.IIOPInputStream.prefill(Unknown Source)
at lotus.priv.CORBA.iiop.IIOPConnection.createInputStream(Unknown Source)
... 1 more
I understand the most common reason for this is because we're not correctly importing the TrustedCerts.class file, however after double and triple checking it's in the class path just fine (and the fact it works in dev environment) we're confident that it's being loaded in.
We know if we disable SSL (aka remove the aforementioned arg) our code will connect to the non-SSL DIIOP port 63148 and work just fine however it is a project requirement that all data must be passed through SSL.
Which finally brings me to my actual question: How do we get Lotus to report why this connection is failing?
I've tried upping the DIIOP log level to 4 which apparently should show all transmissions but the logs show nothing when I attempt to connect. Also it's worth noting the DIIOP service is definitely running and on the correct ports as well.
I've also checked that we're making it through the firewall to the remote box and TCPDUMP on our RedHat machine clearly shows that we establish a connection with the remote Lotus Notes host before it responds closing the connection.
[Pertinent Information]
Application: Java
Library: NCSO.jar
Lotus Version: Domino 8.5.3 FP6
Lotus Server: Windows Server 2008 Standard
Ports: 63148 (non-SSL), and 63149 (SSL)
Alright, the answer was clear as crystal but not something I was actively looking for.
The reason this doesn't work is that the third party certificate is not a SHA-1 certificate and Lotus Notes 8.5.x only supports SHA-1 (as per this documentation).
So basically that certificate of theirs can never be used for SSL authentication programatically or otherwise.
You mentioned DIIOP logging, but if the connection is failing in the SSL handshake, then the guts of the diiop task probably don't know what's wrong since that's occurring at a lower level in the stack. There are, however, additional debug variables that can be set on the server.
DEBUG_SSL_HANDSHAKE=1
DEBUG_SSL_CIPHERS=1
DEBUG_SSL_ALL=1
The last setting can be pushed up to 2 or 3 for more detailed information.
Restart of the server (or possibly of the server's diiop task) may be required to get the settings to take effect.
Related
I’ve been receiving the following error:
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "SQL Server did not return a response. The connection has been closed. ClientConnectionId:be8d9e1d-fff7-4310-ae77-03394c83f86b".
(More of the error at bottom of post)
When trying to connect to a MSSQL database.
I’m using the following connection string:
jdbc:sqlserver://192.168.100.190:1433;databaseName=myDatabase;user=validUser;password=validPassword;encrypt=false;trustServerCertificate=false;sslProtocol=TLSv1;
I’ve tried variations of the connection string, essentially changing and omitting:
encrypt=false;trustServerCertificate=false;sslProtocol=TLSv1;
I’ve tried different versions of the driver from:
https://learn.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view=sql-server-2017
all with the same results.
It is important to note that on some PC’s the application connects
and works as expected but I have so far found no real differences
between the PC’s or user accounts, no pattern really.
I’ve tried different versions of the JDK and different JRE’s, all
give the same results.
UPDATE: I have since found JRE 1.8.0_152 works in all my test cases
I’ve tried looking at logs on the servers and there are no entries in
the SQL logs.
If I try a connection string with the wrong credentials, the error is
exactly the same.
I’ve setup a test server and database, this works fine, as does one I
setup in a Virtual Machine.
I can connect to said database using Navicat for example and have
another application, writing in Visual Basic.Net that connects fine,
so it would see that it is just something with this driver or java,
but as I say, it does work on some PC’s and not others and of course
works as expected in my test environment.
Any thoughts or suggestions would be greatly appreciated.
I’ve not provided any code, as I can replicate the exact same results using the example code provided here:
https://learn.microsoft.com/en-us/sql/connect/jdbc/step-3-proof-of-concept-connecting-to-sql-using-java?view=sql-server-2017
More detail on error:
com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "SQL Server did not return a response. The connection has been closed. ClientConnectionId:be8d9e1d-fff7-4310-ae77-03394c83f86b".
at com.microsoft.sqlserver.jdbc.SQLServerConnection.terminate(SQLServerConnection.java:2670)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1837)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:2257)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:1921)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectInternal(SQLServerConnection.java:1762)
at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:1077)
at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:623)
at java.sql.DriverManager.getConnection(Unknown Source)
at java.sql.DriverManager.getConnection(Unknown Source)
at database.DataBase.openConnection(DataBase.java:122)
at jambuddylite.jblCoord.readSimex(jblCoord.java:387)
at jambuddylite.jblCoord$2.run(jblCoord.java:314)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: SQL Server did not return a response. The connection has been closed. ClientConnectionId:be8d9e1d-fff7-4310-ae77-03394c83f86b
at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.ensureSSLPayload(IOBuffer.java:780)
at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.readInternal(IOBuffer.java:836)
at com.microsoft.sqlserver.jdbc.TDSChannel$SSLHandshakeInputStream.read(IOBuffer.java:827)
at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.readInternal(IOBuffer.java:1009)
at com.microsoft.sqlserver.jdbc.TDSChannel$ProxyInputStream.read(IOBuffer.java:997)
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.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSChannel.enableSSL(IOBuffer.java:1767)
... 11 more
check the port is open or not using on cmd or terminal
telnet 192.168.100.190 1433
and check the database name and credentials
and firewall there is some thing in firewall i think
and take a look here may help you
I am working on a Java alternative to libimobiledevice (not a wrapped or binding over the native libs).
I decided it makes sense to use Netty (v4.1.12) as the communication layer, due to the nature of multiple protocol layers involved with communicating with services on the device, which Netty can easily handle using pipeline configurations.
After implementing a few simple queries from Usbmux and Lockdown, I am trying to perform TLS handshake to request specific services on the device.
First, I've tried the simple approach - adding an SslHandler to the pipeline:
SslContext context = SslContextBuilder.forClient().build();
channel.pipeline().addFirst(context.newHandler(channel.alloc()));
But it seems the certificate sent from the device is not valid, in the eyes of the JDK x509 certificate parser:
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLProtocolException: Empty issuer DN not allowed in X509Certificates
...
Caused by: java.security.cert.CertificateParsingException: Empty issuer DN not allowed in X509Certificates
Next thing I tried, was using bouncycastle as ssl handler.
bouncycastle successfully parsed the certificate, but failed during the handshake with a different error:
Caused by: org.bouncycastle.crypto.tls.TlsFatalAlert: illegal_parameter(47)
at org.bouncycastle.crypto.tls.TlsClientProtocol.receiveServerHelloMessage(Unknown Source)
at org.bouncycastle.crypto.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)
at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source)
at org.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(Unknown Source)
at org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown Source)
I have tried to debug into bouncycastle and understand what was the illegal parameter, and it seems to me that there's a mismatch in the protocol version requested by the device (TLSv1.0) vs the one requested by the client (TLSv1.2).
I would paste a sample working code here, but getting to the part of the SSL session requires pretty large set of tools and parsing libraries.
I will try to create a sample git repo for this purpose (maybe even make the whole project open source later), but I was hoping someone can point me in the right direction in the meanwhile.
Feel free to ask for other materials, such as hex dump of the handshake, or the certificates involved.
I am launching a JNLP downloaded from my web application.
After being prompted with a Java Security Warning prompt, the application can run successfully if the user response is within 2-3 seconds. However, if the user took more than 3 seconds to respond to the Java Security Warning prompt, the application fails to run with error with the following socket exception:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during
handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:946)
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:563)
at
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect
(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:1300)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream
(HttpsURLConnectionImpl.java:254)
at com.sun.deploy.net.HttpUtils.followRedirects(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
at com.sun.deploy.net.BasicHttpRequest.doGetRequestEX(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.checkUpdateAvailable
(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.isUpdateAvailable(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:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
... 19 more
Java Security Warning
Exception
Additional Info: I have checked the ports and they were pointing on the correct port numbers and TLS value also matched. The certificates were also added under cacerts.
Question: What causes the exception when response to the security prompt reaches more than 3-5 seconds? and how can I avoid the mentioned exception(possibly increase the waiting time)?
Actions done:
1. Add connectionTimeout attribute in Tomcat connector, but still, after 5 seconds of waiting time to respond to the Java Security Warning, the application still fails to launch.
This is most easily controlled by the https.protocols system property. This is how you are able to control what the factory method returns. Set to "TLSv1" for example.
It leads to problems when you want to use two protocols instead of one. For example, SSLv3 and TLSv1. This -Dhttps.protocols=TLSv1,SSLv3 will lead to exceptions if you try to connect either SSLv3 or TLSv1.
Please check this answer.
How to make Java 6, which fails SSL connection with "SSL peer shut down incorrectly", succeed like Java 7?
I was facing the same problem, then I switched from JRE1.7 to JRE1.8 of course for reason TLS1.2 More references
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.
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.