Zertifikat Status revoked ändern

[anselm]

Hallo!

Folgendes Problem:

Aus einem mir noch nicht ersichtlichen Grund hatte ich nach dem Löschen einer Regel
Probleme mit allen push routes aller meiner OpenVPN Verbindungen. (Es waren keine mehr vorhanden)
Da ich das Problem nur lösen konnte, indem ich eine alte Config importierte, entstand das Problem, dass ich zwischenzeitlich bereits ein neues Clientzertifikat erzeugt
und an meinen User ausgegeben hatte.
Ich wollte diesem User kein neues Zertifikat schicken und dachte mir folgende Lösung:

1. Zertifikat noch in der alten Konfiguration exportieren
2. Zertifikat in die neue Konfiguration importieren (hat geklappt, Status war gültig)
3. neue Konfiguration mit importiertem Zertifikat abspeichern.
4. SP neu booten

Leider war das Zertifikat danach nicht mehr vorhanden. Alle anderen Änderungen aber schon.

5. Ich habe das Zertifikat nochmal importiert.

Das hat zwar geklappt, aber nun war das Zertifikat "revoked"!

Nun die Frage, die vielleicht auch für jemand interessant ist, der aus Versehen
eine Zertifikat Löschung rückgängig machen will:

Wie bekomme ich das/ein Zertifikat im Bereich "revoked" wieder gültig?

Danke!

[Erik]

1. root-User erstellen und damit auf der Konsole einloggen
2.

Code: Alles auswählen

# sqlite3 /tmp/running.db
sqlite3> .mode columns
sqlite3> .header on
sqlite3>  select x509_id, x509_name, x509_status from x509;
x509_id     x509_name   x509_status
----------  ----------  -----------
1           erikCA
2           ovServer
4           testbla     1
5           ovClient_e

das ungültige Zertifikat hat unter x509_status eine "1" stehen. Machen Sie daraus wie folgt eine "0" und alles ist gut:

Code: Alles auswählen

sqlite3> update x509 set x509_status = 0 where x509_id = 4

die "4" ersetzen sie durch die ID aus der ersten Spalte

[anselm]

Danke!

Aber das klappt bei mir nicht.

Zuerst für alle, wie mich, die nicht mit sqlite3 arbeiten und das diesen Tipp auch mal brauchen:
Im letzten Komando fehlt der ';'
Also lautet das Ende:

sqlite3> update x509 set x509_status = 0 where x509_id = 4;
sqlite3> .exit

Danach hat der Entry (hier 126) zwar als Status eine 0, aber er ist der einzige:
...........
sqlite3> select x509_id, x509_name, x509_status from x509;
...........
121 ovClient_XY
123 ovClient_XZ 1
124 ovClient_XX
126 ovClient_AA 0

Und vor allem: Das Zertifikat ist immer noch revoked!

Muss danach noch irgendwas gemacht werden?

save..... load...... reboot..... ????

[Erik]

Und das Zertifikat hatte vor dem update-Befehl auch wirklich eine "1" bei "x509_status" stehen? Wenn nicht, ist es aus einem anderen Grund ungültig...
Was steht denn im Revoked-Tab in der letzten Spalte? "REVOKED"? "EXPIRED"? "NOT YET VALID"?

[anselm]

Entschuldigung! Habe ich vergessen.

Das Zertifikat hatte vorher keine 1.
Ich habe nur gedacht: Schaden kann es ja nicht, es auf 0 zu setzen.

Hier die kopierte Zeile aus dem Revoked Tab im Web-Interface:

ovClient_AA User / Server 08/12/2014 21:59:59 XYZ_CA REVOKED

Die zugehörige CA ist noch bis 2018 gültig!

Vielleicht hilft der Hinweis: Importiert wurde beide Male mit dem Security Manager und nicht mit der Web-Oberfläche.

[Erik]

Sie haben da noch ein REVOKEDes Zertifikat (ovClient_XZ) in der Datenbank. Sollte Ihr neues Zertifikat jetzt beim Import die gleiche Seriennummer erhalten haben (passiert gern beim Update von 2006 auf 2007 bzw 2007 auf 2010), sind automagisch beide ungültig.

Sichern Sie ihre Config mal und führen dann in der sqlite-Shell aus:

Code: Alles auswählen

sqlite3> delete from x509 where x509_status = 1;

Dadurch wird natürlich das (gewollt) ungültige Zertifikat ebenfalls wieder gültig...

[anselm]

Habe ich gemacht!
Soweit so schlecht.
Mir war schon klar, daß dann alle "revoked" Zertifikate gelöscht sind und somit
dauerhaft gültig und nie mehr "revoke"-bar, da sie nie wieder in einer CRL auftauchen.
Ich habe deshalb vorher alle Zertifikate (revoked oder nicht) als pem exportiert.
Die Idee:
Ich importiere alle "revoked" Zertifikate wieder.
Die sind dann wieder vorhanden und damit auch revoke-bar.
Aber nach dem ersten solchen Reimport ist mir der Kern des Problems klar geworden.
Jeder Import rouiniert einem die ganze Zertifikatverwaltung.
Denn dem importierten Zertifikat wird nicht diesselbe/ursprüngliche Nummer zugewiesen, sondern
eine (irgendwie, mir jetzt nicht nachvollziehbar generierte) neue Nummer.
Und zwar in meinem Fall (immer?) eine bereits vorhandene Nummer.
Wenn ich dieses eigentlic gemeinte Zertifikat jetzt revoke, ist nur das bereits vorher vorhandene Zertifikat ungültig. Haha.
Auch das ursprünglich importierte Zertifikat (als Auslöser dieses Topic) bekam eine bereits vorhandene Nummer eines "revoked"-en Zertifikates und war deshalb ungültig!
Die CRL definiert nach meinem Wissen aber den Status gültig oder ungültig nach der Nummer.
Wenn die Nummer aber (nach einem Import) nicht mehr zum ursprünglichen Zertifikat passt, ist alles im Eimer.
Ein exportiertes und einem Client/User zur Verfügung gestelltes Zertifikat hat
ja immer die Nummer zum Zeitpunkt des Exports.
In einem "Standard"-Linux System könnte ich jetzt vielleicht im openssl-System
mit dem Editor reparierend bei den Nummern eingreifen.
Im Securepoint System nicht, da es Datenbank basierend ist.

Aber jetzt nochmal der Kern des Problems (als Frage formuliert):

Eigentlich müßte man das Importieren eines Zertikates unmöglich machen
oder zumindest dringend davor warnen?

Möglicherweise wird das auch noch durch den Umstand verschärft, daß
bei jedem Import auch noch eine CRL in der Zertliste auftaucht, die ebenfalls eine bereits
vorhandene Nummer bekommt. Aber das kann auch völlig unkritisch sein.
Ich bin vielleicht jetzt nur überkritisch.

PS: Aber ja, der Tip mit dem delete hat natürlich auch das Zertifikat wieder gültig gemacht.

Bin gespannt auf die Lösung.