2016-03-25 28 views
0

Wir haben den statischen Wert 'usernameTest' als Benutzernamen verwendet, um EJBCA zur Generierung von X.509-Zertifikaten aufzufordern. Nach dem Generieren von Zertifikaten unter Verwendung dieses satic-Benutzernamens haben wir ihn in einen eindeutigen Wert geändert, der jedes Zertifikat eindeutig identifiziert (Da die Verwendung eines statischen Benutzernamens als Erneuerung gilt, da der Benutzername für alle Zertifikate gleich ist (*)), lehnt EJBCA nun das Generieren von Zertifikaten ab stil referenziert den alten statischen Benutzernamen 'usernameTest'; wir erhalten diesen Fehler:EJBCA verweigert das Generieren von Zertifikaten mit Fehler: Es ist nicht zulässig, denselben Schlüssel zu verwenden

Der Benutzer '250320092916' darf nicht den gleichen Schlüssel verwenden wie der Benutzer 'usernameTest' verwendet.

Wir widerrufen alle Zertifikate, die zuvor für den Benutzernamen 'usernameTest' generiert wurden, aber wir erhalten immer noch diese Fehlermeldung von EJBCA. Gibt es eine Möglichkeit, den Benutzernamen usernameTest zu entfernen?

Jedes Zertifikat hat einen eindeutigen SubjectDN und Benutzernamen.

Die Version von EJBCA ist ejbca-6.2.0.

(*): Alle generierten Zertifikate in der EJBCA Administrations-GUI beziehen sich auf denselben Benutzernamen.

Vielen Dank im Voraus.

Antwort

0

Problem gelöst; Das Problem ist nicht, dass ein Verweis auf usernameTest immer noch in EJBCA, aber dass der gleiche Schlüssel (RSA Public Key) für die Anfrage des anderen Benutzers ('250320092916') verwendet wird.

Es scheint, dass dies eine bekannte Einschränkung ist, wenn man sich auf den HSM PTK-C-Simulator aus der Safenet ProtectServer-Reihe verlässt; Der Simulator startet seinen Zufallsgenerator neu, wenn wir ihn neu initialisieren (ich vermute einen Missbrauch von mir), was bedeutet, dass er immer dieselben Schlüssel in der gleichen Reihenfolge erzeugt (was zu solchen Fehlern führt).

Aber auch der Nachrichtenfehler ist nicht klar; Sprechen über den "Schlüssel" ohne Angabe, führt dies zu einer Verwechslung mit dem SubjectDN oder anderen Attributen, die dem EJBCA mitgeteilt werden, als Fehlermeldung kann es "öffentlicher Schlüssel" oder "RSA-Schlüssel" sein, ... statt Schlüssel;)

1

Es hat nichts mit dem HSM zu tun. Die Standardrichtlinieneinstellung für Zertifizierungsstellen besteht darin, Benutzern nicht zu gestatten, denselben öffentlichen Endbenutzerschlüssel zu verwenden. Ich möchte kein Zertifikat mit demselben öffentlichen Schlüssel an verschiedene Benutzer ausgeben. Dies ist eine Checkbox-Einstellung in den CA-Einstellungen.

+0

Dies ist, was ich getan habe, um dieses Problem zu umgehen.Tatsächlich besteht unsere Anforderung darin, ein anderes Schlüsselpaar pro Zertifikat zu haben, während wir in unserer Entwicklungs-/Testumgebung einen Simulator verwenden, um Schlüsselpaare basierend auf Safenet HSM (nur Software-Modus) zu generieren, die manchmal doppelte Schlüsselpaare generiert. –

2

Tomas hat Recht. Gehen Sie zu Ihren "Zertifizierungsstellen" unter CA-Funktionen. Bearbeiten Sie Ihre Zertifizierungsstelle, und suchen Sie unter dem Abschnitt "Direktiven" die Einstellung "Erzwingen eindeutiger öffentlicher Schlüssel".

Deaktivieren Sie erzwingen, und Sie können den gleichen öffentlichen Schlüssel für verschiedene Benutzer verwenden.

+0

Das habe ich getan, um dieses Problem zu umgehen. Tatsächlich besteht unsere Anforderung darin, ein anderes Schlüsselpaar pro Zertifikat zu haben, während wir in unserer Entwicklungs-/Testumgebung einen Simulator verwenden, um Schlüsselpaare basierend auf Safenet HSM (nur Software-Modus) zu generieren, die manchmal doppelte Schlüsselpaare generiert. –

1

Sie können den PTK-C-Simulator so konfigurieren, dass der zufällige Seed nicht wieder verwendet wird (ja, das ist sehr ärgerlich). Für ejbca haben wir es dokumentiert here. Sie müssen die Umgebungsvariable ET_PTKC_SW_AUTOSEEDRNG = true setzen. Mit dieser Einstellung erzeugt der Simulator echte Schlüssel, jedes Mal einen neuen.

+0

Ich werde das versuchen. Danke Tomas. –