相关文章推荐
温柔的煎鸡蛋  ·  Python 工程师进阶 ...·  1 年前    · 
鬼畜的饼干  ·  MySQL Grant 命令·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

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)
                It don't look like Tomi has written any KeyStore-related code; this stack is simply an Applet getting started. It looks like the class loader is having trouble preparing to verify applet signatures.
– erickson
                Jun 27, 2009 at 17:16
                @erickson: Yes. Now I see it too. But without an OP response we cannot proceed further I'm afraid.
– akarnokd
                Jun 27, 2009 at 18:28
                How did you generate the JKS file? checkout this thread: stackoverflow.com/a/59312913/7051466
– Zak Aroui
                Dec 12, 2019 at 21:30

Are you using maven? If you are copying keystore file with "filter=true", you may corrupt the file.

Please check the file size.

Great! I really helped me. Could you, please, clarify why does the filtering parameter corrupts the keystore? – Dmitry Jul 30, 2013 at 14:39 in my case, the maven-cargo-plugin container configuration should use <files><file>...</file></files> for binary files, rather than <configfiles><configfile>, as per the maven:cargo documentation – krevelen Mar 13, 2018 at 15:02 I was having below in my parent pom. Marking filtering false solved the problem.<resources> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> </resource> </resources> – Sanjay Jain Mar 6, 2020 at 6:45

(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.

This worked for me - just installing the latest, which Mac had already 'updated' as a patch or something - but only once I started a new terminal window so the path used the new java update. Particularly useful were the commands replicating the error and demonstrating the issue had been resolved (although because of the $(java_home) reference, those worked in the terminal where the gradle command didn't work, which was a bit confusing)! – android.weasel Oct 25, 2016 at 22:42

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... :D

Just a short shot: between Versions 51 and 201 the unlimited crypto policy in Java got enabled, so maybe you should install the unlimited crypto files from Oracle in your "old" Java (you will find a lot of topics here). – Michael Fehr Jun 19, 2020 at 10:15

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

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.

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.

You can generate the debug keystore by running this command in the android/app/ directory:

keytool -genkey -v -keystore debug.keystore -storepass android -alias androiddebugkey -keypass android -keyalg RSA -keysize 2048 -validity 10000

Or just download from official template https://raw.githubusercontent.com/facebook/react-native/master/template/android/app/debug.keystore

This should be marked correct answer. When you generate the key-store from android studio, something wrong may happen. But using command line, I never got issue. Signing was alway successful but getting SHA was a failure sometimes. – Abhinav Saxena Sep 18, 2022 at 17:27

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.

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 :)

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.

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 !!!

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

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

This worked for me (Switched to JDK 11, instead of 8)

Previous JAVA Path "C:\Program Files\Java\jdk1.8.0_202\bin"

Changed Path to "C:\Program Files\Java\jdk-11.0.14\bin"

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.
        

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.