Probleme beim Import von Zertifikaten in Thunderbird

[Alf72]

Hallo zusammen,

ich hoffe mir kann hier jemand weiterhelfen... ich habe leider keine Ideen mehr

Ich habe mir eine eigene CA und einige Zertifikate erstellt (mit TinyCA2/openssl).
Die erstellten Zertifikate wollte ich nun in Thunderbird importieren.

Nun kommt das Kuriose...
Das CA Zertifikat und einige "Benutzer" Zertifikate (Schlüssel) ließen sich problemlos importieren und auch verwenden.
Manche der erstellten Zertifikate lassen sich nicht importieren... folgende Meldung erscheint:
"Die PKCS#12-Operation ist aus unbekannten Gründen fehlgeschlagen."

Erst dachte ich, es läge irgendwie am "Inhalt" der Zertifikate. Daher habe ich 2 bis auf die EMail Adresse identische Zertifikate erstellt (test1@... und test2@...). Bei beiden habe ich die gleichen Kennwörter gesetzt. Das eine läßt sich importieren, das andere nicht

Ich habe auch den Thunderbird Debug-Mode gestartet (NSPR_LOG_MODULES=all:5)... es gibt aber leider keine Fehlermeldungen zu den Imports.

Habe aus Verzweiflung den Import sogar unter Windows probiert... das gleiche Ergebnis.

Die nicht importierbaren Zertifikate lassen sich mit openssl problemlos anzeigen... die Dateien sind also ok!

Hat jemand noch eine Idee, woran das liegen könnte?

Wenn keines der Zertifikate funktionieren würde, hätte ich auf einen Fehler beim Erstellen getippt.
Aber das manche gehen und manche nicht...

Vielen Dank schon mal...

Gruß Alf

 

[/dev/null]

Hallo Alf,

also ich mache das mit der Mailverschlüsselung per S/MIME schon fast 10 Jahre und ich betreibe auch fast so lange eine eigene "kleine" CA mit welcher ich schon rund 1.500 Zertifikate für diverse Leute hergestellt habe - aber diese Fehlermeldung hatte ich wirklich noch nie.
Und da ich auch fast ebenso lange der für Verschlüsselung und el. Signatur "zuständige" Moderator im Thunderbird-Forum bin kann ich auch sagen, dass mir eine derartige Fehlermeldung nicht bekannt ist (bzw. ich kann mich an eine solche nicht erinnern, was mir altersmäßig auch zusteht ;-)).

Also was tun?
Ich würde zuerst einmal bei beendetem Thunderbird das vorhandene TB-Nutzerprofil durch Umbenennen von ~/.thunderbird "verstecken". Dann den TB neu starten und der Auforderung zur Erstellung eines neuen Profils nachkommen. Passieren kann nix, du kannst das ja jederzeit zurücknehmen. Oder du nutzt den Profilmanager und erstellst dir ein Testprofil (was auch sonst sehr zu empfehlen ist).
Jetzt hat du ein ganz frisches Profil und kannst damit die Problemzertifikate testen.

Als weiteres biete ich dir an, mir dein CA-Zertifilat und deine "Problemschlüsseldateien" zu schicken. Da sie eh nicht funktionieren, sind sie ja so wie so "Schrott". Ich kann mich gern damit beschäftigen. Per PN können wir ja die Modalitäten austauschen.
Ich kann dir auch anbieten, einen Request von dir mal zu zertifizieren. Sozusagen die Problemfälle als Test über meine CA laufen zu lassen. Du kannst dann versuchen, die bei dir wieder zusammengefügten Schlüsseldateien zu importieren.

Egal was und wie, irgendwie werden wir die Klemmstelle schon finden.

BTW: Ich bin sehr schnell von TinyCA weg und bei "XCA" gelandet. Das ist ein fast professionell daherkommendes Programm (ich kann das vergleichen!), und dieses Programm bietet vor allem die Möglichkeit, Templates für alle Einsatzfälle anzulegen. So habe ich mir Vorlagen für die jeweiligen Jahres-CA (jedes Jahr eine neue!), für S/MIME-Nutzer, für diverse SSL-Zertifikate (VPN, sonstige Server) usw. angelegt. Und mit diesen Vorlagen passieren auch garantiert keine Pannen.
Aber, das ist nur ein Vorschlag.

MfG Peter

 

[Alf72]

Hallo Peter,

das klingt doch gut... vielen Dank für die angebotene Unterstützung!

Ich werde noch einmal mit einem neuen Profil und auch mit XCA probieren.
Das mit dem Profil wollte ich durch meinen Test unter Windows (natürlich mit einem anderen Profil) testen. Da dies jedoch auch schief gegangen ist würde ich vermuten, dass es daran nicht liegt. Werde es aber trotzdem probieren.

Falls ich wirklich keine Lösung finde, würde ich gerne auf Dein Angebot zurückkommen und Dir ein Problemzertifikat zuschicken. Da ja alles nur "für mich" ist, gibt's da auch keine "Sicherheitsprobleme"

Gibt es XCA eigentlich als Binaries oder nur die Source-Variante?
Habe aktuell keine Binaries gefunden (außer für Windows).
Oder läuft XCA auch unter wine?
Ansonsten könnte ich natürlich auch kompilieren oder unter Windows installieren... aber wäre eben aufwendiger

Die Fehlermeldung selbst ist aber eigentlich bekannt... zumindest Google kennt sie. Allerdings passt das alles nicht zu meinem Problem

Gruß Alf

 

[Alf72]

Ok... ist wirklich kurios...

Ich habe nun 3 Testzertifikate erstellt. Die ersten 2 ließen sich importieren, das letzte nicht.
Dann ein neues Profil angelegt... alle 3 ließen sich importieren.
Danach habe ich das 3. Zertifikat noch einmal mit dem ersten Profil versucht... geht immer noch nicht.

Gleicher Rechner, gleiches OS, gleiche Thunderbird Version und natürlich die selben Zertifikate/Dateien.

Zusätzliche Info:
Ich habe aktuell kein Master Passwort vergeben (in beiden Profilen!)... vielleicht hängt es trotzdem irgendwie damit zusammen?
Bei meinem neuen Profil hatte er mich nach einem gefragt, beim alten Profil nicht... ist das eventuell der Unterschied?

Werde weiter testen... wenn nur die Fehlermeldung etwas aussagekräftiger wäre :/

 

[/dev/null]

Du brauchst ein Masterpasswort!
Denn es kann dir ganz schnell passieren ...
(Aber lese selber, was ich dazu im TB-Forum geschrieben habe)
... Thunderbird verlangt nach Master-Passwort, obwohl keines vergeben wurde

XCA gibt es auch als rpm.
Wie lautet doch gleich die erste Anlaufstelle, wenn man Software für openSUSE sucht, die nicht in den üblichen Repos drin ist ;-)

Es kann auch sein, dass du dir in deinem ersten Profil eine der vier für die Speicherung von Passwörtern, Schlüsseln und Zertifikaten (also den öffentlichen Bestandteilen) verantwortlichen Dateien zerschossen hast. Du kannst diese Dateien löschen (durch Umbenennen verstecken), sie werden als Systemdateien des TB beim nächsten Start neu und leer angelegt. Inhalt (Passwörter) ist natürlich weg.

• cert8.db
  Client Zertifikat-Datenbank. Bei Problemen mit Zertifikaten kann diese Datei gelöscht werden. Sie wird wieder mit der Standardeinstellung erstellt.
• key3.db
  Schlüssel-Datenbank für Zertifikate. Bei Problemen mit Zertifikaten kann diese Datei gelöscht werden. Sie wird vom System danach mit Standardeinstellungen neu erstellt. Zertifikate müssen dann aber auch neu eingebunden werden.
• secmod.db
  Datenbank der Sicherheitsmodule. Löschen, falls es zu Problemen mit Zertifikaten kommt. Danach müssen alle Zertifikate neu erstellt werden; deshalb im gleichen Zug auch cert7/8.db und key3.db löschen.
• signons.txt oder xxxxxxxx.s und ab TB 3.x signons.sqlite
  Enthält die verschlüsselten Passwörter

(Stammt alles aus unserer Anleitung, welche wir gehässigerweise gern vor unseren Nutzern gut verstecken ;-))

MfG Peter

 

[Alf72]

Moin,

danke für die Tipps!

Ich habe schon einige "Nichtstandard" Repos eingebunden... so ist es nicht
Aber z.B. bei packman/links2linux (das ist für mich immer die erste Anlaufstelle) gibt's xca überhaupt nicht und auch unter rpmfind finde ich nur Fedora rpm's (da bin ich dann immer etwas "vorsichtig", da ich schon einmal Probleme mit "fremden" rpm's bekommen hatte).

Welches Repo ist denn das, was Du als erste Anlaufstelle nimmst/meinst?

Die von Dir angesprochenen Dateien kann ich gerne einmal löschen. Aber bei meinem neu angelegten Profil (unter einem anderen User) gab es sie sowieso nicht. Es gab ja noch nicht einmal das ".thunderbird" Verzeichnis
D.h. es war alles "frisch". Daher kann dort der Fehler eigentlich nicht liegen. Zumindest wäre ich niemals auf die Idee gekommen... selbst wenn ich es in Eurer versteckten Anleitung gelesen hätte

Ich habe aktuell eine andere Idee...
Mir scheint, dass beim Importieren mit aktiviertem Masterpassword alles glatt läuft. Wenn man dann das Masterpasswort entfernt gehen manche der nächsten Importe schief... warum auch immer. Bin gerade noch am Testen ob ich eine reproduzierbare Regel dabei finde. Aber es hat scheinbar tatsächlich etwas mit dem Setzen/Entfernen des Masterpasswortes zu tun.

Und noch etwas...
Mir ist bei den ganzen Versuchen auch aufgefallen, dass selbst ohne Masterpasswort KEIN Kennwort beim Signieren einer Mail abgefragt wird!
Die Mail kommt beim Empfänger jedoch signiert an und die Signatur lässt sich ohne Probleme validieren.
Da sollte doch eigentlich eine Abfrage wir beim Mailempfang kommen... oder nicht? Thunderbird scheint den private key OHNE Passwortabfrage zu verwenden. Das würde ich als BUG einschätzen.

Edit:
Ich habe Dir gerade eine PN geschickt... da stehen Details

 

[/dev/null]

Ich habe schon einige "Nichtstandard" Repos eingebunden... so ist es nicht

=> software.opensuse.org in den Browser einhacken und dann ins Suchfenster xca ... .

Die von Dir angesprochenen Dateien kann ich gerne einmal löschen. Aber bei meinem neu angelegten Profil (unter einem anderen User) gab es sie sowieso nicht. Es gab ja noch nicht einmal das ".thunderbird" Verzeichnis

Sobald du erstmalig bei einem user den Thunderbird gestartet hast, wird das Verzeichnis ~/.thunderbird (das so genannte TB-Userprofil) angelegt. Und dort sind die von mir genannten Dateien drin. Definitiv! Selbst wenn du das Einrichten des ersten Mailkontos abwürgst, wird zumindest ein rudimentäres TB-Userprofil angelegt.

D.h. es war alles "frisch". Daher kann dort der Fehler eigentlich nicht liegen. Zumindest wäre ich niemals auf die Idee gekommen... selbst wenn ich es in Eurer versteckten Anleitung gelesen hätte

Hast du sie nun endlich gelesen?
Glaube mir, es erleichters so manches.

Ich habe aktuell eine andere Idee...
Mir scheint, dass beim Importieren mit aktiviertem Masterpassword alles glatt läuft. Wenn man dann das Masterpasswort entfernt

Ich habe dir das Risiko beschrieben, welches dich evtl. erwartet, wenn du ohne Masterpasswort Zertifikate und Schlüssel importierst.
Wo ist dein Problem, mit einem Masterpasswort zu arbeiten? Du willst deine Mails verschlüsseln, und bist zu f***, um deine (richtig guten, unterschiedlichen, 12 bis 16 stelligen kryptischen) Mail-Passwörter mit einem einzigen merkbaren Masterpasswort zu schützen?

Und noch etwas...
Mir ist bei den ganzen Versuchen auch aufgefallen, dass selbst ohne Masterpasswort ....

Sinn hinter dem Masterpasswort immer noch nicht verstanden (Anleitung wohl doch noch nicht gelesen....)
Aus dem Masterpasswort wird der Schlüssel generiert, welcher alle deine Mail-Passwörter, sonstige Konto-Passwörter, evtl. im TB genutzte ftp-, WebDAV- und sonstige Serverzugänge, und auch deine gespeicherten privaten Schlüssel nach dem Beenden des TB automatisch wieder verschlüsselt werden. Das Masterpasswort wird beim Start des TB von dir abgefordert, wenn eine Komponente (in der Regel der erste Server, welcher nach dem PW fragt) die Entschlüsselung der beiden Datenbanken anfordert. Diese Datenbanken bleiben so lange geöffnet, bis du den TB wieder schließt.
Das Master-PW ist also kein Schutz deiner Mails usw., sondern nur der o.g. sensiblen Daten, wenn du den TB beendet hast.
Das Passwort, mit welchem du deine privaten Schlüssel (p12 oder pfx) schützt, ist nur deren Transportschutz. Sobald diese Dateien in den als Passwortmanager etwas schwach bezeichneten kryptologisch gesicherten Speicher des TB importiert wurden, schützt dieser die privaten Schlüssel.

MfG Peter

 

[Alf72]

Mach mal langsam mit den jungen Pferden... sei doch nicht gleich eingeschnappt...

Die von Dir angesprochenen Dateien kann ich gerne einmal löschen. Aber bei meinem neu angelegten Profil (unter einem anderen User) gab es sie sowieso nicht. Es gab ja noch nicht einmal das ".thunderbird" Verzeichnis

Sobald du erstmalig bei einem user den Thunderbird gestartet hast, wird das Verzeichnis ~/.thunderbird (das so genannte TB-Userprofil) angelegt. Und dort sind die von mir genannten Dateien drin. Definitiv! Selbst wenn du das Einrichten des ersten Mailkontos abwürgst, wird zumindest ein rudimentäres TB-Userprofil angelegt.

Ich sagte, dass die Dateien nicht da waren, da ich thunderbird unter diesem Nutzer noch nie genutzt hatte (.thunderbird Verzeichnis war nicht da -> noch nie gestartet). Natürlich werden die nach dem Start angelegt. Aber Du meintest ja ich solle sie löschen um zu testen... und das war ja implizit der Fall. Daher meinte ich ja, dass es nicht daran liegen kann.

Ich habe aktuell eine andere Idee...
Mir scheint, dass beim Importieren mit aktiviertem Masterpassword alles glatt läuft. Wenn man dann das Masterpasswort entfernt

Ich habe dir das Risiko beschrieben, welches dich evtl. erwartet, wenn du ohne Masterpasswort Zertifikate und Schlüssel importierst.
Wo ist dein Problem, mit einem Masterpasswort zu arbeiten? Du willst deine Mails verschlüsseln, und bist zu f***, um deine (richtig guten, unterschiedlichen, 12 bis 16 stelligen kryptischen) Mail-Passwörter mit einem einzigen merkbaren Masterpasswort zu schützen?

Was soll das jetzt? Ich bin nicht zu faul... ich versuche hier den Fehler einzukreisen. Das hat nichts damit zu tun wofür das Masterpasswort da ist.

Und noch etwas...
Mir ist bei den ganzen Versuchen auch aufgefallen, dass selbst ohne Masterpasswort ....

Sinn hinter dem Masterpasswort immer noch nicht verstanden (Anleitung wohl doch noch nicht gelesen....)

Auch das tut nichts zur Sache. Meiner Meinung nach müsste Thunderbird eben das Passwort abfragen, wenn KEIN Masterpasswort gesetzt ist. Mehr habe ich nicht gesagt. Damit habe ich nicht gesagt, dass ein Masterpasswort unnütz ist oder sonst was. Du scheinst das anders zu sehen. Ok... Deine Meinung.

Aus dem Masterpasswort wird der Schlüssel generiert, welcher alle deine Mail-Passwörter, sonstige Konto-Passwörter, evtl. im TB genutzte ftp-, WebDAV- und sonstige Serverzugänge, und auch deine gespeicherten privaten Schlüssel nach dem Beenden des TB automatisch wieder verschlüsselt werden. Das Masterpasswort wird beim Start des TB von dir abgefordert, wenn eine Komponente (in der Regel der erste Server, welcher nach dem PW fragt) die Entschlüsselung der beiden Datenbanken anfordert. Diese Datenbanken bleiben so lange geöffnet, bis du den TB wieder schließt.
Das Master-PW ist also kein Schutz deiner Mails usw., sondern nur der o.g. sensiblen Daten, wenn du den TB beendet hast.
Das Passwort, mit welchem du deine privaten Schlüssel (p12 oder pfx) schützt, ist nur deren Transportschutz. Sobald diese Dateien in den als Passwortmanager etwas schwach bezeichneten kryptologisch gesicherten Speicher des TB importiert wurden, schützt dieser die privaten Schlüssel.

Ich habe ja auch nie gesagt, dass meine Mails damit geschützt werden oder ähnliches.
Wenn ich Thunderbird öffne und eine Mail signiere werde ich ohne gesetztem Masterpasswort trotzdem nicht nach einem Passwort für den privaten Schlüssel gefragt. Thunderbird signiert die Mail trotzdem!!! Das mit dem Mailkennwort war ein Beispiel, wie ich es erwarten würde... nämlich das Thunderbird nach dem Mailkennwort fragt wenn KEIN Masterpasswort gesetzt wurde. Das tut er ja auch. Der private Schlüssel besitzt doch normalerweise einen Passwortschutz. zumindest muss ich ihn bei Verwendung mit openssl angeben. Vorher komme ich nicht dran. Das Thunderbird es ohne tut empfinde ich eben als Fehler.

Ich weiß nicht warum Du Dich jetzt so auf den Schlips getreten fühlst und mich so anmachst.

Aber ok... ich werde dann eben selbst weiter nach der Ursache forschen... Danke für Deine bisherige Unterstützung.

Gruß Alf

 

[/dev/null]

Komm bitte wieder runter.
Selbstverständlich helfe ich dir weiter.
Und dass f*** = faul heißt, hast du verraten ;-)

Bis morgen!

MfG Peter

 

[Alf72]

Ich war nie "oben"... Du scheinst aber ein Problem mit meinen "Beschreibungen" zu haben... ich fand sie eigentlich nicht so missverständlich. Hast Du meinen Beitrag denn komplett gelesen? Die Zitate sind ja leicht "verfremdet".

Aber egal.

Ich habe mir bereits XCA unter Win installiert und werde es damit versuchen... mal schauen ob es damit klappt.

Gruß Alf

 

[Alf72]

Falls es jemandem hilft... hier ein Zwischenbericht...

Ich habe nun mehrere Testzertifikate mit XCA erstellt.
Alle Zertifikate/Keys lassen sich ohne Probleme in Thunderbird importieren.
Vielleicht macht TinyCA2 hier irgendetwas anders?!? Keine Ahnung.
Die mit TinyCA2 erstellten Zertifikate mag TB immer noch nicht.

Dann habe ich versucht eine SubCA mit weiteren Zertifikaten zu erstellen.
Der Import des SubCA Zertifikats hat bei 2 Usern funktioniert... bei weiteren 2 meldet TB, dass er das Zertifikat bereits im Speicher hätte, was aber nicht sein kann, da ich es gerade erst erstellt und auch noch kein von der SubCA signiertes Zertifikat importiert oder empfangen habe
Es taucht auch nicht in der Liste der Serverzertifikate auf und beim Versuch ein damit signiertes Zertifikat zu importieren, bricht er mit der Fehlermeldung ab, dass er es nicht validieren könne... also scheint er es doch nicht "richtig" im Speicher zu haben :???:

Gut... diese Konstellation brauche ich nicht unbedingt... die "normalen" Zertifikate scheinen alle zu funktionieren.
Ist aber trotzdem komisch, warum der Import bei den ersten 2 Usern funktioniert (das SubCA Zertifikat erscheint dort auch in der Serverliste und der Import von Userzertifikaten funktioniert hier problemlos) und bei den nächsten dann nicht mehr. Das Zertifikat lag in allen Fällen auf dem selben (!) USB Stick.

Ich habe auch bei den nicht funktionierenden Usern mal die 4 oben angegebenen Dateien gelöscht, TB neu gestartet und direkt versucht das SubCA Zertifikat zu importieren... leider ohne Erfolg. Er meint trotzdem, dass er es bereits hätte.

 

[/dev/null]

Ich hatte dir angeboten, mir mal deine Schlüsseldateien anzusehen ... .

Zuerst einmal, trenne bitte in deinen Erklärungen sauber zwischen "Zertifikaten" (sie enthalten nur die öffentlichen Schlüssel, also .cer oder .der) und den so genannten "Softtoken" oder auch "Schlüsseldateien" (enthalten die öffentlichen und die privaten Schlüssel, also .p12 oder .pfx).

Du kannst natürlich auch sowohl die Zertifikate als auch die Softtoken und sogar nur die privaten Schlüssel im Format .pem exportieren. Kann der TB auch importieren, aber du siehst nicht gleich, was es ist (nur an der Größe der Datei oder wenn du sie direkt betrachtest.)

Dann empfehle ich dir, die Softtoken als ".p12 mit Zertifikatchain" (oder so ähnlich) zu exportieren. Das bedeutet, dass in der Schlüsseldatei nicht nur das Nutzerzertifiklat + privatem Schlüssel, sondern auch gleich noch sämtliche Herausgeberzertifikate (root- und Sub-CA) in einer Datei zusammen exportiert werden. Wenn du diese dann importierst (unter eigene Z.), dann werden unter Herausgeber diese gleich mit angezeigt, weil ja mit importiert. Allerdings musst du nach dem Import auch dort das Vertrauen einstellen. <= Das ist übrigens etwas, was sehr gern vergessen wird.

 

[Alf72]

Moin,

ich habe unterschieden...

Alle Zertifikate/Keys lassen sich ohne Probleme in Thunderbird importieren.

Die Imports, die nun funktionieren, sind "Zertifikate/Keys"... also öffentlicher UND privater Teil (als PKCS#12).
Vielleicht hätte ich nicht "abkürzen" sollen... ok.

Der Import des SubCA Zertifikats...

Der Import, der nicht funktioniert, ist der des SubCA "Zertifikats"... also der öffentlicher Teil der SubCA (als PEM).

...der Import von Userzertifikaten funktioniert hier problemlos...

Auch hier meinte ich wirklich die Zertifikate der User, die mit der SubCA signiert wurden... also ebenfalls den öffentlichen Teil.

Bei allem, was gerade nicht geht, betrifft es den öffentlichen Teil... also wirklich - wie geschrieben - die Zertifikate!

Ist aber nicht so wild, da ich diese Konstellation nicht unbedingt benötige... war nur ein Test von mir, da ich versuchen wollte den ursprünglichen Fehler einzugrenzen.

Gruß Alf