Using the IBM Connections API from other languages using custom certificates

I was reading up on some stuff in the IBM Connections REST API during the weekend and came across a post titled Using IBM Connections API in different programming languages on how to use the REST API from other languages than JavaScript from within IBM Connections. The approach there is very nice and quite valid but it fails to mention what to do if the SSL certificate of the API endpoint either isn’t trusted or isn’t certified using a “known” root certificate. In this case “known” means to the Java runtime you’re using or the runtime of any other language for that matter. Here I’m only dealing with Java though.

By default the java.net classes will not allow a SSL connections to a server using a unknown/untrusted certificate but there are ways around that. Of course the best is always to make sure that the certificate of the server may be validated by the Java keystore (including intermediate certificates) but for testing – or if you know what you’re doing – simply ignoring the certificate test can be beneficial. Below is some code showing how to configure the SSL runtime to ignore the certificate and hostname checks. The code is a static configuration method and I deem it pretty readable. The code allows *all* certificates but could pretty easily be locked down to be more restrictive if need be.

private void enableSelfSignedCerts() throws Throwable {
  TrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
      public java.security.cert.X509Certificate[]
        getAcceptedIssuers() {
        return null;
      }
      public void checkClientTrusted(X509Certificate[] certs,
          String authType) {
      }
      public void checkServerTrusted(X509Certificate[] certs,
        String authType) {
      }
    }
 };

 SSLContext sc = SSLContext.getInstance("SSL");
 sc.init(null,
         trustAllCerts,
         new java.security.SecureRandom());
  HttpsURLConnection.
    setDefaultSSLSocketFactory(sc.getSocketFactory());

  // Create all-trusting host name verifier
  HostnameVerifier allHostsValid = new HostnameVerifier() {
    public boolean verify(String hostname,
      SSLSession session) {
      return true;
    }
  };

  // Install the all-trusting host verifier
  HttpsURLConnection
    .setDefaultHostnameVerifier(allHostsValid);
}

http://./files/prettyprint/prettify.js

prettyPrint();

Using a non self-signed certificate with Lotus Connections

When you deploy Lotus Connections you find out that the login has to be done using SSL and hence you need a SSL certificate. When Lotus Connections is installed a self-signed certificate is generated but you’ll probably want to use a “real” certificate whether this be one signed by a public CA or one signed by a corporate CA. Doing this is quite simple if you only swap out the IBM HTTP Server certificate as this only requires change to httpd.conf and using the ikeyman application.

Although the ikeyman application looks like something from another century it works and does its job. To launch it go to c:websphereappserverprofilesappserver1bin and invoke ikeyman.bat (substitute the path as appropriate). Once this is done follow the documentation to create a new keystore database (KDB format) and create a stash file. Then generate a new key pair and submit the keys for certification at your CA (again follow the documentation). The stash file is used by the web server to open the otherwise encrypted keystore without a password.

When you receive the reply please bear in mind that the certifying certificate must be in the keystore before accepting the reply. For most CA’s this will require you to import a certificate before proceeding. This goes for Equifax as well as Verisign. The easiest way to find these is to surf to your CA and search for “intermediate”.

Once this is done you can import the certificate reply, update httpd.conf, restart IHS and you’re laughing…