It’s been a long time that i didn’t write a post on my blog, i am sorry, but i was realy very very busy for personnal reason (birth of my twins boys and many others things). So, I will go on with several posts on a technology and product named Documentum (DCTM).

That’s all!!!!!



After my previous post concerning the SSL, PorteCle Generate KeyStore, self-signed certificate, tool PorteCle, concerning the generation of server’s KeyStore, self-signed certificate…, in this post, i would expose the case of a server SERVER1 which communicates with an other server securized SERVER2 (like Jboss, Tomcat,…), so, now, we are speaking about the TrustStore of server.

A keystore contains private keys, and the certificates with their corresponding public keys. A truststore contains certificates from other parties that you expect to communicate with, or from Certificate Authorities that you trust to identify other parties.

So it’s necessary to add the certificate of SERVER1 contained in its KeyStore, into the TrustStore of SERVER2.

Create a new TrustStore
First, execute the portecle and create a new KeyStore/TrustStore which will contain the certificate:
… select the type Java Keystore:

Import a trusted certificate
Importation of a new certificate (or Key Pair) in the previous created TrustStore for the SERVER2:
…then, select the *.cer certificate file of SERVER1:
…give the same name than the *.cer file to the imported certificate:
…finally, save the TrustStore of SERVER2 with the name myTrustStore.ks on the local disk with a specific password myPass123:

Tomcat Server Configuration
Copy this TrustStore on SERVER2 file system and modify the “Java Options” of Tomcat server in order to add the following options (Configure Tomcat or Eclipse server environment):"..../myTrustStore.ks""myPass123"

That’s all!!!!!



After my first post concerning the SSL : self-signed certification generation and the installation on Tomcat server, I would expose a new tool PorteCle allowing the generation of KeyStore, self-signed certificate instead of Keytool supported in the JDK / JRE 1.5.

A simple reminder concerning the types of keys:

  • symmetric type: the sender and the recipient have the same key,
  • asymmetric type: the sender and the recipient haven’t the same key i.e. there are a private key and a public key,

Case of data transmission: ACTOR1 sends crypted data to ACTOR2

  • ACTOR1 uses the public key of ACTOR2 in order to encrypt and send the data to ACTOR2,
  • ACTOR2 uses its private key in order to decrypt the received data from ACTOR1,

Case of signature: ACTOR1 signs a document

  • ACTOR1 uses its private key in order to sign the document,
  • ACTOR2 (recipient of this document) uses the public key of ACTOR1 in order to authenticate the document signed by ACTOR1,

Note: The sent document could be also encrypted.

During the navigation of a secured website, the installation of the certificate on the client poste doesn’t asked explicitly because the certificate has been certified by a certification authority (CA). When creating the certificate (in the keystore on server side), it’s possible to precise if the certificate is dedicated to be diffused (classic case) or not be diffused.

The principle of SSL
The securization of transactions via SSL is based on the exchanges of keys between client and server. The transaction securized via SSL is done by the following model:

  • First, the client connects to the server secured by SSL and asks it the authentication. The client sends also the list of supported cryptosystems, sorted by the descending order according to the length of keys.
  • Then, the server sends a certificate to the client, containing its public key (server side) signed by a certification authority (CA) or its self-signed public key. This certificate contains the name of the most complex client’s compatible cryptosystem from the previous list: the length of the encryption key (40 bits or 128 bits) will be that of the common cryptosystem with the largest key size.
  • The client creates random secret key, encrypts this key using the public key of server, then sends the result (session key) to server.
  • So, the server is capable of decrypting the client’s session key with its private key (server key). Thus, the 2 entities have a common key known only by these 2 parts. The rest of the transactions can be done using this session key, ensuring the integrity and confidentiality of the data exchanged.

For example, the generation of certificate is possible via the keytool:

keytool.exe -genkey -dname ", ou=JAVA/LU, o=Blog, c=LU"
-alias tomcatKey 
-keypass 123456
-keystore D:\keytool\javablogkeystore.ks
-storepass 123456
-validity 365

..but there are other tools like PorteCle.

Installation of PorteCle
First, download from and unzip it.
Then, execute the portecle.jar file with the Java Platform SE binary:
…this is PorteCle:

Create a new KeyStore
The KeyStore contains the keys/certificates:
… select the type Java Keystore:

Create a new certificate
Creation of a new certificate (or Key Pair) in the previous created KeyStore:
…the Key Algorithm will be RAS and with a Key Size of 2048:
…and the détails of our certificate will be:

  • Validity: 365 days
  • CN (Common Name): HUO
  • OU (Organisation Unit): JAVABLOG.FR
  • O (Organisation Name): JAVA.LU
  • L (Locality Name): LU
  • ST (State Name): LU
  • C (Country): LU

…it is necessary to fill in an alias and a password for the certificate in the KeyStore (here huo and 123456):
…and double-click on the certificate to display its détails:

…finally, save the KeyStore on the local disk with a specific password 123456. In Tomcat, the private key password and keystore password should be the same. See the official documentation You MUST use the same password here as was used for the keystore password itself. This is a restriction of the Tomcat implementation.




Export the certificate to *.cer file
Here, it is possible to export a “*.cer” file in order to install directly the certificate for example on client computer/PC. In the case of this article, it is not necessary, however, the installation will not have any impacts.





Important point : the certificate trusted by a certification authority (CA) doesn’t need to be installed on client side, because the most of these certificates have a root certificate which is already installed on user PC (example : UNIPASS).
To install the certificate on client PC and view the détails of certificate : double click on HUO.cer file


In this last screenshot, you could observe that the certificate has not been trusted by a certification authority (CA) (we have generated a self-signed certificate).

Install the certificate on client side:

Certificates Manager
After certificate installation on client side, it is visible in the certificates manager.
Execute the command certmgr.msc:

Then, you could find the newly installed certificate:


Tomcat Server Configuration : configuration of SSL and tests
Activate the following connector in the file “server.xml” of “conf” folder, to use the https protocol targeting the “C:\MyFiles\Development\Java\tools\sslcertificats” keystore with the password filled above “”: (keystore=”C:\MyFiles\Development\Java\tools\myKeyStore.ks” keystorePass=”123456″):

    <!-- Define a SSL HTTP/1.1 Connector on port 8443
         This connector uses the JSSE configuration, when using APR, the 
         connector should be using the OpenSSL style configuration
         described in the APR documentation -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
              maxThreads="150" scheme="https" secure="true"	
              keystore="C:\MyFiles\Development\Java\tools\myKeyStore.ks" keystorePass="123456"               
              clientAuth="false" sslProtocol="TLS" />

…don’t modify the connector because, per default, the 8080 port is redirected to the 8443 port:

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

…and when the tomcat server is started:

15 juil. 2014 01:09:28 org.apache.coyote.http11.Http11Protocol init
INFO: Initialisation de Coyote HTTP/1.1 sur http-8080
15 juil. 2014 01:09:29 org.apache.coyote.http11.Http11Protocol init
INFO: Initialisation de Coyote HTTP/1.1 sur http-8443
15 juil. 2014 01:09:29 org.apache.catalina.startup.Catalina load
15 juil. 2014 01:09:32 org.apache.coyote.http11.Http11Protocol start
INFO: D�marrage de Coyote HTTP/1.1 sur http-8080
15 juil. 2014 01:09:32 org.apache.coyote.http11.Http11Protocol start
INFO: D�marrage de Coyote HTTP/1.1 sur http-8443

Note: If the Tomcat starts with the below error, it’s because in Tomcat, the private key password and keystore password should be the same. So, set the key and keystore to the same password.

15 juil. 2014 00:57:27 org.apache.coyote.http11.Http11Protocol init
INFO: Initialisation de Coyote HTTP/1.1 sur http-8080
15 juil. 2014 00:57:27 org.apache.coyote.http11.Http11Protocol init
GRAVE: Erreur � l'initialisation du point de contact Cannot recover key

If we check our configuration by access to application deployed on tomcat server (for example: https://localhost:8443/test_extJs_1/index2.html):

Advanced tests
In order to verify that the connection is secured, we will use the TCP/IP Monitor view in Eclipse to display the content of messages sent and received between the client (browser) and server.

Configure a local monitoring port 8444 redirected to the SSL secure port 8443 on localhost server:

So, access to the securized site via the port 8444 (https://localhost:8444/test_extJs_1/index2.html) and check the crypted data in the configured proxy:

Best regards,



In this article, I will try to expose a Tomcat server installed like Windows service.
We will use Tomcat6, Windows7 and Jdk 6.

First, our Tomcat server is installed in the “C:\MyFiles\Development\Java\tools\TomCat” folder with the following executables:

– Tomcat6 is a service application for running Tomcat6 as NT service.
– Tomcat6w is a GUI application for monitoring and configuring Tomcat services.

Before to expose Tomcat server like Windows service, below the Tomcat server configuration in Eclipse:





First, we will start the cmd.exe like administrator:

So, we will expose the Tomcat server like Windows server with the below command (IS = Install Service):

tomcat6 //IS//Tomcat6HUO --DisplayName="Apache Tomcat JAVABLOG.FR" --Install="C:\MyFiles\Development\Java\tools\TomCat\bin\tomcat6.exe" 
--Description="This is my Tomcat server as windows service" 
--Jvm="C:\Program Files\Java\jre6\bin\server\jvm.dll" 
--Classpath="C:\Program Files\Java\jdk1.6.0_32\lib\tools.jar;

Then, it is possible to update the Windows service configuration (US = Update Service):

tomcat6 //US//Tomcat6HUO 

For information, it is possible to use environnement variables:

C:\MyFiles\Development\Java\tools\TomCat\bin>echo %JAVA_HOME%
C:\Program Files\Java\jdk1.6.0_32

For example, we could use the JAVA_HOME variable:

--Classpath="C:\Program Files\Java\jdk1.6.0_32\lib\tools.jar;"

Of course, a service could be delete with the command (DS = Delete Service):

tomcat6 //DS//Tomcat6HUO

The result should be :

The properties of Tomcat service are:

…and when we try to start the service, we obtain the following error:

==> I don’t found the solution of this problem, have you already encountered the same error?

For more information, read the page :

Thanks in advance,


Page 1 of 30:1 2 3 4 »Last »
Copyright ® 2012 Huseyin Ozveren. No reproduction, even partial, can be used from this site and all its contents including text, documents, images, etc.. without the express permission of the author.
Jeux gratuit | flash jeux gratuits