FULL PRODUCT VERSION :
java version " 1.7.0_21 "
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
Microsoft Windows Vista [6.0.6002]
Microsoft Windows 7 [Version 6.1.7601]



EXTRA RELEVANT SYSTEM CONFIGURATION :
not relevant

A DESCRIPTION OF THE PROBLEM :
Since the introduction of the new security features the entries in the user's trusted cert keystore are incorrectly named when added by the new security dialog for browser based java programs (e.g. webstart).


REGRESSION. Last worked in version 7u17

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start a webstart-application that uses a self-signed certificate and wait for the new security-dialog. Then add the certificate to the user's certificate keystore by checking the boxes for " trust " and " don't ask again " .

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
User's truested cert keystore containing an entry like

deploymentusercert$tsflag$loc=http//my.server.here:80-45352345984574
ACTUAL -
Keystore's entry is

deploymentusercert$tsflag$loc=http//my.server.here:80java.util.random@195648f

It is obvious that there is missing the call to the method " toLong() " in the certificate entry string building method.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
no explicit error message



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
The faulty code resides in " deploy.jar " in JAVA_HOME/lib/

Class: com.sun.deploy.security.CertUtils

Method: protected static boolean add(KeyStore, String, Certificate, String, boolean)

The line assembling the certificate alias name is the problem.

  Programmed this way, even " null " -strings could occur in the name (instead of empty strings like intended). We also don't think, that the timestamp-flag ( " $tsflag " ) implemented correctly.

Looks like programmed in a rush without proper testing.

---------- END SOURCE ----------