Develop Reference

How to enable javax.net.debug on demand

Our application uses Apache HttpClient 4.5.3 and we are observing a very weird behavior with communication between our client and the server using SNI capability
The server is configured to return a Go Daddy signed certificate if the SSL request comes in the with the server name expected from our client(ie: the host name of the server) and it will return a self signed certificate for all other domain names
Behavior observed
The client receives the correct server certificate on all server except on our production machine
The client code is running in an application deployed on tomcat 8, we have noticed that initial requests to the endpoint go through successfully. After some time of running we receive an SSL exception on the client.
The error is because the server is not sending the correct certificate(it sends the default self signed certificate)
If we restart the tomcat server on which the client is deployed, the calls again start to go through successfully.
We have used javax.net.debug for debugging purposes in the past but we cannot use it in this case as we need to restart the tomcat server for its effect to take place and when we restart the tomcat server, the calls to the endpoint server start to succeed.
Also the javax.net.debug logs a lot of information which will flood our logs and hence we wanted it enabled only for a specific request.
We are hoping to log only the Client Hello(which contains the server_name passed to the endpoint)
I have read through
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#OwnX509ETM
But not sure of what we can use to print only the SSL server name indicator pushed down to the server.

I had the same concern as yours, then firstly I was thinking about dynamically adding environment variable, but it's always taking old value. Then I found out that javax.net.debug environment variable is read once only with static block in SSLSocketFactory.java. The full source code is available here.
static {
String s = java.security.AccessController.doPrivileged(
new GetPropertyAction("javax.net.debug", "")).toLowerCase(Locale.ENGLISH);
DEBUG = s.contains("all") || s.contains("ssl");
}

How to make possible ActiveMQ with SSL connection encryption?

Currently my ActiveMQ is working fine with TCP connection. But i want to activate data encryption with SSL connection.
Got one trick on internet that by adding new <transportConnector> we can do. but after changing, got error and my tomcat server is also not getting started.
my entry for SSL connection enable.
<transportConnector name="ssl" uri="ssl://0.0.0.0:61617?trace=true&needClientAuth=false"/>
<amq:sslContext>
<amq:sslContext
keyStore="file:${activemq.conf}/amq-server.ks" keyStorePassword="xxxx"
trustStore="file:${activemq.conf}/amq-server.ts" trustStorePassword="xxxx"/>
</amq:sslContext>
After putting the above code, ActiveMQ is not working properly. Even my tomcat server is also not getting started.

Getting error "javax.net.ssl.SSLException: 530 Please login with USER and PASS" while performing ftp

I am getting the below given error while performing ftp from ubuntu machine to same machine. I have done the complete setup and able to transfer file using Filezilla. But while doing the same from code it is giving error. Below I have shown the code snippet.
String PROTOCOL= "SSL"; //I Have tried with TLS also
FTPSClient ftpsClient = new FTPSClient(PROTOCOL, false);
ftpsClient.setTrustManager(TrustManagerUtils.getAcceptAllTrustManager());
ftpsClient.connect("192.168.13.5",21);
ftpsClient.login(userName, password);
I am getting the error 530 Please login with USER and PASS. While connecting only. It is not even going to login statement.
Can somebody please point me out what I am doing wrong here?

I am getting the error 530 Please login with USER and PASS. While connecting only. It is not even going to login statement.
If it is not even going to the login statement the message might be caused by the server rejecting the AUTH TLS command which is used to upgrade the connection to SSL/TLS. This might indicate that the server does not support TLS at all.
... able to transfer file using Filezilla.
Are you sure that Filezilla did use FTP with TLS and not plain FTP or SFTP (which is file transfer using SSH, something completely different to FTPS)?

I'm not quite sure, but when you're saying you're using the server and the Client on one machine, you have to use localhost 127.0.0.1 as IP Adress

Java SSL connection and UNKNOWN SERVER CERTIFICATE warning

I'm using Netty for asynchronous http(s) requests. When the url for the request is https I'm adding this to the pipeline:
SSLEngine engine = SecureChatSslContextFactory.getClientContext().createSSLEngine();
engine.setUseClientMode(true);
pipeline.addLast("ssl", new SslHandler(engine));
This works well, I get the response back and everything, but a warning is being written to the output saying: UNKNOWN SERVER CERTIFICATE, for example if I issue a request for: https://www.google.com this is what I get:
UNKNOWN SERVER CERTIFICATE: CN=www.google.com, O=Google Inc, L=Mountain View, ST=California, C=US
Since everything is still working it's not that much of an issue for me, but there are two things I would like to know:
Why do I get that warning? googles' certificate is a "well known" one, the browsers don't seem to warn about it. Should I somehow tell the ssl engine where to look for the certificates?
Can I somehow catch this warning at runtime instead of having this message printed out?
Thanks.

Check to make sure that the "trust store" is correctly identified to Netty when you do this, you may have to look at adding ${JAVA_HOME}/jre/lib/security/cacerts as a trusted store.
If that's not configured you probably won't be able to connect over SSL

Dave,
Take a look at the code sample in this thread: Set up Netty with 2-way SSL Handsake (client and server certificate)
I think that will help you with your keystore and truststore setup.

Question on ssl handshake and behavior in java

I am using https to connect to an https server.
Specifically I am using apache httpclient and I configure the ssl context to use my keystore and truststore.
The https server I am using is IIS7 and is configured to require client authentication.
I think I have set it up properly.
Anyway, if I configure the httpClent's ssl context with a keystore (i.e. with client certificates) valid for IIS then there is no problem connecting.
Now my problem is the following:
If I do not configure the ssl context with any client certificate to send to IIS, there is no connection with the server. What makes me think though, is the fact that I was expecting to see some java exception in the code as a result of a hanshake failure alert.
Monitoring what is happening with wireshark, I could not see a certificate request from IIS to my application, but I noticed that after ServerHelloDone everything was encrypted.
I did not expect that. I think the handshake is usually in cleartext.
I used private key to decrypt traces and i saw a certificate request from IIS but after many starting and opening of new connections.
My app send back as a response a certificate of length 0 and IIS replies with a TLSv1 Finished.
After that the packets stop (i.e. seems that the communication ends).
I was expecting a handshake alert.
My question is, is this how it is supposed to work or at least how IIS works?
Or if I do not see the alert something is wrong with my use case?
Thanks

It sounds like IIS is only requiring client certificates for certain URLs (ie, for example.com/foo, but not example.com/bar).
In the initial handshake, it does not know which url you are requesting, so it does not require a certificate. When it sees that you are requesting a restricted resource (/foo), it then rehandshakes, requiring a certificate.
However, I would still expect a handshake_failure to occur.

As I was saying in an answer to this question, as far as I remember, IIS uses re-negotiation to get the client certificate. You should be able to change this behaviour using netsh and clientcertnegotiate=enable (depending on the version of IIS you're using).
You might also be interest in this similar question.

Failing to supply a certificate in response to a CertificateRequest isn't an SSL protocol error, so there is no handshake_error. 'Requiring' instead of just 'needing' client certificates is added-in by SSL libraries, and all they can do if you don't send one is just close the connection.