javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name

Caused by: javax.net.ssl.SSLProtocolException: handshake alert:  unrecognized_name

at sun.security.ssl.ClientHandshaker.handshakeAlert(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 sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)

at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)

at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)

at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)

at java.net.URL.openStream(Unknown Source)

Issue :

I got this exception when I am trying to connect to WebService using https. You may also get this while connecting to any HTTPS url .

Solution:

It is issue with Server , because in their certificate the common name doesn’t match with  url domain.

It's possible to put multiple hostnames in a modern certificate and just use that one certificate in the default vhost, there are many hosting providers who are hosting for too many sites on a single address for that to be practical for them

In two ways we can fix the issue :

Http Client Side:

Java 7 introduced SNI support which is enabled by default. I have found out that certain misconfigured servers send an "Unrecognized Name" warning in the SSL handshake which is ignored by most clients... except for Java.

As workaround, I suggest to set the jsse.enableSNIExtension property. To allow your programs to work without re-compiling, run your app as:

java -Djsse.enableSNIExtension=false yourClass

The property can also be set in the Java code, but it must be set before any SSL actions. Once the SSL library has loaded, you can change the property, but it won't have any effect on the SNI status. To disable SNI on runtime (with the aforementioned limitations), use:

System.setProperty("jsse.enableSNIExtension", "false");

The disadvantage of setting this flag is that SNI is disabled everywhere in the application. In order to make use of SNI and still support misconfigured servers:

1. Create a SSLSocket with the host name you want to connect to. Let's name this sslsock.
2. Try to run sslsock.startHandshake(). This will block until it is done or throw an exception on error. Whenever an error occurred in startHandshake(), get the exception message. If it equals to handshake alert: unrecognized_name, then you have found a misconfigured server.
3. When you have received the unrecognized_name warning (fatal in Java), retry opening a SSLSocket, but this time without a host name. This effectively disables SNI (after all, the SNI extension is about adding a host name to the ClientHello message).

HttpServer Side:

On the server side we have to create certificate with matching Domain name as Server Name or define where we have ServerName / ServerAlias as same name mentione din certificate common name.

Ref:

1. https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

2.https://support.roambi.com/hc/en-us/articles/200858194-Cannot-verify-SSL-portal-due-to-error-javax-net-ssl-SSLProtocolException-handshake-alert-unrecognized-name

3.http://en.wikipedia.org/wiki/Server_Name_Indication

SSL Certificate

Today we will learn about  " How SSL Works ?" , which is a common question to most of the techies who work with the socket and SSL.

 I assume reader knows about the browser and web server .

Why Use SSL?

Inshort, SSL stands for Secure Socket Layer. It adds more security to the communication. It is used with HTTP or TCP or FTP. To avoid data tampering in the communication we will choose SSL.

 

Transferring sensitive information over a network can be risky due to the following three issues:

• You cannot always be sure that the entity with whom you are communicating is really who you think it is.
• Network data can be intercepted, so it is possible that it can be read by an unauthorized third party, sometimes known as an attacker.
• If an attacker can intercept the data, the attacker may be able to modify the data before sending it on to the receiver.

SSL addresses each of these issues. It addresses the first issue by optionally allowing each of two communicating parties to ensure the identity of the other party in a process called authentication. Once the parties are authenticated, SSL provides an encrypted connection between the two parties for secure message transmission. Encrypting the communication between the two parties provides privacy and therefore addresses the second issue. The encryption algorithms used with SSL include a secure hash function, which is similar to a checksum. This ensures that data is not modified in transit. The secure hash function addresses the third issue of data integrity.
Note, both authentication and encryption are optional, and depend on the the negotiated cipher suites between the two entities.
The most obvious example of when you would use SSL is in an e-commerce transaction. In an e-commerce transaction, it would be foolish to assume that you can guarantee the identity of the server with whom you are communicating. It would be easy enough for someone to create a phony Web site promising great services if only you enter your credit card number. SSL allows you, the client, to authenticate the identity of the server. It also allows the server to authenticate the identity of the client, although in Internet transactions, this is seldom done.
Once the client and the server are comfortable with each other's identity, SSL provides privacy and data integrity through the encryption algorithms it uses. This allows sensitive information, such as credit card numbers, to be transmitted securely over the Internet.
While SSL provides authentication, privacy, and data integrity, it does not provide non-repudiation services. Non-repudiation means that an entity that sends a message cannot later deny that they sent it. When the digital equivalent of a signature is associated with a message, the communication can later be proved. SSL alone does not provide non-repudiation.

How SSL Works?