The Java certificates are stored in a special files called KeyStore. The file of KeyStore is a keys database file which contains as many public keys as private keys. The public keys are stored as signatories certificates while the private keys are stored in the personal certificates. The keys are used with differents objectives, among which authentication and data integrity are included. The KeyStore contains two types of elements: Key Entry (private key) and Trusted Certificate Entry (public key).

This type of entry of the KeyStore stores very sensitive cryptographic information, stored in a protected format to prevent the unauthorized access. A stored key of this type is a secret key or a private key accompanied by the certficate string for thecorresponding public key. The private key is used to sign documents and messages. It must be exclusively under the power of the signer.

This type of entry of the KeyStore contains a single certificate of public key belonging to a third. It is called trusted certificate because the owner of the KeyStore trust that the public key in the certificate belongs in fact to the identity authenticated by the certificate. A digital certificate is an electronic document signed electronically by a Certification Services Provider, which associates a public key with its owner.

The digital certificate allows to authentify and garant the confidentiality of communications between citizens, companies and other public institutions through open communication networks. It is guaranteed that only the citizen can access to the information, avoiding impersonations.

To create the KeyStore you can use the utility of java called keytool.

keytool is the utility which allows to manage keys and certificates. Allows to the user to manage the public and private key pairs and the associated certificates for the use of the authentication itself (of the user to other services or users) or data integrity and authentication of services, using the digital signature. Also allows the users to have a public keys cache (in the certificate form) of its communications. First, you have to add the path of the bin directory where the jdk (instalated to the environment variable PATH) is located, or use the complete path because the utility keytool is located inside of this directory. The syntax of the command:

syntax of keytool:

-certreq     [-v] [-protected]
             [-alias <alias>] [-sigalg <algorithm_signature>]
             [-file <archivo_csr>] [-keypass <password_key>]
             [-keystore <keystore>] [-storepass <password_storehouse>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-delete      [-v] [-protected] -alias <alias>
             [-keystore <key_storehouse>] [-storepass <password_storehouse>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-export      [-v] [-rfc] [-protected]
             [-alias <alias>] [-file <archivo_cert>]
             [-keystore <key_storehouse>] [-storepass <password_keystore>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-genkey      [-v] [-protected]
             [-alias <alias>]
             [-keyalg <algorithm_key>] [-keysize <key_size>]
             [-sigalg <algorithm_signature>] [-dname <name_d>]
             [-validity <dÝas_validity>] [-keypass <password_key>]
             [-keystore <storehouse_keys>] [-storepass <password_storekey>]
             [-storetype <type_store>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-help

-identitydb  [-v] [-protected]
             [-file <archvo_idb>]
             [-keystore <storehouse_keys>] [-storepass <password_storehouse>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-import      [-v] [-noprompt] [-trustcacerts] [-protected]
             [-alias <alias>]
             [-file <archivo_cert>] [-keypass <password_key>]
             [-keystore <key_store>] [-storepass <password_keystore>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-keyclone    [-v] [-protected]
             [-alias <alias>] -dest <alias_destination>
             [-keypass <password_key>] [-new <new_password_key>]
             [-keystore <key_storehouse>] [-storepass <storehouse_password>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-keypasswd   [-v] [-alias <alias>]
             [-keypass <password_old_key>] [-new <new_password_key>]
             [-keystore <keys_storehouse>] [-storepass <password_keystore>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-list        [-v | -rfc] [-protected]
             [-alias <alias>]
             [-keystore <storehouse_keys>] [-storepass <password_storehouse>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-printcert   [-v] [-file <file_certif>]

-selfcert    [-v] [-protected]
             [-alias <alias>]
             [-dname <name_d>] [-validity <dÝas_validez>]
             [-keypass <password_keys>] [-sigalg <algorithm_signature>]
             [-keystore <storehouse_keys>] [-storepass <password_storehouse>]
             [-storetype <type_storehouse>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

-storepasswd [-v] [-new <new_password_storehouse>]
             [-keystore <storehouse_keys>] [-storepass <password_storehouse>]
             [-storetype <storehouse_type>] [-providerName <name>]
             [-providerClass <name_class_provider> [-providerArg <arg>]] ...

Below an example of the creation of a keystore is showed.

keytool -genkey -alias acme1 -keypass mykeypass -keystore keystore.ks -dname "cn=Acme, c=US"

The keytool command is used with the arguments:

• genkey: is used to generate a new key.
• alias: the entries in the storehouse are identified with an unique alias.
• keypass: indicates the initial password, required in the successive management operations which are performed with the entry associated to the indicated alias.
• keystore: name of the file where the storehouse is stored.
• dname: optional argument, specifies a X.500 Distinguished Name to associate it to an alias.

The following example shows how a second key should be added to the same storehouse (changing alias, dname is optional):

keytool -genkey -alias acme2 -keypass mykeypass -keystore keystore.ks -dname "cn=Acme, c=US"

The following example shows how a signed certificate is exported (generated):

keytool -export -alias acme2 -file acme.cer -keystore keystore.ks

The command keytool is used with the arguments:

• export: indicates to export a entry of an alias of the keystore.
• file: indicates the name of the file to generate.
• keystore: indicates the name of the file where the storekey is stored.

The following example shows how a certificate is imported to the keystore:

keytool -import -alias cert2 -file acme.cer -keystore keystore.ks

• export: indicates to export an entry of an alias of the keystore.
• file: indicates the name of the file to generate.
• keystore: indicates the name of the file where the storekey is stored.

Optionally, the argument providerClass can be also indicated in the command keytool. It can be used to specify a key provider. The provides admits differents types of cryptography. This argument should be used to specify the provider of the cryptography service when this can not be found in the security properties file.

The providers typically instalated are:

• SUN version 1.5
• SunRsaSign version 1.5
• SunJSSE version 1.5
• SunJCE version 1.5
• SunJGSS version 1.0
• SunSASL version 1.5
• Bouncy Castle (BC) version 1.38

Cryptography types. Each provider admits differents types, for example:

• SUN: admits the KJS type between others.
• Bouncy Castle (BC): admits the PKCS type.

In cryptography, PKCS reference to a group of cryptography standards of public key conceived and published by the RSA laboratories in California. A RSA Security was assigned the licensing rights for the RSA asymmetric key algorithm patent and acquired the licensing rights for others key patents.

In the system of electronic signature intervene two keys:

Private key with which the signature is generated. Only the person who generates the signature knows it.

Public key with which the signature is generated. It is known by third parties that they must be able to decrypt the generated signature.

The private key should remain exclusively under the control of its owner, this allows that the digital signature identify univocally the signer.

The public key enables to the receiver to verify the author of the message and the integrity of the sent data.

The encrypt content with the private key only can be deciphed with the associated public key. In this way when a message or a document is deciphed with a public key is being determined the issued of the message or document (signer).

The following schema shows the process of the difital signature of a message with the private key property of the issuer. Only the issuer dispose of private key, otherwise the public key should be known by the receivers to be able to decipher the message or document.

Once the document has been signed and sent, the issuer should decipher the signature with the certificate or public key. So, it is about carrying out the inverse process but using the certificate or public key (unlike when the document is generated where the private key in possession of only the issuer is used).