Ssl and Cert Keystore

SSL and cert keystore

System.setProperty("javax.net.ssl.trustStore", path_to_your_jks_file);

Relationship between key store, trust store, and certificate

Store: keyStore would usually hold private/public keys and the TrustStore stores only public keys and represents the list of trusted parties i.e. CA
Purpose: In SSL handshake purpose of TrustStore is to verify credentials and purpose of keyStore is to provide credential.
keyStore is used to store your credential (server or client) i.e. private keys and certificates while TrustStore is used to store others credential (Certificates from CA) contain the CA certificates you're willing to trust when a remote party presents its certificate.
TrustStore and keyStore are very much similar in terms of construct and structure as both are managed by keytool command(binary comes with JDK installation inside JAVA_HOME/bin).
JAVA_HOME/JRE/Security/cacerts is a TrustStore, where java stores public certificates of root CA's to authenticate i.e. it is used to authenticate peers(i.e. servers). In Java, one file can represent both KeyStore vs TrustStore but it's better to separate private and public credential both for security and maintenance reason.
JAVA_HOME/bin/keytool is a tool to manage key and certificates.
KeyStore is needed when you are setting up server side on SSL, it is used to store server's identity certificate, which server will present to a client on the connection while trust store setup on client side must contain to make the connection work. If you browser to connect to any website over SSL it verifies certificate presented by server against its TrustStore.

source

Relationship between Java cert and keystore

when you create a jks file it has a private key entry inside, if you do not specify any alias for key it is myKey by default

you can try listing jks file to see the same key

run

keytool -list -keystore mykeys.jks -storepass <password to mykeys.jks>

Self signed certificate is something which you can export out of this key store using following command

keytool -export -alias <keyalias> -file abc.cer -keystore mykeys.jks -storepass <password to mykeys.jks>

the file abc.cer is a self signed certificate

Bonus Answer : yes your one keystore can have number of keys with different alias and more than one certs also if you import them

Self-signed Certificate and Client Keystore for SSL Authentication

Not an answer yet, but getting too complicated for comments so I'll give a start and edit later.

Should (SSL/TLS) server(s) and client(s) share a key (and cert)? Okay for development and maybe test, varies for production. As a general rule every independent system that needs to be authenticated should have its own privatekey and a certificate for that key (or sometimes but rarely multiple certs). If both (or more generally all) the systems involved and the communication between them will be under control of the same administrator, it doesn't really hurt to relax this rule and (re)use one key+cert. Since the key+cert(s) used should always be (re)configurable, this is a decision you can change later, even change several times if that turns out to be desirable or necessary.

Should the cert(s) be self-signed? Usually good for development and test, varies for production. Again if all relevant systems are under control of one admin, or at least a limited group of people who know each other (such as divisions or offices of one organization) there's no real security need for a CA to verify identities and determine trust. One consideration is that the server cert must encode the domain-name(s) (or IP address(es) if you use that option) in the cert, so changing them, which is often needed in development and test, means going back to the CA for a new cert, at least a minor nuisance and sometimes a delay.

At the moment you have one key and selfsigned cert you are trying to share for both client and server. While you may well want to change these later, I would recommend focussing on getting something working first. Changing several interrelated things at the same time tends to cause confusion.

"Extract" a cert? For the current setup, with one (shared) key+cert (selfsigned), you already have the key+cert in a JKS, the same key+cert in a P12, and the same cert in a file (cert.crt) so you don't need to extract anything. If you (later) generate for the Java (client) side a new key and selfsigned cert using keytool, yes you would need to extract that cert.
If you obtain a CA-signed cert for either the existing key or a new key, you might need to extract the root/anchor, but you might already have it, see below.

What cert(s) is needed to trust? The client always (with minor exceptions not relevant here) needs in its truststore the anchor for the server's cert, and when client authentication (also called mutual or two-way) is used as in your case the server needs in its truststore the anchor for the client's cert. In your current case the client and server use the same cert, so both sides need the same anchor.

For a self-signed cert the anchor must be the cert itself -- which must be changed, usually manually, any time the partner cert changes.
For a CA-issued cert the anchor can be and (always?) should be the root cert for that CA; the CA root is usually long-lived (like 20 years and more) and does not need to change when a partner/entity cert does.
If you use a well-known CA like Verisign or GoDaddy, as opposed to a CA run by yourself or maybe by "Joe's Dicount Liquor Store and Certificate Authority" in your local red-light district, in some systems the roots for those well-known CAs may be already installed in which case you don't need to do anything.

How did the client work to trust the server? Your Java client apparently used the client.jks file as both keystore and truststore. This can easily work because Java uses one file format that can contain both kinds of data, and further treats the cert in an own-key entry as also a trusted cert (anchor).

What about the server truststore? On the other hand, software that uses pkcs12 format for a keystore, or at least to import a keystore entry, sometimes (I'd say often) does not use that same format for its truststore, and certainly not the same file(s). The fact that it did reject client use of the same cert it already has as its own probably means it doesn't treat the pkcs12 you gave it as truststore data, although in principle it could be disliking something else such as the lack of an ExtendedKeyUsage extension or the unavailability of revocation/status data.

You don't identify or describe the device which is your server, so I can only guess at the myriad of ways that SSL/TLS servers, especially embedded ones, can work. But somewhere in your device there is probably a way to add certs to its truststore. Also it should have some kind of error log somewhere that may contain additional information about whether it just needs the anchor (here the selfsigned cert) in the truststore, or something else -- assuming you can see that log without SSL/TLS authentication!

If you can give us (a link to) doc on your server/device, or tell us in sufficient detail what it shows, offers, and/or accepts, I can probably be more specific.

How to import a .cer certificate into a java keystore?

If you want to authenticate you need the private key - there is no other option.
A certificate is a public key with extra properties (like company name, country,...) that is signed by some Certificate authority that guarantees that the attached properties are true.
.CER files are certificates and don't have the private key. The private key is provided with a .PFX keystore file normally.
If you really authenticate is because you already had imported the private key.

You normally can import .CER certificates without any problems with

keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias"

Java client certificates and keystores

My understanding is that if you have to store a certificate with an alias matching the target domain name (in our case i.domain.io or r.domain.io) so java can provide the associated certificate as a client certificate when you are attempting a SSL connection to that domain e.g. https://r.domain.io

That's not the case at all.

Matching is based on the certificate_authorities list sent by the server in its TLS CertificateRequest message (the issuers), and on the type of key (e.g. RSA or DSA). Some imperfect matches can be chosen if the attributes are not quite as expected (see this answer), but you'd at least want to have your client certificate issued by a CA the server advertises for (this is generally done automatically on the server side when you configure the CA certificates it's willing to accept, unless you explicitly change the configuration there).

If intermediate certificates are required, you'll certainly want to make sure you've imported the full chain.

Essentially, there is no point having twice the same certificate in your keystore.

(You can try to force a specific alias by extending your own X509KeyManager, but that's not sufficient; in particular, that's not going to make the server request it nor make the chain valid.)

You need to make sure that the server is configured to request a certificate. This can sometimes be done via renegotiation, so the CertificateRequest TLS message might not necessarily be visible using Wireshark. However, you should be able to see it from the client side using -Djavax.net.debug=ssl (or all): the official documentation for Debugging SSL/TLS Connections has an example if you search for CertificateRequest on the page.

Then, you need to make sure your certificate (or the top of the chain on the client end, if there are intermediate certs) was issued by one of the CAs that is advertised in that CertificateRequest message (the Issuer DN must match).

(If the certificate authorities list in CertificateRequest is empty, but the CertificateRequest message is still sent, the client will send the first certificate it finds in its keystore by default. That sort of scenario is atypical, since it requires custom configuration on the server side in general.)

What is difference between cacerts and keystore?

'cacerts' is a truststore. A trust store is used to authenticate peers. A keystore is used to authenticate yourself.

SSL certificate in keystore not working

You made a small mistake when you imported the SSL certificate. You have to use the same alias that you used for generating the key.

Right now the key and the certificate issued by Comodo are in two separate entries and the PrivateKeyEntry still contains the self-signed certificate that was created with the key:

tomcatserver, 22-Mar-2016, PrivateKeyEntry, 
...
adminhq.neo-image.com, 22-Mar-2016, trustedCertEntry,

By importing the CA reply using the key alias you replace the self-signed certificate with the one issued by the CA.

Ssl and Cert Keystore