Beiträge von Thomas_123

Hallo Susanne,
Hallo Peter,

zunächst vielen Dank für eure Kommentare. Den Grund für das beschriebene Verhalten von Thunderbird habe ich gefunden:
Bei "keyUsage" war u.a. auch "keyCertSign" angegeben, was natürlich Unsinn ist. Wenn man das weglässt funktioniert es wie erwartet.

Hier noch ein paar Kommentare zu Peters Anmerkungen:
> Ein root-Zertifikat mit einer Laufzeit von 30 Jahren?
Auch das offizielle "thawte Primary Root CA" Zertifikat besitzt eine Laufzeit von 30 Jahren. Diese Laufzeit an sich ist ja erstmal kein Problem. (siehe Screenshot im Anhang)

> Und sogar ein "Universalzertifikat" mit 20 Jahren Gültigkeit? Ist das nicht "etwas" übertrieben?
Siehe oben. Der Grund für das Verhalten von TB ist jedenfalls nicht die Laufzeit.

> Und bei diesen Megalaufzeiten wurde auch noch der uralte und längst nicht mehr zu verwendende Signaturalgorithmus SHA-1 verwendet.
Falsch. Bei den E-Mail-Zertifikaten (und das ist entscheidend) wurde sha256 verwendet:

$ openssl x509 -noout -text -in foo.barATfoobar.de.crt | grep "Signature Algorithm"
    Signature Algorithm: sha256WithRSAEncryption
    Signature Algorithm: sha256WithRSAEncryption
$ openssl x509 -noout -text -in foo.bar.2ATfoobar.de.crt | grep "Signature Algorithm"
    Signature Algorithm: sha256WithRSAEncryption
    Signature Algorithm: sha256WithRSAEncryption

> Auch 2K-Schlüssel sind nicht unbedingt mehr zu empfehlen
2K-Schlüssel gelten nach wie vor als sicher und werden auch von "gängigen" CA's immer noch als Standard verwendet. Siehe auch https://www.thawte.com/resources/2048-bit-compliance/ "... require that certificates issued after January 1, 2014 MUST be at least 2048-bit key length" (Stand: 11.02.2015)

> Client-Zertifikate mit dem Attribut zur Zertifikats-Signatur?
Richtig. Genau dieses Attribut (keyCertSign) hat hier nichts verloren und hat das "Problem" verursacht.

> Code-Signing, SSL-Client, Objektunterzeichner und auch noch S/MIME? Mehr haben wir nicht zu bieten?
In der standardmäßigen openssl.cnf findet sich:

# For normal client use this is typical
nsCertType = client, email




# and for everything including object signing:
nsCertType = client, email, objsign

Auch hier darf dann eine Person ein Zertifikat für S/MIME, SSL/TLS Web Client Authentication und Code Signing verwenden. Und ich wüsste keinen Grund, weshalb das schlecht sein soll!?

Hallo mrb,

> werden die Dateien denn unter "Zertifizierungsstellen" angenommen?
Wenn ich versuche so ein E-Mail-Zertifikat unter Zertifizierungsstellen hinzuzufügen, dann kommt die Meldung: "Dies ist kein Zertifikat für eine Zertifizierungsstelle und kann deshalb nicht in die Liste der Zertifizierungsstellen importiert werden."

Ist also kein möglicher Workaround für das Problem. Dennoch vielen Dank. Gruß Thomas_123

Hallo Feuerdrache,

vielen Dank für deine Antwort. Die Zertifikate im Anhang enthalten keine vertraulichen Daten sondern wurden von mir eigens zu demonstrationszwecken erstellt.

Gruß,
Thomas_123

Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
* Thunderbird-Version: 31.4.0 (Problem existierte auch schon in Vorgängerversionen seit ca. 2-3 Monaten unter Debian Wheezy. Vorher ging es)
* Betriebssystem + Version: Win7 sowie Debian 7.8
* Kontenart (POP / IMAP): n/a
* Postfachanbieter (z.B. GMX): n/a
* S/MIME oder PGP: S/MIME

Beim Versuch S/MIME E-Mail-Zertifikate von Personen zu importieren erscheint folgender Fehler:
Dieses Zertifikat kann nicht verifiziert werden und wird nicht importiert. Der Aussteller des Zertifikats ist möglicherweise unbekannt oder ihm wird nicht vertraut, das Zertifikat könnte abgelaufen oder widerrufen worden sein, oder es wurde möglicherweise nicht akzeptiert.

Die (eigene) CA habe ich aber hinzugefügt. Siehe auch Screenshots im Anhang.

Zum Testen habe ich eine Test-CA sowie Test-Zertifikate erstellt. Diese sind genauso konfiguriert wie meine "richtigen" Zertifikate. Die Test-Zertifikate habe ich angehängt. Vergleichbare Foren-Einträge haben mir leider nicht weitergeholfen.

Bin für jeden Hinweis dankbar.