Writing Java clientSSL code to communicate using HTTPS can be a frustrating experience.
You will need to complete the following two tasks to have yourSSLhandshake working and HTTPS communication going:
1) Create and configurekeystoreswhich are repositories storing X509 certificates
2) Write client java code
Depending on project objectives, you will also need to consider the followingSSLconfiguration options:
1) Self-signed certificates - used in development environment and sometimes Intranets
2) Two-waySSLauthentication - typically used to facilitate securedSOAcommunication over WAN
3) One-waySSLauthentication - most common way to submit sensitive data toeCommercewebsites
This article discusses various steps and challenges encountered when configuringSSLwith IBMJDK1.4.x, IBMJDK1.6.x, and SUNJDK1.6.x.
We should start with determining what type ofSSLcommunication we will be handling. In the development environment, we typically deal with self-signed X509 certificates. The SSL/HTTPS server configuration steps and tools depend obviously on the server's vendor. For example, when configuring servers which use SUN's JDK we should usekeytool located in SUN's JREbin folder, and when configuring WebSphere or IBM HTTPS, we should use IBM's ikeyman.bat. When working with certificate repositories (keystores),we need to be aware of different providers such asCMS,JKS,PKCS12.
The most important difference between self-signed certificates and production certificates obtained from Certificate Authorities (CAs), such as Verisign is that self-signed certificates are not trusted. Every X509 certificate contains other certificate references (certificate chain). This certificate chain leads to a root CA certificate and proves that a certificate installed on a server and used forSSLcommunication has been legitimately obtained and the owner of this certificate is a registered entity with the CA. Obtaining certificates fromCAscosts money and obviously, in the development environment, we do not care whether a certificate is legitimate or not; we just want to make sure that ourSSLcode works. The one problem with self-signed certificates is that when java code or a browser communicates with a server which uses a self-signed certificate the code returns certificate errors. TheSSLJava handshake throws exceptions that a server certificate cannot be trusted. One of the required steps to fix this issue is to force Java code to trust this self-signed certificate.
Configuring server with HTTPS/SSL
The steps to configure the server's keystoredepend on vendor so you will need to consult appropriate documentation. In the case of IBM HTTP server, you will useikeymanto create a newkeystore. When creating an IBM HTTPSkeystore,you will need to useCMSprovider and stash password (do not forget to select the stash passwordcheckbox). To make everything even more difficult, IBM requires use of the CMS provider for both IBM HTTP 6 and IBM HTTP 7, but IBM HTTP 6 does not come with this provider in the default configuration. You will have to go to the java security configuration folder to enable the CMSprovider. Fortunately, IBM HTTP 7 does not have this issue. Once you have yourkeystore updated/created, you will need to generate a new self-signed certificate. I suggest you select a maximum number of days, which is either 999 or 9999, depending on your keystore tooling. The last step is to export the public portion of the certificate. The export function works the same-way for self-signed as forCAscertificates. The export extracts public key. You will need this public key to configure your client.
Configuring trustedkeystoreon the client
When dealing with more recentJDKimplementation, you need to be aware of two types of certificate repositories: regularkeystoresand trustedkeystores. The trustedkeystoreis the source of all the grief when trying to configure a straight HTTPS using self-signed certificates.By default, a self-signed certificate is not trusted because a client cannot validate the server's certificate chain when establishingSSLconnections. You need to usekeytoolorikeymanto import a public portion of the server's self-signed certificate into the client's default trustedkeystore. Internet mailing lists are full of postings reporting various chain certificate errors (and believe me you will get different errors depending on whatJSSEAPIs you are using). TheSUN'sand IBM's default trustedkeystoreshave already all necessary entries that include rootCAs, so when communicating with a site that uses a certificate obtained from CA you do not need to modify this default trustedkeystore. ASUN'strustedkeystoreis located in <JAVA_HOME>/lib/security/jssecacerts. You should not modify this file but rather you should make a copy and use properties settings as in the sample Java code to override the location of your trusted keystore file. If you are not using self-signed certificates you do not need to import anything to the trustedkeystore.
If a client usesJDK1.6. you have to configure bothkeystoreand trustedkeystorewhether you plan to store any X509 certificates in thekeystoreor not. While the client's trustedkeystoreneeds to have all certificates loaded to validate the server's certificate chain, thekeystoreitself can be empty. You will need certificates in this client'skeystoreonly if you plan to use the two-waySSLauthorization. The process for obtaining client certificates for the two-way authorization is similar to a process for obtaining server certificates. In the development environment, you can usekeytoolto generate a self-singed certificate and then export public key. You guessed it right, this public key needs to be imported in the trusted serverkeystoreor otherwise you will be getting some nasty errors in server logs.
The sample client Java code will initializeSSLcommunication and verify that everything works.
I believe that learning is an ongoing process and we should always seek to better ourselves.
I am not afraid of challenges and putting forth an extra effort needed to achieve objectives. I love tackling these challenges in new creative ways that have not been tried before so I can enrich myself and others in the process.