Cannot import pkcs12 file into a jks keystore
scop opened this issue · 17 comments
I am trying to create a new keystore containing one
single keypair. I generated the keypair using openssl
to convert the client certificate and the client key
into pkcs12 format.
I then tryied to import the keypair using portecle and
get the error: net.sf.portecle.crypto.CryptoException:
Could not load keystore as type 'PKCS12'.
This is the stacktrace produced:
net.sf.portecle.crypto.KeyStoreUtil.loadKeyStore(Unknown
Source)
net.sf.portecle.FPortecle.importKeyPair(Unknown Source)
net.sf.portecle.FPortecle.access$7500(Unknown Source)
net.sf.portecle.FPortecle$76.run(Unknown Source)
java.lang.Thread.run(Thread.java:595)
java.io.IOException: exception decrypting data -
java.security.InvalidKeyException: Illegal key size
org.bouncycastle.jce.provider.JDKPKCS12KeyStore.decryptData(JDKPKCS12KeyStore.java:637)
org.bouncycastle.jce.provider.JDKPKCS12KeyStore.engineLoad(JDKPKCS12KeyStore.java:895)
java.security.KeyStore.load(KeyStore.java:1150)
net.sf.portecle.crypto.KeyStoreUtil.loadKeyStore(Unknown
Source)
net.sf.portecle.FPortecle.importKeyPair(Unknown Source)
net.sf.portecle.FPortecle.access$7500(Unknown Source)
net.sf.portecle.FPortecle$76.run(Unknown Source)
java.lang.Thread.run(Thread.java:595)
I am using portecle v1.1 under gentoo 2.6.14-r4 with
original sun jdk installed.
Reported by: c3lph1sh
The keypair that fails to import
Original comment by: c3lph1sh
- status: open --> closed
Original comment by: scop
Logged In: YES
user_id=32457
You'll probably need to install the umlimited strength
jurisdiction policy files for your JCE from Sun. See README
and "Important Notes" at
http://www.bouncycastle.org/documentation.html
I can't verify if it works for me using the supplied .p12
file because it seems to have a non-empty passphrase.
Original comment by: scop
Logged In: YES
user_id=1406567
I installed the unlimited jurisdiction policy files for my
JCE from Sun. But I am still unable to import the .p12 file
into my new created keystore.
I sent you a message containing the passphrase for the
keypair-file.
Original comment by: c3lph1sh
Logged In: YES
user_id=32457
Thanks for sending the passphrase. Importing the keypair
from the supplied works just fine here.
I tried uninstalling the unrestricted JCE policy files and
re-importing, and then it fails with the same stacktrace as
for you. After reinstalling the unrestricted ones, it works
for me again. This is with Sun's JDK 1.5.0_08 on Fedora Core.
Please check again that you installed the files correctly;
local_policy.jar and US_export_policy.jar in
$JAVA_HOME/jre/lib/security need to be replaced with the
unrestricted ones from the .zip downloaded from Sun.
Original comment by: scop
- status: closed --> closed-works-for-me
Original comment by: scop
Logged In: YES
user_id=1406567
Thank you for your fast replies.
Despite beeing sure that I really installed those .jar files
at the correct location, I removed them and copied the ones
I downloaded from
http://java.sun.com/javase/downloads/index.jsp to my
$JAVA_HOME/jre/lib/security/ directory.
Then I started portecle, created a new JKS keystore, tried
to import the keypair and failed.
Here some additional information about my setup:
$> java -version
java version "1.5.0_08"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.5.0_08-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_08-b03, mixed
mode)
Do you want me to upload the US_export_policy.jar and
local_policy.jar I use?
Original comment by: c3lph1sh
Logged In: YES
user_id=32457
The JCE files are not redistributable, so it might be better
to not upload them...
I'm using the i586 version of the JDK on a x86_64 box, and
the sha1sums of the policy files I use are:
$ sha1sum /usr/java/jdk1.5.0_08/jre/lib/security/*.jar
401133fd4bb8182b7ba50cceb3620399ebb15756
/usr/java/jdk1.5.0_08/jre/lib/security/local_policy.jar
ac86f572f36e35fc176f156b311338b1443fd79d
/usr/java/jdk1.5.0_08/jre/lib/security/US_export_policy.jar
You don't happen to have multiple JDK's/JRE's installed? If
you do, make sure that you're running Portecle with the one
you installed those files for.
Original comment by: scop
Logged In: YES
user_id=1406567
We're obviously using the same .jar files.
I discovered a strange phenomenon:
$> echo $JAVA_HOME
/usr/share/jdk
Starting portecle with the explicit path to java works... (???)
$> /usr/share/jdk/bin/java -jar portecle.jar
Thanks a lot for your patience and support in getting
portecle to run correctly and sorry for bothering you.
Original comment by: c3lph1sh
Logged In: YES
user_id=32457
No problem. Having to install the JCE policy files
separately really sucks, hopefully upstream can do something
about it in the future.
Original comment by: scop
Logged In: YES
user_id=266141
Hi scop, it appears that c3lph1sh had multiple installations
of java and the startup script did some miraculous cross-over...
To help users haunted by similar situations in the future, I
suggest that portecle upon the "Illegal key size" exception
amends the raw stack-trace with the following hints:
1) <<make sure you use the unlimited strength cryptography
jars as per
http://java.sun.com/products/jce/javase.html\#UnlimitedDownload
. Check with
sha1sum $JAVA_HOME/jre/lib/security/*.jar
2) also print the content of the JAVA_HOME environment
variable - this may help the people who with the current
plethora of symlinks and wrapper scripts of modern linux
distributions get confused about which of the many java
installations they are REALLY using
Original comment by: ralfhauser
Logged In: YES
user_id=32457
I'd be glad to add more clueful hints to the error message,
but unfortunately the issue is a bit more complex than what
it seems at first sight. It's not rocket science, but
things that need to be taken into account include at least:
1) Not all JCE implementations require any extra policy jars
nor even have ones available.
2) I don't currently know the exact exception patterns (or
other things that could be detected) that should trigger
these additional hints - only one example is the one in this
report where an "Illegal key size" InvalidKeyException is
wrapped in an IOException - and there are others (see for
example Portecle's README.txt)
3) Pointing to URLs would be Java vendor and version
dependent and could even then bitrot
4) sha1summing would be meaningful only if Portecle had a
database of "known good" sha1sums - that's not something I'm
interested in maintaining
5) I think I've heard somewhere that the upcoming Sun 1.6
JCE won't need any extra steps
6) I've probably forgotten a number of other things.
Anyway, I think I'll try to find some cases where this could
be improved for the upcoming 1.2 release.
Original comment by: scop
Logged In: YES
user_id=32457
Eh, well, the Sun JDK 1.6 beta 2 download page still lists
the separate JCE policy file download, so apparently I
remembered wrong :(
Original comment by: scop
Logged In: YES
user_id=266141
agreed, mentioning sun-specifics only is not the right
thing. But providing some debug info such as the JAVA_HOME
would certainly still be good. Another idea is just listing
an URL back to this portecle home-page (perhaps even to this
page?) or perhaps a wiki page that kind of does a
reverse-look-up from the exception to "common causes" why
this has happened in the past...
Original comment by: ralfhauser
Logged In: YES
user_id=32457
Good ideas, thanks, will keep them in mind, but I think the
harder part is to decide/detect exactly when it is
meaningful to show this additional info or a reference to it.
One possible KISS and "good enough" way forward could be to
just examine the exception to be shown in
net.sf.portecle.gui.error.DThrowable and maintain logic for
some usual suspect patterns there (one of those being the
IllegalKeyException wrapped in an IOException case) without
passing any context about what Portecle is doing.
Original comment by: scop
Logged In: YES
user_id=32457
The code just committed to svn has some heuristic detection
for these errors, and displays the attached dialog when it
finds a candidate.
Original comment by: scop
Screenshot of modified error dialog
Original comment by: scop