ubuntuusers.de

Dovecot, Thunderbird und SSL-"unknown CA"-Fehler

Status: Gelöst | Ubuntu-Version: Server 14.04 (Trusty Tahr)
Antworten |

illCP

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

Hallo zusammen!

Ich beschäftige mich gerade mit Mailservern und bin bei meinen ersten Versuchen mit dem Dovecot. Dazu verwende ich momentan eine lokale, gebridgte VM mit einem 14.04 Server, die ich nach jedem fehlgeschlagenen Konfigurationsversuch zurücksetze (auf "frisch geupdatetes System ohne alles").

Ich habe bereits mit den diversen Authentifizierungsmöglichkeiten herumgespielt, mein Problem beginnt aber offenbar schon vorher:

Versuche ich, mich per Thunderbird (38.3.0 auf Windows 7, IMAP mit SSL/TLS) zum Server zu verbinden, passiert clientseitig nix außer der Meldung "Thunderbird konnte keine Einstellungen für Ihr E-Mail-Konto finden". Im syslog des Servers erscheint folgendes:

imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=192.168.0.104, lip=192.168.0.40, TLS: SSL_Read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=<yA4hOzUlbwDAqABo>

"Unknown CA", "No auth attempts" und leerer User lässt mich darauf schließen, dass der TB schon vor dem eigentlichen Login-Vorgang abbricht, da ihm die CA des (selbstsignierten) Zertifikats nicht passt bzw. unbekannt ist.

Mir ist bewusst, dass selbstsignierte Zertifikate (oder solche, die für die entsprechende Domain ungültig sind) Sicherheitsmeldungen hervorrufen, zu denen man dann eine Ausnahme hinzufügen kann. Soweit komme ich hier aber gar nicht, d.h. der Thunderbird lehnt die Verbindung offenbar von Anfang an ab, ohne mich zu fragen, ob ich das unvertraute, potentiell unsichere Zertifikat tatsächlich nutzen möchte.

Alle Dovecot-Configs sind auf ihren initialen Standardwerten, außer folgenden:

In der /etc/dovecot/conf.d/10-ssl.conf habe ich folgendes gesetzt/geändert:

ssl_cert = </pfad/zum/zertifikat/dateiname.pem
ssl_key = </pfad/zum/key/dateiname.pem

ssl = required

und später testweise zusätzlich explizit

ssl_require_crl = no
ssl_verify_client_cert = no

Im ersten Versuch habe ich bei der Dovecot-Installation ein selbstsigniertes Zertifikat erzeugen lassen (ist in der 10-ssl.conf dann als /etc/dovecot/dovecot.pem eingetragen und existiert im Dateisystem im angegebenen Verzeichnis auch).

Zweiter Versuch:

sudo make-ssl-cert generate-default-snakeoil

Die resultierenden /etc/ssl/certs/ssl-cert-snakeoil.pem und /etc/ssl/private/ssl-cert-snakeoil.key entsprechend als ssl_cert und ssl_key in die conf eingetragen - keine Änderung, immer noch "unknown CA".

Dritter Versuch:

openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem -keyout /etc/ssl/private/dovecot.pem

Sämtliche Abfragen ("Location" etc.) habe ich leer gelassen, nur den CommonName habe ich auf den Hostname des Servers gesetzt. Nach wie vor das gleiche Problem.

Alle diese Zertifikate lassen sich übrigens im Apache nutzen - zwar natürlich mit entsprechender, üblicher "Dieser Verbindung wird nicht vertraut"-Meldung im Browser, aber hat man die einmal abgenickt, kommt eine HTTPS-Verbindung zustande.

Frage: Was geschieht hier?

Mit meinen beschränkten Kenntnissen im Bereich SSL/TLS und einigem Googlen glaube ich erkannt zu haben, wo das Problem liegt:

Normalerweise weiß der Client, wer ein Zertifikat unterschrieben hat - "Guten Tag, mein Name ist Meier. Herr Müller kann Ihnen sagen, dass ich vertrauenswürdig bin. Bitte vertrauen Sie mir!" Nun wird nachgeschaut, ob denn der Herr Müller offiziell zur Gruppe der vertrauenswürdigen Personen gehört - tut er es nicht, gibts eine Warnung, die Herren Müller und Meier können hier aber als vertrauenswürdige Ausnahme hinzugefügt werden.

In meinem Fall scheint es aber eher "Guten Tag, mein Name ist Meier. Bitte vertrauen Sie mir!" zu sein, also ohne jegliche Information über eine CA, so dass der Thunderbird jegliche verschlüsselte Kommunikation von Grund auf ablehnt.

Diverse Quellen im Internet sprechen davon, man sollte das Root-(und/oder ein Intermediate-)Zertifikat mit in das eigentliche Zertifikat packen ("Chain"). Aber wie (einfach mit cat >> ?) und vor allem: welche(s), bzw. wie lauten die Dateinamen dieser Zertifikate?

Oder liegt das Problem an einer anderen Stelle - wird zusätzlich evtl. noch ein DNS benötigt, der den Hostnamen auflöst?

nexusplasma

Anmeldungsdatum:
19. November 2015

Beiträge: 16

IMHO kommt bei Thunderbird im Gegensatz zu Firefox keine Frage bei unbekannter CA.

Hast Du mal versucht, das Snakeoil CA PEM File zu nehmen und in Thunderbird über die Config als vertrauenswürdige CA zu importieren?

illCP

(Themenstarter)

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

nexusplasma schrieb:

Hast Du mal versucht, das Snakeoil CA PEM File zu nehmen und in Thunderbird über die Config als vertrauenswürdige CA zu importieren?

Hinzugefügt unter "Server" bewirkt es nichts; Füge ich es unter "Zertifizierungsstellen" hinzu, ändert das zumindest schonmal die Fehlermeldung:

imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=192.168.0.104, lip=192.168.0.40, TLS: SSL_Read() failed: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42, session=<jDBkH0olCgDAqABo>

"Aktuelle Gültigkeit von Zertifikaten durch Anfrage bei OCSP-Server bestätigen lassen" habe ich dann testweise mal deaktiviert, das ändert leider auch nichts.

Ich denke immer noch, dass hier die "CA Chain" fehlt, die (in irgendeiner mysteriösen Art und Weise, die nirgendwo explizit erklärt wird) erstellt werden muss.

Ich habe zu "bad certificate" noch was gefunden:

http://unix.stackexchange.com/questions/123367/thunderbird-fails-to-connect-to-dovecot-and-postfix

Also update the CA authority in /etc/dovecot/dovecot.ca.pem

Was soll das bedeuten? Nimmt das Bezug auf eine Chain? Wie "update ich die CA authority"?

nexusplasma

Anmeldungsdatum:
19. November 2015

Beiträge: 16

CA Chain braucht man nicht, wenn nur eine übergeordnete CA das Zertifikat signiert. Anders wäre es, wenn es Sub-CA's gäbe, die Certificate Requests quasi "im Auftrag" signieren würden.

Natürlich nützt das CA Zertifikat nichts unter Server, es ist ja nicht das Zertifikat des Servers, sondern das der CA.

Was passiert, wenn Du das Zertifikat des Servers ebenfalls in Thunderbird importierst und dann bei Server ablegst?

Die Fehlermeldung über ein "bad certificate" auf Serverseite klingt für mich aber eher danach, als würdest du erzwingen, dass der Client sich mit einem Client-Zertifikat ausweisen muss, was er Deiner Beschreibung nach ja wahrscheinlich gar nicht kann, da er keine persönlichen Zertifikate besitzt...

illCP

(Themenstarter)

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

nexusplasma schrieb:

Was passiert, wenn Du das Zertifikat des Servers ebenfalls in Thunderbird importierst und dann bei Server ablegst?

Wo finde ich das? Unter /etc/ssl/certs ist massenweise Gedöns, aber nichts, was nach irgendetwas eigenem aussähe. Unter /etc/ssl/private sind nur die Private Keys der von mir angelegten Zertifikate.

Oder habe ich hier grundsätzlich etwas missverstanden? Muss ich vorher manuell ein Server-Zertifikat (bzw. eine CA) anlegen und meine Zertifikate damit signieren?

nexusplasma schrieb:

Die Fehlermeldung über ein "bad certificate" auf Serverseite klingt für mich aber eher danach, als würdest du erzwingen, dass der Client sich mit einem Client-Zertifikat ausweisen muss, was er Deiner Beschreibung nach ja wahrscheinlich gar nicht kann, da er keine persönlichen Zertifikate besitzt...

Daran hatte ich auch schon gedacht - ich habe neben

ssl_verify_client_cert = no

in der 10-ssl.conf

nochmal explizit

auth_ssl_require_client_cert = no

in der 10-auth.conf gesetzt - das ist aber soweit ich sehe sowieso die Standard-Einstellung und ändert auch offenbar nichts.

PS: "auf Serverseite": Ich bin mir nicht ganz im Klaren darüber, was genau Dovecot hier ins Syslog spuckt - für mich sieht das so aus, als würden hier auch clientseitige (bzw. vom Client ausgelöste) Fehlermeldungen erscheinen.

nexusplasma

Anmeldungsdatum:
19. November 2015

Beiträge: 16

Ähm, die Frage wo das Server Cert steht hast Du Dir selbst schon ganz am Anfang dieses Threads beantwortet:

"ssl_cert = </pfad/zum/zertifikat/dateiname.pem"

illCP

(Themenstarter)

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

nexusplasma schrieb:

Ähm, die Frage wo das Server Cert steht hast Du Dir selbst schon ganz am Anfang dieses Threads beantwortet:

"ssl_cert = </pfad/zum/zertifikat/dateiname.pem"

nexusplasma schrieb:

Natürlich nützt das CA Zertifikat nichts unter Server, es ist ja nicht das Zertifikat des Servers, sondern das der CA.

Was passiert, wenn Du das Zertifikat des Servers ebenfalls in Thunderbird importierst und dann bei Server ablegst?

Jetzt kann ich dir nicht mehr ganz folgen - ich glaube, ich werfe ein paar Begrifflichkeiten durcheinander.

Du unterscheidest zwischen "Zertifikat des Servers" und "Zertifikat der CA".

Wenn ich per

openssl req -new -x509 -days 3650 -nodes -out /etc/ssl/certs/dovecot.pem -keyout /etc/ssl/private/dovecot.pem

ein Zertifikat anlege, bekomme ich die entsprechenden PEMs in den beiden Verzeichnissen.

Die dovecot.pem aus /etc/ssl/certs habe ich im TB unter "Zertifizierungsstellen" hinzugefügt, was "unknown ca" in "bad certificate" ändert. Unter "Server" hinzugefügt ändert es nichts.

Wenn dies das Zertifikat des Servers ist, was bzw. wo ist dann das Zertifikat der CA?

nexusplasma

Anmeldungsdatum:
19. November 2015

Beiträge: 16

Also ich habe das Gefühl, Du solltest Dir vielleicht erst einmal Grundkenntnisse zum Thema PKI aneignen, bevor Du hier weitermachst.

CA = Certification Authority, "Unterzeichner" des Zertifikats, Zertifizierungsstelle, quasi die Behörde die den Personalausweis ausstellt (/etc/ssl/certs/ssl-cert-snakeoil.pem)

CERT = Server Certificate, der "Personalausweis" des Servers, der von der "Behörde" = CA unterschrieben wurde (/etc/ssl/certs/dovecot.pem)

illCP

(Themenstarter)

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

nexusplasma schrieb:

CA = Certification Authority, "Unterzeichner" des Zertifikats, Zertifizierungsstelle, quasi die Behörde die den Personalausweis ausstellt (/etc/ssl/certs/ssl-cert-snakeoil.pem)

Ja... nee... ssl-cert-snakeoil.pem ist mit Sicherheit nicht das CA-Zertifikat. So wie ich das sehe ist das auch nur ein Server-Zertifikat, das erst existiert, nachdem man es per

make-ssl-cert generate-default-snakeoil

erzeugt hat, was wiederum die Installation des Pakets ssl-cert erfordert.

Wer ist CA bzw. wo ist ihr Zertifikat, wenn ich auf einem frisch installierten 14.04 Server per openssl req -new ein Server-Zertifikat erstelle? Gibt es dann einfach keine CA bzw. ist das erzeugte Zertifikat dann einfach nicht signiert?

Deshalb auch meine Frage oben:

illCP schrieb:

Oder habe ich hier grundsätzlich etwas missverstanden? Muss ich vorher manuell ein Server-Zertifikat (bzw. eine CA) anlegen und meine Zertifikate damit signieren?

Das habe ich aber - denke ich - jetzt verstanden:

Ich habe jetzt noch mal alles zurückgesetzt und die Schritte gemäß https://wiki.ubuntuusers.de/CA durchgeführt: Eine CA angelegt, ein Server-Zertifikat erzeugt und es signiert. Packe ich Server-Zertifikat und -Key in die Dovecot-Config und füge ich dem Thunderbird unter "Zertifizierungsstellen" das CA-Zertifikat (/home/username/demoCA/cacert.pem hinzu) scheint es tatsächlich zu klappen - es funktioniert zwar aufgrund mangelnder sonstiger Konfiguration sonst nix, aber zumindest scheint erstmal eine saubere TLS-Verbindung zustande zu kommen; im Syslog tauchen keine diesbezüglichen Fehler mehr auf. ☺

Und jetzt kommts:

Thunderbird 38.3.0 unter Ubuntu 14.04.3 Desktop (also exakt die gleiche TB-Version wie unter Win 7) produziert faszinierenderweise keine SSL-Fehler, auch wenn man ihm die CA nicht manuell bekannt gemacht hat... langsam wirds wirklich verwirrend...

sebix Team-Icon

Moderator, Webteam

Anmeldungsdatum:
14. April 2009

Beiträge: 5482

illCP schrieb:

nexusplasma schrieb:

CA = Certification Authority, "Unterzeichner" des Zertifikats, Zertifizierungsstelle, quasi die Behörde die den Personalausweis ausstellt (/etc/ssl/certs/ssl-cert-snakeoil.pem)

Ja... nee... ssl-cert-snakeoil.pem ist mit Sicherheit nicht das CA-Zertifikat. So wie ich das sehe ist das auch nur ein Server-Zertifikat, das erst existiert, nachdem man es per

make-ssl-cert generate-default-snakeoil

erzeugt hat, was wiederum die Installation des Pakets ssl-cert erfordert.

Wer ist CA bzw. wo ist ihr Zertifikat, wenn ich auf einem frisch installierten 14.04 Server per openssl req -new ein Server-Zertifikat erstelle? Gibt es dann einfach keine CA bzw. ist das erzeugte Zertifikat dann einfach nicht signiert?

Ja, genau. Self-signed bedeutet, dass es sich selbst signiert. Das ist Leaf-Zertifiakt und CA-Zertifikat in einem. Es signiert sich selbst.

illCP

(Themenstarter)

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

sebix schrieb:

Ja, genau. Self-signed bedeutet, dass es sich selbst signiert. Das ist Leaf-Zertifiakt und CA-Zertifikat in einem. Es signiert sich selbst.

Ah, OK. Ich hatte "self" immer als "ich selbst" verstanden, also ich signiere ein Zertifikat als (gegenüber jedem anderen außer mir) erstmal unbekannte, nicht vertrauenswürdige CA selbst.

illCP schrieb:

Thunderbird 38.3.0 unter Ubuntu 14.04.3 Desktop (also exakt die gleiche TB-Version wie unter Win 7) produziert faszinierenderweise keine SSL-Fehler, auch wenn man ihm die CA nicht manuell bekannt gemacht hat... langsam wirds wirklich verwirrend...

Kommando zurück: Der Linux-TB schmeißt doch einen SSL-Fehler, den man interessanterweise allerdings nur mit

verbose_ssl = yes

in der 10-logging.conf sieht - er unterscheidet sich jedoch vom Windows-TB-Fehler:

TB Windows 7 (ohne importiertes CA-Zertifikat):

imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
auth: Debug: auth client connected (pid=4019)
imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [192.168.0.104]
imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [192.168.0.104]
imap-login: Debug: SSL: where=0x2002, ret=-1: SSLv3 read client certificate A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client key exchange A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read finished A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write session ticket A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write change cipher spec A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write finished A [192.168.0.104]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [192.168.0.104]
imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully [192.168.0.104]
imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully [192.168.0.104]
imap-login: Warning: SSL alert: where=0x4004, ret=560: fatal unknown CA [192.168.0.104]
imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=192.168.0.104, lip=192.168.0.40, TLS: SSL_read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=<OAbgqFklcwDAqABo>

TB Linux (ohne importiertes CA-Zertifikat):

imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
imap-login: Debug: SSL: elliptic curve secp384r1 will be used for ECDH and ECDHE key exchanges
auth: Debug: auth client connected (pid=4038)
imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 read client hello A [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server hello A [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write certificate A [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write key exchange A [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 write server done A [192.168.0.38]
imap-login: Debug: SSL: where=0x2001, ret=1: SSLv3 flush data [192.168.0.38]
imap-login: Warning: SSL failed: where=0x2002: SSLv3 read client certificate A [192.168.0.38]
imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=192.168.0.38, lip=192.168.0.40, TLS handshaking: Disconnected, session=<NGQ+sFklAwDAqAAm>

"read client certificate A"?

10-ssl.conf:

ssl_verify_client_cert = no

10-auth.conf:

auth_ssl_require_client_cert = no

Wieso denn bitte dann noch "client certificate"?

Mache ich nun mein CA-Zertifikat mit beiden TBs bekannt, verschwindet der Fehler beim Zugriff mit dem TB unter Windows; der "read client certificate A"-Fehler beim Zugriff mit dem Ubuntu-TB bleibt.

openssl s_client -connect 127.0.0.1:993:

CONNECTED(00000003)
depth=1 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = meintestmailserver
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=meintestmailserver/CN=meintestmailserver
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=meintestmailserver
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=meintestmailserver
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=meintestmailserver
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID3zCCAsegAwIBAgIJANrBOFn6zpZdMA0GCSqGSIb3DQEBCwUAMGIxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQxGzAZBgNVBAMMEndvY290ZXN0bWFpbHNlcnZlcjAeFw0x
NTExMjQwODU0NTRaFw0xNjExMjMwODU0NTRaMH8xCzAJBgNVBAYTAkFVMRMwEQYD
VQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBM
dGQxGzAZBgNVBAsMEndvY290ZXN0bWFpbHNlcnZlcjEbMBkGA1UEAwwSd29jb3Rl
c3RtYWlsc2VydmVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvHgh
faEqJIDBj3MA3AdjV/we+txfy8IbFJ8F837lhTlBCUGaOv51qmQi0RFX11vp74pj
Dq0muMiDCwrdk6/XZAvcytgk4SVRjv/XKvGgOkMVAk5oJt/Vzj9qNeYaUAviilaO
cZtz2aUPraZO0MVa8ZeSchGG5obKv5Pu0T9WoYi+FGIvFKIQNnNfLddc2DP34c9X
f3Sra2hx75k2KIVZ+UJrw+NS9RPsGPNQJG8BbKC+7NJ1r/jbp4f8W51L3DisyQC1
3o83TjQjti36OBrLRRU8nrHDY518FLitwB/i2rsXGq7dfDd6APw9yeo0+qvcGI9i
Sk6acvPhoBHGp0UlIwIDAQABo3sweTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQf
Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKtniDJLd
lR0NeNt1p+mN37dmXqowHwYDVR0jBBgwFoAUl/odmzmr1lzqhEbsr9yDGpMdN74w
DQYJKoZIhvcNAQELBQADggEBAJIyNT2iae7+mD06K/rbN2icYdse20tYkxQXTsHa
MywXO/0YKYKb53XlGAWG+Q0iwT2+pyF6LQVUOQI6oaKTpdLNIGYKN957XK8aNbN4
36xETpCccWlKpI8jjvINtEIJkFydtxG+AxFWpIGzg+O07WAJZP0VuEpP3wOtpVnf
6UqEF9IWe41cAxwGi2m7xig9XDZ6uBzONAG40Uwtm49/zy0MdCKw+CCu4Bfv31Za
bjkDtG3FekJz+d2HUuJbmyZoCiuZFAfscRCyXcZk4463KyXrXiGZE2l3tRrOQO9q
OyQ29YqJVPhcn2qSSQYdyB3GsYLFbPyTJ3ADb0N4IVUHds8=
-----END CERTIFICATE-----
subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/OU=meintestmailserver/CN=meintestmailserver
issuer=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=meintestmailserver
---
No client certificate CA names sent
---
SSL handshake has read 2612 bytes and written 453 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: A696F80DA7CEB7A06E3150F94A99357C5FA534D7301D7EC86D29583D74A1247C
    Session-ID-ctx:
    Master-Key: D5053749099C34FC8D6650F1C8FF8D6CDC7A7FCC575A73D90A27698A7841664228FE24965DBB476729F2AE7ABA2D5B4C
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - ee 99 26 89 2c a0 fd 96-b6 ce ff 21 62 ea 90 40   ..&.,......!b..@
    0010 - dc 43 c4 16 fa 6c 47 b3-1f 19 e5 22 52 3d 8f c0   .C...lG...."R=..
    0020 - 42 e6 6c 52 85 87 7d a5-28 6a be 0b 10 e4 bf 11   B.lR..}.(j......
    0030 - 3f bc 50 9b aa 1c ac 4c-d3 c3 d5 c2 a0 a1 78 6d   ?.P....L......xm
    0040 - 25 ce c0 ad 3b b8 95 a3-27 bb 40 10 b4 c5 e1 55   %...;...'.@....U
    0050 - cb e0 1d d4 40 b6 73 18-4c e0 bd f2 03 25 ee df   ....@.s.L....%..
    0060 - d8 fe ee 64 34 67 92 9a-a3 ba ba d7 de 12 1e 72   ...d4g.........r
    0070 - 27 d1 63 10 6b 37 56 aa-74 88 1e e9 e6 0d 9a 9b   '.c.k7V.t.......
    0080 - 78 70 64 ed 44 6a 35 57-0c 83 28 c8 c7 29 a1 26   xpd.Dj5W..(..).&
    0090 - df 8f 0f f1 51 f7 ed f2-00 af 83 7d a5 de ac 42   ....Q......}...B

    Start Time: 1448442288
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot (Ubuntu) ready.

doveconf -n:

# 2.2.9: /etc/dovecot/dovecot.conf
# OS: Linux 3.19.0-33-generic x86_64 Ubuntu 14.04.3 LTS
auth_debug = yes
auth_verbose = yes
log_path = /var/log/dovecot.log
mail_debug = yes
mail_location = mbox:~/mail:INBOX=/var/mail/%u
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
    special_use = \Drafts
  }
  mailbox Junk {
    special_use = \Junk
  }
  mailbox Sent {
    special_use = \Sent
  }
  mailbox "Sent Messages" {
    special_use = \Sent
  }
  mailbox Trash {
    special_use = \Trash
  }
  prefix =
}
passdb {
  driver = pam
}
protocols = " imap"
ssl = required
ssl_ca = </etc/dovecot/ca.pem
ssl_cert = </etc/dovecot/bla.pem
ssl_key = </etc/dovecot/bla_key.pem
ssl_protocols = TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2
ssl_require_crl = no
userdb {
  driver = passwd
}
verbose_ssl = yes

Weiterhin habe ich (wie in diversen Quellen empfohlen) folgendes probiert:

sudo -s
cat /etc/dovecot/ca.pem >> /etc/dovecot/bla.pem

Ändert leider auch nix.

Im TB-Bugtracker finde ich diverse Bugreports über nicht mehr funktionierende, selbstsignierte Zertifikate, das sind allerdings alles Einträge von 2014, die sich auf frühe 30er-Versionen beziehen und angeblich längst gefixt sind.

illCP

(Themenstarter)

Anmeldungsdatum:
26. Oktober 2010

Beiträge: 134

HA! Hab den Fehler gefunden - "Unknown CA" war hier (entgegen der Meldung) eigentlich gar nicht das Problem:

Die Ausgabe der Fehlerkonsole des Thunderbird (Strg. + Shift + J oder "Extras" ⇒ "Fehlerkonsole" - kannte ich bisher nur aus dem Firefox und war mir gar nicht bewusst, dass der Thunderbird auch eine hat) offenbart nach einigem Herumprobieren die Lösung:

192.168.0.40:993 verwendet ein ungültiges Sicherheitszertifikat.
Dem Zertifikat wird nicht vertraut, weil das Aussteller-Zertifikat unbekannt ist.
Das Zertifikat ist nur für meintestmailserver gültig
(Fehlercode: sec_error_unknown_issuer)

Entscheidend ist hier (entgegen dieser Meldung und dem Fehler im Dovecot-Log) nicht etwa das unbekannte CA-Zertifikat, sondern der angegebene Common Name "meintestmailserver" - Zugriff auf den Server erfolgt (mangels DNS respektive DNS-Eintrag) per 192.168.0.40 - und genau da knallts.

Ich habe testweise ein weiteres Zertifikat erstellt, diesmal mit "192.168.0.40" als Common Name - sowohl in der Thunderbird-Konsole als auch im Dovecot-Log bleiben die CA-Fehler, das IMAP-Konto wird aber dennoch als gültig erkannt und anschließend die bekannte, abzunickende Sicherheitswarnung "Diesem Zertifikat wird nicht vertraut" angezeigt bevors weitergeht.

D.h. stimmt der Common Name im Zertifikat nicht mit der Domain (respektive der IP-Adresse) des Servers überein, gehts im TB grundsätzlich nicht weiter. Den Firefox hingegen stört das nicht, bzw. man bekommt es gemeldet, kann es aber ignorieren/akzeptieren.

Ein wenig schleierhaft ist mir dennoch, wieso sich Windows- und Ubuntu-TB hier unterschiedlich verhalten... kann der TB unter Linux evtl. irgendwie auf den Hostname des Servers (der in meinen ersten Versuchen mit dem Common Name im Zertifikat übereinstimmte) zugreifen? Und was soll die "Warning: SSL failed: where=0x2002: SSLv3 read client certificate A"-Meldung beim Zugriff mit dem Ubuntu-TB? Die taucht beim Zugriff mit dem Windows-TB definitiv nicht auf.

Vielen Dank an alle Helfer!

Antworten |