In the Wheelhouse: IBM, We Have an SSL Problem

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times


In the spirit of last week's article regarding IBM's on-premises intentions for IBM Mail Next, we need to simplify and fix Domino SSL. It's going to break.



A few months ago, I renewed my wildcard SSL certificates from and began the process of updating both types of HTTP servers in my shop: IBM HTTP Server and IBM Domino. I usually do Domino first and then IBM HTTP Server, the latter of which is a bit of a struggle. I'll get to that.


Updating Domino is always a journey as it involves importing a new certificate into the Domino keystore and then updating the existing proprietary *.kyr key file in my primary Domino server's data directory.


Then, I have to move the newly minted *.kyr file into the Domino data directories of the other nine Domino servers in my shop and give HTTP a restart or perhaps even a full Domino server reboot if I feel that a server or two needs it. Then all of my Domino HTTPS servers are doing SSL transactions using updated certificates. By now, I've got it down to a science, and it takes only about an hour to get all my servers done. This is usually a once-a-year thing for me. I could buy a certificate with multiple years, but to be bluntly honest, I don't want to let my "replace the Domino SSL certificate" procedure to go dull in my mind, because it's easy to screw it up if you get rusty.


Now for the fun part. I have to use the IBM Key Management utility (i.e., IKeyMan) to convert my *.kyr file into a *.p12 file so that IBM HTTP Server can use it. I suppose I could buy certificates for both servers, but I cut my teeth at a paper company for eight years and tend to save money where I can. The amount of web pages referencing "kyr to p12" scenarios gives you an idea of how popular this process is. Many people do it...or at least attempt to do it.


To get started, you have to use an antiquated version of IKeyMan because new versions won't do the conversion. How antiquated? Well, it has to run on Windows XP. That means I'm digging into the basement for the old faithful laptop with Windows XP that I boot up religiously every year for this single purpose. I put the new *.kyr file into the magical software and poof! It spits out a magical *.p12 file. Then I import it into IBM Digital Certificate Manager and let my IBM HTTP Servers use it. Getting IBM HTTP Server on IBM i to update a certificate instead of importing a new one and then having the IBM HTTP Servers use the brand new one instead is another issue altogether. I've been meaning to PMR that because I've never had much success with updating a certificate, but I digress.


To end the process, I usually gripe on Twitter about the convoluted method with the old version of IKeyMan a little, have people gripe back, and then don't think about it again until next year.


This time, the process was different.


SHA-2, Where Are You?


The certificate I downloaded was encoded by default with the SHA-2 hash function. SSL certificates encrypt communication between a server (HTTP, Telnet, FTP, etc.) and a client (web browser, Telnet client such as a 5250 emulater, FTP client, etc.). This prevents others from eavesdropping on your communications no matter if it's on a public or private network. This encryption is implemented with a hash function. The SHA-1 hash function has been around for about 20 years and is being phased out in favor of SHA-2. Computers are far more powerful now, and the ability to break encryption is more likely with a weaker target such as SHA-1.


My problem occurred because SHA-2 is now the standard, and it would not import into Domino because it's not fully supported on that platform within the Domino SSL stack. Only SHA-1, MD5, and DSA are supported. Luckily, when I contacted again, they were sympathetic to my needs and supplied me with a less secure but supported SHA-1 SSL certificate. Your mileage may vary with your provider if you've bought and paid for SHA-2 already.


According to, new certificates with expiration dates after January 1, 2017, can only use SHA-2. Code-signing certificates with expiration dates after December 31, 2015, must also use SHA-2. Microsoft is driving all public Certificate Authorities toward adoption of SHA-2 as their default hash function, so whoever you use for SSL certificates will be affected.


Oh, but good news!


There's a method to get SHA-2 to work for your Domino HTTP servers. It involves putting an IBM HTTP Server in front of Domino!




But, my dear friends in the Power Systems community, are you ready for the real rub? The HTTP Server module is available only on 32-bit Windows. Other platforms are "under investigation."


In June, there was an IBM Ask The Experts webinar about Domino administration. A bit of Q&A went on, and this SHA-2 question was pretty popular. Here are the bits that matter from the Q&A:


Q32. Can someone provide an update what the plans are to have SHA-2 certificate support on Domino for SSL (Microsoft will drop support of older certificates by 31-Dec-2015)? SPR # ABAI7SASE6 Enhancement Request: Support SHA-2 algorithm for SSL on Domino (High triage priority, but no answer).


For SHA2 certificate support, we recommend at this time using an HTTP proxy server to handle the inbound HTTPS requests, Domino 9.x provides IHS with the server that is configured to work with the Domino HTTP web server.


OK, but this is Windows only. It doesn't help me. Next.


Q33. Will Domino support SHA-2? IBM HTTP Server on the front is not ideal.


Natively there's limited support for SHA-2 -;Highlight=0,Encryption,standards


OK, but this doesn't help me either. It's irrelevant. I need Domino HTTPS with SHA-2. I can't serve secure web pages with SMIME. Next.


Q34. Domino support told me to get a SHA-1 certificate because SHA-2 wasn't supported.


SHA-2 is not supported for Domino SSL. SHA-2 pretty much is limited to SMIME message encryption.


OK. See my previous snarky comment about it not helping me. And question 34 actually answered itself.


The next question loops back to the beginning of my article about making exporting *.kyr files in a supported, easy fashion. It's actually pretty easy once you have the XP box and an old version of IKeyMan, but the point still stands to have something supported. I'll give you this question/answer (and solutions provided by Darren Duke of Simplified Technology Solutions) in case you wanted to know how to do it.


Q35. What are your plans to resolve wildcard cert setup and import with Domino and related products that run on Domino? It is far too complex a process for 2014, poorly documented, and really a put-off for new customers.


You can use wildcard SSL certs on Domino as long as you create the CSR using the Domino server certificate admin database. However, as of today we don't have a supported way to import or export the SSL private key out of a kyr so you wont be able to share the SSL wildcard cert with any non-Domino Web servers.


From Darren Duke (STS):


it's convoluted but you *can* convert Domino wild cards for other purposes....


So IBM's answer was to ultimately use IBM HTTP Server on Windows. What you don't get from the published Q&A was the chat when people who are using Linux and IBM i started grumbling pretty hard.


Imagine someone with a bunch of Domino on System z being expected to put Windows servers in front of it! I know that Windows is out there in the world, but the world doesn't run on Windows. Support requirements might come out of operating system metrics on PMRs, but in reality, the metrics are screwy if you take Windows being Windows into consideration. Chances are, if it's Domino being wonky on Windows, it's because there's a good chance it's Windows making Domino go wonky. IBM i customers don't call you that much because IBM i doesn't bend, let alone break.


Ideally, native Domino SHA-2 support inside the SSL stack should be the solution. Manipulating kyr files in supported versions of IKeyMan should be the solution. Overall, I should be able to import a certificate into Domino easily and export it out of *.kyr format to another easily. It's a very modest goal: simplify the customer SSL experience.


Why am I telling you this?


A few reasons come to mind.


First, IBM has a cross-platform solution "under investigation." I figure if IBM has enough people knocking on their door asking for a proper solution, then they'll investigate harder and faster. It's the squeaky-wheel deal. Talk to your IBM rep about getting SHA-2 hashed certificates supported in the native Domino SSL stack and the ability to use an updated version of IKeyMan to manipulate them or the ability to export a key file right out of Domino into *.p12 or other formats.


Second, it's a ticking time bomb for anyone running Domino HTTP servers not on Windows. Of course, my readership will be mostly Power Systems plus System i, iSeries, and maybe some really old AS/400 iron. Eventually, SHA-1 certificates just won't be able to be acquired. Nor should they. We need a better road to being supported and protected. It affects you.


Third, and I'll be frank with this, putting an IBM HTTP Server in front of a Domino server is entirely unacceptable. It compromises the relative simplicity that Domino offers a customer. Sticking IBM HTTP Server in front of it isn't going to work for everyone. Even if it were cross-platform, if you've got 20 Domino servers, are you really going to consider putting 20 IBM HTTP Servers in front of them? I'd rather politely decline and ask IBM to do right by their customers.