How to correct Lotus Notes public key mismatches in four easy steps

If a public key in the Notes Address Book (NAB) isn't the same as the one in the ID file, processes fail, including email encryption, renames and recertifications, password checking and public key checking, and requests sent to the AdminP task. Fixing Lotus Notes IDs with mismatched public keys is simple though, if you know these four steps.

To be honest, it's not really four easy steps. It's really three easy steps and one kind of tedious step. But public key mismatches in Lotus Notes and Domino are so important to correct that you'll want to do all four of them anyway, even if the last one is somewhat irksome.

Background on Lotus Notes public keys

Every Lotus Notes user's ID file stores a pair of extremely important security keys: the private key and the public key. These keys are mathematically related to each other and are unique to each user ID.

The public key is stored in your user ID and the Domino Directory. Your private key is a well-kept secret that is only stored in your user ID file. These two security keys have the same mathematical key ancestry, but have slightly different content and functionality. Think of them as fraternal twins rather than identical twins.

The private key and public key are used by Lotus Notes and Domino Server in a variety of security situations, such as authenticating with a server, signing email, or sending and receiving encrypted email. When someone sends you encrypted email, their Lotus Notes client reads your public key from the Notes Address Book (NAB) and uses it to encrypt the message. When you receive the message, your Lotus Notes client uses your private key in the process of decrypting the message.

Occasionally, mostly by accident or through someone not following best practices, the public key in a Lotus Notes ID file becomes different than the one in the Notes Address Book.

If the public key in the address book is not exactly the same as the public key in your ID file, many Lotus Notes processes, such as encrypting email, will cease to function correctly.

More information on Lotus Notes encryption and public keys:

An overview of the 'check public key' feature in Lotus Notes

Using an event handler to track down public key mismatches in Lotus NotesTroubleshooting an agent that cannot encrypt email message

A primer on encryption and privacy in Lotus Notes/Domino

But that's not all. Renames and recertifications will fail, as will password checking and public key checking. Requests sent to the AdminP task break also, because the public key of the requestor doesn't match the one in the NAB.

IBM Lotus has published many documents with instructions on how to copy the public key from an ID to a person document in the address book. But how can you be proactive and find all the Notes users that have the mismatched public keys?

This is especially important if you want to implement password or public key checking for the first time. You'd hate to turn on those functions, only to find out that you've accidentally prevented a few hundred users from accessing servers. That would be a very unpleasant day.

How to fix Lotus Notes user IDs with mismatched public keys

Fortunately, the solution is a piece of cake, if you know these four steps:

  1. Know what to look for.

    In releases 5.x and 6.x of Notes/Domino, an event is logged whenever a user with a mismatch is authenticated by a server. The error in the log and on the console looks like this in these versions:

    WARNING: The public key for Liam 
    Michaels/Technotics found in directory 
    names.nsf on server Mail01/Servers/Technotics 
    does not match the one used during 

    In ND7, server documents must be configured to log this event. You'll find the setting in the security tab.

    Figure 1

    This is the ND7 version of the public key mismatch message:

    Mark McGurk/Technotics from host 
    [] encountered non-fatal 
    problem during authentication: Your public 
    key was not found in the Name and Address 

    Now that you know what's going to show up in the log, you can capture and analyze the information to find out which users have the problem.

  2. Create a database to hold all of the errors.

    You don't really have to put all the errors in a database. You could use log analysis to find all of the occurrences. That works if you have just three or five servers.

    But if you have 20 or 50 or 100 servers, pulling these incidents out of the logs would be painfully slow and a mind-numbing experience. Notes/Domino administrators like us are generally too busy to comb through data on every Lotus Domino server log in a big domain.

    Instead, pick your favorite server and create a database using the Monitoring Results (statrep.ntf) template. Give the database a title and a file name that identifies what it contains, like "Public Key Mismatch Catcher" (pkstatrep.nsf).

  3. Configure an event handler to capture the logged event and place it in the database you created.

    Open the Monitoring Configuration (events4.nsf) database on one of the Lotus Domino servers in your domain and create an Event Handler.

    I like to choose "all servers" during the discovery process. I also select "Any Event," because we don't care what kind of event it is. We're going to be interested in a specific text string appearing in the server console and thus in the log.

    Figure 2

    For R5/6 configure the "Events must have this text in the message" to hold a portion of the error message, such as the following:

    WARNING: The public key

    This screenshot shows the Event tab of the Event Handler for R5/6.

    Figure 3

    If you're using ND7, you could use this line instead:

    public key was not found

    Figure 4

    Lastly, configure the Action to be "Log to a database", and enter the filename of the database you created and the server that contains it.

    The Event Handler is enabled by default.

    Figure 5

    Then just sit back and let the collection happen. In a very short amount of time, the database will start collecting the error and you'll know who has a public key mismatch.

  4. Fix the problem.

    This is the tedious part. Use the instructions in this link to a Lotus knowledge base article about fixing public keys in the address book. This is the R6.5 method, but the other versions are very similar.

Unfortunately, I am not aware of any automated way to fix this problem. If you have one and share it with me, I will in turn share it with the extended family of Notes/Domino administrators here on SearchDomino.com and give you the credit. You can write to me at AndyP at Technotics dot com.

About the author: Andy Pedisich is President of Technotics, Inc. He has been working with Lotus Notes and Domino since Release 2. Technotics provides strategic consulting and training on collaborative infrastructure projects for customers throughout the world. You can contact Technotics through their Web site at www.technotics.com.

Do you have comments on this tip? Let us know.

Please let others know how useful this tip is via the rating scale below. Do you have a useful Lotus Notes, Domino, Workplace or WebSphere tip or code snippet to share? Submit it to our tip contest and you could win a prize.

Dig Deeper on Lotus Notes Domino Access, Permissions and Authentication

  • Favorite iSeries cheat sheets

    Here you'll find a collection of valuable cheat sheets gathered from across the iSeries/Search400.com community. These cheat ...