Error received "error updating the certifier log" when creating new Notes ID in V 4.6

We are receiving the following error when a new Notes ID is created in V4.6, "error updating the certifier log".  

Also some of our existing notes ID's have expired as of today even when the experation date was set to 2099.
Who is Participating?
SysExpertConnect With a Mentor Commented:
Apparaently you do not have manager rights to the Certlog.

You need to use the ID of the Notes Admin.

I hope this helps !
1) Check the server dates and workstation dates.

2) reboot server

3) try again.

4) Check the Certification log

If none of these work, I would say it is time to upgrade.

R 4.6 and R5 are both no longer supported, time to go to at least R 6.5

I hope this helps !
Swamp_ThingAuthor Commented:
I have tried all of the above with no result.  All of the users in our Cert Log do not expire until 2099.

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

I would try replacing the design on the Certifier log.

Did you check the IBM site  ?

Swamp_ThingAuthor Commented:
To be honest we are not quite sure how to replace the design on the Certifier Log.  Is this something that I can learn about on IBM's website?

Also listed below is another error message that we receive in the Server Log whenever a user tries to use notes:

“Error locating an address book entry for Certifier. Entry not found in index.”

When a user tries to log in they receive this error message:

"The certificate expired on 10/29"

As you may have guessed we are not Lotus experts.  
You need to be an adminstrator.

Right click on the Icon for the Certification Log, choose database- replace design,
From the template Server list, choose the server the certlog is on.
Click the checkbox to show advanced templates and choose Certification Log ( certlog.ntf )

Click replace, and accept the warning message.

I hope this helps !

Swamp_ThingAuthor Commented:

When I right click on the Icon a Replicate option appears and that's it.

Swamp_ThingAuthor Commented:
Is there a quick way to find out if an ID is an Admin ID?  All of our ID's are user names and none are clearly marked as Admin.  

Sorry to be a pain but I just want to be positive we are using the Notes Admin.
You should check the Acess control list of the database.

It will have the names of the managers listed.

Right click on the DB ICON-  choose database - Access control

I hope this helps !
Swamp_ThingAuthor Commented:
I found this in the Notes error logs...Any idaes?


Originating Server:      ie_server_notes/ADMIN            Event Time:      10/30/2006 03:49:58 PM
Event Severity:      Failure            Event Type:      Replica

Event Text:      
Unable to replicate with server GoldlineApps/ADMIN: Server not responding       

********Also the CPFmon Admin Service will not Start (unable to find specifies file)
These are replication errors. Hard to know if they will cause any issues.

The last error I am not familiar with, but may  not even be Notes related.

Is this a Compaq Server ?

Swamp_ThingAuthor Commented:
No. It is a Dell PowerEdge server.

rrabieConnect With a Mentor Commented:
Check the acces control on the certlog.nsf, you need access to it though.

The Entry not found in index is a bigger problem though. Is the certifier your using the O or OU (Organization or Organizational unit)? You need to re-create the certificate if its the O or re-certify the OU if its that. It might be that you have a OU certifier and that whole OU has expired.

You can find out what ID is an admin ID by checking the server document in the domino directory on the security tab.

The replication error is due to network issues. Check if you can ping, telnet on port 1352.

Hope this helps...

Hmm... just reading along here.  You have a certlog.nsf in Domino running 4.6.  A copy of the certlog needs to reside on each server, and those who certify users needs to have editor access.  The designer server needs to have designer access to update the template, and your admin people need to have manager access.  All other servers, other than the registration server need to have at least reader access.

If Notes Id's were set to expire in 2099, then when where these set ?  It's possible that your adminp is not running and performing the registration and certifier process, or that the certlog is not listed in the address book.

Also, if I recall with R4.6, people can have local copies of the O and OU certifiers that have different certificates, so the ones that work might be on a server, but the ones stored locally are out of date and expired or have the wrong keys from a previous installation.

So, first, make sure the certifier ids that you are using are ones from the server, or the latest.

Then make sure that you are using the Administration server to certify people.

Then click on a test user in the address book residing on the administration server and select "recertify user".  

Then open admin4.nsf on the server and see what errors are being reported.   If you go to the server console, type: tell adminp process new.  And see if it does process the certification request.

The replication error is probably as mentioned above.. the administration server cannot reach the GoldlineApps/ADMIN server.. and that is a routing, permissions, or IP address failure, or the server isn't running, or the ACL of certlog doesn't list GoldlineApps/ADMIN  in the ACL or GoldlineApps/ADMIN is not a member of the localdomainservers group.

You can re-create the certlog.  (experts, chime in if I miss a step here)

First make a local replica, then  create a new certlog2.nsf using File>>Database>>New and select the certification log template from the Server, once you do this, you will have manager access to the new certlog2.nsf.

Adjust the Access Control List to include your standard groups, and I think you can copy the documents from the old certlog into the new certlog2.nsf

Down the server, move the old certlog out of the directory and replace with the new log, renaming it certlog.nsf.  Now, you'll have to do this for EACH server so that EACH server has a REPLICA of this certlog.nsf.   Then you'll have to manually replicate for the first time to test replication.

Then you'll have to test a recertification, by recertifying a user and then running the adminp process to see if you get any errors.  

This last is an involved step, because if it doesn't work, you'll have to roll back.  
If you don't have access to the original certlog, then the server should.  You should be able to access the ACL using the client on the SERVER and the SERVER ID.  (for 4.6)  You may have to down the server in order to access via the server's notes client.


It's been awhile since I've had to recreate the certlog in the R4 environment, but I do recall that the biggest problem comes from those locally stored O's and OU's, and multiple copies not replicating through the domain.  It took me a good weekend to clear up these issues then.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.