Hello Friends,


What is the exact difference between a PKCS#12 and JKS type of keystore?

The key.p12 and trust.p12 default files that we have in WAS are in PKCS#12 format ,correct?

Is it preferable to use keystores/truststores in JKS format for WAS or should we stick to PKCS#12 types of keystores.Kindly justify your answer. 

Does WAS understand .kdb type(CMS) of keystores or are they understood only by the IHS server.


I also have some confusion on the below mentioned points.Correct me if I am wrong on below points-->

1)If the keystore is in CMS format(.kdb),then that store acts as a keystore as well as a truststore. We do not have to create a seperate truststore in this case.We will be adding the different signers in the keystore itself.
Example:plugin.kdb file 

2)However if the keystore format is PKCS#12 or JKS then we will need to have seperate keystores and truststores.  

Thanks,

Kushal        

[quote author=137782419 post=530052123]Hello Friends,


What is the exact difference between a PKCS#12 and JKS type of keystore?

JSSE configurations typically reference a keystore and a truststore. By convention the keystore reference represents a Java keystore object that holds personal certificates and the truststore reference represents a Java keystore object that holds signer certificates. You may have only one store that holds both - personal certificates and signer certificates.

A default keystore and truststore are created by WebSphere Application Server during profile creation. You can also create a new keystore and truststores using the WebSphere administration tools.

WebSphere Application Server supports following keystore types:
    JKS: Java KeyStore (*.jks)
    JCEKS: Java Cryptography Extension KeyStore (*.jceks)
    PKCS12: Public-Key Cryptography Standards #12 (*.p12), Microsoft® calls it PFX.
    PKCS12JarSigner
    PKCS11: Cryptographic Token Device
    CMSKS: Format used by IBM HTTP Server (*.kdb)
    JCERACFKS: z/OS only, stores certificates in RACF
    JCECCARACFKS: z/OS only, uses hardware cryptography device
    JCECCAKS: z/OS only, uses hardware cryptography device



The key.p12 and trust.p12 default files that we have in WAS are in PKCS#12 format ,correct?

Yes from WAS 6.1, but you can use JKS too

Is it preferable to use keystores/truststores in JKS format for WAS or should we stick to PKCS#12 types of keystores.Kindly justify your answer. 

You can use the format you want, WAS support both, for standarization prefered PKCS#12.

Does WAS understand .kdb type(CMS) of keystores or are they understood only by the IHS server.

Yes WAS understand .kdb.

I also have some confusion on the below mentioned points.Correct me if I am wrong on below points-->

1)If the keystore is in CMS format(.kdb),then that store acts as a keystore as well as a truststore. We do not have to create a seperate truststore in this case.We will be adding the different signers in the keystore itself.
Example:plugin.kdb file 

CMS format is implemented in C (or C++) so the servers (WebServers) who use this format try to find personal certificates and signer certificates in only one store.

2)However if the keystore format is PKCS#12 or JKS then we will need to have seperate keystores and truststores. 


You may have only one store that holds both - personal certificates (KeyStores) and signer certificates (trustores). Keystores and trustores are determined by java specification  (JKS is implemented in Java) not by WebSphere (WAS implement the specification).  You can point to the same file both stores.

When you open an store (jks, .p12, kdb,...) you always have a personal certificate section and signer section.  

Hope this helps


Thanks,

Kushal        [/quote]

Gabriel,


The answers you provided were bang on target.It answers my questions.

Thank you very much.
I knew you would be the first one to answer my questions on this portal.    .
I guess you are the most popular member on the site by now.    

Hi Kushal,

  Glad to help other's with their doubts or questions

  I'm only one more member of the site that try to contribute with my experience, there are other great contributors.
 
  The important is that the site "is live" among all
 
regards