Working with SHA-2 in Domino

Any production web site on Domino will have been flagged for months (if not years) on lack of support for SHA-2.  Since the poodle scares last year, a lot of third party certifiers made the decision to no longer support SHA-1 certs, just in time for Domino to begin supporting SHA-2 (phew).

So by now you’ll probably be aware of the prerequistes

and the steps from IBM to a point are actually very clear. (though it does make sense for it to be packaged in the server certificate admin tool soon – please IBM)

There’s two steps that need to be different though.  The first is the same with any third party supplier of certs and that’s getting the correct root and intermediate certs for your SSL cert.  That’s a problem independent of Domino though and anyone who has installed a cert previously will have done similar to this.

The second issue is the step:

“6. Import the RSA keypair and self-signed certificate into the new keyring file

6a. Concatenate server.key and server.pem into a single file:

This step varies from the self-signed case. You will have more than one certificate in your “.pem” file, and will want to place them in order with your server’s SSL “leaf” certificate first and the root certificate last. Verify step 6b will check to ensure that the ordering is correct. If it returns any warnings or errors, edit the PEM file and verify it again.

Note the following:

  • Certificate Authorities will frequently return a signed certificate in a .crt file. If they also provide the root certificates when returning the CSR file, then you can concatenate all of the .crt files to the private key by using the “type” command from a DOS prompt.
  • The files should be concatenated with the server key first, the server’s cert next, the intermediate cert next, and the root cert last. Concatenation can be done from a DOS prompt using the TYPE command. The type command takes a list of files, and appends them together into an output file designated with a greater-than symbol. For example, type server.key server.crt intermediate.crt root.crt > server.txt In this example “server.txt” is the file provided to the kyrtool for import into a Domino keyring. You can display this output file in Notepad.
  • If the root and intermediate certs are not provided with the signed certificate, export the intermediate and root certificates by opening the server certificate with Windows Crypto Extensions. This will display the server in a three-tabbed user interface. On the third tab, select each of the signing certificates, select display, and then export that certificate using the “save to file” command on the second tab. Save each cert file using Base 64 format.

I’ve had continious issues with concatenating certs using type server.key server.crt intermediate.crt root.crt > server.txt

The last cert usually gets cut off (you can see when you open server.txt)., but it’s not immediately obvious and you get various errors saying the chain is invalid if you go any further.

The simple workaround is rather than concatenating all the certs in one step, simply do them one by one.


type server.key >key.txt

type server.crt >sslcert.txt

type intermediate.crt > intermediate.txt

type root.crt > root.txt

Then create a new text file in notepad called server.txt, and manually copy the contents of key.txt, sslcert.txt, intermediate.txt and root.txt in one by one.  The rest of the steps should now work for you.

Let us know if that helps or if you’ve any more gotchas!

Cormac McCarthy – Domino People Ltd


New iNotes 9.0 Undocumented Security Feature.

In iNotes on a Domino 8.x server you can view encrypted mail over http, once you’ve uploaded your ID.

In iNotes on a Domino 9.0 server you get this message:

It’s an interesting that this is now forced, I haven’t seen it documented anywhere.

Not that we’d recommend that anyone use HTTP for any production releases of iNotes!

Cormac McCarthy – Domino People Ltd

Domino Error – Unable to Bind port…..

Most Domino Admins will have seen this in a console from time to time.  It happens when a local OS application is using a port Domino wants to use.  So far, so simple.  But what’s the quickest way of finding out which application/service is using the port you want?  In windows it really is quite easy…

Open a command prompt and type:

netstat -an -o

This will give you a list of applications (and PIDs) that have ownership of ports. Look for the port, and associate the PID with a Process in task manager.

Let’s take a common example.  You enable HTTPS for web connections in the server document and restart http.   The Domino console tells you “HTTP Server: Error – Unable to Bind port 443, port may be in use or user needs net_privaddr privilege”.

Remote to the OS of the server.  Open a command prompt.  Type “netstat -an -o”.  You’ll get something like this:-

Look for the port in question, in this case it’s 443, and the associated PID is 1268.  Open windows task manager, click “View” and “Select Columns..

Make sure PID is selected as a column.


Sort by the “PID” column and look for the PID from earlier (1268 in this case), you’ll find the “offending” application under “Image Name”.

In this case it was TeamViewer as you can see.

I hope you found this useful.  It’s not that complex a problem, but often it takes few minutes to remember exactly what the best way of checking this is!

Cormac McCarthy – Domino People Ltd.

SSL breaks after upgrading to Traveler 8.5.3 UP 1

On a production upgrade of Traveler to 8.5.3 U.P. 1 yesterday we came across a problem.

The upgrade itself completed without issue but mobile clients couldn’t connect to the server automatically after the server was back up and running.

We could see the following in the log :-

“HTTP Server: SSL Error: Keyring file not found, key ring file [keyfile.kyr], [Default Server]”

So we did some digging.  Before the upgrade the “SSL key file name” field (Server Document -> Ports > Internet Ports- >  SSL key file name) was something other than default (say mobile.kyr for argument’s sake).

After the upgrade this field changed back to the default “keyfile.kyr” automatically!  It is quite an easy fix (either renaming the the .kyr file on the OS and restarting HTTP or renaming the field in the server document and restarting HTTP fixes the problem).

We’ve done a few tests and it doesn’t appear to be reproducible on demand, however it is worth noting in case the same thing happens to you!

Cormac McCarthy – Domino People Ltd.