I initially posted this as a question in the Novell Support Forums, that got posted as an article at:
https://community.microfocus.com/cyberres/b/sws-22/posts/certificate-renewal-tips-for-idm-drivers

I wanted to revisit it, and expound further on the topic.

I have been working as a consultant doing Identity Management projects and support Identity Management implementations. This particular problem, is probably the most common one I have run into.

It is one of my favorites, since the error so clear and to the point, it seems like it should be obvious what the solution is. More than anything else, I wanted to get the actual error message into an article, so other people encountering this error, can use Google to find a resolution. Basically my assumption is that when someone runs into an error, one of the steps they take in troubleshooting is trying to paste the error message into Google to see what comes up. The previous post does not include the error message, so it is worth revisiting it, just to get the message into the Google index!

So here is one case, from an Active Directory driver.

09:39:05 97CA5540 Drvrs: adlink PT:

DirXML Log Event -------------------

Driver: \IDM\US\NYC\idm\Treelink\adlink

Channel: Publisher

Status: Error

Message: java.io.IOException: SSL handshake failed, SSL_ERROR_ZERO_RETURN, error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate expired

Literally a week after I submitted this article, and four days after it was published, a client called with this exact problem. In his case, we had fixed this exactly two years ago, and he had marked it on his calendar that his certificate was due to expire in two years. Well he did not get it fixed in advance, so off we went to fix it today. He had a slightly different error message that I would like to add as well to this message.

This is the error from the Windows Event log for the remote loader

Event Type:     Error

Event Source:   DirXML Remote Loader

Event Category: None

Event ID:       2

Date:           11/17/2008

Time:           11:59:49 AM

User:           N/A

Computer:

Description:

Driver :

Thread : Subscriber Channel

Object :

Message : SSL protocol failure: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 

This error has been reported 407 times in a row since first logged.

The symptoms are the Active Directory driver stops processing events. If you restart the driver, you see the above error at the bottom of the trace file.

The ultimate cause, is usually that the certificate used for SSL encryption of the communication between the Remote Loader and the Identity Manager engine was created with an expiration date. The default for the longest time was two years, some tools now default to 10 years, or the max, it depends exactly how you created it. For us, usually this comes up after the system has been up and running for quite a while, and suddenly it stops working. Pretty funny that nothing really went wrong for two years, until this issue!

Fixing it is pretty trivial. Recreate a certificate with the exact same name (or a new name, but if you change the name, you need to change the value of the kmo="Cert Name" part of the connection string in the driver configuration) and try to set the expiration date to maximum (which is set by the expiration date of the Tree CA, usually the end of CTIME, around 2037. 2037 is when we face the Y2K-37 bug, where all systems using CTIME run out of numbers. CTIME is roughly seconds since 1970, in a signed integer, so you get about 2 billion seconds. Well that runs out in early 2037. I have no clue what we will do then, I will just leave that issue to my children to deal with. Heheh. Suckers!).

Ok, as I re-read that last attempt at a sentence, I realized that for something so trivial, I sure qualified it quite a bit.

Seriously though, create a new certificate. The connection string uses the name of the certificate stored as a string, not as a DN reference, so as long as the name is the same, signed by the same Certificate Authority (CA), you should be fine.

There are several ways to do it.

You can just mint a new one 'by hand' via Console One with the PKI snapins, or via iManager with the PKI plugins. Select Custom for the definition so you can be sure to specify the longest lifetime left on it.

On Netware you can just run PKIDIAG, if it is one of the default certificates, and it will recreate them for you with the same name. Here is a link from Support on using PKIDIAG on Netware: https://support.microfocus.com/kb/doc.php?id=10095905

If you are using one of the cross platform eDirectory installs (Windows, Linux, AIX, HP-UX, Solaris, etc) then the iManager plugins are pretty much your only approach. There is a task in the Novell Certificate Server section, called Create Default Certificates. I do wish they had named it slightly differently, as it is not very clear what and when to use this option. Here is a Support TID on the topic:
https://support.microfocus.com/kb/doc.php?id=3392944

If you are using a certificate you minted just for this purpose, delete and recreate it. If you are using an external certificate, then you will have to get a new one.

The other twist is if you have an eDirectory to eDirectory driver. In that case it is not sufficient to just replace one certificate, since there is a certificate in each tree, and they are tightly intertwined.

In this case, you have three approaches.

1. Use the iManager plugins and the eDir to eDir Certificate wizard to recreate them, much as you would if you were setting the driver up the first time.

• Use Designer in much the same way.
• Do it the hard way, like we had to do in DirXML 1.1a days.

Usually I find between the first two options are sufficient to get it done, and have not ever had to resort to the third option.

A really nice feature in Designer is that you can control how long the certificates will last, in the Preferences.

Go to the Window menu, select Preferences, expand the Novell node, expand the Identity Manager node, then the Configuration node, and finally the eDir to eDir SSL/TLS tab. Its the Preferred Validity period. Lots of other good options on this page.

Click to view.