Zertifizierungs Problem

[bwinger]

Hallo,
habe ein Problem beim Anlegen neuer User. Immer wenn die Person sich anmeldet kommt ein Requester mit dem Inhalt:
Der aktuelle Schlüssel passt nicht mit dem Zertifizierten Schlüssel überein.

Folgende Meldung erscheint im log.nsf
06.08.2003 10:29:00   Fehler bei der Verarbeitung des Zertifikats, das von O=Neuland für O=Neuland erstellt wurde: Der benutzte öffentliche Schlüssel stimmt nicht mit dem zertifizierten Schlüssel überein.
06.08.2003 10:29:00   CN=Nina Schocker/O=Neuland konnte sich nicht authentifizieren: Der aktuelle öffentliche Schlüssel stimmt nicht mit dem zertifizierten Schlüssel überein. Lesen die lokale Protokolldatei.

Folgende Sache habe ich versucht und gemacht:
Öffentlichen Schlüssel der cert.id  /o mit dem Notes Zertifizierer geprüft bzw neu eingefügt.
Neue cert.id angelegt als /ou und damit einen User angelegt.

Was kann man noch machen ?

:Bernd

[Glombi]

Hi,
hast Du irgendwan mal den Certifier Neuland neu erstellt?

Hier ein möglicher Workaround:
"The Public Key That is Being Used Does Not Match..." Renaming with AdminP

Problem:

When an Administrator uses the Administration Process (AdminP) to rename a Person, the following error message appears in the ADMIN4.NSF database:

"The Public Key That is Being Used Does Not Match the One That Was Certified."

The error is a response document listed under the "Request to Initiate Rename" document in the Name and Address Book (NAB).  A sample Administration Process Log displaying this error message can be found in Figure 1 below.

Solution:

This error message indicates that the Public Key in the Certification document does not match the Public Key in the Certification.ID.  To troubleshoot this issue, verify that the Public Key in the Certification document in the NAMES.NSF file is the same as the Public Key in the Certfication.ID used when renaming the Person through the AdminP request.

NOTE:  If you are using Organizational Units (OU), verify that the Public Keys in both the OU certifier and the ancestor (the CERT.ID that was used to create the OU) CERT.ID match the corresponding certifiers in the NAB.

Steps:

1.   Make sure that the administrator is using the correct Certfiicate.ID when renaming.
2.   If the correct Certificate.ID is being used, verify the Certified Public Key.
3.   Compare the public key on the Certificate.ID to the public key in the Certificate document in NAMES.NSF.  You must put the Certificate document in edit mode to do this.
4.   Do not edit the NAMES.NSF public key unless you are sure this is the correct Certficate.ID.

Achtung!!! Das ganze ist mit Vorsicht zu genießen, insb. derartige Änderungen !!! Am besten postets Du mal mehr Infos...

Andreas

[Glombi]

Wenn das ganze aber nur bei dem einen user auftritt, bei den anderen aber nicht, liegt die Ursache woanders. Dann stimmt was mit dem key des Users nicht.

Andreas

[bwinger]

Hallo,
Das Problem tritt bei allen Neu angelegten Usern auf.

Welche Daten werden noch benötigt ?

Was die Cert.id angeht, so benutzen wir immer ein und die Selbe. Die Organisation Neuland gab es schon immer. Wurde also nicht angefasst oder geändert (zumindest nicht wissentlich).

:Bernd

[Meff]

Was hast Du da genau gemacht:

Öffentlichen Schlüssel der cert.id  /o mit dem Notes Zertifizierer geprüft bzw neu eingefügt.
Neue cert.id angelegt als /ou und damit einen User angelegt.

Meff

[bwinger]

Hallo,
unter Registrieren -> Unterorganisation

dort habe ich eine unterorganisation angelegt mit der Vorhandenen Cert-id

die unterorg. hies ering

Danach habe ich den öffentlichen Schlüssel geprüft, dieser war identisch. in der cert-id und im notes zertifizierer Dokument.

----
An anderer stelle wurde vermutet, da bei bei mir unter den Notes zertifiziern mehrere einträge zu finden sind, liegt hier das problem. Auch da habe ich den richtigen eintrag gesucht, der mit meiner Cert-id übereinstimmt und alle anderen gelöscht. Doch auch das brachte keinen erfolg. Werde wohl ein Backup einspielen mussen, von einem Zeitpunkt wo ich weis, das es geklappt hat. Welche dateien muss ich eigentlich überspielen ?
names.nsf, notes.ini, server.id, cert.id ?

welche noch ?

:Bernd

[Glombi]

Hi,
das Problem ist, dass der Schlüsselinformationen, die in der User-ID für den Certifier Neuland gespeichert ist, nicht mit der Schlüsselinformation übereinstimmt, die für den Certifier Neuland im Domino Directory gespeichert ist.
Entweder hat dort jemand "rumgepfuscht" (was ich nicht glaube) oder jemand hat am Certifier was gedreht.
Da es ja bei den alten User-IDs funktioniert, darf man jetzt nicht den öffentlichen Schlüssel des Certifiers im Domino Directory ändern, denn dann könnte ja die alten User-ID nicht mehr zugreifen.
Also würde ich mal schauen, ob es eine Sicherhung der cert.id für Neuland gibt. Falls ja: Lasse einen User mit dieser cert.id zu und prüfe, ob er sich am Server anmelden kann.
Falls ja, ist das der richtige Certifier. Die User, bei denen es nicht geht, müssen neu zertifiziert werden.

Andreas

[bwinger]

Hallo,
danke, das wars. Die Cert.id war kapput.
Ich habe sie von einer sicherung geholz, wo ich wusste, da habe ich eine Person angelegt.

Aber ne Frage:
wodurch kann die id beschädigt werden ? Nur um vorzubeugen.

:Bernd