Thunderbird16 ignoriert importiertes Stammzertifikat für SSL

Hallo silverado,

und willkommen im Forum! (<= Ja, so viel Zeit nehmen wir uns hier ... .)
Ja, im Prinzip hst du alles richtig gemacht, und dass es bislang immer funktionierte, bestätigt mir das ja auch.
Demzufolge darf ich ja auch davon ausgehen, dass der richtige cn im Zertifikat steht.
(BTW: Ich mache das seit Jahren auch so mit meinem Mail- und FTP-Server ... .)

Hast du das Server-Zertifikat auch mal bewusst händisch unter "Server" importiert?
Die "Ausnahme" bedeutet ja nichts anderes, als dass dort automatisch ein Serverzertifikat hinzugefügt werden soll, aber dafür kein Herausgeberzertifikat vorhanden ist. Etwas, was ich gar nicht mag ... .

Ein Unterschied in der entsprechenden Funktion der beiden TB-Versionen ist mir nicht aufgefallen. Solltest du das ganze wirklich nicht zum Laufen bekommen, empfehle ich dann mal einen Blick in BugZilla.

BTW:
Ich hatte auch schon viele Fälle, wo einfach nur die Serverzertifikate abgelaufen waren. Passiert selbst in großen Firmen ... .

Und als höflicher Mensch verabschiede ich mich auch, deshalb:
MfG Peter

Diesen Effekt kann ich voll bestätigen !
Ich verwende inzwischen TB 16.0.1 und ebenfalls selbst signierte Zertifikate, mit einem eigenen (importierten) CA-Zertifikat. Dieses hat auch im TB 15 noch problemlos funktioniert.

Interessant ist, das die Meldung auch nicht lautet, dass das Zertifikat nicht mit dem Server übereinstimmt, sondern die Meldung kommt:

Unbekannte Identität
Dem Zertifikat wird nicht vertraut, weil es nicht von einer bekannten Authorität unter Verwendung einer sicheren Signatur verifiziert wurde.

Was vielleicht noch interessant ist, dass das CA damals noch mit MD5 erstellt wurde (default_md = md5).
Kann dieses evtl. die Ursache sein ?

Hallo niva,

ich staune, dass da noch jemand md5 benutzt hat ... .
Um das nachzuvollziehen, werde ich mal per openSSL eine CA aufsetzen, welche md5 verwendet. Wird allerdings erst am Wochenende werden. Ich werde dann berichten.
Auf jeden Fall könnte das eine Ursache sein, und mich wundert, dass der TB dann noch so lange md5 unterstützt hat.

Ansonsten kann ich mich nur wiederholen.
Ich habe seit Erscheinen von TB v.16.x 136 Zertifikate ausgestellt und verteilt. Niemand hat sich beschwert ... .
Und ob das Zertifikat selbstsigniert ist oder nicht, spielt überhaupt keine Rolle. Die PCA-1-Verwaltung (im Bundesamt für Sicherheit in der Informationstechnik) verwendet zur Signatur der Zertifikate der einzelnen Verwaltungs-PKI auch ein selbstsigniertes Zertifikat. Irgendwo muss schließlich die oberste Instanz angesiedelt sein ... .

MfG Peter

Ich habe inzwischen auch noch etwas experimentiert und festgestellt, dass es nicht an MD5 liegt. Die Ursache war ein aufgerufener DNS-Name, welcher nicht im Zertifikat (CN bzw. Subject Alternative Name) hinterlegt war. Das Problem war weg, als ich den fehlenden Namen unter Subject Alternative Name hinterlegt habe.

Allerdings ist die Meldung "Dem Zertifikat wird nicht vertraut, weil es nicht von einer bekannten Authorität unter Verwendung einer sicheren Signatur verifiziert wurde." etwas verwirrend.

Übrigens MD5 ist bei der Installation noch ein Überbleibsel einer alten Installation und wird gerade umgestellt...

Danke niva,

ich habe es wegen noch andauernden Besuchs von Verwandten bislang nicht testen können. Nun kann ich es mir sparen
Dass der TB wegen eines fehlenden bzw. falschen DNS-Namen eine Fehlermeldung bringt, betrachte ich eher als Funktionstest der Zertifikatsprüfung. Zugegebenermaßen ist die Fehlermeldung eindeutig falsch. Wird wohl an dem geringen Vorrat der möglichen Fehlermeldungen liegen. (Mal hier: Fehlerberichte und Wünsche nachgesehen oder selbst gemeldet?

MfG Peter

Hallo,

bez. MD5 noch folgende Informationen aus den Release Notes zu TB 16.0:

Quote

No longer supporting MD5 as a hash algorithm in digital signatures (650355)

Danke, Graba,

das wäre ja auch echt ein "Verbrechen", wenn der TB immer noch md5 unterstützen würde. Ich staune, dass das noch bis 15.x so war.

MfG Peter

Quote from "niva"

... Die Ursache war ein aufgerufener DNS-Name, welcher nicht im Zertifikat (CN bzw. Subject Alternative Name) hinterlegt war. Das Problem war weg, als ich den fehlenden Namen unter Subject Alternative Name hinterlegt habe...

Musstest du dazu dann das Stammzertifikat neu erstellen?

Ich habe das Problem nämlich auch und diese Fehlermeldung wird gezeigt:

Was ist hier dann falsch?

Nachtrag: ich habe noch ein bisschen mit einem neuen Profil getestet und tatsächlich, das md5 ist wohl schuld. Wenn ich in der TB config:

security.enable_md5_signatures = true

setze, also umschalte vom Standardwert, dann kommt keine obige Fehlermeldung.
Ich werde also doch eine neue CA machen müssen mit der Einstellung:

default_md = sha1

in der openssl.cfg