S/MIME E-Mail-Zertifikate von Personen können nicht importiert werden (eigene CA)

    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.

    Hallo Thomas_123,

    willkommen im Thunderbird-Forum.

    Zum Thema selbst kann ich keine Stellung nehmen, außer der erst einmal zu kontrollieren, ob das Vertrauen ausgesprochen wurde.

    Bedenklich finde ich jedoch, dass Du offenbar diese Zertifikate als Anhang in Form einer ZIP-Datei hier einstellst. Diesen Anhang solltest Du schleunigst aus Datenschutzgründen entfernen.

    Gruß
    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

    Hallo Thomas_123,

    danke für Deine umgehende und entwarnende Rückmeldung. So geht das dann natürlich in Ordnung.

    Gruß
    Feuerdrache

    „Innerhalb der Computergemeinschaft lebt man nach der Grundregel, die Gegenwart sei ein Programmfehler, der in der nächsten Ausgabe behoben sein wird.“
    Clifford Stoll, amerik. Astrophysiker u. Computer-Pionier

    Hallo,
    werden die Dateien denn unter "Zertifizierungsstellen" angenommen?
    Ich hatte vor einigen Wochen mit XCA eigene Zertifikate und Schlüssel erzeugt, aber nie unter "Personen" installieren können.
    Nachdem ich mir aber andere Zertifikate besorgt hatte, war ein Typ dabei, den man unter "Personen" installieren konnte. Der ließ sich aber wiederum aber nicht unter anderen beiden Reitern installieren.
    Auch wenn ich mit XCA erstellte Zertifikate nicht unter "Personen" abspeichern konnte, hat im Endeffekt aber alles also Verschlüsslung und Signierung perfekt funktioniert.
    Sicher wird die Peter_Lehmann eine erschöpfende Antwort geben können.
    Gruß

    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 Thomas,

    ich hab's kurz getestet. In meiner virtuellen xp-Umgebung kann ich die Zertifikate ohne weiteres in den TB importieren. Ich habe in der Kürze der Zeit nicht kontrolliert, welche Attribute Du den Zertifikaten mitgegeben hast, also für welche Verwendungsszwecke Du sie generiert hast.

    Ich habe zum Aussprechen des Vertrauens bei allen dreien das Häkchen gesetzt, und TB hat sie anstandslos akzeptiert.
    Die beiden User-Zertifikate werden danach allerdings nicht unter Personen sondern unter Server angezeigt. Das mag daran liegen, dass Du Allround-Zertifikate erstellt hast und der TB diese dann nur in einer Kategorie anzeigt. Das ist aber nur eine Vermutung. Ich kann es mit eigenen Zertifikaten auch nicht überprüfen, weil ich mir für den Zweck der Kommunikation per E-Mail auch allein darauf beschränkte Zertifikate erstellt habe:

    X509v3 Key Usage:
    Digital Signature, Key Encipherment, Data Encipherment
    Netscape Cert Type:
    SSL Client, S/MIME

    Auf den ersten Blick würde ich daher sagen, dass die Zerts ordnungsgemäß importiert wurden. Bleibt die Frage, weshalb es bei Dir zu einer Fehlermeldung kommt. Ich habe derzeit keine Idee. Mal schauen, ob Peter oder jemand anderes eine hat.

    Gruß

    Susanne

    Hi,

    hiermit stelle ich der Kryptologie-Studentin Susanne eine Note "1" aus.
    Alles richtig erkannt!

    Ich habe Zeile für Zeile die Zertifikate verglichen und die "gute Antwort" ist:
    - es wurde immerhin die richtige root-CA zum Signieren der erzeugten Nutzer-Maschinen-CS-und_sonstwas-Zertifikate verwendet.

    Dass diese beiden nachgeordneten Zertifikate nur als Serverzertifikate akzeptiert wurden liegt IMHO daran, dass dort keine sauberen Attribute vergeben wurden. Ja, als Maschinenzertifikate in irgend einen Server importiert würden diese funktionieren. Aber der TB scheint das zu bemerken und diese nur als Serverzertifikate zu akzeptieren.
    Ich habe bei den Tausenden von Zertifikaten, welche ich im Laufe der Jahre gebaut habe, derartigen Murks noch nicht gemacht (es widerstrebt mir auch das zu testen), so dass ich hier nur diese Ursache vermuten kann. Auf jeden Fall stimmt, wie oben schon geschrieben, der Vertrauensbaum.

    Nun zu meiner Bemerkung "Murks":

    • Ein root-Zertifikat mit einer Laufzeit von 30 Jahren? Und sogar ein "Universalzertifikat" mit 20 Jahren Gültigkeit? Ist das nicht "etwas" übertrieben? Vor allem auch unter Beachtung des folgenden Punktes.
    • Und bei diesen Megalaufzeiten wurde auch noch der uralte und längst nicht mehr zu verwendende Signaturalgorithmus SHA-1 verwendet.
    • Auch 2K-Schlüssel sind nicht unbedingt mehr zu empfehlen (Jeder gängige MUA, selbst der Androide, arbeitet problemlos mit SHA-512 und 4K-Schlüsseln!)
    • Client-Zertifikate mit dem Attribut zur Zertifikats-Signatur? Sollen diese Zertifikate etwa auch noch CA spielen dürfen? Andererseits hast du dieses wieder in den Basiseinschränkungen drin.
    • Code-Signing, SSL-Client, Objektunterzeichner und auch noch S/MIME? Mehr haben wir nicht zu bieten?


    Also Thomas, es ist sehr gut, dass du dich mit dem Thema der Erzeugung von X.509-Zertifikaten und der Mailverschlüsselung überhaupt befasst. (Ich will Optimismus verbreiten und hoffe mal, dass du das alles zum Laufen bringst, bevor unsere Großkopferten uns die private Verschlüsselung verbieten).

    Meine Empfehlung:
    Vergiss openSSL (auch wenn dieses immer im Hintergrund werkelt), und schau dir eine komfortable GUI wie XCA an. Dieses Programm gibt es für Linux und auch für die WinDOSe. Mit diesem Programm kannst du sehr schön Templates zusammenstellen, mit deren Anwendung du dann immer perfekte Einstellungen für das Erzeugen der Zertifikate hast.


    MfG Peter

    Thunderbird 45.8.x, Lightning 4.7.x, openSUSE Tumbleweed, 64bit
    S/MIME, denn ich will bestimmen, wer meine Mails lesen kann.
    Nebenbei: die Benutzung der (erweiterten) Suche, und von Hilfe & Lexikon ist völlig kostenlos - und keinesfalls umsonst!
    Und: Ich mag kein ToFu und kein HTML in E-Mails!

    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:

    Code
    $ 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:

    Code
    # 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!?