Develop Reference

Should certificates be always imported in keystores?

I'm doing some crytography in Java and I wanted to know what are the best and common pratices on certificate storage.
Can certificates be loaded from a file or should they always be imported in keystore/truststore ?
EDIT: My use case is to load a private key and a certificate in order to be able to crypt and decrypt data.
The question is: should the private key and the certificate be both in a keystore or can the certificate be aside in a file ?

I'd strongly recommend storing the certificates at least in the key store. If your key store and file have about the same access rights security is not that much different - although the password does add a level of protection (it's not called "changeit" by default for nothing).
Java and Java key stores are however pretty focused on X.509 based PKI, and you may not be even store the private key successfully without the certificate. So it is certainly best practice to store the certificate or rather, the certificate chain in the key store.

java 7b55 - security warnings appear even though web start app is signed

I have an app delivered via Java Web Start that is signed with an official certificate provided by Verisign, and also a self-signed certificate that we have generated. This is done because we restrict use of the official certificate for the build delivered to customers, but we need to have our test builds signed by a certificate to get the application loaded at all.
My question is; is it normal that Java 7b55 still shows security warnings for the self-signed certificate, even though the official certificate is present? I would expect the official certificate to take precedence but it appears to be not the case.
Just wondering if anyone else has hit this or if it's unique to my environment..

Its shouldn't.... Unless you are using 1 keystore to perform all this.
Sounds like you are using your self signed keystore that is paired up with the private key inside and that you may have imported the official VeriSign one into the same keystore without matching up with the private key in the inside. Which is probably why the Official VeriSign certificate is not getting read during signing
Usually in situation like yours there should be two keystores. 1 with the self signed and another with the Official Signed certificate.
~DomSYMC

When to install keystore & when to install only certificate wrapped in keystore [duplicate]

This question already has answers here:
Truststore and Keystore Definitions
(7 answers)
Closed 6 years ago.
I have a PKCS#12 file which I considered as a keystore file since it contains one key entry & one certificate entry.
In Android, I see people programmatically install keystore in the following way (The code is from Android developer blog):
byte[] keystore = . . (read from a PKCS#12 keystore)
Intent installIntent = KeyChain.createInstallIntent();
installIntent.putExtra(KeyChain.EXTRA_PKCS12, keystore);
startActivityForResult(installIntent, INSTALL_KEYSTORE_CODE);
I also see people programmatically install only the certificate wrapped inside keystore:
Intent intent = KeyChain.createInstallIntent();
intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert);
startActivity(intent);
Besides, I also see people install both the keystore & the certificate wrapped in keystore. For example, this article shows us how to first install keystore & then install the certificate wrapped in keystore programmatically.
I really get confused about when should I install keystore only & when should I install certificate (wrapped inside keystore) only ? And when should I install both ?? Could someone make me clear about this please?
For example, my keystore PKCS#12 file (mycert.p12) contains key/certificate pair, it is used to connect to VPN server. When should my android client install both keystore and certificate wrapped in the keystore ? When should client install only certificate wrapped in keystore? What are the differences ? I am quite confused about this.

I have a PKCS#12 file which I considered as a keystore file since it contains one key entry & one certificate entry.
Correct.
In Android, I see people programmatically install keystore in the following way ...
This is done when you have a keystore, i.e. a keypair and certificate.
I also see people programmatically install only the certificate wrapped inside keystore
This is done when you have someone else's certificate, typically a self-signed one, that isn't trusted by any of the default CA's (certificate authorities) that are already installed. You should never have to do this.
So note that you never do both with the same certificate, because the cases (the ownerships) are different. There can never be any doubt about which process is appropriate. If it's yours, import the keystore. If it's someone else's, import the certificate.
The ultimate normative reference for all this stuff is ITU Recommendation X.509.
Finally, some notes on the poor quality blog articles you have linked.
From Unifying key store access in ICS:
In the past, it was common practice for apps to maintain their own key
store if they needed to authenticate a secure SSL web server, or
authenticate the user to a server via a client certificate.
This is already incorrect.
To authenticate a web server you shouldn't need anything, if it has a CA-signed certificate. If it has a self-signed certificate you will need to import it into your truststore.
To authenticate yourself to a web server, you need a keystore containing your own private key and a certificate, preferably a CA-signed one. Otherwise the server has to import your self-signed certificate into its truststore, i.e. the converse of (1) above. Don't go down this path. Self-signed certificates are far more trouble than they are worth, which is nothing, as you can tell from the price you pay for them.
From Using ICS keychain API:
We first get the private key and certificate chain using the key alias
and then create and verify a signature to check if the key is actually
usable.
Complete nonsense. We already have the private key, the public key, and the certificate. They are already usable. Creating a signature and verifying it locally is just a complete waste of time.
Installing a CA certificate is not very different from installing a
PKCS#12 file: you load the certificate in a byte array and pass it as
an extra to the install intent.
The difference being that you use KeyChain.EXTRA_CERTIFICATE in the CA certificate case, and KeyChain.EXTRA_PKCS12 in the keystore case.

Since no one has answered you yet, I hope I can at least clarify some points from the blog article you have linked to.
In the past, it was common practice for apps to maintain their own key
store if they needed to authenticate a secure SSL web server, or
authenticate the user to a server via a client certificate.
These are the two basic use-cases right here:
If you are authenticating with a client certificate (which proves to the server that you are an authorized client), then you would only install a certificate.
If you are trying to verify the server's identity, then you will want to validate the server's certificate. In this case you will need a keystore installed (possibly a chain if you're not using self-signed certs). The private key in the keystore will be used to validate the server's certificate.
That second bit of code you have in your question was intended for creating a certificate chain (when you're NOT using self-signed certs):
We first get the private key and certificate chain using the key alias
and then create and verify a signature to check if the key is actually
usable. Since we are using a self-signed certificate the 'chain'
consists of a single entry, but for a certificate signed by a CA you
will need to find the actual end entity certificate in the returned
array.
Installing a CA certificate is not very different from installing a
PKCS#12 file: you load the certificate in a byte array and pass it as
an extra to the install intent.
Intent intent = KeyChain.createInstallIntent();
intent.putExtra(KeyChain.EXTRA_CERTIFICATE, cert);
startActivity(intent);
I hope this explanation helps! :)

With respect to an android or any other 'client', that is, an application, the following hold -
A truststore (public key only) is required whenever it needs to validate the certificate (or a certificate chain) that is sent across by the server during SSL communication (in case of ssl communication the server will always present its certificate to the client).
If the server's certificate is already signed by a trusted certificate authority (implying that certificate is already present in the java-runtime-truststore that can usually be found under $JAVA_HOME/jre/lib/security/cacerts), then this step is not required unless a customized SSLContext is being used (which also means that a customized TrustManager is being used).
For example SO's current certificate is signed by DigiCert identified by SHA1-Thumbprint : 5F:B7:EE:06:33:E2:59:DB:AD:0C:4C:9A:E6:D3:8F:1A:61:C7:DC:25 and would likely be present in the 'cacerts' truststore under the alias 'digicerthighassuranceevrootca'. If a java client were to make a request to https://stackoverflow.com then by default there would not be any specific keystore or truststore required for communication.
A keystore (private and public key) is generally required when the client is required to digitally-sign some data which is being posting to the server.
A common example is xml-signing, you can find a mention here
It is also required if the server expects the client to present its own certificate for authentication as part of two-way ssl handshake. From what I have come across this is not common.
Links :
Two Way SSL
SO's own Keystore and truststore post

Does anyone know how to use StartCom SSL without keystore in Java OR use a custom keystore?

I have found the following post, which I think I may help because I need a way of verifying my website (that my java application connects to) without having to use the java keystore:
http://www.mombu.com/programming/java/t-ssl-for-java-without-keystores-1366416.html
However, I'm quite new to the world of SSL and don't know which files and passwords I need to use, so if anybody can point me in the right direction that would be great. If you didn't guess, I got my SSL certificate from StartSSL, who are ran/owned/something by StartCom Ltd. Here is a post I used for putting the details into the keystore:
https://forum.startcom.org/viewtopic.php?t=1390
Thanks in Advance!
Alternitively, is there any way for me to use a custom keystore. i.e I'll do what I need with the default keystore and then copy the keystore into the .JAR so that I can tell my application to use the one in the .JAR instead of the one in the Java install directory, etc...

Yes, you can create and use your own keystore for your app using the keytool utility which comes with the JDK.
Basically, a keystore is a datastore for your keys & certificates, which will be used in your app either to authenticate yourself to another entity or to digitally sign your messages or any other data.
A distinct keystore called trustore is used to keep the public key certificates of the entities you trust.
You can have these keystores placed in your classpath and specify the path in your app in code like (these are VM params which will affect all apps running in this VM):
Properties properties = System.getProperties();
properties.put("javax.net.ssl.keyStore", path/to/keystorefile);
properties.put("javax.net.ssl.keyStorePassword", keyStorePassword);
properties.put("javax.net.ssl.trustStore", path/to/truststore);
properties.put("javax.net.ssl.trustStorePassword", trustStorePassword);
EDIT:
Yes, you can specify the keystore & trustore locations and their passwords in a property file and load the properties file as myProperties.load(myProperties.getClass().getResourceAsStream("/path/to/proertyfile.properties")); and then use it in your code as (exception handling omitted)(this will not affect any other app):
KeyStore mykeystore = KeyStore.getInstance("JKS");
InputStream is = new FileInputStream("/path/from/myproperties");
mykeystore.load(is, myKeystorePasswordFromProperties.toCharArray());

Programmatically adding a trusted cert in Java

I use SSL to communicate between two components written in Java. I can't use a CA, so I have to self-sign everything. Unfortunately, this means that when I try to handshake, I get a SunCertPathBuilderException. I can create my own X509TrustManager that just trusts everything, but that sort of defeats the purpose of having a signed cert.
I would like, when first making the connection, to prompt the user with "SSL handshake with invalid cert. Add cert to store?" or something so they could have it added for them to their certificate store, like web browsers do at sites with invalid certs. I can find plenty of examples online of adding a cert to the store through the commandline, but I can't figure out how to do it programmatically. Is there a way to do this?

Yes it is possible.
There is some code here that I've used before. I had to modify it to do what I wanted and I suspect that you will too but this should get you close - you aren't trying to import a key so theoretically you should be able to simplify things. In any case you can get an idea of what you'll need.
The JDK JavaDoc for java.security.KeyStore is pretty useful too.

Why don't you create your own CA and sign your certificates with that? Then all you would need to do is install the CA own certificate on the machines and every certificate signed by that CA would validate.

Why would you need to do this, you are not validating that the client is who they say they are you are only using the certs to encrypt the comms, so a custom trust manager that allows all certs is all you need.
What you are asking is possible and from memory also involves a custom trust manager to validate the certificates and store them in the keystore. I can't remember the details, but at least you know it is possible to do it.