How does my Java program know where my keystore containing the certificate is?
Or alternatively: How do I tell my Java program where to look for the keystore?
After specifying the keystore in some way, how to specify the certificate to use for authenticating the server to client?
SSL properties are set at the JVM level via system properties. Meaning you can either set them when you run the program (java -D....) Or you can set them in code by doing System.setProperty.
The specific keys you have to set are below:
javax.net.ssl.keyStore- Location of
the Java keystore file containing an
application process's own certificate
and private key. On Windows, the
specified pathname must use forward
slashes, /, in place of backslashes.
javax.net.ssl.keyStorePassword - Password
to access the private key from the
keystore file specified by
javax.net.ssl.keyStore. This password
is used twice: To unlock the keystore
file (store password), and To decrypt
the private key stored in the keystore
(key password).
javax.net.ssl.trustStore - Location of
the Java keystore file containing the
collection of CA certificates trusted
by this application process (trust
store). On Windows, the specified
pathname must use forward slashes, /,
in place of backslashes, \.
If a trust store location is not
specified using this property, the
SunJSSE implementation searches for
and uses a keystore file in the
following locations (in order):
$JAVA_HOME/lib/security/jssecacerts
$JAVA_HOME/lib/security/cacerts
javax.net.ssl.trustStorePassword -
Password to unlock the keystore file
(store password) specified by
javax.net.ssl.trustStore.
javax.net.ssl.trustStoreType - (Optional)
For Java keystore file format, this
property has the value jks (or JKS).
You do not normally specify this
property, because its default value is
already jks.
javax.net.debug - To switch
on logging for the SSL/TLS layer, set
this property to ssl.
System.setProperty("javax.net.ssl.trustStore", path_to_your_jks_file);
Just a word of caution. If you are trying to open an existing JKS keystore in Java 9 onwards, you need to make sure you mention the following properties too with value as "JKS":
javax.net.ssl.keyStoreType
javax.net.ssl.trustStoreType
The reason being that the default keystore type as prescribed in java.security file has been changed to pkcs12 from jks from Java 9 onwards.
you can also mention the path at runtime using -D properties as below
-Djavax.net.ssl.trustStore=/home/user/SSL/my-cacerts
-Djavax.net.ssl.keyStore=/home/user/SSL/server_keystore.jks
In my apache spark application, I used to provide the path of certs and keystore using --conf option and extraJavaoptions in spark-submit as below
--conf 'spark.driver.extraJavaOptions=
-Djavax.net.ssl.trustStore=/home/user/SSL/my-cacerts
-Djavax.net.ssl.keyStore=/home/user/SSL/server_keystore.jks'
First of all, there're two kinds of keystores.
Individual and General
The application will use the one indicated in the startup or the default of the system.
It will be a different folder if JRE or JDK is running, or if you check the personal or the "global" one.
They are encrypted too
In short, the path will be like:
$JAVA_HOME/lib/security/cacerts for the "general one", who has all the CA for the Authorities and is quite important.
Related
I need help, first of all, in any of stackoverflow posts I can't found a correct answer.
I'm tring to set my Web application in tomcat server with SSL using Keytool and Certbot
First I used Certbot and generated the respectives .pem files (privkey.pem, fullchain.pem, etc).
After that I did this steps:
Add with OpenSSL my privkey.pem to JKS
My password is too simple "123456", impossible to forget. (I'm just trying)
After that I convert the pkcs12 to JKS with:
Finally Add the chain.pem to my Keystore. In this step I enter the password that I entered previously. And I get the meesage:
keytool error: java.io.IOException: Keystore was tampered with, or password was incorrect
If I edit my server.xml file in Tomcat server with connector 8443 and my keystore, when I start server I get the same error in catalina.out.
The password of your MyDSKeyStore.jks file is '-destkeypass', as a consequence of the way keytool parses the second commandline you used: -deststorepass should be followed be the password. In your case it is followed by -destkeypass.
Remark: Your question seems to be na XY problem: you want to configure a Tomcat SSL connector using certificates in PEM format, so you ask how to transform a PEM certificate into JKS. While the procedure you show is almost correct, it is useless on modern Tomcat's (cf. this answer): Tomcat supports PKCS12 files since version 5.5 at least and supports certificates in PEM format since version 8.5. There is no need to convert anything.
Can someone help to me to understand this error? Is is due to some configuration problem? Or is because the permissions are not properly set?
xyz#tatlo .globus]$ voms-proxy-init
Credentials couldn't be loaded
[/mnt/t3nfs01/data01/shome/xyz/.globus/userkey.pem,
/mnt/t3nfs01/data01/shome/xyz/.globus/usercert.pem]:
Can not load the PEM private key: java.io.IOException:
Can not load the PEM private key: no input data (empty source?)
No credentials found!
[xyz#tatlo .globus]$ ls
mycert.p12 usercert.pem userkey.pem
I hope you have configured VOMS server endpoints properly. Also, check if the credentials are in the correct directory.
They should generally go into $HOME/.globus directory. Certificates encoded in PKCS12 and PEM formats are correctly handled by the VOMS clients.
The default path for looking up PKCS12 credentials is:
$HOME/.globus/usercred.p12
Also, check the permissions set on the formats if not set accordingly.
Permissions on $HOME/.globus/usercred.p12 must be 600.
For PEM credentials the following paths are used:
$HOME/.globus/usercert.pem (certificate)
$HOME/.globus/userkey.pem (private key)
Permissions on the pem files must be:
644 for $HOME/.globus/usercert.pem
400 for $HOME/.globus/userkey.pem
In case both the PEM and PKCS12 formats are present, PEM takes precedence.
Refer link for more guidelines.
I am facing the following SSL connection exception when trying to connect to remote server:
java.net.SocketException: Default SSL context init failed: null
Most of the thread suggest that there is some problem with the keystore location that contains the certificate file.
Others like this post: Default SSL context init failed: null suggests is to create the SSL Context by yourself. But, again the issue is not resolved yet.
And here is what I did so far:
I tried to add certificate to the following file locations and all of them gave me the same error mentioned earlier:
• Cacerts file in Java Home.
• Default cacerts location for the IDE I am using (JDveloper 10.1.3.2) which is in my case : C:\JDeveloper\WorkSpace_10g\jdevstudio10132\jdk\jre\lib\security\cacerts
• New keystore that only contains this certificate.
The certificated is added using Portecle applet( I also tried keytool options from Command prompts)
I am also referring to the trustStore and keyStore in the code as follow:
System.setProperty("javax.net.ssl.trustStore", trustStore file path goes here);
System.setProperty("javax.net.ssl.trustStorePassword", password goes here);
System.setProperty("javax.net.ssl.keyStore", keyStore file path goes here);
System.setProperty("javax.net.ssl.keyStorePassword", password goes here);
In the above code the file path refer for the cacerts files mentioned earlier (Java home, default JDeveloper cacerts and newly created keystore) of course I tried each one separately.
The keystore isn't found. Check that you can open that file from within the same piece of code by the same name you're using in javax.net.ssl.keyStore.
If you're using the default cacerts you don't need to set javax.net.ssl.trustStore/trustStorePassword at all.
I have a problem with signing my jar files with jarsigner. I used this tutorial to sign my jar files, but with the last step(signing the jar), I got this error:
jarsigner error: java.lang.RuntimeException: keystore load: Invalid keystore format
and I didn't use step #10, I used instead step #5 from this site since, I'm using a real certificate not a fake one ...
Note:
I'm having my certificate in .spc & .pvk format...
But, since I'm using jarsigner, I have to convert them to .p12 format. So, I convert them first to .pfx using pvkimprt.exe then to .p12. I used the method that I specified in the link that I mentioned it before.
Also, I tried to create a fake certificate to make sure that the problem is not from the pvkimprt.exe tool or from the certificate. It gave me the same error.
The certificate is just fine. So, where is the problem came from?
The error you are facing indicates that jarsigner does not understand the format of the keystore containing the key.
If you converted your key & certificate into a PKCS#12 file you have to specify the type of used keystore to jarsigner with the -storetype PKCS12 command line option and the P12 password with -storepass mystorepassword
(actually most of the time .pfx and .p12 are used for the same file format therefore I am not sure that the firefox import/export step in the tutorial is mandated)
Not really an answer, just a comment - I found that the upper case was crucial - "pkcs12" didn't work but "PKCS12" did, using Jcs's answer.
This is what I did and that worked:
<ant:signjar alias="le-f0b73c88-1f82-4497-8c3f-e10d399b4c9c" storetype="pkcs12"
storepass="fount-current"
keystore="/vobs/oam_base/loadbuild_tools/common/src/conf/kunal.pfx">
Store pass should be the lower case, this is the working order or arguments, some time wrong order with throw the runtime padding exception.
[signjar] jarsigner error: java.lang.RuntimeException: keystore load:
We have signed a JAR file using a certificate generated by MS Active Directory Certificate Services. However, when accessing it via Java Web Start we are getting the prompt that the digital signature cannot be verified even though we've installed the root CA into the certificate store on the client machine.
Now trying to look at the root CA on the client machine, using "keytool -list", I'm seeing an exception (invalid URI:file://\my_msadcs_server\path\to\CRL.crl). So now I'm not sure exactly what is going wrong.
Anyone have a suggestion or sample Java code on how I can test the downloaded JAR file's signature on the client machine in an attempt to figure out exactly why JWS is complaining? It could be that the root CA certificate has a problem (and I will chase down that avenue when my AD admin gets in) but I'd like to rule out other possibilities first. Currently the only thing I have to go on is the exception from "keytool -list", but keytool had no issues importing the root CA certificate in the first place.
Thanks in advance!,
mG.
I use jarsigner with the -verify, -verbose and -certs options. You may have to specify your -keystore, too.
I think the invalid URI message is a clue. Java file URI takes the following form: file://host/path