Manage Learn to apply best practices and optimize your operations.

Certifier ID storage: Your call

Chuck Connell offers his advice on Notes/Domino certifier ID storage.

In last month's tip, Your views on Notes ID storage, I responded to the results of's poll about storage of Notes ID files. Several readers had interesting feedback about that tip, including a particularly insightful post by reader John K. Be sure to look at what he says at the bottom of my tip. This month I address the poll results related to storage of certifier IDs.

In June, asked the question: "Where do you store your certifier IDs?" A total of 189 people responded, which is a pretty good sample. Your answers were:

  • 44%: Network drive
  • 20%: Other
  • 18%: Local hard disk of administrator's computer
  • 16%: Diskette in a locked cabinet

As I noted last month, the answer "network drive" is ambiguous, which is my fault for wording the choices poorly. I did not distinguish between a shared, wide-open network folder, and a tightly controlled, secure place on a file server. Given this caveat, I have several comments on the poll results.

  • One of the most common questions I receive from Notes administrators worldwide goes something like this: "I suspect/know that someone has taken a copy of my organization's certifier ID. What should I do?" Someone with a copy of your certifier (either the root certifier or an organization certifier) can create new user IDs, mimic your Domino servers on the network and generally make your life difficult. Dealing with a stolen certifier is a large topic, which I won't address here, but the easiest way to prevent this headache is to make sure your certifier is not stolen in the first place. It is imperative that you protect your certifier ID(s) very carefully.

  • If you put your certifiers on a network folder, that folder must be really secure. Make sure only people who must have access to the certifiers can get into that folder. Use a high-quality pass-phrase for the folder (or for the network accounts that can access the folder). Change these passwords regularly. Make sure no previous employees still have valid passwords or accounts. Define (and enforce) a corporate policy against telling anyone your password. The penalty for doing so, except in an emergency, should be dismissal from the company.

  • The local disk drive of an administrator's computer is a pretty secure place to store a certifier ID, if two conditions are met. First, the computer's disk must not be shared at the network level, which could allow someone to hack into it. Second, it must be kept in a locked room, so someone cannot walk off with the computer and its hard disk.

  • A locked (fireproof) cabinet is an excellent place to store certifiers, and my personal choice. Each certifier can be on a separate diskette; the diskettes are returned to the cabinet each night; and only a few trusted people have keys to the cabinet. It is hard to get more secure than this.

  • No matter where you store your certifiers, use high quality pass-phrases for all certifiers. If someone does steal a certifier, it is useless if the person does not know the password. If your organization has more than one certifier, the passwords on each certifier should be unique. Knowing the password for one certifier should not help someone guess the passwords for the other certifiers.

Unfortunately, the "locked computer" and "locked cabinet" models break down in large organizations. When many people around the world must be able to create new user IDs, it is not practical to keep all the certifiers in a single room. One solution to this problem is to make careful use of organizational unit certifiers, and then distribute the organization certifiers only to administrators who need them. Here is an example:

Suppose the top-level certifier is /Acme. Only a couple people, in one room, have access to this certifier. They use it only to create organization units. So they create certifiers for /Servers/Acme, /Beijing/Acme, /Boston/Acme. The certifier for /Servers/Acme is given to one group of people, in one location, and they are the only people who can create new server IDs for Acme Corp. The /Beijing/Acme certifier is given to the Beijing office, and only a small set of people there can create Beijing IDs. Similarly, the /Boston/Acme certifier is given only to the Boston office. This overall scheme allows a large organization to function effectively, but controls the proliferation of each certifier ID.

A final suggestion: The optimum number of copies for each certifier is two. The first is your production copy, which you use day-to-day to create organization/user/server IDs. Since there is only one copy in-house, which you protect carefully, the chance of it being stolen is small. But you need a second copy in case the first is corrupted. Keep the second copy in a very secure location outside the building, such as a bank safe-deposit box.

I'd like to continue the interactive nature of this column. Please write to me with ideas for future articles. What do you want me to address? What have I said that you disagree with? Do you have a different idea for how to attack a problem I discussed? Send an e-mail to either or Or you can pose a question in my Security forum on

Chuck Connell is president of CHC-3 Consulting, which helps organizations with all aspects of Domino and Notes. CHC-3 allows companies to outsource their Domino administration needs via and runs the popular security site

Do you have comments of your own? Let us know.

Dig Deeper on Lotus Notes Domino Hardware Management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.




  • iSeries tutorials's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...