When signing an apk after a long break from Android development I was surprised that I'm no longer able to enter an empty keystore password to unlock it. Is it just me or has this been possible before? If so, when did that change and how can I manage to unlock the keystore anyway?
Some background: maybe I'm just crazy and didn't use an empty password for the keystore before, but the one and only possible password that I could have been using instead doesn't work either (I swear, there's no chance I'd have used another password!).
The keystore can be manipulated using the keytool in the Java sdk.
Try executing the keytool on your keystore, and extract the certificates with the empty password. After that, import it into a new keystore. This time, use a real password.
The switch -exportcert will help you accomplish that.
It could be that you updated your java sdk and therefor you cannot enter empty password (due to some security upgrade of the tool). In that case, you can try to install an older sdk and do the above.
Good luck!
You cannot use an empty password for your keystore.
I checked, as far as jdk 1.3 keytool does'nt allow it, see http://docs.oracle.com/javase/1.3/docs/tooldocs/win32/keytool.html where doc explicitely states that:
storepass must be at least 6 characters long. It must be provided to all commands that access the keystore contents. For such commands, if a -storepass option is not provided at the command line, the user is prompted for it.
For fun, I wanted to try keytool from jdk 1.2 and downloaded it since its documentation doesn't state that password is mandatory, but I need a Windows NT box to install it!
I absolutely don't think Android ever used this keytool version.
Sorry, but it looks like you have either: forgotten your password, or typed it with caps locks / a wrong keyboard layout activated. :(
EDIT:
If it is not a layout problem you can try to
Use this reverse engineered code to extract key using an empty string password: http://metastatic.org/source/JKS.java.
If this doesn't work you are screwed, your only hope will be to brute force the key using http://code.google.com/p/android-keystore-password-recover/ or http://code.google.com/p/patator/ (test and use the fastest one)
Try default android debug mode keystore password which is android or java cacerts default changeit/changeme.
I faced this issue as well and it was very weird. I had a legacy keystore that was not protected by any password. I could use it successfully in SoapUI but keytool and keystore explorer failed to open it. I had to create new keystore that already had a password and since then everything was fine.
I suspect that Java 8 is more picky that Java 7 was.
keytool -importkeystore -srckeystore client.jks -destkeystore client2.jsk -srcstoretype JKS -deststoretype JKS -deststorepass changeit
Instead of using keytool, you could write a simple Java SE program that tries to use your key or lists aliases. The API should (not a 100% on this) allow you to use an empty ("") password.
You can also try third party tools like portecle to list/extract keys.
I've just faced the same problem when trying to use the key store provider for hadoop, which uses none as default password, see: JavaKeyStoreProvider.java
I ended up copying the original keytool from OpenJDK8 and removed the restrictions in this new implementation (it is the same but without the 6 characteres limitation): KeytoolWithoutPasswordLimits
In this way, I managed to use none as password.
If all of the above fail you can try cracking it. Related question: Android - Forgot keystore password. Can I decrypt keystore file?
That works for me:
keytool -list -keystore keyStoreFileWithotPassword.jks -protected
CORRECTION: It turn out the list feature works without entering the actual password! But the import features do require a password
Related
I currently have a website hosted with Hostgator that has a java upload applet; however, on page visit, the browser blocks the java applet from executing. Reason given is security settings have blocked a SELF-SIGNED application from running.
My question is, how can I get past this, WITHOUT modifying java security levels. I want users to be able to access the applet without getting this error AND without having to modify any of their current browser settings.
(I signed the applet myself using keytool).
Thank you.
There are two ways:
You need to buy a SSL certificate from a trusted party like Verisign or Thawte, or any other (cheaper) trusted provider. Then you need to sign your applet with this certificate instead. Since such certificate will be provided by a globally-trusted party, your users' JVM will automatically trust it.
If you decide to go with the cheaper ssl provider, make sure it's root certificate is in the default list of trusted certificates of the JVM. You can check that, by listing certificates, that come with the installation of Java - like this:
keytool -list -keystore cacerts -storepass changeit
where changeit is the default cacerts keystore password, and the cacerts file can be found in lib\security folder of jour JRE installation - on Windows this will be something like:
c:\Program Files (x86)\Java\jre[version]\lib\security\
Send the public key to your users, and make them add it to trusted certificates of their JVM (usually that means, importing the certificate you provide to the aforementioned cacerts file. This step however requires using keytool and command line and will most likely be troublesome for most of your users.
I want to sign an applet using netbeans, but i don't want to self-sign it because since the Java 7u51 was released it is considered as unsigned. How do I get a keystore password?
You're asking the wrong question.
You need a keypair.
You need a CSR.
You need to get the CSR signed by a CA.
All this stuff goes into a keystore, and not the one that came with the JDK or JRE. That's a truststore, and has an entirely different purpose.
So, you need to either create a new keystore, with the keytool, in which case you get to choose your own password, or you need to use an existing keystore, typically $HOME/.keystore, in which case you must already know its password.
Then you do:
keytool -genkey ...
keytool -certreq ...
Get the CA to sign the CSR just generated.
keytool -importcert ..., importing the signed CSR, using the same alias as at 1-2.
Note that NetBeans has nothing to do with any of this.
I have a problem with a keystore in pkcs12 format, which contains a private key I need to use to authenticate myself (using mutual authentication) to a remote SSL server. The keystore file can be read perfectly fine by Firefox, and when used, I can access the remote server without problems.
However, my Java program does not work with the keystore file. And if I use keytool to list keys inside the file, it seems empty -- while it is clearly not!
How can I get Java/keytool to see the private key inside the keystore?
Java can only understand JKS format which stands for Java KeyStore.
Here is a good article to generate the .jks from pkcs12
http://blog.asyd.net/2009/07/how-to-convert-a-pkcs12-to-jks/
I'm trying to use Amazon S3 and Amazon Cloudfront CDN to deliver the jar files of my applet application.
I'm seeing several cache misses of my jars by the java plugin. This is a show-stopper for me, as the size of my application is around 3Mb, and I can't make my customers re-download the application every time.
The problem is that, due to a "security vulnerability issue" the java plugin cache is resolving the IP address of the jar remote host, but Amazon S3 uses a dynamic IP. I guess the same problem would happen with Akamai or any other decent CDN service.
Is there anything I can do?
Well the address has to be resolved at some point, that’s not exactly the problem.
The problem is that the applet wants to make sure the .jars come from the same source as the page holding the applet to make sure nobody is returning malicious jars instead of the originals. But when the sockets are opened using the URL it is resolving to a different address, yes, because you are using a cloud not a single server.
Im sure you can solve it by signing the .jars. That way the applet knows they are originals, no matter the source.
What I do is that I create a certificate manually. Like thie:
keytool -genkey -keyalg rsa -keysize 1024 -alias {put a name for the cert here} -validity 3650 -keystore {.. and a file name here.}
Note this will prompt for you to set a user and password for the certificate.
Then sign ALL your jars like this ->
$1/jarsigner -keystore { the above file name} -storepass password -keypass password whatEver.jar {cert name, from above.}
The only issue I have seen with this method is that since the cert is not signed by a recognized authority in the browser, it will promopt the first time to add it to the trusted certs. Normally not an issue.
Other wise you can:
1) Get a certificate from a recognized authority in the browser (Thwate, Verisign ) ( There are some that will do it for free)
2) Set up an authority and ask your users to add it into the browser's recognized authorities.
Hope this helps!
-Alex
How can I verify an X509 (or DER-formatted) certificate against the Java certificate store via the command line?
I've looked into using the keytool utility, but it looks like it only handles import/export/display functionality (no verification).
EDIT: It looks as though keytool can be used for verification, but only if an import is attempted. I suppose a better way of asking this questions is whether or not a more passive approach (as in: not modifying the keystore) is available. Thanks!
You can use keytool to export the needed certificates (those that are in the chain for the one you need to verify) from the Java keystore into X.509 files. Then, concatenate them together into one file. Finally, use openssl to do the verification.
openssl verify -CAfile concatenated-certs.crt cert-to-verify.crt
Not a perfect solution since it involves popping the certs out of the truststore, but it ought to work given what you are starting with.
This page could be oversimplifying:
http://java.sun.com/docs/books/tutorial/security/toolfilex/rstep1.html
But it doesn't look like even import with keytool does a true verification of a certificate. I'm not seeing any description of verifying the signature of the incoming certificate against the signature of another trusted certificate.
jarsigner will verify a signature on a signed jar, but doesn't do anything to verify the signature on the certificate used to sign the jar.
I'm afraid you'd either have to write a tool to do the verfication, or look for a commercial tool that does it. I would think that some of the PKI tool kits would have a certificate verification tool that would do this.