Beiträge von annotationshacker

Hallo Peter,

nachdem ich die Absendeadresse auf die verwendete Adresse im Zertifikat geändert habe klapp's endlich

Das Problem liegt wohl in meiner CA ...
Nochmals zum Verständnis, wir reden IMMER nur von x509v3 Zertifikaten.
Wenn ich mir das von Trustcenter mir ausgestellte Zertifikat und das von meiner openssl CA ansehe, sehe ich schon einige Unterschiede.

Das kann 2 Gründe haben
a) erstelle ich mein keypair und den CertReq mit dem (Java) keytool. Das hat den Hintergrund, das meine Anwendung aus der ich die signierten Mails sende hat eine JavaAnwendung ist ...
b) das meine openssl CA ev. falsch konfiguriert ist

Hier mal ein prominenter Unterschied, der Subject

trustcenter zertifikat:
subject=/C=DE/CN=\x00M\x00a\x00t\x00h\x00i\x00a\x00s\x00 \x00L\x00\xF6\x00s\x00c\x00h\x00e/emailAddress=adresse@provider.domain

OpensslCA Zertifikat (Req. erstellt mit keytool)
Subject: C=de, ST=irgendwo, O=irgendwas, OU=abteilung, CN=name
Dort wurde ich nicht nach irgendeiner EMailadresse gefragt ...

Hast Du eine Idee wo das Problem liegt, in der CA oder im CertReq generiert via keytool ? Sollte so ein CertReq egal mit welchem Tool generiert nicht immer gleich sein ?

Warum openssl, ja eigentlich schon um die Zusammenhänge zu verstehen und nicht nur zu klicken, aber hier stehe ich wieder vor einem Problem, wo ich nicht so richtig weiterweiß ...
Ich werde mal dieses GUI versuchen ..
--
Noch was: Du kannst selbstverständlich mit deinem vom TC HH erzeugten Mailzertifikat kein selbst hergestelltes Zertifikat signieren. Das geht natürlich nur, wenn du dir ein entsprechendes root-Z. hast machen lassen (das hättest du aber an deinem Kontostand gemerkt. Ganz sicher ...) Das Z. vom TC HH ist lediglich zum Mailen zu benutzen.
---
Das man mit einem verifizierten PublicKey=Zertifikat keine anderen PublicKeys verifizieren kann (und damit CA spielt) ist schon klar.

Gruß
Mathias

Hallo,

das ist Learning by Doing ! Wenn ich das Zertifikat meines pubKeys mitgebe, so erkennt der TB das die Unterschrift gültig ist. Nun ist nur noch das Problem, das die EMail Adresse im Zertifikat des Unterzeichners nicht mit der Adresse übereinstimmt, von wo aus die Mail gesendet wurde. Das läßt sich beheben ...

Mathias

Hallo,

ich habe nun eine SMIME Mail erstellt, in welcher die Signatur mit meinem privKey und dem Zertifikat, welches ich von Trustcenter erhalten habe, generiert wurde. Ich habe die Einstellungen des root(Class1)Zertifikates im TB nochmals überprüft. Ich habe das Vertrauen ausgesprochen, das diese Zertifizierungsstelle Mailbenutzer identifizieren darf. Trotzdem wird nach wie vor behauptet, das ich der Zertifizierungsstelle für diese Art von Zertifikaten nicht vertraue :cry:

Muss man das Zertifikat der CA, mit welcher mein PublicKey verifiziert wurde, der Signatur (d.h. damit der Mail) mit anhängen ? Ich habe eine solche Option im Quellcode gefunden, weiß aber bis jetzt noch nicht so genau wozu das gut sein soll ...

Hat jemand eine guten Link zur allgemeinen Beschreibung Signatur mit SMIME ?

Mathias

Hallo Peter,

zu1 ) Danke für diese Information. Ich hatte schon am Zusammenhang zwischen Ursache und Wirkung gezweifelt ...

zu2) ich habe beides versucht.
a) das Zertifikat einer via openssl selbsterstellten CA und b) das von http://www.trustcenter.de zu importieren. Der Import an sich ist kein Problem (Einstellungen->Datenschutz->Zertifikate->Zertifizierungsstellen). Wenn ich jedoch via 'Bearbeiten' dieser CA alle möglichen (u.a. diese Zertifizierungsstelle kann einen Mail Benutzer identifizieren) Vetrauensmöglichkeiten gebe, so wird unter -> Ansicht u.a. nicht 'verifiziert für E-Mail-Unterzeichner-Zertifikat' angezeigt, was allerdings bei allen Build-In Zertifizierungsstellen so ist. Ist das so in Ordnung oder ist diese Eigenschaft bei der Generierung einer CA zu konfigurieren ? Bei openssl ist mir dazu allerdings nichts aufgefallen ...

Eine Mail mit einer Signatur, welche mit meinem von Trustcenter verifizierten Zertifikat erstelle wurde, habe ich aus meiner Anwendung heraus noch nicht generiert. Das werde ich heute mal versuchen ...

---
Du weißt aber schon, dass ein importiertes Root-Zertifikat (auch "Vertrauensanker" genannt) lediglich das Vertrauen in Zertifikate ausspricht, welche von genau dieser root zertifiziert wurden?
---
Das ist schon klar

Erstmal vielen Dank für die Information zu 1).

Gruß
Mathias

Hallo,

nach etwas herumprobieren habe ich wohl (einen) möglichen Grund gefunden. Der HashAlgorithmus muß bei meinem TB wohl SHA1 sein.

Bei folgendem ContentType wird die Signatur erkannt

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1;

Hat das einen besonderen Grund ?

Wie auch immer, nun möchte ich dem Zertfikat meiner CA das Vertrauen aussprechen, MailBenutzer zu authentifizieren. Trotz dieser gesetzten Option im Zerfifikatsmanager->Zertifizierungsstellen, wird meinem CAZertifikat nicht vertraut.

Hat jemand eine Idee, wieso das so ist ? Gibt es noch andere Möglichkeiten dieses Vertrauen zu konfigurieren ?

Danke !
Mathias

Hallo,

bei meinem TB Version 1.5.0.14pre (20071023) aus Ubuntu 6.10 wird eine via S/MIME signierte Mail unter Ansicht->Nachrichtensicherheit als nicht digital unterschrieben erkannt. Was mich wundert ist, das diese Mail als nicht signiert interpretiert wird (egal ob die Signierung gültig oder nicht gültig ist) , obwohl der Quelltext nun schon den ContentType 'multipart/signed' und als Content-Description: S/MIME Cryptographic Signature enthält. Hat jemand eine Idee woran das liegen könnte ? Ich habe schon das Forum durchsucht, aber nichts passendes gefunden ...

Danke !
Mathias

Der Mailquelltext:
(Die unwichtigen EnvelopeDaten lasse ich mal weg ...)

MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256;
boundary="----=_Part_2_18669924.1193395191632"
Date: Fri, 26 Oct 2007 12:39:51 +0200 (CEST)

------=_Part_2_18669924.1193395191632
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello world!
------=_Part_2_18669924.1193395191632
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Hier ist die Signatur ...

------=_Part_2_18669924.1193395191632--