3

is it possible to change java version of keytool file - .keystore? Our keystore file for signing apks was created under java 7 which is too old as we all know. All our app are developed under newest java version, however because of signing process we still need to keep java 7 on our machine just for signing. Is there any way how to copy entire keystore under newest java version? I already tried e.g.: 

keytool -importkeystore -srckeystore old.keystore -destkeystore new.keystore -v

under java 8 and I got exception:

Unable to initialize, java.io.IOException: DerInputStream.getLength(): Redundant length bytes found

When I run same command under java 7 it works of course.

Already tried:

Oleg's post - gives the same exception as above

Unable to initialize, java.io.IOException: DerInputStream.getLength(): Redundant length bytes found

Import original keystore to new one, using KeyStore Explorer tool, which imported certificate successfully however with changed SHA1 fingerprint.

Create completely new keystore file under Java 7 and list its details using keystool of Java 8 successfully, just to conform that keystore file is somehow broken.

Even tried Oleg's suggestion to open this keystore file under newest Java is not working still Redundant length bytes exception.

Edit As @Oleg pointed in comment, alias was probably somehow corrupted. So we are not able to use newest Java with this one for signing. So it looks like there is no solution for my issue. Anyway for copying content of one keystore file to another is Oleg's solution is correct.

Mony
  • 93
  • 1
  • 11
  • 1
    I've been using the same keystore for about 17 years, dating back to Java 1.3 if not earlier, and I have never had a compatibility problem. – user207421 Aug 09 '17 at 07:13

1 Answers1

2

Java 8 should have no problem with a keystore file created by Java 7. You probably have different default keystore types defined by keystore.type property in java.security file or some other configuration problem. See here.

Instead of figuring out what the problem is an easy way to solve this would be to use a temporary keystore with explicit type.

With Java 7 keytool:

keytool -importkeystore -srckeystore old.keystore -destkeystore temp.keystore.p12 -deststoretype PKCS12

And then with Java 8:

keytool -importkeystore -srckeystore temp.keystore.p12 -srcstoretype PKCS12 -destkeystore new.keystore
Oleg
  • 6,124
  • 2
  • 23
  • 40
  • also ensure both versions of JRE have JCE policy jars – Monish Sen Aug 07 '17 at 15:16
  • Thanks @Oleg, I found this one before but am not sure if this is what I'm searching for. Will give it a try and let you know if it will work. – Mony Aug 08 '17 at 06:16
  • You need more than that. This way will lose all the private keys. – user207421 Aug 09 '17 at 07:14
  • @EJP Thanks, you are totally right. I changed my answer. – Oleg Aug 09 '17 at 09:31
  • @Mony I changed my answer, check if it helps you now. – Oleg Aug 09 '17 at 09:31
  • @Oleg unfortunately it looks like you're right that there is something wrong with .keystore file. Your command is not working for me, I'm getting the same exception as mention in my Q. I tried to copied content of keystore file to new one under Java 8 using Keystore Explorer tool what was successful, however SHA1 fingerprint was different. What would then probably explain why Java 8 has a problem with my original keystore file. If there is no way how to "repair" original keystore file than we probably need to create new one and lose our current app users. – Mony Aug 09 '17 at 20:40
  • @Mony Have you seen [this](https://stackoverflow.com/questions/42554221/signing-android-app-throws-ioexception-redundant-length-bytes-found)? If it works with java7 then the keystore file itself is fine. – Oleg Aug 09 '17 at 20:58
  • @Mony Are you using 121 java 8 version? – Oleg Aug 09 '17 at 21:10
  • @Oleg our OnPremise agent uses 1.8.0_121 however hosted agent uses 1.8.0_102 and both have problem to use our original keystore file. For link you posted, It will not gonna work for me, as I describe above I already tried to import original keystore to new one (I used .p12, jks also cert) new keystore or .p12 or others have different SHA1 finger print then original one and that's why Google rejects apk signed with this certificate. – Mony Aug 10 '17 at 07:03
  • @Mony The problem is not with the *keystore* but with the **certificate** (alias) itself. The keys in your certificate do not work with java 8 121.It's something oracle broke after 112 and fixed in 131. If they have different fingerprint it means that the tool you used "fixed" the keys, changing the fingerprint in the process and making the certificate useless. What's "OnPremise agent"? Are you talking about Visual Studio Team Services? I'm not familiar with it. You should try with your original certificate on your own computer with the latest java version. – Oleg Aug 10 '17 at 10:46
  • @Oleg OnPremis agent is our computer for releasing our app to play store, it is visual studio team service and, we already tried to use original key on this agent with latest java, no success still exception with redundant length bytes. So we decided to just give up on this one and create completely new app for play store, what means to lose users, however discovering what's the real problem with key will cost much more money than lose these few users. Thanks for your time and helping really appreciate that. – Mony Aug 11 '17 at 07:06
  • @Mony Ok, though I'm still pretty sure you are using a version that has the bug in it. Upon further investigation oracle only fixed it for their BPR(for enterprises) versions. Latest java 8 openjdk or java 9 should work. – Oleg Aug 11 '17 at 09:32
  • old keystores allowed passwords under 6 characters, the newer keytools are - quite stubbornly disallowing this, and refusing to open or do anything with the older keystore as a result,. so yeah, i can see an older keytool being useful. – T.S Oct 14 '21 at 11:15