The package java includes several functions which are grouped in:

  1. common: functions of common utilities, for example the creation and use of a java native class and a function which allows to embed java code inside a program.
  2. jmx: functions that are wrappers of
  3. security: functions which allows the signature management and electronic certificate.

The digital signature and certificate are elements which are part of the security policy of a system. This document explains this elements are created, stored and used. From Axional Studio, features have been implemented for the package XSQL-Script Java and XSQL-Script PDF which allows the use of digital signature and certificate.


1 KeyStore

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).


1.1 Key entry (private 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.


1.2 Trusted Certificate Entry (public key)

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.


2 Create the KeyStore

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>]] ...


-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>]] ...


When a keystore is created you must indicate a password. This password must be also used to add new entries to the storehouse.


2.1 Example of the creation of a keystore

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"

2.2 Example of export (generation) of a signed certificate

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.

2.3 Example of import of a certificate

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.

2.4 Providers

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 admited in windows are indicated in the file $JDKHOME\jre\lib\security\

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

2.5 Cryptography types

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

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

2.5.1 El tipo PKCS de Bouncy Castle (BC)

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.

Summary of the PKCS standards
Version Name Comentaries
PKCS#1 2.1 RSA cryptographic standard See RFC 3447. Define the RSA encryption format.
PKCS#2 - Obsolete Define the RSA encryption of message summaries but was absorved by the PKCS#1.
PKCS#3 1.4 Key exchange standard Diffie-Hellman
PKCS#4 - Obsolete Define the syntax of the RSA key but was absorved by the PKCS#1.
PKCS#5 2.0 Encryption standard based in passwords. Ver RFC 2898y PBKDF2 .
PKCS#6 1.5 Syntax standard of extended certificates. Define extensions to the old specification of X.509 certificates version 1. The version 3 of the same left it obsolete.
PKCS#7 1.5 Standard about the syntax of the cryptographic message See RFC 2315. Used to sign and/or encode messages in PKI. Also used for the disemination of certificates (for example as response of a message PKCS#10). It was the base for the standard S/MIME, now based in the RFC 3852, an upgrade of the standard [CMS] Cryptographic Message Syntax, used to digitally sign. obtain the digest, authenticate or arbitrarily encrypt the content of a message (do not confuse with Content Management System).
PKCS#8 1.2 Standard about the syntax of the information of provate key.
PKCS#9 2.0 Types of selected attributes.
PKCS#10 1.7 Standard of certification request. See RFC 2986. Format of the sent messages to a certification authority to request the certification of a public key.
PKCS#11 2.20 Interface of cryptographic device (" Cryptographic Tok in Interface" or Cryptoki). Define a generic API for accessing cryptographic devices (see HSM).
PKCS#12 1.0 Standard of syntax of personal information exchange. Define a file format commonly used to store private keys with its certificate of public key protected through symmetric key.
PKCS#13 - Standard of cryptography of elliptic curve. (Developping)
PKCS#14 - Generation of pseudo-random number. (En desarrollo)
PKCS#15 1.1 Standard of format of cryptographic devices. Define an standard qhich allows to the users of a cryptographic devices identifie them with applications idependent of the implementation of the PKCS#11 (crytoki) or other API .

3 Electronic signature

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).


3.1 Electronic signature

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).


Axional Studio XSQL-Script is a pseudojava in the sense that offers all the power of a high level language oriented to objects: Java, in a syntax relatively simple: XML. Each label used in the script corresponds with a class in the compilator which interpret it. In addition to the methodes which uses indirectly the programmer when writing XML tags, he has the possibility of instantiate any class (create object) and invoke its methodes.