JDK-7174166 : Code signing issue
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 7u4
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_vista
  • CPU: x86
  • Submitted: 2012-06-04
  • Updated: 2012-06-05
  • Resolved: 2012-06-05
Related Reports
Relates :  
J2SE Version (please include all output from java -version flag):
  java version "1.7.0_04"
  Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
  Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode, sharing)

Does this problem occur on J2SE 6ux or 7ux?  Yes / No (pick one)
  Java 7

Operating System Configuration Information (be specific):

  Windows Vista Business SP2

Hardware Configuration Information (be specific):

  HP Pavillion dv9000
  Windows Vista Business SP2 32 bit
  3 GB RAM
  Intel Core 2 Duo T9300

Bug Description:

The problem is that signing jar files with a timestamping service does work in
practice.  Verisign, being one of the players in certificates, has a recommend 
TSA service to use.  jarsigner does not work with their service using Java 7,

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

This bug has been reported to both Oracle and Versign, with no resolution.

In the previous bug report sent to Oracle, there is a comment in the evaluation:
> > however since most Browsers happyly connect to those servers,
> I tried to access the UEL mentioned in the bug description,
> with IE and Firefox. Both shows no page found. So what's your mean about 
> "most browsers happyly connection to those servers"?

The evaluator is correct that this URL is not accessible to browsers, but it does
work from jarsigner.  They must be blocking this URL from browsers.  However,
https://timestamp.geotrust.com does work from a browser and the certificate
information can be obtained from this URL.

The crux of this issue is that timestamping is the recommend way to do things.
Verisign (part of Symantec) is doing its thing, and Oracle is doing theirs.  
However, people like me need both entities to cooperate to get our job done.

Current workaround is just to use the jarsigner from Java 6.  However, using a
"workaround" is always a bit unnerving since one can never be quite sure how long 
the workaround will work.



Steps to Reproduce (be specific):

Created a certificate just for this test, called mykey in the attached keystore.  
The password is 'passwd'.  The dsn.jar is a jar I downloaded as part of the 
java mail bundle to have a jar to include in this report.

jarsigner -keystore keystore -tsa https://timestamp.geotrust.com/tsa -signedjar dns-signed.jar dsn.jar mykey

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

PUBLIC COMMENTS Not a defect, close it. From JDK 7, the server name indication will be included in the TLS client messages. 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. 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. Please 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.