You attempt to access another Lotus Domino® server and one of the following error messages displays:
"Your address book does not contain any cross certificates capable of authenticating the server."
"Server error: The encrypted data has been modified or the wrong key was used to decrypt it."
"The signature on the cross certificate was found to be invalid."
How do you troubleshoot this issue?
Resolving the problem
The above error messages can occur when a user, either at a workstation or at a server's administrative client, attempts to access another server. This situation can exist in an environment in which cross certificates already exist and have been functional for some time, or it can exist when an administrator is in the process of setting up cross certification.
To troubleshoot this issue:
1. Determine whether there have been any protocol or network connectivity issues recently.
2. Check if there any error messages received on server startup.
3. Determine whether servers can access other servers within their own domain.
4. When did the initial cross certification take place? Have there been any changes recently? Did the cross certification work properly at one time?
5. Is there a cross certificate listed in either domain's Domino Directory (names.nsf) referencing cross certification in each direction/organization?
6. Where is the error message displayed? On the server's admin workstation? On a client workstation? Does it display in both domains or just one?
7. Were there any error messages when the cross certificates were originally created?
8. Open the Domino Names & Address Book (NAB) --> Certificates view. Check the properties of the cross certificates involved, and check the date created to ensure they are the same generation. Make sure that there are no replication/save conflicts in the Certificates view.
9. Has the cert.id of either domain changed? Is the cert.id that created the cross certificates the current cert.id? Is there more than one cert.id on the server or available on disk? (When there is more than one cert.id involved, this margin of error is increased.
10. Can any of the servers within either domain access any server in any other domain? Is it isolated to only one server, some servers, or all servers? Do any cross certificates work with other domain/companies that are not involved in the problem? If one domain can cross certify with a third "neutral" domain and the other cannot, this indicates which cert.id is damaged or which may be the wrong cert.id.
11. Is the problem isolated to only a particular workstation? If so, check the personal NAB on the workstation and delete any trace of cross certificates. Try to access a server in the other domain. If this fails, copy and paste the cross certificate from the public NAB and try to access a server in the other domain.
12. If cross-certification problems persist, open the public NAB and delete all cross certificates referencing the target domain. Make sure this is done within both domain's NABs. Then cross certify on the server level in both directions. Can servers on each side open databases on the other domain's server without error? If so, this may indicate that a certifier is damaged, or that a wrong certifier was used during cross certification.
13. If Step 10 was successful, delete the cross certificates at the server level. Move up one level to the organization unit (OU) level or organization (Org) level, and try the cross certification at that level, making sure the cross certification is done on both sides. If there is an OU level within the domain and cross certification is successful, this is a strong indicator that there may be a problem with the cert.id.
14. If Step 11 was successful at the OU level, delete the cross certificates and cross certify at the Org level, using the cert.id's. Make sure that cross certification is done on both sides.
15. If cross certification fails at the Org level, one of the cert.id's may be damaged. Try using a backup of the cert.id in question.
16. Open the Server Document of each server in question, go into Edit mode, and ensure that the public key is still evident. If it is not, bring down the server, copy the public key from the server.id and paste it in the Server Document. Bring the server back up and try to access the other domain.
Rate this page:
Copyright and trademark information
IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.