JDK-6178366 : REGRESSION: keytool corrupts password entered on prompt
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 5.0,5.0u2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: generic,sparc
  • Submitted: 2004-10-13
  • Updated: 2010-04-02
  • Resolved: 2004-12-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u2Fixed 6 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Description
Found with J2SE 1.5.0 FCS (b64).

Steps to reproduce:
- generate key using
  keytool -genkey -alias MyAlias -keystore ./keystore
  type in infos for dname and choose some passwords
- list the keys (optional)
  keytool -list -keystore ./keystore
- try to clone key
  keytool -keyclone -alias MyAlias -keystore ./keystore
  you will be prompted for keystore password which passes OK, then for key
  password which fails. See "conversation" bellow.

jt146064@sr-eprg05-01:~/tmp/keytooltest>java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
Java HotSpot(TM) Server VM (build 1.5.0-b64, mixed mode)
jt146064@sr-eprg05-01:~/tmp/keytooltest>which java
/home/jt146064/java/bin/java
jt146064@sr-eprg05-01:~/tmp/keytooltest>which keytool
/home/jt146064/java/bin/keytool
jt146064@sr-eprg05-01:~/tmp/keytooltest>keytool -genkey -alias MyAlias -keystore ./keystore
Enter keystore password:  jt146064
What is your first and last name?
  [Unknown]:  Jiri Tusla
What is the name of your organizational unit?
  [Unknown]:  G11n
What is the name of your organization?
  [Unknown]:  SMI
What is the name of your City or Locality?
  [Unknown]:  Prague
What is the name of your State or Province?
  [Unknown]:  Czech Rep.
What is the two-letter country code for this unit?
  [Unknown]:  CZ
Is CN=Jiri Tusla, OU=G11n, O=SMI, L=Prague, ST=Czech Rep., C=CZ correct?
  [no]:  yes

Enter key password for <MyAlias>
        (RETURN if same as keystore password):  prague_g11n
jt146064@sr-eprg05-01:~/tmp/keytooltest>keytool -list -keystore ./keystore
Enter keystore password:  jt146064

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

myalias, Oct 13, 2004, keyEntry,
Certificate fingerprint (MD5): 49:DB:62:B6:79:D6:97:61:C9:11:23:B0:0B:1D:B5:2F
jt146064@sr-eprg05-01:~/tmp/keytooltest>keytool -keyclone -alias MyAlias -dest SCTAlias -keystore ./keystore
Enter keystore password:  jt146064
Enter key password for <MyAlias>prague_g11n
keytool error: java.security.UnrecoverableKeyException: Cannot recover key
jt146064@sr-eprg05-01:~/tmp/keytooltest>
###@###.### 10/13/04 10:50 GMT

Comments
SUGGESTED FIX Fix the catch block (line 1755) in the recoverPrivateKey method in the sun.security.tools.KeyTool class. ###@###.### 10/14/04 13:29 GMT
13-10-2004

WORK AROUND Pass all passwords as a CLI parameters to keytool ###@###.### 10/13/04 10:50 GMT
13-10-2004

EVALUATION The keytool utility fails to clone a private key under certain circumstances. The problem only occurs when the following two conditions are met: 1) the private key (to be cloned) is protected by a password that is different from the password that protects the keystore. 2) the key password has not been supplied as a command-line argument to keytool. Since no key password has been provided, KeyTool first tries to recover the key using the keystore password. That will fail and throw an UnrecoverableKeyException. The exception is caught and the user is prompted to enter the key's password. KeyTool then tries to recover the key using the supplied password. The key will be found if the password is correct. The problem is that following the retry, the exception gets thrown anyway. ###@###.### 10/14/04 13:29 GMT
13-10-2004