STARTTLS schlägt fehl, Client meldet "Bad Certificate"

Am 24.09.2018, werden in der Zeit zwischen 21:00 Uhr und 09:00 Uhr des folgenden Tages Wartungsarbeiten am Server durchgeführt. Daher wird die Webseite in dieser Zeit nur eingeschränkt erreichbar sein.
  • Ich verwende seit vielen Jahren icedove (38.7.0) unter Debian Linux um per IMAP auf meinen eigenen Cyrus Mail-Server zuzugreifen. Nach Ablauf des Server-Zertifikats habe ich dieses erneuert. Im selben zeitlichen Kontext sind aber auch die Clients aktualisiert worden.


    Nun hängt icedove beim Verbindungsversuch mit der Meldung "foo@bar.baz: Überprüfe den Funktionsumfang des Servers ...". Schalte ich TLS aus, klappt alles wie gewohnt.


    Ich habe den Verbindungsversuch mit Wireshark mitgeschnitten. Client Hello und Server Hello inklusive Zertifikatsanforderung sind unauffällig. Allerdings antwortet icedove mit einem Fatal Alert: Bad Certificate. (0x022a) Dem Anwender wird wie gesagt keine Meldung angezeigt.


    openssl s_client -starttls imap -crlf -connect 'imap.example.com:143' -CAfile /etc/certs/cacert.pem baut die Verbindung anstandslos ohne irgendwelche Warnungen auf. cacert.pem habe ich natürlich in den Zertifikatsspeicher importiert.


    Als weiteren Versuch habe ich das Server-Zertifikat ebenfalls importiert. Auch das ging ohne Probleme und ich kann mir im Zertifikat-Manager die Details beider Zertifikate (CA, Server) ansehen. Es gibt auch keine augenfälligen Abweichungen zu den Zertifikatsinhalten.


    Als Signaturalgorithmus wird PKCS #1 SHA-256 With RSA Encryption verwendet. Schlüssellänge ist 2048 Bit.


    Gibt es eine Möglichkeit mehr Details zur Zertifikatsprüfung zu bekommen? Oder ist irgendwo dokumentiert, was genau geprüft wird?

  • Mein erster Verdacht wäre der, dass die Zertifikatskette nicht vollständig im TB bekannt ist. Ist die CA im TB wirklich als Root-CA bekannt oder ist das Zertifikat von einer weiteren CA unterschrieben, die dem TB noch nicht bekannt ist?

  • Die Root-CA ist bekannt. Sie wird in der Detailansicht des Server-Zertifikats auch dargestellt. Das sollte bedeuten, dass sie auch als CA des Zertifikats erkannt wird, hoffe ich.

  • Die Root-CA ist bekannt.

    Meine Frage bezog sich darauf, ob die vermeintliche Root-CA auch wirklich eine Root-CA ist? Oder benötigt deren Zertifikat wiederum selbst eine weitere Instanz?


    Wie sieht die Kette aus?
    Dein Zert -> Root-CA oder
    Dein Zert -> (nur vermeintliche Root-) CA -> Root-CA

  • Nun, wenn das wirklich ist, dann musst Du Deiner CA nach dem Import nur noch das Vertrauen aussprechen. Dann sollte es funktionieren.

  • Tja, immer diese Konjunktive.

    Natürlich im Konjunktiv. Ich sitze schließlich nicht vor Deinem Rechner und kann somit keine Aussage darüber treffen, ob es sich einen bug, einen Fehler im Zertifikat oder einen Fehler deinerseits handelt.
    Ich kann Dir aber im modus indicativus bestätigen, dass der TB bei mir auch mit von mir selbst erstellten Zertifikaten klarkommt, sofern die Kette vollständig ist und das Vertrauen ausgesprochen wurde. Ich tendiere deshalb eher nicht zu einem bug im TB - auch wenn das natürlich nicht auszuschließen ist.

    Ich habe das ganze mal als Bug registriert.

    Ein Link auf diesen Bug wäre nett.

  • Sorry, das mit den Konjunktiven war nicht gegen Dich gemünzt. Es ist eher die Zusammenfassung von bald 40 Jahren intensiver, praktischer Computererfahrung.


    Bug für icedove: #819747

  • Hallo Lars,


    falls Du in der Zwischenzeit etwas testen möchtest, hätte ich einen Vorschlag:


    Versuche es mit einem kostenlosen Zertifikat über die Let's-Encrypt-Initiative, siehe z.B. http://mailserverblog.de/koste…lserver-mit-lets-encrypt/


    Nicht ganz so aussagekräftig aber vielleicht auch eine Möglichkeit:


    Besorge die für einen Test eine richtig alte Version des TB, also eine von vor 2014 bevor Mozilla aufgrund von Poodle und Co. den Umgang mit Zertifikaten verschärft hat.



    Beide Tests zielen darauf ab, zu prüfen ob der Fehler im Zertifikat bzw. bzw. der Kette liegt.


    Gruß


    Susanne

  • Gerade ist mir noch eine Fehlerquelle eingefallen, wegen der die Telekom vor ein paar Wochen ein Problem hatte. Schau mal, ob Du unter [tmdemenupath]Einstellungen[/tmdemenupath] [tmdemenupath]Erweitert[/tmdemenupath] [tmdemenupath]Zertifikate[/tmdemenupath]die Option


    Aktuelle Gültigkeit von Zertifikaten durch Anfrage bei OCSP-Server bestätigen lassen


    aktiviert hast und deaktiviere sie ggf. für einen Test.

  • OCSP war eine gute Idee, war aber scheinbar nicht die Ursache. Danke für den Tip.


    Ich habe zum Zugriff auf den Mail-Server mal KMail eingerichtet, und der hat kein Problem nachdem ich die CA ins KDE Systemrepository importiert hatte. Da OpenSSL auch kein Problem hat, dürfte die Problematik bei icedove liegen.


    Mal eben ein anderes Zertifikat mit anderer CA zu generieren ist nicht so leicht, da z.B. der Mailserver wieder per SSL auf LDAP unter derselben CA zugreift.

  • Ich habe zum Zugriff auf den Mail-Server mal KMail eingerichtet, und der hat kein Problem nachdem ich die CA ins KDE Systemrepository importiert hatte.

    Das überrascht mich nicht. So penible (im positiven Sinn) wie Mozilla ist in diesem Umfeld meines Wissens kaum jemand unterwegs. Mozilla hat aus Poodle, Heartbleed und Co. sehr guten Leeren gezogen.

    Mal eben ein anderes Zertifikat mit anderer CA zu generieren ist nicht so leicht, ...

    OK. Jedoch würde der angesprochene Test mit einem Zertifikat über Let's Encrypt Klarheit schaffen, ob der TB/Icedove das Problem sind oder nicht.