Fehlerhafter Verbindungsaufbau zu IMAP-Server über IMAPS

Wenn Sie plötzlich keine E-Mails mehr empfangen können

Bitte lesen Sie die Hinweise zu den beiden derzeit häufigsten Problemursachen!

Hier bitte klicken!

Diese rote Box verschwindet, wenn Sie in der rechten oberen Ecke auf das X klicken.

    Umgebung:

    • Thunderbird-Version: 60.0 (64-bit)
    • Betriebssystem + Version: Linux revival 4.18.9-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 19 21:19:17 UTC 2018 x86_64 GNU/Linux
    • Kontenart (POP / IMAP): IMAP
    • Postfach-Anbieter (z.B. GMX): Eigener Server
    • Eingesetzte Antiviren-Software: Keine
    • Firewall (Betriebssystem-intern/Externe Software): iptables
    • Router-Modellbezeichnung (bei Sende-Problemen): Irrelevant


    Guten Abend zusammen,


    als Mailersatz für KMail sollte Thunderbird dienen um auch die Konten zwischen Linux und Windows jeweils identisch zu halten (KMail existiert nicht unter Windows). Leider scheint Thunderbird als einziger Mailclient mit den TLS-Einstellungen des Servers (Dovecot) nicht klar zu kommen.


    Server-Eintrag bei TB:

    Code
    Sep 27 20:11:54 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=<>, lip=<>, TLS: SSL_read() failed: error:1404C412:SSL routines:ST_OK:sslv3 alert bad certificate: SSL alert number 42, session=<ebU+8992yo8gAwDMi9phAB+xXsODvW0a>

    Server-Eintrag bei KMail:

    Code
    Sep 27 19:43:06 imap-login: Info: Login: user=<>, method=PLAIN, rip=<>, lip=<>, mpid=16629, TLS, session=<dPxFjN92uLAgAwDMi9phAOiHpCphmlfH>          
Sep 27 19:43:07 imap-login: Info: Login: user=<>, method=PLAIN, rip=<>, lip=<>, mpid=16630, TLS, session=<lnxMjN92t7AgAwDMi9phAOiHpCphmlfH>          
Sep 27 19:43:07 imap(): Info: Connection closed (UID FETCH finished 0.132 secs ago) in=660 out=2832                                                                                                             
Sep 27 19:43:08 imap(): Info: Connection closed (LIST finished 1.039 secs ago) in=23 out=3477

    Wenn man es mit OpenSSL versucht bekommt man eine erfolgreiche Verbindung zustande:

    Wenn man das erweiterte Logging von TLS-Verbindungen aktiviert, zeigt sich dass Thunderbird nach dem Handshake etwas Seltsames versucht:

    Code
    Sep 27 20:33:29 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization                                                                                                            
Sep 27 20:33:29 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization                                                                                                       
[...] 
Sep 27 20:33:29 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully                                                                                                  
Sep 27 20:33:29 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully                                                                                             
Sep 27 20:33:29 imap-login: Debug: SSL error: SSL_read() failed: error:1404C412:SSL routines:ST_OK:sslv3 alert bad certificate: SSL alert number 42                                                                                        
Sep 27 20:33:29 imap-login: Warning: SSL alert: where=0x4004, ret=554: fatal bad certificate                                                                                                    
Sep 27 20:33:29 imap-login: Debug: SSL alert: close notify
Sep 27 20:33:29 imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=<>, lip=<>, TLS: SSL_read() failed: error:1404C412:SSL routines:ST_OK:sslv3 alert bad certificate: SSL alert number 42, session=<BTB2QOB2opAgAwDMi9phAB+xXsODvW0a

    Andere Clients handeln die Sache schon besser aus:

    Code
    Sep 27 20:31:24 imap-login: Debug: SSL: where=0x10, ret=1: before/accept initialization                                                                                                                                 
Sep 27 20:31:24 imap-login: Debug: SSL: where=0x2001, ret=1: before/accept initialization                                                                                                                                   
[...]                                                                                                                                            
Sep 27 20:31:24 imap-login: Debug: SSL: where=0x20, ret=1: SSL negotiation finished successfully                                                                                                                            
Sep 27 20:31:24 imap-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully                                                                                                                          
Sep 27 20:31:24 imap-login: Info: Login: user=<>, method=PLAIN, rip=<>, lip=<>, mpid=16767, TLS, session=<yMoAOeB2AJtXrKSt>

    Die TLS-relevanten Einstellung von Dovecot sind:

    Code
    # SSL protocols to use
ssl_protocols = !SSLv3 !TLSv1

# SSL ciphers to use
ssl_cipher_list = HIGH:!CAMELLIA:!SSLv3

# Prefer the server's order of ciphers over client's.
ssl_prefer_server_ciphers = yes

    Der Server verlangt vom Client also nicht das Unmögliche. Jedoch habe ich es mit allen möglichen Einstellungen versucht, sowohl unter Linux als auch unter Windows. Weitere Clients, welche eine Verbindung zustande bekommen sind: Aquamail, der Android Standard-Mailclient, K9 Mail, Roundcube, mutt und (nicht unbedingt ein Client) OpenSSL mit Terminalbefehlen (Login und Listing von INBOX).


    Betreibt hier jemand selbst einen Mailserver und kann seine Einstellungen hier teilen? Danke schon mal im Voraus.


    Schönen Abend,

    Kalionda

    Gemäß der Fehlermeldung akzeptiert der Thunderbird das Zertifikat nicht bzw. hält es für fehlerhaft. Thunderbird ist nach meinem Kenntnisstand in dieser Beziehung strikter als andere Programme.

    Für den Fall dass es sich bei dem Zertifikat um ein selbst erzeugtes handelt, würde ich den Fehler dort vermuten. Mir fällt dazu insbesondere das OCSP-Stapling ein, das standardmäßig aktiv ist. Bei eigenen Zertifikaten wird das wohl in den meisten Fällen zu einem Fehler führen.

    Ich hatte das OCSP-Stapling nicht im Verdacht. Thunderbird gibt für das Zertifikat in seiner UI keinen Fehler aus sondern scheint einfach einen SSL-Alert an den Server zu senden und erklärt die Sache für beendet. Nicht gerade hilfreich bei der Fehlersuche.


    Das Zertifikat beinhaltet in der Tat das OCSP Must-Staple-Flag, ist aber von Let'sEncrypt.


    Vielen Dank für den Fingerzeig.