meta/LPAR

Thinking inside the Big Blue box.

Domino server and Java client, SSL with self-signed certificate

Here’s the problem scenario:

  • You have a Java client program, and you want it to connect to a Domino server using HTTPS.
  • Java fails at runtime with javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  • This is happening because you have a self-signed SSL certificate on the server, which Java refuses to accept.
  • You’ve found out that you can import a self-signed SSL cert into Java’s runtime environment using keytool, but Domino uses an obscure proprietary keyring format .kyr which is only readable by IBM’s IKeyMan application, which doesn’t ship with Domino. (Or possibly you have IKeyMan, but the version you have doesn’t support .kyr conversion to other formats, or you don’t have access to the server to yank out its SSL certificate.)

The solution to all of the above:

  • Use Firefox 3 to navigate to the Domino server via HTTPS. Set up a certificate override so Firefox 3 will accept your self-signed cert.
  • In Firefox, follow through this sequence of menus, dialogs and buttons: Edit > Preferences > Advanced > Encryption > View Certificates > Authorities.
  • Find your certificate in the list, click it, click the Export... button.
  • Export into regular PEM format (the default), call it servername.pem.
  • Import it into a Java keystore using keytool. The command and output will look like this:

$ keytool -importcert -file servername.pem
Enter keystore password:
Re-enter new password:
Owner: CN=servername.example.com, O=YourOrgName, L=City, ST=State, C=US
Issuer: CN=servername.example.com, O=YourOrgName, L=City, ST=State, C=US
Serial number: 01decaf3
Valid from: Thu Feb 07 00:00:00 GMT 2008 until: Fri Feb 06 23:59:00 GMT 2009
Certificate fingerprints:
MD5:  7A:E2:F4:BE:D3:6C:7C:79:5C:51:73:15:DD:24:92:C4
SHA1: 95:21:31:47:8E:49:A2:18:7E:B4:B8:17:DA:50:7E:F7:D3:13:E4:57
Signature algorithm name: MD5withRSA
Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore

  • Finally, copy and rename the newly created ~/.keystore to be $JAVA_HOME/lib/security/jssecerts on the client machine.

You should now find that Java SSL clients will connect to your server. If you want some simple test code, try listings 7 and 7 from the article about JSSE at O’Reilly ONJava.

There’s a caveat to be aware of, though. If the JVM finds a jssecerts file, it doesn’t bother to check the regular cacerts. What this means is that normal SSL certificate resolution (for non-self-signed certs) will be broken for any Java client that uses JSSE. So if you run other software that uses JSSE, it might suddenly refuse to connect to other SSL sites.

So, a better approach is to locate your Java cacerts file, and add the .pem file to that. Your server then becomes another trusted source of certificate signatures, alongside Verisign and the other root certificate providers.

The cacerts file is in $JAVA_HOME/lib/security/cacerts, and the command to add your server to it is:

keytool -importcert -keystore cacerts -storetype jks -file server.pem

There are supposed to be deployment properties which let you override the jssecerts file for a specific Java runtime. That would be the best approach, but it doesn’t seem to work with Java 6. If anyone can get it to work, I’d be delighted to know what the secret is.

Update: Andreas Sterbenz wrote a handy utility while he was working for Sun. Grab the code before Oracle take it down. He’s now working for Google, like many ex-Sun Java guys, so obviously you’ll never hear from him again.

Posted by meta on 2008-07-17 | Posted in Domino, Java | Tagged , , , | 1 Comment

Domino date/time format gotcha

I inherited a legacy Domino application which had been coded to assume mm/dd/yyyy format for dates. Bad idea, but there’s a lot of it about.

I got a steady stream of users complained that sometimes when they entered data via the web, the months and days were being switched around at random during save. Yet no matter how much I tried, I couldn’t reproduce the problem.

Days of attempted debugging followed. To cut a long story short, here’s what was going on:

Continue reading »

Posted by meta on 2008-07-17 | Posted in Domino | Tagged , , , , , , | 1 Comment

Genetic non-discrimination

During a recent conference call, I learned that IBM has adopted a genetic non-discrimination policy. Apparently this news somehow slipped past me back in 2005 when it was announced. The company also supports proposed legislation to make it illegal to discriminate based on someone’s genetic code.

A few other facts about IBM you might not know:

  • IBM hired its first black employee in 1899, along with three female employees. (At the time, it was known as the Computing Scale Company.) The four worked for the company for over 25 years.
  • The first disabled employee was hired in 1914.
  • IBM began hiring women to work as professional systems service staff in 1935. Thomas J. Watson Sr. wrote: “Men and women will do the same kind of work for equal pay. They will have the same treatment, the same responsibilities and the same opportunities for advancement.”
  • In 1944, IBM was the first corporation to support the United Negro College Fund.
  • In 1953, IBM published the first US corporate mandate on equal employment opportunity, stating that the company would hire people based on their ability, “regardless of race, color or creed”.
  • Sexual orientation was added to the nondiscrimination policy in 1984.

So no, it really isn’t a bunch of middle-aged white guys in suits. Which reminds me–the dress code was relaxed in the early 90s. I’ve seen senior executives get teased during on-stage presentations for wearing a tie. At IBM Austin I’ve seen sandals and Hawaiian shirts.

Posted by meta on 2008-07-17 | Posted in Culture | Tagged , , , , , | Comment