ShowTable of Contents
IBM Connections, IBM Domino, and IBM Sametime provide Application Programming Interfaces (APIs) over HTTP. These communications can occur over an unencrypted channel such as HTTP on Port 80, or over an encrypted channel such as HTTPS on Port 443. The IBM SmartCloud for Social Business only allows access through secure communications over HTTPS.
Each channel has it's draw backs and benefits for a developer:
HTTP
Pro - Easy to Access, No Special Settings Needed to Access
Con - Insecure, and Customers Rarely use it in production
HTTPS
Pro - Customers Use it in Production, and Secure
Con - Requires Additional Configuration to Access
As a developer, one finds there is a development environment connecting to a test server which provides APIs. These Test Server APIs are configured much like a customer environment using HTTPs with Self Signed Certificates. As self signed certificates are considered insecure, the developer must explicitly review and trust the signer of the self signed certificate in order to access the APIs from his development environment. The trust of a HTTPs Certificate Signer may need to be set up in both directions Developer-to-Test-Server and Test-Server-to-Development-Environment.
This article gives pointers and details on how to configure the security of your environment to setup trust on your test servers, and on your development environment.
Generating a Self-Signed Certificate for IBM HTTP Server
You can use the IKeyMan tool, however it is not necessary to use the tool to access the KDB.
In just a few steps, you can do the same thing via commandline. Note, you might need to make slight modifications for Windows, as this script is for Linux.
The following corresponds to variables which are reused through the generation, and assume an existing KDB is at least available, if not, there is an extra step to generate a new KDB.
GSK7CAPICMD=/local/opt/IBM/HTTPServer/bin/gskcapicmd
PLUGINKEYDB=/local/opt/IBM/WebSphere/Plugins/config/webserver1/plugin-key.kdb
KDBPASS=WebAS
LABEL=HTTP
The first command creates a new Key Database based on the prior parameters, which don't expire for 1000 days, and have a password stash file.
${GSK7CAPICMD} -keydb -create -db <${PLUGINKEYDB} -pw ${KDBPASS} -type kdb -expire 1000 -stash
The next step is to delete the current certificate, so there are no duplicates.
${GSK7CAPICMD} -cert -delete -db ${PLUGINKEYDB} -pw ${KDBPASS} -label ${LABEL}
The commandline utility is called to create a a new certificate with label, where ${HOSTNAME} is the server such as qs.renovations.com , ${DOMAIN} is the domain, such as Renovations, and ${ORG} correspond to the organization such as IBM.
${GSK7CAPICMD} -cert -create -db ${PLUGINKEYDB} -pw ${KDBPASS} -label ${LABEL} -size 2048 -x509version 3 -default_cert yes -expire 720 -dn "CN=${HOSTNAME},o=${DOMAIN},c=${ORG}"
The commandline utility is then sets the labeled certificate as the default for the KDB.
${GSK7CAPICMD} -cert -setdefault -db ${PLUGINKEYDB} -pw ${KDBPASS} -label ${LABEL}
*This applies to any WebSphere Application Server which is connected via plugin to an IBM HTTP Server. By Default, the IBM WebSphere Application generates a trust.p12 file which contains the default signer, and self signed certificate for your communications. The file p12 can be viewed using the keytool.
Generating a Self-Signed Certificate for IBM Domino
Simon Doherty generated an excellent document on generating a self signed certificate for IBM Domino Servers.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Connecting_to_a_Domino_server_over_SSL_in_Java_using_a_self_signed_certificate._
Generating a Self-Signed Certificate for Apache Tomcat
The Tomcat documentation describes how a developer can go about setting up the SSL settings.
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html
To be more specific, there are three main steps: generate the keystore and self signed key, and configure tomcat.
To generate, per docs, the self-signed key and keystore run.
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA -keystore \path\to\my\keystore
where JAVA_HOME is the location of your Java Runtime on Windows.
Next, you should copy the keystore to the conf directory of your tomcat instance.
Edit the conf/server.xml file
Add after the first use of the Connector Tag
<Connector SSLEnabled="true" clientAuth="false"
keystoreFile="conf/keystore" keystorePass="changeit"
maxThreads="150" port="8443" protocol="HTTP/1.1"
scheme="https" secure="true" sslProtocol="TLS"/>
Save the file
Restart Tomcat and connect to HTTPS via 8443.
In general, these techniques apply to generating a self-signed certificate for any J2EE Server, however, it is recommended each developer consult their specific appserver's documentation.
Now all your communication between your test servers and development environment, and ready to use for development.