Personen-Zertifikat importieren funktioniert nicht

  • Um Rückfragen vorzubeugen, bitten wir um folgende Angaben:
    * Thunderbird-Version: 31.6.0
    * Betriebssystem + Version: Windows 8.1 / Windows Server 2012 R2
    * Kontenart (POP / IMAP): POP
    * Postfachanbieter (z.B. GMX): GMX
    * S/MIME oder PGP: S/MIME
    * Eingesetzte Antivirensoftware: Avast! FREE ANTIVIRUS
    * Firewall (Betriebssystem-intern/Externe Software): Windows Firewall (und die NAT-Firewall natürlich)


    Hallo,


    und danke schon mal für die ausführlichen Informationen hier im Forum. Ich hoffe, dass die bei meiner anfrage ähnlich ausfallen, insbesondere von Peter_Lehmann. ;)


    ich beschäftige mich aktuell mit E-Mail-Verschlüsselung, da ich mit zwei Freunden verschlüsselt E-Mails austauschen möchte. Es geht also um keinen professionellen Einsatz.


    Kurz mein Kenntnisstand:

    • Ich weiß, was symmetrische und asymmetrische Verschlüsselungsverfahren sind.
    • Daher kenne ich auch den Unterschied zwischen dem öffentlichen und privaten Schlüssel.
    • Ich weiß, was eine Signatur ist und wie mit den genannten Verschlüsselungsverfahren signiert und verschlüsselt wird.
    • Ich weiß, was Zertifikat und Zertifikatsketten sind.
    • Mit Zertifikatsattributen kenne ich mich nicht besonders gut aus, insbesondere nicht mit den erweiterten.


    Wir haben zuhause eine Zertifizierungsstelle unter Windows Server 2012 R2. Um die Vertrauensstellung einfach zu gestalten (und weil ich es kann :mrgreen: ), habe ich bei meinen Freunden auf dem Rechner einen CSR mit openssl erstellt, damit der private Schlüssel nie den Zielrechner verlässt, und diesen anschließend in der Zertifizierungsstelle eingereicht. Dort habe ich eine Zertifikatsvorlage für sichere E-Mail erstellt. Das Zertifikat haben meine Freunde erhalten und anschließend mittels openssl daraus ein p12-Zertifikat erstellt.


    Zum Versand haben meine Freunde zunächst Windows Live Mail 2012 verwendet und ich nutze Outlook 2010. Da aber Live Mail ständig die digitalen IDs der Kontakte vergisst oder nicht mehr lesen kann und ich dazu nichts gefunden habe, wollte ich mal einen anderen Client ausprobieren und habe mich Thunderbird zugewandt, was längst überfällig war.


    Also habe ich in Thunderbird die Zertifikate der Root CA und der ausstellenden Sub CA als Zertifizierungsstellen installiert. Auch das p12-Zertifikat (mit dem privaten Schlüssel) ließ sich einfach installieren. Dann wollte ich die Personenzertifikate hinzufügen, was aber an der angehängten Meldung scheiterte. Das Zertifikat lässt sich allerdings als Server-Zertifikat importieren. Also habe ich mir eine signierte E-Mail zugeschickt, in der Hoffnung, ich könnte hierüber das Zertifikat importieren oder bekäme wenigstens weiteren Aufschluss. Aber auch hier wird die Gültigkeit bemängelt, wie der zweite Anhang zeigt, den ich aus Datenschutzgründen zensiert habe. Die Meldung bot natürlich einen Hoffnungsschimmer: Vertrauen in den Zertifizierungsstellen nicht gesetzt! Nein, das war leider auch nicht die Lösung. Bei Root und Sub CA sind alle Haken gesetzt.


    Also habe ich mit anderen Zertifikaten versucht den Fehler einzugrenzen. Ich las hier im Forum von XCA. Das habe ich verwendet, um eine Root und eine Sub CA zu erstellen. Anschließend habe ich mein eigenes Zertifikat importiert und daraus eine Vorlage erstellt. Mithilfe dieser Vorlage habe ich anschließend ein Zertifikat signiert, das fast identische Attribute wie mein ursprüngliches hat. Aber dieses lässt sich importieren. (Natürlich erst nach dem Import der Root und der Sub CA meines Tests.) Einen Unterschied konnte ich nur in zwei Attribut Sperrlisten-Verteilungspunkte feststellen:


    Beim ursprünglichen Zertifikat sind zwei URL-Angaben in einem Punkt vorhanden, beim neuen Zertifikat hingegen, sind sie in getrennten Punkten vorhanden. Diese Auswirkung habe ich ausgeschlossen, indem ich ein neues Zertifikat von meiner (echten) Zertifizierungsstelle ausgestellt habe, dass keine Sperrlisteninformationen enthält. Es tritt derselbe Fehler auf. Außerdem ist der Signaturalgorithmus verschieden: Beim alten ist er "RSASSA-PSS" und beim neuen "sha256RSA". Aber irgendwie kann ich mir nicht vorstellen, dass es daran liegt. Auf jeden Fall würde ich dann eine andere Fehlermeldung erwarten.


    Ich habe auch versucht mich dem Problem über die anderen Attribute zu nähern, aber immer hat der Import bei meinem Testzertifikat funktioniert.


    Hat vielleicht jemand hier eine Idee, was ich noch machen könnte?

  • Hallo hat_guy,


    und willkommen im Forum!
    Schön, dass du dir Gedanken um die Wahrung deiner Privatspäre machst!
    Wenn ich mir deinen (dankenswert sehr umfangreichen und aussagefähigen!) Beitrag durchlese, dann kann ich nur feststellen, dass du dich sehr gut informiert und eigentlich auch alles richtig gemacht hast. Der Fehler muss also irgendwo im Detail liegen.


    Ich vermute, dass du in den Attributen der Userzertifikate einen Fehler gemacht hast. Diese Vermutung resultiert daraus, dass du die Benutzerzertifikate nicht unter "Personen", aber dafür unter "Server" installieren kannst. Es sieht so aus, dass in diesen Zertifikaten die falschen capabilities (also SSL-Client oder -Server usw., und nicht alle Optionen für E-Mail = Digital Signature, Key Encipherment, Data Encipherment, und E-mail Protection) eingetragen wurden.
    Was du auch wissen musst ist, dass du bei einem unter "Personen" importierten Userzertifikat nicht noch einmal das Vertrauen aussprechen darfst! Also nur importieren und fertig. Wenn du das Vertrauen einstellst, verschwindet das Zertifikat aus "Personen" und taucht auf einmal unter "Server" auf! Das Vertrauen der Userzertifikate wird automatisch von den als vertrauenswürdig deklarierten Herausgeberzertifikaten geerbt.


    Sollte es dann immer noch nicht funktionieren, kannst du mir gern beide Herausgeber- und die drei Userzertifikate schicken. Ich kann sie mir gern ansehen und finde garantiert evtl. Unregelmäßigkeiten. Es handelt sich ja immer um öffentliche Schlüssel, also problemlos.


    Und noch ein Hinweis:
    Wie ich ja im Forum schon ein paar mal gepostet habe, habe ich innerhalb vieler Jahre mehrere Tausend Nutzerzertifikate für entsprechend viele Leute hergestellt (*). Selbstverständlich biete ich sowohl die "Komplettversorgung" (also auch einschl. der .p12) als auch das Signieren mir zugesandter Zertifikatsrequests an. (Dabei empfehle ich immer die Nutzung von XCA auch bei den Antragstellern! - Es werden keine Fehler produziert, was ja bei openSSL sehr häufig bei Laien passiert!) Fast alle Nutzer wählen die "Komplettversorgung". Woran mag das nur liegen? Und innerhalb drei Freunden oder Bekannten gäbe es da für mich überhaupt keine Frage.
    (*) Ich betreibe dabei einen recht hohen (Sicherheits-)Aufwand.
    Die XCA läuft unter Linux in einem TrueCrypt-Container. Wird dieser gemounted, werden scriptgesteuert sämtliche Netzverbindungen gekappt. Die .p12 und das Transportpasswort werden den Nutzern auf getrennten sicheren Wegen zugestellt. Nach Empfangsbestätigung von den Nutzern und einer Testmail in beiden Richtungen werden die privaten Schlüssel geshreddert. Ich kann also meinen Nutzern garantieren, dass ich nichts mehr "zum Herausgeben" besitze.
    Und selbstverständlich führe ich im beidseits zumutbaren Umfang eine "Identitätsprüfung der antragstellenden Personen" (sinngemäßes Zitat aus SigG §5) durch. Und das, obwohl es sich rechtlich nur um "Class 1-Zertifikate" handelt. Hier tue ich also mehr, als es die Billigheimer bei ihren Kostnixzertifikaten machen! (Selbstverständlich gibt es diese bei mir auch kostenlos. Ich betrachte es als meinen konkreten Beitrag zur Wahrung des Privatsphäre in unserem zunehmend von Überwachung geprägten Land. NOCH dürfen wir privat verschlüsseln!)



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


    vielen Dank für die schnelle Antwort.


    Das mit dem Truecrypt-Container halte ich für eine gute Idee. Ich habe sogar schon gehört, dass Root CAs auf virtuellen Servern auf externen Laufwerken installiert werden und die Laufwerke anschließend im Tresor landen. Man kann nie paranoid genug sein. :D (Wobei das anerkennend gemeint ist. Man kann ja viel Blödsinn mit einer geklauten CA anstellen). Wir verwenden jedoch zuhause eine Windows Domäne und versuchen immer in neue Bereiche vorzudringen, die sich damit verwalten lassen.


    Aber zurück zum Thema:

    Ich vermute, dass du in den Attributen der Userzertifikate einen Fehler gemacht hast. Diese Vermutung resultiert daraus, dass du die Benutzerzertifikate nicht unter "Personen", aber dafür unter "Server" installieren kannst. Es sieht so aus, dass in diesen Zertifikaten die falschen capabilities (also SSL-Client oder -Server usw., und nicht alle Optionen für E-Mail = Digital Signature, Key Encipherment, Data Encipherment, und E-mail Protection) eingetragen wurden.

    Das ist auch meine Vermutung. Daher habe ich versucht den Fehler durch das ausprobieren verschiedener Attribute zu reproduzieren und kann auch folgendem nur zustimmen:

    Der Fehler muss also irgendwo im Detail liegen.

    Nur sind diese Details leider (noch) nicht meine Stärke. :|


    Was du auch wissen musst ist, dass du bei einem unter "Personen" importierten Userzertifikat nicht noch einmal das Vertrauen aussprechen darfst! Also nur importieren und fertig. Wenn du das Vertrauen einstellst, verschwindet das Zertifikat aus "Personen" und taucht auf einmal unter "Server" auf! Das Vertrauen der Userzertifikate wird automatisch von den als vertrauenswürdig deklarierten Herausgeberzertifikaten geerbt.

    Ich wünschte, ich wäre so weit gekommen, diesen Fehler machen zu können. Aber leider ist der Import an sich gescheitert. Aber das ist schon mal gut zu wissen, für die Zeit, wenn es funktioniert.


    Da ich jemand bin, der nicht viel Zeit für Foren hat, möchte ich diesen Fall öffentlich für die Nachwelt dokumentieren. Daher folgen nun die XCA Konfigurationen der verschiedenen Zertifikate (Details des Zertifikates anzeigen >> Erweiterungen >> Konfiguration anzeigen), die ich wieder aus Datenschutzgründen zensiert habe. Überall dort wo das geschehen ist, wurde der Text durch ein Tag in "spitzen Klammern" (<>) ersetzt.


    Ich habe mich für diese Darstellungsform entschieden, da ich festgestellt habe, dass es bei den meisten Programmen am einfachsten ist, wenn man eine schöne Key-Value-Tabelle der Konfiguration hat, um Fehler zu finden. Insbesondere war "Linux" in deinem Beitrag da ein Schlüsselwort für mich. ;) Da das jedoch nicht immer gilt - es kommt ja immer darauf an, was man gewohnt und wie das Programm ist - zögere bitte nicht, mich um eine andere Darstellungsform zu bitten. Ich persönlich finde da immer die Windows-Zertifikatsdarstellung gut, da sie sehr sprechend ist.



    Windows Zertifizierungsstelle


    Root CA (Windows Zertifizierungsstelle):

    Code
    1. MsCaV=DER:02:01:00
    2. subjectKeyIdentifier=hash
    3. basicConstraints=critical,CA:TRUE
    4. keyUsage=digitalSignature, keyCertSign, cRLSign

    Sub CA (Windows Zertifizierungsstelle):


    E-Mail-Zertifikat (Windows Zertifizierungsstelle):


    Der Signaturalgorithmus ist bei der Windows Zertifizierungsstelle jeweils rsassaPss.



    XCA


    Root CA Test (XCA):

    Code
    1. basicConstraints=CA:TRUE


    Sub CA Test (XCA):

    Code
    1. nsComment=xca certificate
    2. nsCertType=sslCA, emailCA, objCA
    3. keyUsage=keyCertSign, cRLSign
    4. subjectKeyIdentifier=hash
    5. basicConstraints=critical,CA:TRUE


    E-Mail-Zertifikat (XCA):


    Der Signaturalgorithmus ist bei XCA jeweils sha256WithRSAEncryption.



    S/MIME-Attribute


    Die "SMIME-CAPS" müssten aufgelöst folgendes ergeben (so findet es sich in der schon erwähnten Windows-Zertifikatsdarstellung:

    Code
    1. [1]SMIME-Funktion
    2. Objekt-ID=1.2.840.113549.3.2
    3. Parameter=02 02 00 80
    4. [2]SMIME-Funktion
    5. Objekt-ID=1.2.840.113549.3.4
    6. Parameter=02 02 00 80
    7. [3]SMIME-Funktion
    8. Objekt-ID=1.3.14.3.2.7
    9. [4]SMIME-Funktion
    10. Objekt-ID=1.2.840.113549.3.7


    Mit Gruß,
    hat_guy