69

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)
Improve this question
7
  • What exactly are you trying to do? Posting some example code would be helpful. Commented Jun 27, 2009 at 11:48
  • And please post what things you tried already? Commented Jun 27, 2009 at 12:26
  • 2
    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. Commented 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. Commented Jun 27, 2009 at 18:28
  • How did you generate the JKS file? checkout this thread: stackoverflow.com/a/59312913/7051466 Commented Dec 12, 2019 at 21:30

23 Answers 23

Reset to default
106

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Great! I really helped me. Could you, please, clarify why does the filtering parameter corrupts the keystore?
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
I was using Gradle to deploy the file to a certain directory. Looks like it was corrupting the file. Then I uploaded the certificate to the pod, using kubectl cp command and then the problem disappeared. So for development/testing purposes, this can be done.
53

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>
Improve this answer

2 Comments

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>
Thanks, this worked for me. I had to do a maven build again after the change
24

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

Improve this answer

2 Comments

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).
Just using the JRE instead of JDK for the same version 1.8.0_202 was enough for me.
18

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

enter image description here

Just change Gradle JDK -> from 1.8 to 11 then rebuild the project and try again

Improve this answer

2 Comments

Thanks! updating Gradle JDK to 11 worked for me
I've noticed that keystore created by newest java versions sometimes doesn't work with older java version
17

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

Improve this answer

3 Comments

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)!
This command helped me validate the jks file (keytool -list -keystore <path-to-jks>)
This worked after installing the latest JDK!!
10

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.

Improve this answer

1 Comment

I think this is the best answer - as it solves the underlying issue and teaches us - generate keystore & csr on the server VM where it would be deployed, and not on our development environment. It's an important best practice.
8

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

Improve this answer

1 Comment

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

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.

Improve this answer

Comments

3

Your keystore is broken, and you will have to restore or regenerate it.

Improve this answer

1 Comment

I was afraid to mention that :)
3

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.

Improve this answer

Comments

3

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

Improve this answer

Comments

2

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

Improve this answer

Comments

2

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.

Improve this answer

Comments

1

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

Improve this answer

Comments

1

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"
Improve this answer

Comments

1

In my case, after updating to Api 33, keytool was creating keystore with the pkcs12 format when the jarsigner was expecting jks format. Had to convert the keystore after creating: keytool -importkeystore -srckeystore .\original.keystore -destkeystore .\destination.keystore -deststoretype jks

Improve this answer

Comments

0

go to build clean the project then rebuild your project it worked for me.

Improve this answer

Comments

0

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

Improve this answer

Comments

0

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.
Improve this answer

Comments

0

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.

Improve this answer

Comments

0

In my particular case, I require the Maven filter to function on the application.yaml file, thereby necessitating the filter to be set to true. To address this issue, I employed the maven-resources-plugin as a viable solution. It is possible that this approach could also prove effective for your needs.

Here is the modified XML code with the Maven resource plugin configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-resources-plugin</artifactId>
    <configuration>
        <nonFilteredFileExtensions>
            <nonFilteredFileExtension>jks</nonFilteredFileExtension>
        </nonFilteredFileExtensions>
    </configuration>
</plugin>
Improve this answer

Comments

0

It worked for me after changing the filtering configuration for me. I am answering the question just to be more clear. The below config in pom.xml worked for me. i had to have filter=true for some other files, so i worked it out in this way.

<resources>
    <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
        <excludes>
            <exclude>**/*.jks</exclude>
        </excludes>
    </resource>
    <resource>
        <directory>src/main/resources/saml</directory>
        <targetPath>saml</targetPath>
        <filtering>false</filtering>
        <includes>
            <include>*.jks</include>
        </includes>
    </resource>
</resources>
Improve this answer

Comments

0

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

Improve this answer

1 Comment

github.com/jenv/jenv is their repository on GitHub

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.