Zertifikats-Problem bei Mail-Abruf über TLS

**sanyok**

Zitat von mse

Meine Situation unter XP SP3 und v5.0.18.2:

Ich glaube, ich habe eine ähnliche bzw. sogar die exakte Situation unter v5.0 beobachtet. Kannst du es kurz mit v4.2 testen?

Edit:
Ich habe verstanden, woran das liegt.

Wenn man über das Hauptmenü "Optionen | S/MIME und TLS..." -> "Interne Implementierung" wählt, dann bekommt man im Adressbuch nur die interne Zertifikatsdatenbank zu sehen, im Menü "Ansicht" wird also nur der Befehl "Zertifikatsdatenbanken" bzw. auf Englisch "Certificate Address Books" angezeigt.

Stellt man hingegen "Microsoft Crypto API" als S/MIME Engine ein, bekommt man im Adressbuch im Menü "Ansicht" nur den Befehl "Windows-Zertifikate speichern..." bzw. auf Englisch "Windows Certificate Store" zu sehen.

Es gilt also die "entweder-oder" Regel, nur dass diese in v5.0 nicht richtig zu funktionieren scheint, denn dort bekommt man zunächst beide Befehle zu sehen. Hier ist der entsprechende BT-Thread dazu: #0008672: "Windows Certificate Store" menu item disappears.

Edit #2:
Wie es scheint, besteht dieses Problem bereits seit v5.0.0.132 Beta: #0008369: Address Book : Menu entry "Windows Certificate Store" is enabled, even Internal SMIME is selected.

avoelp

... jou, damit wäre wohl jetzt klar, weshalb sich die Menues unterscheiden.

Zu meiner Frage, wie es sein kann, dass in dem Zertifikat der Uni Frankfurt anstatt der darin enthaltenen Verweise auf drei Hosts nur einer in TB erkannt wird, hat mir der HRZ Support inzwischen noch folgendes geschrieben:

Zitat
wie der in Textform angehängten Version das Uni-Zertifikates zu entnehmen ist enthält dieses im Abschnitt "X509v3 extensions" neben dem Eintrag für "thot.rz.uni-frankfurt.de" ebenfalls Einträge für "imap.server.uni-frankfurt.de", sowie für "popmail.server.uni-frankfurt.de".
Hier das Zertifikat in (gekürzter) Textform:
Code
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 302273121 (0x12045261)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=Hessen, L=Frankfurt am Main, O=Johann Wolfgang Goethe-Universitaet, CN=UNI-FFM CA/emailAddress=ca@uni-frankfurt.de
        Validity
            Not Before: May 31 11:45:22 2011 GMT
            Not After : May 29 11:45:22 2016 GMT
        Subject: C=DE, ST=Hessen, L=Frankfurt am Main, O=Johann Wolfgang Goethe-Universitaet, OU=Hochschulrechenzentrum, CN=thot.rz.uni-frankfurt.de
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:dc:fb:c6:9e:e4:49:87:45:82:07:09:67:28:c2:
                    ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication
            X509v3 Subject Key Identifier: 
                D6:C3:E6:45:B9:31:C8:1C:F4:9C:58:8A:77:5C:3C:27:92:83:0F:0E
            X509v3 Authority Key Identifier: 
                keyid:63:59:77:B1:46:6F:E1:E6:AB:AF:C2:C7:93:FF:5F:71:0D:4F:E0:FF


            X509v3 Subject Alternative Name: 
                DNS:thot.rz.uni-frankfurt.de, DNS:imap.server.uni-frankfurt.de, DNS:popmail.server.uni-frankfurt.de
            X509v3 CRL Distribution Points: 


                Full Name:
                  URI:[url]http://cdp1.pca.dfn.de/uni-frankfurt-ca/pub/crl/cacrl.crl[/url]


                Full Name:
                  URI:[url]http://cdp2.pca.dfn.de/uni-frankfurt-ca/pub/crl/cacrl.crl[/url]


            Authority Information Access: 
                CA Issuers - URI:[url]http://cdp1.pca.dfn.de/uni-frankfurt-ca/pub/cacert/cacert.crt[/url]
                CA Issuers - URI:[url]http://cdp2.pca.dfn.de/uni-frankfurt-ca/pub/cacert/cacert.crt[/url]


    Signature Algorithm: sha1WithRSAEncryption
        14:b7:1a:02:83:1c:e0:c0:4d:b1:07:69:df:78:2c:08:41:ce:
         ...
Alles anzeigen
Somit dürfte die Weigerung des von Ihnen eingesetzten Mail-Clients vermutlich daran liegen, dass dieser die in in RFC 5280 Sektion 4.2. (http://tools.ietf.org/html/rfc5280#page-26) spezifizierten Erweiterungen der aktuellen Version 3 des X.509 Standards garnicht, oder zumindest nicht vollständig unterstützt.
Nähere Informationen zu der genannten Erweiterung "X509v3 Subject Alternative Name" sollten Sie ebenfalls in oben genanntem Standard finden können.
(http://tools.ietf.org/html/rfc5280#page-35)

Da er allem Anschein nach nicht der Forderung (sektion 4.2. Ende):
"At a minimum, applications conforming to this profile MUST recognize the following extensions: key usage (Section 4.2.1.3), certificate policies (Section 4.2.1.4), subject alternative name (Section 4.2.1.6), basic constraints (Section 4.2.1.9), name constraints (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 4.2.1.14)."
nachkommt die genanntenErweiterung korrekt zu verarbeiten scheint es in Ihrem Falle keine keine schlechte Idee zu sein den Hersteller des von Ihnen eingesetzten Mail-Clients darauf hinzuweisen, dass dieser die Anforderungen des aktuellen Standards nicht erfüllt und eine Behebung des Problems einzufordern.
Alles anzeigen

Was haltet ihr davon?

**sanyok**

Zitat von avoelp

... jou, damit wäre wohl jetzt klar, weshalb sich die Menues unterscheiden.

Hast du das Zertifikat jetzt auch in die TB!-Zertifikatsdatenbank importiert (vgl. oben)?

avoelp

Zitat von sanyok

Hast du das Zertifikat jetzt auch in die TB!-Zertifikatsdatenbank importiert?

Gestern Abend noch nicht - jetzt aber schon, wie von dir hier beschrieben. Ergebnis:

Unter Certificate steht auf dem Tab "General" die frohe Botschabt "The Bat! can use this certificate for message encryption - no, verifying digital signature of a message - no, TLS connections - no"
Auf dem Tab "Details" steht beim Subject Alternative Name nur "ca@uni-frankfurt.de"
Aber - und das ist wohl das Wichtigste: Nach dem Import der Zertifikate in die TB-interne Datenbank sind beim Mail-Abruf im Log endlich alle drei Host-Namen zu sehen und das Ganze funktioniert jetzt auch mit dem "amtlichen" Host popmail.server.uni-frankfurt.de

Das verstehe, wer mag ... Und es ist dann wohl auch nicht ausreichend, die Zertifikate in die Windows Zertifikats-DB zu importieren.

**sanyok**

Zitat von avoelp

Unter Certificate steht auf dem Tab "General" die frohe Botschabt "The Bat! can use this certificate for message encryption - no, verifying digital signature of a message - no, TLS connections - no"

Bei mir stand "TLS connections - yes". Funktioniert denn die TLS-Verbindung bei dir trotzdem?

Zitat von avoelp

Auf dem Tab "Details" steht beim Subject Alternative Name nur "ca@uni-frankfurt.de"[/b]

Bei mir waren unter "Details | Subject Alternative Name" alle drei Server aufgelistet. Ich habe aber das Zertifikat ausschließlich in die TB!-Zertifikatsdatenbank importiert. Die windowseigene war davon verschont. Vielleicht weil du es hier und dort hast, gibt es Überschneidungen o.ä. Wenn jetzt aber alles wieder funktioniert, dann ist die Sache zumindest bis auf Weiteres erledigt.

avoelp

Zitat von sanyok

Bei mir stand "TLS connections - yes". Funktioniert denn die TLS-Verbindung bei dir trotzdem?

... ja, funktioniert trotzdem.

**GwenDragon**

Du kannst dann die von dir in die WIndows-Datenbank importierten ja wieder löschen, wenn die im TheBat-Adressbuch ausreichen zur Herstellung einer sicheren Verbindung.