Develop Reference

ActiveMQ TLS host hostname verifications

In ActiveMQ 5.15.6 they enabled the TLS host name verification, and I see my application failing after upgrade.
In their documentation they mentioned they have fixed the server side TLS validation by making default to False. Is their any way I can make TLS hostname verification FALSE at client side as well?

Yes, you can disable TLS hostname verification at the client side as well. Use something like this:
ssl://hostname:61616?socket.verifyHostName=false
or
ssl://hostname:61616?verifyHostName=false

SSL works on url without .com?

I am trying to enable SSL in my hosted project via tomcat.
I managed to upload certs but the connection is still unsecured.
My Url looks like this
laptap.partner.solution
Is it possible to enable SSL using this url, and get a green lock at the same time? Someone told me SSL only works on TLD's.
What does it mean?

when you generate an SSL certificate you must use wildcard (*.example.com) so it works with your subdomain.
you can use Let's Encrypt to generate free SSL certificates which also supports wildcards and the Green Bar you want to have

Netty skips hostname validation when we use trust manager with trustCertCollectionFile

I am using io netty version 4.1.19.Final
I am trying to set up a client which will connect to a server using TLS.
I want the netty to perform hostname validation when it receives TLS certificates, but it looks like since I am using a custom trustManager using TLS Trust file path netty skips hostname validation completely.
Is there a way for me to specify a custom trustManager using TLS Trust file path AND have io netty perform hostname validation????
SslContextBuilder builder = SslContextBuilder.forClient();
File trustCertCollection = new File(conf.getTlsTrustCertsFilePath());
builder.trustManager(trustCertCollection);
Netty API:- https://netty.io/4.0/api/io/netty/handler/ssl/SslContextBuilder.html#trustManager-java.io.File-
Full code:-
https://github.com/apache/incubator-pulsar/blob/master/pulsar-client/src/main/java/org/apache/pulsar/client/impl/ConnectionPool.java#L97

Can you open a bug in the netty issue tracker and share some reproducer (best would a unit test)?

Missing ServerHelloDone while SSL Hanshake

I try to connect to a wss (Secure Websocket) server with a java applet but the ssl handshake fails without any helpfull log entrys.
If I connect to wss://echo.websocket.org the handshake works fine, so I think it's not a general java code error.
If I try to connect to my own server, the HelloDone bit is sent (verified by wireshark) but the connections ends in a hang-up and it's not in the log. Normally there should be the following message in the log: "*** ServerHelloDone"
See my java console log of "javax.net.debug=sll"
http://pastebin.com/ZuvKww4J
It is not truncated, it simply ends there.
After a couple of seconds the tcp connection timeout message is added to the log.
I use the following example of java code:
https://github.com/TooTallNate/Java-WebSocket/blob/master/src/main/example/SSLClientExample.java
But instead of keystore I use:
sslContext.init( null, null, null );
For the server I have two different test systems:
At port 443 a ha-proxy
at port 8443 a stunnel.
I tried to isolate the error with different methods. First I forced with stunnel the same cipher as echo.websocket.org "SSL_RSA_WITH_RC4_128_SHA" but no success.
Second I checked if the ssl certificate itself is still valid. But as web browser and normal https connection by my java applet, are accepted from the server (Same server. ha-proxy orstunnel) everything is working at that point to.

Problem was solved by maintainer of Java-WebSocket.
Big thans

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.