使用Java SSLSocket时，Windows和Linux / OS X有什么区别？

Question

I wrote a multi-server chat system based on Java under Windows. At the security part, I created one keystore to create the SSLSocket. When I launch 3 servers, it works on Windows(Win10 14393.321) but fails on OS X(Version 10.12 (16A323)) and Linux(Ubuntu 14.04.4 LTS). It really confused me. Here is the keystore part:

System.setProperty("javax.net.ssl.keyStore",keyFilepath);
System.setProperty("javax.net.ssl.trustStore",keyFilepath);
System.setProperty("javax.net.ssl.keyStorePassword","password");
System.setProperty("javax.net.ssl.trustStorePassword", "password");

And when I run the third server on OS X or Linux, it shows:

java.net.ConnectException: Connection refused

at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:427) at sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:88) at server.AuthorizeServer.MessageReceive(AuthorizeServer.java:99) at server.AuthorizeServer.main(AuthorizeServer.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method. invoke(Method.java:497) at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)

This is my first time asking on StackOverflow and I really looking forward to your kind help. Thanks!

Answer 1

java.net.ConnectException: Connection refused

Connection refused is an error message from the TCP stack and means that it could not connect with TCP to the other side. Since SSL/TLS is a layer on top of TCP and is only started once the TCP connect succeeded it means that the problem is not caused by different behavior at the SSL/TLS layer.

That this is not cause by the SSL layer but the TCP layer can also be seen by the stacktrace: Connection refused at java.net. PlainSocket Impl.socketConnect

More likely is that there is something blocking the TCP connection (firewall) or that you've tried to listen/connect to the wrong IP address (eg trying to reach a server listening on 127.0.0.1 on Windows from the Linux system). But is impossible to say from the currently provided information what exactly is the case.