Does anyone know how to solve this?
I tried many things, but none of them worked.
And when I click more details I get this:
at sun.security.provider.JavaKeyStore.engineLoad(Unknown Source)
atsun.security.provider.JavaKeyStore$JKS.engineLoad(Unknown Source)
at java.security.KeyStore.load(Unknown Source)
at com.sun.deploy.security.RootCertStore$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.RootCertStore.loadCertStore(Unknown Source)
at com.sun.deploy.security.RootCertStore.load(Unknown Source)
at com.sun.deploy.security.RootCertStore.load(Unknown Source)
at com.sun.deploy.security.ImmutableCertStore.load(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Ramesh R
7,0094 gold badges25 silver badges38 bronze badges
asked Jun 27, 2009 at 11:43
7
You may corrupt the file during copy/transfer.
Are you using maven?
If you are copying keystore file with «filter=true», you may corrupt the file.
Please check the file size.
answered Aug 13, 2011 at 13:05
2
Maybe maven encoding you KeyStore, you can set filtering=false to fix this problem.
<build>
...
<resources>
<resource>
...
<!-- set filtering=false to fix -->
<filtering>false</filtering>
...
</resource>
</resources>
</build>
answered Mar 8, 2016 at 7:58
xiezefanxiezefan
6016 silver badges5 bronze badges
2
(Re)installing the latest JDK (e.g. Oracle’s) fixed it for me.
Prior to installing the latest JDK, when I executed the following command in Terminal.app:
keytool -list -keystore $(/usr/libexec/java_home)/jre/lib/security/cacerts -v
It resulted in:
keytool error: java.io.IOException: Invalid keystore format
java.io.IOException: Invalid keystore format
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:650)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1445)
at sun.security.tools.keytool.Main.doCommands(Main.java:792)
at sun.security.tools.keytool.Main.run(Main.java:340)
at sun.security.tools.keytool.Main.main(Main.java:333)
But, after installing the latest Oracle JDK and restarting Terminal, executing the following command:
keytool -list -keystore $(/usr/libexec/java_home)/jre/lib/security/cacerts -v
Results in:
Enter keystore password:
Which indicates that the keytool on path can access the keystore.
answered Jan 5, 2016 at 21:39
Gary S. WeaverGary S. Weaver
7,9664 gold badges37 silver badges61 bronze badges
3
I had the same issue with different versions of keytool:
C:\Program Files\Java\jdk1.8.0_51\bin\keytool
but the same keystore file worked fine with
«C:\Program Files\Java\jre1.8.0_201\bin\keytool»
I know it is an old thread but have lost a lot of hours figuring this out…
answered Jun 19, 2020 at 9:55
ShoaebShoaeb
7097 silver badges18 bronze badges
2
I had spent lot of time on this and finally This worked for me —
go to file -> project structure -> SDK Location -> Gradle Settings -> Change Gradle JDK -> from 1.8 to 11
Just change Gradle JDK -> from 1.8 to 11 then rebuild the project and try again
answered Aug 9, 2022 at 6:54
1
for me that issue happened because i generated .jks file on my laptop with 1.8.0_251 and i copied it on server witch had java 1.8.0_45 and when I used that .jks file in my code i got java.io.IOException: Invalid Keystore format.
to solve this issue i generated .jks file directly on the server instead of copy there from my laptop which had different java version.
answered Jan 19, 2021 at 0:48
FaribaFariba
6931 gold badge12 silver badges27 bronze badges
I think the keystore file you want to use has a different or unsupported format in respect to your Java version. Could you post some more info of your task?
In general, to solve this issue you might need to recreate the whole keystore (using some other JDK version for example). In export-import the keys between the old and the new one — if you manage to open the old one somewhere else.
If it is simply an unsupported version, try the BouncyCastle crypto provider for example (although I’m not sure If it adds support to Java for more keystore types?).
Edit: I looked at the feature spec of BC.
answered Jun 27, 2009 at 11:48
akarnokdakarnokd
69.2k14 gold badges157 silver badges192 bronze badges
Your keystore is broken, and you will have to restore or regenerate it.
answered Jun 27, 2009 at 15:34
1
I ran into the problem with openJDK on ubuntu, had to install Oracle JDK to get it working.
You can follow this guide on google sites to do that.
answered Sep 19, 2017 at 10:19
Sadiq AliSadiq Ali
1,2722 gold badges15 silver badges22 bronze badges
Same issue here, I have Oracle JDK installed and my keystore was created using that, but in the jceks
format
keytool -importkeystore -destkeystore client.keystore \
-srckeystore redislabs_user.p12 -srcstoretype pkcs12 \
-deststoretype jceks -alias client-cert
I deleted the -deststoretype jceks
option and it worked fine
answered Nov 5, 2020 at 14:49
rulowebruloweb
7048 silver badges10 bronze badges
In my case, I was running the project with Java version 1.8. and the Keystore.jks file that I generated from java 16.
I changed my project java version to 16 and the error goes away.
Please check the JDK version with which you are generating the keystore and the JDK version for your project are the same or not. If they are different, either generate the keystore from the same JDK on which your current project is running or change the project JDK.
answered Nov 13, 2021 at 17:03
I came across this issue while running keytool command. There is an other way to run the keytool command, mentioned here: https://developers.google.com/android/guides/client-auth using gradlew command
.
When I ran in debug mode ./gradlew signingReport --debug
got to know that gradle plugin required java 11 and my local has java8. Downloaded java11 and updated Path. Ran the command (Make sure you open a new terminal so that java path is reflected to 11). Works like a charm !!!
answered Sep 25, 2021 at 6:59
saiyansaiyan
5511 gold badge4 silver badges20 bronze badges
This worked for me (Switched to JDK 11, instead of
Previous JAVA Path «C:\Program Files\Java\jdk1.8.0_202\bin»
Changed Path to "C:\Program Files\Java\jdk-11.0.14\bin"
answered Feb 19 at 12:07
The Keystore generation is different for Java v8 and Java v11.
Java v8 produces keystore of the jks format and I guess Java v11 produces keystore of type PKCS12 with ethe extension .p12.
What you could do is try converting the keystore of .jks format to .12 and try and vice versa. This might help.
Syntax:
To convert a PKCS12 (.p12) keystore to a JKS (.jks) keystore, please run the following command:
keytool -importkeystore -srckeystore key.p12 -srcstoretype pkcs12 -destkeystore key.jks -deststoretype jks
where key.p12 is the name of the p12 file and key.jks is the name of the jks keystore to be created.
The command to do the same is:
keytool -importkeystore -srckeystore kafkatools.truststore.jks -srcstoretype pkcs12 -destkeystore trust.jks -deststoretype jks
This is what I used myself and got rid of the invalid keystore issue.
Reference: https://knowledge.broadcom.com/external/article/151981/how-to-convert-a-pkcs12-p12-keystore-to.html
answered May 16 at 17:19
go to build
clean the project
then rebuild your project
it worked for me.
answered Feb 18, 2019 at 10:27
It may be necessary to run cmd
as administrator.
the paths to specify the .jks
file must be /
and not \
.
If they open the cmd
with the path where the .jks
file is located, they only put in the /key.jks
path
answered Apr 2, 2022 at 22:57
I had problem with «Invalid Keystore format» too. All this answers can’t helped me.
In my case problem was on Mac OS. JAVA_HOME=jdk1.8 not pulled from .zschrc, so I think that generate certs on it, but default was jdk11. I changed it to jdk1.8 with «jenv» and generate certs. How it works.
You can download jenv by brew. And some commands that I used
jenv versions
to check all versions of JDK
jenv global JDK
to set wanted jdk
java -version
to check it
answered Jul 18, 2022 at 14:19
Upgrade your JVM version — I moved from Java 8 to java 17 and it was fixed.
From Oracle:
In Java 8u301 release, a new fix went in to upgrade the default PKCS12 encryption algorithm, as noted in Java 8u301 release notes at https://www.oracle.com/java/technologies/javase/8all-relnotes.html#R180_301
➜ Upgraded the Default PKCS12 Encryption Algorithms
The default encryption algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
For compatibility, a new system property named keystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.
answered Mar 3 at 9:44
MartinsMartins
1,2312 gold badges14 silver badges17 bronze badges
Here’s another reason: If you have multiple JDK versions on your system and generate a keystore with one version but try to import it using a different version, you’ll encounter the error. In my case, I used JDK 17 to create the keystore and JDK 8 to import it.
answered May 19 at 8:56
If you’re a developer, you might have come across the ‘keytool error: java.io.ioexception: keystore was tampered with, or password was incorrect’ error while trying to sign a JAR file or an Android app. This error can be frustrating because it prevents you from signing your application and deploying it. However, don’t worry, as this error is fixable, and we’ll show you how to fix it in this guide.
Step-by-Step Guide to Resolve the Error
- First, navigate to the directory where your keystore file is located. The default location for the keystore file is
~/.android/debug.keystore
. - Open the terminal or command prompt and navigate to the directory where the keystore file is located.
- Run the following command to list the aliases in the keystore file:
keytool -list -keystore {keystore_name}
- After running the command, you’ll be prompted to enter the keystore password. Enter the password and press Enter.
- If you see the same error message, it means that the keystore password is incorrect. You’ll need to reset the password using the following command:
keytool -storepasswd -new {new_password} -keystore {keystore_name}
- After running the command, you’ll be prompted to enter the old keystore password. Enter the old password and press Enter.
- Next, you’ll be prompted to enter the new keystore password. Enter the new password and press Enter.
- Finally, you’ll be prompted to confirm the new keystore password. Enter the new password again and press Enter.
- Once you’ve reset the keystore password, run the following command to list the aliases in the keystore file again:
keytool -list -keystore {keystore_name}
- Enter the new keystore password when prompted, and you should see a list of aliases in the keystore file.
Congratulations! You’ve successfully fixed the ‘keytool error: java.io.ioexception: keystore was tampered with, or password was incorrect’ error.
FAQ
Q1. What does ‘keytool error: java.io.ioexception: keystore was tampered with, or password was incorrect’ mean?
A1. This error message means that the keystore file you’re trying to access has been tampered with or the password is incorrect.
Q2. Why does the ‘keytool error: java.io.ioexception: keystore was tampered with, or password was incorrect’ error occur?
A2. This error can occur due to a variety of reasons, such as an incorrect password, a corrupted keystore file, or a bug in the keytool utility.
Q3. Can I recover a corrupted keystore file?
A3. Unfortunately, it’s not possible to recover a corrupted keystore file. You’ll need to create a new keystore file and migrate your existing keys to the new file.
Q4. Can I keep the same password for the new keystore file?
A4. Yes, you can keep the same password for the new keystore file. However, it’s recommended to use a strong and unique password to protect your keys.
Q5. How can I avoid the ‘keytool error: java.io.ioexception: keystore was tampered with, or password was incorrect’ error in the future?
A5. To avoid this error in the future, make sure to store your keystore file in a secure location and use a strong and unique password. Also, make sure to back up your keystore file regularly to avoid losing your keys.
- How to Use Keytool to Create a Keystore
- How to Sign Your Android App
The «java.io.IoException: Incorrect AVA format» error is encountered when using the keytool command in Android. This error occurs when the certificate or keystore information provided to the keytool is in an incorrect format. This error can prevent the creation of a new keystore or the import of an existing certificate into an existing keystore.
Method 1: Check the Certificate Information
To fix the «keytool error: java.io.IOException: Incorrect AVA format» in Android, you can check the certificate information using the following steps:
-
Open the command prompt or terminal on your computer.
-
Navigate to the directory where your keystore file is located.
-
Run the following command to check the certificate information:
keytool -list -v -keystore your_keystore_file_name
-
Replace
your_keystore_file_name
with the name of your keystore file. -
Enter the keystore password when prompted.
-
Look for the certificate with the incorrect AVA format in the output.
-
Verify that the certificate’s distinguished name (DN) is in the correct format. The DN should be in the format
CN=your_name,OU=your_organizational_unit,O=your_organization,L=your_city,ST=your_state,C=your_country_code
. -
If the DN is incorrect, you can fix it by creating a new certificate with the correct DN using the following command:
keytool -genkey -v -keystore your_keystore_file_name -alias your_alias_name -keyalg RSA -keysize 2048 -validity 10000
-
Replace
your_keystore_file_name
with the name of your keystore file andyour_alias_name
with a unique alias name for your certificate. -
Follow the prompts to enter the required information, including the correct DN.
-
Once you have created the new certificate, you can delete the old certificate using the following command:
keytool -delete -alias your_alias_name -keystore your_keystore_file_name
- Replace
your_alias_name
with the alias name of the old certificate andyour_keystore_file_name
with the name of your keystore file.
By following these steps, you should be able to fix the «keytool error: java.io.IOException: Incorrect AVA format» in Android by checking the certificate information and creating a new certificate with the correct DN.
Method 2: Use the Correct Alias Name
If you’re seeing the «java.io.IOException: Incorrect AVA format» error when trying to use the Android keytool, it’s likely that you’re using an incorrect alias name. Here’s how to fix this error by using the correct alias name:
-
Open a terminal or command prompt and navigate to the directory where your keystore file is located.
-
Run the following command to list the aliases in your keystore:
keytool -list -keystore your_keystore_file.keystore
-
Identify the correct alias name that you should be using. It will be listed under the «Alias name» column.
-
Use the correct alias name in your command. For example, if the correct alias name is «myalias», you would use the following command:
keytool -exportcert -alias myalias -keystore your_keystore_file.keystore | openssl sha1 -binary | openssl base64
That’s it! By using the correct alias name, you should no longer see the «java.io.IOException: Incorrect AVA format» error.
Method 3: Import the Certificate in Binary DER Format
To fix the «java.io.IoException:Incorrect AVA format» error in Android, you can import the certificate in Binary DER format. Here are the steps to do it:
-
Export the certificate from the server in Binary DER format. You can use the following command:
keytool -export -alias <alias> -keystore <keystore> -rfc -file <filename>.cer -storepass <password>
Replace
<alias>
,<keystore>
,<filename>
, and<password>
with the appropriate values. -
Copy the exported certificate file to your Android project’s
app/src/main/res/raw
directory. -
In your Android code, use the following code to read the certificate file and import it:
CertificateFactory cf = CertificateFactory.getInstance("X.509"); InputStream is = getResources().openRawResource(R.raw.<filename>); Certificate cert = cf.generateCertificate(is); KeyStore ks = KeyStore.getInstance(KeyStore.getDefaultType()); ks.load(null, null); ks.setCertificateEntry("<alias>", cert); TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm()); tmf.init(ks); SSLContext sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, tmf.getTrustManagers(), null);
Replace
<filename>
and<alias>
with the appropriate values. -
Use the
sslContext
object to create the SSL socket factory:SSLSocketFactory sslSocketFactory = sslContext.getSocketFactory();
You can now use the
sslSocketFactory
object to create SSL sockets.
That’s it! This should fix the «java.io.IoException:Incorrect AVA format» error in Android.
Method 4: Verify the Keystore and Key Algorithm Compatibility
To fix the «java.io.IoException:Incorrect AVA format» error when using keytool in Android, you can verify the Keystore and Key Algorithm Compatibility. Here are the steps:
- Open the command prompt and navigate to the location of the keystore file.
- Run the following command to verify the keystore:
keytool -list -v -keystore my.keystore
Replace «my.keystore» with the name of your keystore file.
- Check the «Signature Algorithm» field in the output. It should be one of the following:
- SHA256withRSA
- SHA1withRSA
- MD5withRSA
If it is not one of these, you need to create a new keystore and key with a compatible algorithm.
- To create a new keystore and key with a compatible algorithm, run the following command:
keytool -genkeypair -alias myalias -keyalg RSA -keysize 2048 -sigalg SHA256withRSA -validity 10000 -keystore my.keystore
Replace «myalias» with the alias you want to use for the key, and «my.keystore» with the name of your keystore file.
-
Follow the prompts to enter the required information for the key.
-
Once the key is created, verify it using the command from step 2 to ensure the «Signature Algorithm» field is now compatible.
That’s it! By verifying the Keystore and Key Algorithm Compatibility, you can fix the «java.io.IoException:Incorrect AVA format» error when using keytool in Android.
Does anyone know how to solve this?
I tried many things, but none of them worked.
And when I click more details I get this:
at sun.security.provider.JavaKeyStore.engineLoad(Unknown Source)
atsun.security.provider.JavaKeyStore$JKS.engineLoad(Unknown Source)
at java.security.KeyStore.load(Unknown Source)
at com.sun.deploy.security.RootCertStore$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.security.RootCertStore.loadCertStore(Unknown Source)
at com.sun.deploy.security.RootCertStore.load(Unknown Source)
at com.sun.deploy.security.RootCertStore.load(Unknown Source)
at com.sun.deploy.security.ImmutableCertStore.load(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at sun.plugin.security.PluginClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadCode(Unknown Source)
at sun.applet.AppletPanel.createApplet(Unknown Source)
at sun.plugin.AppletViewer.createApplet(Unknown Source)
at sun.applet.AppletPanel.runLoader(Unknown Source)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Ramesh R
7,0094 gold badges25 silver badges38 bronze badges
asked Jun 27, 2009 at 11:43
7
You may corrupt the file during copy/transfer.
Are you using maven?
If you are copying keystore file with «filter=true», you may corrupt the file.
Please check the file size.
answered Aug 13, 2011 at 13:05
2
Maybe maven encoding you KeyStore, you can set filtering=false to fix this problem.
<build>
...
<resources>
<resource>
...
<!-- set filtering=false to fix -->
<filtering>false</filtering>
...
</resource>
</resources>
</build>
answered Mar 8, 2016 at 7:58
xiezefanxiezefan
6016 silver badges5 bronze badges
2
(Re)installing the latest JDK (e.g. Oracle’s) fixed it for me.
Prior to installing the latest JDK, when I executed the following command in Terminal.app:
keytool -list -keystore $(/usr/libexec/java_home)/jre/lib/security/cacerts -v
It resulted in:
keytool error: java.io.IOException: Invalid keystore format
java.io.IOException: Invalid keystore format
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:650)
at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1445)
at sun.security.tools.keytool.Main.doCommands(Main.java:792)
at sun.security.tools.keytool.Main.run(Main.java:340)
at sun.security.tools.keytool.Main.main(Main.java:333)
But, after installing the latest Oracle JDK and restarting Terminal, executing the following command:
keytool -list -keystore $(/usr/libexec/java_home)/jre/lib/security/cacerts -v
Results in:
Enter keystore password:
Which indicates that the keytool on path can access the keystore.
answered Jan 5, 2016 at 21:39
Gary S. WeaverGary S. Weaver
7,9664 gold badges37 silver badges61 bronze badges
3
I had the same issue with different versions of keytool:
C:\Program Files\Java\jdk1.8.0_51\bin\keytool
but the same keystore file worked fine with
«C:\Program Files\Java\jre1.8.0_201\bin\keytool»
I know it is an old thread but have lost a lot of hours figuring this out…
answered Jun 19, 2020 at 9:55
ShoaebShoaeb
7097 silver badges18 bronze badges
2
I had spent lot of time on this and finally This worked for me —
go to file -> project structure -> SDK Location -> Gradle Settings -> Change Gradle JDK -> from 1.8 to 11
Just change Gradle JDK -> from 1.8 to 11 then rebuild the project and try again
answered Aug 9, 2022 at 6:54
1
for me that issue happened because i generated .jks file on my laptop with 1.8.0_251 and i copied it on server witch had java 1.8.0_45 and when I used that .jks file in my code i got java.io.IOException: Invalid Keystore format.
to solve this issue i generated .jks file directly on the server instead of copy there from my laptop which had different java version.
answered Jan 19, 2021 at 0:48
FaribaFariba
6931 gold badge12 silver badges27 bronze badges
I think the keystore file you want to use has a different or unsupported format in respect to your Java version. Could you post some more info of your task?
In general, to solve this issue you might need to recreate the whole keystore (using some other JDK version for example). In export-import the keys between the old and the new one — if you manage to open the old one somewhere else.
If it is simply an unsupported version, try the BouncyCastle crypto provider for example (although I’m not sure If it adds support to Java for more keystore types?).
Edit: I looked at the feature spec of BC.
answered Jun 27, 2009 at 11:48
akarnokdakarnokd
69.2k14 gold badges157 silver badges192 bronze badges
Your keystore is broken, and you will have to restore or regenerate it.
answered Jun 27, 2009 at 15:34
1
I ran into the problem with openJDK on ubuntu, had to install Oracle JDK to get it working.
You can follow this guide on google sites to do that.
answered Sep 19, 2017 at 10:19
Sadiq AliSadiq Ali
1,2722 gold badges15 silver badges22 bronze badges
Same issue here, I have Oracle JDK installed and my keystore was created using that, but in the jceks
format
keytool -importkeystore -destkeystore client.keystore \
-srckeystore redislabs_user.p12 -srcstoretype pkcs12 \
-deststoretype jceks -alias client-cert
I deleted the -deststoretype jceks
option and it worked fine
answered Nov 5, 2020 at 14:49
rulowebruloweb
7048 silver badges10 bronze badges
In my case, I was running the project with Java version 1.8. and the Keystore.jks file that I generated from java 16.
I changed my project java version to 16 and the error goes away.
Please check the JDK version with which you are generating the keystore and the JDK version for your project are the same or not. If they are different, either generate the keystore from the same JDK on which your current project is running or change the project JDK.
answered Nov 13, 2021 at 17:03
I came across this issue while running keytool command. There is an other way to run the keytool command, mentioned here: https://developers.google.com/android/guides/client-auth using gradlew command
.
When I ran in debug mode ./gradlew signingReport --debug
got to know that gradle plugin required java 11 and my local has java8. Downloaded java11 and updated Path. Ran the command (Make sure you open a new terminal so that java path is reflected to 11). Works like a charm !!!
answered Sep 25, 2021 at 6:59
saiyansaiyan
5511 gold badge4 silver badges20 bronze badges
This worked for me (Switched to JDK 11, instead of
Previous JAVA Path «C:\Program Files\Java\jdk1.8.0_202\bin»
Changed Path to "C:\Program Files\Java\jdk-11.0.14\bin"
answered Feb 19 at 12:07
The Keystore generation is different for Java v8 and Java v11.
Java v8 produces keystore of the jks format and I guess Java v11 produces keystore of type PKCS12 with ethe extension .p12.
What you could do is try converting the keystore of .jks format to .12 and try and vice versa. This might help.
Syntax:
To convert a PKCS12 (.p12) keystore to a JKS (.jks) keystore, please run the following command:
keytool -importkeystore -srckeystore key.p12 -srcstoretype pkcs12 -destkeystore key.jks -deststoretype jks
where key.p12 is the name of the p12 file and key.jks is the name of the jks keystore to be created.
The command to do the same is:
keytool -importkeystore -srckeystore kafkatools.truststore.jks -srcstoretype pkcs12 -destkeystore trust.jks -deststoretype jks
This is what I used myself and got rid of the invalid keystore issue.
Reference: https://knowledge.broadcom.com/external/article/151981/how-to-convert-a-pkcs12-p12-keystore-to.html
answered May 16 at 17:19
go to build
clean the project
then rebuild your project
it worked for me.
answered Feb 18, 2019 at 10:27
It may be necessary to run cmd
as administrator.
the paths to specify the .jks
file must be /
and not \
.
If they open the cmd
with the path where the .jks
file is located, they only put in the /key.jks
path
answered Apr 2, 2022 at 22:57
I had problem with «Invalid Keystore format» too. All this answers can’t helped me.
In my case problem was on Mac OS. JAVA_HOME=jdk1.8 not pulled from .zschrc, so I think that generate certs on it, but default was jdk11. I changed it to jdk1.8 with «jenv» and generate certs. How it works.
You can download jenv by brew. And some commands that I used
jenv versions
to check all versions of JDK
jenv global JDK
to set wanted jdk
java -version
to check it
answered Jul 18, 2022 at 14:19
Upgrade your JVM version — I moved from Java 8 to java 17 and it was fixed.
From Oracle:
In Java 8u301 release, a new fix went in to upgrade the default PKCS12 encryption algorithm, as noted in Java 8u301 release notes at https://www.oracle.com/java/technologies/javase/8all-relnotes.html#R180_301
➜ Upgraded the Default PKCS12 Encryption Algorithms
The default encryption algorithms used in a PKCS #12 keystore have been updated. The new algorithms are based on AES-256 and SHA-256 and are stronger than the old algorithms that were based on RC2, DESede, and SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.
For compatibility, a new system property named keystore.pkcs12.legacy is defined that will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.
answered Mar 3 at 9:44
MartinsMartins
1,2312 gold badges14 silver badges17 bronze badges
Here’s another reason: If you have multiple JDK versions on your system and generate a keystore with one version but try to import it using a different version, you’ll encounter the error. In my case, I used JDK 17 to create the keystore and JDK 8 to import it.
answered May 19 at 8:56
Troubleshooting
Problem
When checking in CA certificate, errors occur when trying many different methods.
Symptom
Result from trying to process this file as a JKS KeyStore: JKS decoding failed with java.security.cert.CertificateException: java.io.IOException: Invalid keystore format
Result from trying to process this file as DER encoded object: DER decoding failed with java.security.cert.CertificateException: Error parsing DER data com.trustpoint.asn.AsnException: Cannot find a class that corresponds to Oid 1.3.6.1.4.1.311.60.2.1.1; please see oid.map for details
Result from trying PKCS7: PKCS7 decoding failed with java.security.cert.CertificateException: Error parsing PKCS7 SignedData com.trustpoint.asn.AsnException: Unable to match element Sequence to a member of com.trustpoint.pkcs.pkcs7.ContentInfo — last attempted member was com.trustpoint.asn.AsnObjectId
Result from trying PKCS12: PKCS12 decoding failed with java.security.cert.CertificateException: Error parsing PKCS12 certificate(s): Unable to match element Sequence to a member of com.trustpoint.pkcs.pkcs12.PFX — last attempted member was com.trustpoint.asn.AsnInteger»
Cause
On the details of the certificate under Subject the 1.3.6.1.4.1.311.60.2.1.2 was holding a . (dot)
It states that if you code a State or Province you must code the full name, in a Printable String format field a dot is actually a full stop (http://en.wikipedia.org/wiki/PrintableString) which comes at the end of of a sentence, a full stop never starts a sentence or name.
State or province information, and locality information (where applicable), for the Subject’s Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction.
(4) Jurisdiction of Incorporation or Registration:
Certificate Fields:
Locality (if required):
subject:jurisdictionOfIncorporationLocalityName (OID 1.3.6.1.4.1.311.60.2.1.1)
ASN.1 — X520LocalityName as specified in RFC 3280
State or province (if required): subject:jurisdictionOfIncorporationStateOrProvinceName (OID 1.3.6.1.4.1.311.60.2.1.2)
ASN.1 — as specified in RFC 3280
Country:
subject:jurisdictionOfIncorporationCountryName (OID 1.3.6.1.4.1.311.60.2.1.3)
ASN.1 — X520countryName as specified in RFC 3280
Required/Optional: Required
Contents: These fields MUST contain information only at and above the level of the Incorporating Agency or Registration Agency – e.g., the Jurisdiction of Incorporation for an Incorporating Agency or Jurisdiction of Registration for a Registration Agency at the country level would include country information but not state or province or locality information; the Jurisdiction of Incorporation for the applicable Incorporating Agency or Registration Agency at the state or province level would include both country and state or province information, but not locality information; and so forth. Country information MUST be specified using the applicable ISO country code. State or province information, and locality information (where applicable), for the Subject’s Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction.
Compliance with European Union Qualified Certificates Standard: In addition, CAs MAY include a qcStatements extension per RFC 3739. The OID for qcStatements:qcStatement:statementId is 1.3.6.1.4.1.311.60.2.1.
Resolving The Problem
Have the certificate authority regenerate the certificate with the correct values
[{«Product»:{«code»:»SS3JSW»,»label»:»IBM Sterling B2B Integrator»},»Business Unit»:{«code»:»BU059″,»label»:»IBM Software w\/o TPS»},»Component»:»Adapters»,»Platform»:[{«code»:»PF025″,»label»:»Platform Independent»}],»Version»:»All»,»Edition»:»Advanced»,»Line of Business»:{«code»:»LOB59″,»label»:»Sustainability Software»}}]