JDK-7177232 : JSSE changes in Java 7 break Jarsigner fatally: unrecognized_name
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2003,windows_7
  • CPU: x86
  • Submitted: 2012-06-15
  • Updated: 2012-06-22
  • Resolved: 2012-06-20
Related Reports
Duplicate :  
JDK-7178863 - jarsigner -tsa fails with javax.net.ssl.SSLProtocolException: handshake alert:
Description
FULL PRODUCT VERSION :
JDK 1.7 update 5

ADDITIONAL OS VERSION INFORMATION :
Windows 7, and probably all other OSes

A DESCRIPTION OF THE PROBLEM :
  Bug report 7127374 gives most of the lower-level details. This bug was closed as not a defect. This is incorrect, and the bug is rendering jarsigner unusable in Java 7. The workarounds listed there are not available with jarsigner.

However, this bug report is specifically about jarsigner.

In particular, the person who closed the defect failed to understand the situation.

He states: ""https://timestamp.geotrust.com/tsa", with IE and Firefox. Both shows no page found."

That is the intended behavior of this TSA. It explicitly is returning that respond, and the browsers ARE SHOWING THE RESPONSE. For this to happen, the browsers must first be establishing the SSL connection; therefore the statement made in the report is correct, and the person who closed it is incorrect. This has always been the behavior of this URL, yet it  continues to work correctly with Java 6's jarsigner.

In Java 7, on the other hand, Jarsigner simply dies with:

jarsigner: unable to sign jar: javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name

We cannot ship (or even test) our product signed without a timestamp. This is the URL provided us by our certificate vendor (Verisign). I strongly suspect this is the most widely-used TSA for signing Java code.

Jarsigner has no option for setting jsse.enableSNIExtension=false, so this workaround is unavailable, as are the other two.

The only workarounds are to use Java 6's jarsigner, or to find a TSA that does not send this response.

An documented option to jarsigner to disable this would suffice.

REGRESSION.  Last worked in version 6u31

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Sign a jar file with jarsigner, supplying -tsa https://timestamp.geotrust.com/tsa



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The signed jar file with timestamp from the TSA.
ACTUAL -
jarsigner: unable to sign jar: javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name

ERROR MESSAGES/STACK TRACES THAT OCCUR :
jarsigner: unable to sign jar: javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Use Java 6
Comments
EVALUATION Thank you very much for your report on the incident. I have to say that it is a compatibility issue introduced and exposed in JDK 7. But it is not a issue of Java. Please read more. From JDK 7, the server name indication (SNI) extension (section 3.1, RFC4366) was included in the TLS client handshaking messages by default, in order to support ip-shared virtual hosting or ip-shared virtual machines. According to the spec of TLS, it should not introduce compatibility issue when support server name indication extension in client side. The server can ignore the server name indication, or checking for accuracy of the server name indication. If server want to check the server name indication, it maybe deny connection when the server name indication is not the expected server name, fail with an unrecognized_name alert. When we using the jarsigner as: jarsigner -keystore keystore -tsa https://timestamp.geotrust.com/tsa -signedjar dns-signed.jar dsn.jar mykey the server name indication is referring as timestamp.geotrust.com. The server, timestamp.geotrust.com, do want to check the server name indication, rather than ignore the extension. And it realizes that the server name ("timestamp.geotrust.com") in the SNI extension is not the server name it supports, then terminate the TLS connection with "unrecognized_name" fatal alert. That's to say, the server ("timestamp.geotrust.com") does not think it is "timestamp.geotrust.com". It looks strange and weird. In such cases, according to TLS specificate (RFC4366), the client has to close the connections because the server has refused to continue the handshaking. There is not much we can do in Java. So it is not a bug of JDK, it is the purpose of server that need to deny the server name indication request, or some miss-configuration in the server side. The service provider need to make sure the server configuration is correct, or set the server to accept the server name, "timestamp.geotrust.com". If it is not possible to update the server side, the possible workaround is to disable the server name indication in client side, which can be done by setting system property jsse.enableSNIExtension to false. For the definition of the system property of jsse.enableSNIExtension, please refer to http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#Customization To make sure, please try this: jarsigner -J-Djsse.enableSNIExtension=false -keystore keystore -tsa https://timestamp.geotrust.com/tsa -signedjar dns-signed.jar dsn.jar mykey In general, I would not suggest you disable the SNI extension unless you clearly understand the server structures. As may expose you in the risks that the site is not what you really want to access. Thanks & Regards, Xuelei Fan
16-06-2012
EVALUATION Dispatching to original engineer for reevaluation.
15-06-2012