Zertifikat abgelaufen und erneuert, trotzdem keine Mails versenden "TLS-Handshakefehler"

  • Ich kann keine Mails versenden.
    Aus der Log Datei konnte ich sehen das ein Zertifikat nicht mehr gültig war.
    Daraufhin habe ich meinen Provider informiert und der hat dann geschrieben „Alle Serverzertifikate wurden ausgetauscht und es sollten keine Probleme mehr beim E-Mail Versand entstehen.“

    Leider kann ich immer noch keine Mails versenden.
    In der LogDatei steht immer noch das ein Zertifikat abgelaufen ist.
    Frage, muss ich noch in der Zertifikat Datenbank von TheBat die Zertifikate tausche oder lösche oder ???

    Auszug der Log-Datei

    SEND - Zertifikat S/N: 696849555936BB031A50283EE18FD9FA, Algorithmus: RSA (2048 Bits), ausgestellt von 01.04.2016 bis 01.04.2017 23:59:59, für 2 Host(s): *.servertools24.de, servertools24.de.
    SEND - Besitzer: "Domain Control Validated", "PositiveSSL Wildcard", "*.servertools24.de".
    SEND - Aussteller: "GB", "Greater Manchester", "Salford", "COMODO CA Limited", "COMODO RSA Domain Validation Secure Server CA". Gültig ab 12.02.2014 bis 11.02.2029 23:59:59.
    SEND - Aussteller: "GB", "Greater Manchester", "Salford", "COMODO CA Limited", "COMODO RSA Certification Authority". Gültig ab 30.05.2000 10:48:38 bis 30.05.2020 10:48:38.
    SEND - Root: "SE", "AddTrust AB", "AddTrust External TTP Network", "AddTrust External CA Root" Gültig ab 30.05.2000 10:48:38 bis 30.05.2020 10:48:38.
    SEND - TLS-Handshakefehler. Ungültiges Serverzertifikat (Das Zertifikat ist abgelaufen)

  • Da ist was sowas von falsch und kaputt bei denen.
    Sowohl die Zertifikat für SMTP und POP3 bzw. IMAP beim Server servertools24.de sind falsch.
    Parallels Panel? Udn die Mail-Adresse des Ausstellers?
    Das sind Platzhalterzertifikate, nach der Installation von Plesk Panel!
    Dein Anbieter macht Pfusch bei der Zertifikatausstellung oder kann das Panel nicht richtig bedienen!


    Das Zertifikat des SMTP-Servers ist ausgestellt für:
    /C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=Parallels Panel/emailAddress=info@parallels.com
    Das Zertifikat des IMAP/POP3-Servers ist ausgestellt für:
    /C=US/ST=Virginia/L=Herndon/O=Parallels/OU=Parallels Panel/CN=http://service3.servertools24.de/emailAddress=info@parallels.com

    Ich habe es mit openssl geprüft:

    Die sollten mal das richtige Zertifikat den Mailserern zuweisen!
    Und auch gleich für die Domain servertools24.de, der Webserver ist auch nur für Plesk Panel ausgestellt!


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Einmal editiert, zuletzt von GwenDragon (6. April 2017 um 09:10)

  • Danke GwenDragon für deine schnelle Antwort, aber das ist für mich (zu) viel Input auf einmal :)
    Ich muss es erst einmal selber verstehen damit ich meinen Provider schreiben kann das er nur Bullshit macht.

    Ich fasse mal zusammen:

    das Zertifikat für SMTP auf Parallels Panel ausgestellt ist. Es müsste aber auf servertools24.de ausgestellt sein (das ist mein Serveradresse)

    IMAP/POP3 auf servertools24.de ist dann i.O. Das die Mailadresse info@parallels.com ist falsch, müsste es die von meinen Anbieter sein?


    Die Zertifikate sind zwar falsch( das sollte auch nicht so sein), aber das stört anscheinend TheBat nicht.

    Die Fehlermeldung ist ja das dass Zertifikat 696849555936BB031A50283EE18FD9FA abgelaufen ist.

    Dann kann ich davon ausgehen das dieses Zertifikat definitiv abgelaufen ist und nicht erneuert wurde.


    Danke und Grüße

  • Dein Server? Ist das ein Managed Server?
    Dann schimpfe mal die Person, die deinen Server eingerichtet hat und betreut.

    Kopier denen doch die Ausgabe meiner openssl-Tests in s Mail. Da sehen die das doch, dass die Zertifikate falsch sind.

    C:\> openssl s_client -connect servertools24.de:465 | openssl x509 -dates -noout
    depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = info@parallels.com
    verify error:num=18:self signed certificate
    verify return:1
    depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = info@parallels.com
    verify error:num=10:certificate has expired
    notAfter=Jan 23 21:20:59 2015 GMT
    verify return:1
    depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = Parallels Panel, emailAddress = info@parallels.com
    notAfter=Jan 23 21:20:59 2015 GMT
    verify return:1
    notBefore=Jan 23 21:20:59 2014 GMT
    notAfter=Jan 23 21:20:59 2015 GMT

    C:\>openssl s_client -connect servertools24.de:993 | openssl x509 -dates -noout
    depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = service3.servertools24.de, emailAddress = info@parallels.com
    verify error:num=18:self signed certificate
    verify return:1
    depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = service3.servertools24.de, emailAddress = info@parallels.com
    verify error:num=10:certificate has expired
    notAfter=Jun 30 15:34:17 2016 GMT
    verify return:1
    depth=0 C = US, ST = Virginia, L = Herndon, O = Parallels, OU = Parallels Panel, CN = service3.servertools24.de, emailAddress = info@parallels.com
    notAfter=Jun 30 15:34:17 2016 GMT
    verify return:1
    notBefore=Jul 1 15:34:17 2015 GMT
    notAfter=Jun 30 15:34:17 2016 GMT


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • SEND - Zertifikat S/N: 696849555936BB031A50283EE18FD9FA, Algorithmus: RSA (2048 Bits), ausgestellt von 01.04.2016 bis 01.04.2017 23:59:59, für 2 Host(s): *.servertools24.de, servertools24.de.

    Wenn dieses Zertifikat erneuert wurde, die Fehlermeldung aber trotzdem erscheint, dann kann es sein, dass das abgelaufene Zertifikat bei dir im TB!-Adressbuch gespeichert ist, wo TB! bei einer Verbindung normalerweise zuerst nachschaut. Dazu musst du u.U. über das Menü "Ansicht" Zertifikatsdatenbanken aktivieren.

  • @ GwenDragon
    nein es nicht nicht mein Server. (auch wenn die Leute aus dem Support nicht die schlausten sind, möchte ich den Hosters hier nicht nennen)
    Ich werde denen mal deinen openssl Auszug zusenden. Ich denke aber das es nichts nützt.

    @ sanyok
    Die Zertifikat Datenbank habe ich durchsucht, aber keins mit den Namen 696849... gefunden.
    Dann schließe ich mal ein Fehler meinerseits aus und schreibe den Support noch einmal an.

    * * * Edit * * *
    ich habe mal das Datum von meinen PC auf den 01.04.2017 gesetzt (das ist das Ablaufdatum vom Zertifikat), dann kann ich auch Mails versenden.

    Ich werde berichte wie es weiter geht.

    Einmal editiert, zuletzt von Bert (6. April 2017 um 16:16)

  • Die Zertifikat Datenbank habe ich durchsucht, aber keins mit den Namen 696849... gefunden.

    Hast du jeden Eintrag angeklickt und dann dort auf den Reiter "Zertifikate" oder nur die Liste mit Zertifikaten nach dem Namen durchsucht? Es kann nämlich sein, dass der Name in der Liste vom Zertifikatsnamen abweicht. Und 696849... ist nicht der Name, sondern die Seriennummer des Zertifikats. Um sie zu überprüfen, muss man zuerst das Zertifikat öffnen.

    In deinem Fall müsste der Zertifikatsbesitzer "PositiveSSL Wildcard" sein. Gibt's bei dir einen Eintrag mit diesem o.ä. Namen in der Zertifikatsliste?

    Ich habe bei mir z.B. den Eintrag "PositiveSSL CA 2". Das dort eingebundene Zertifikat ist bis 2020 gültig.

  • Danke für den Hinweis das es ja die SN ist und nicht der Name. Das hätte ich auch selber merken müssen.
    Natürlich habe ich nicht bei allen Zertifikate die SN kontrolliert.
    Ich wollte schlau sein und habe alle Zertifikate zu Sicherung exportiert dann alle Einträge in der Datenbank gelöscht.
    Danach versucht eine Mail zu versenden, dann der übliche Hinweis und das Zertifikat importiert.
    Jetzt habe ich ein Zertifikat mit dem Namen AddTrust External CA Root in der Datenbank, aber es ist nicht das welches ich gesucht habe.
    Hinzu kommt das bei der Sicherung leide nur die Einträge aber nicht die Zertifikate exportiert.
    Jetzt versuche ich gerade diese aus den Mülleimer zurück zu holen. Ob das geht kann ich noch nicht sagen.
    So kann man sich auch Arbeit machen :)
    Das PositiveSSL CA 2 habe ich auch mit der gleichen Gültigkeit.

    Mal eine Grundsätzliche Frage, die Zertifikatsdatenbank ist doch nur dafür da das ich nicht jedes mal das entsprechende Zertifikat downloaden muss.
    Somit wäre es nicht so schlimm das ich die Zertifikate gelöscht habe, die kommen ja dann bei bedarf wieder.

  • Dann schließe ich mal ein Fehler meinerseits aus

    Das wird wohl so sein. Es sieht nämlich danach aus, dass das Serverzertifikat doch NICHT erneuert wurde. Wenn man z.B. https://www.servertools24.de/ oder https://www.servertools24.de:8443/login_up.php3 aufruft, wird angezeigt, dass das Zertifikat längst abgelaufen ist. https://de.ssl-tools.net/mailservers/servertools24.de zeigt ebenfalls, dass das Zertifikat von Parallels Panel für mail.servertools24.de abgelaufen ist. Die Logs von Gwen bestätigen dies auch. Welche Serverzertifikate ausgetauscht worden seien, ist daher nicht verständlich.


    Ich werde berichte wie es weiter geht.

    Poste mal, was sie auf die Logs antworten. Da sind wir hier alle gespannt.


    Mal eine Grundsätzliche Frage, die Zertifikatsdatenbank ist doch nur dafür da das ich nicht jedes mal das entsprechende Zertifikat downloaden muss. Somit wäre es nicht so schlimm das ich die Zertifikate gelöscht habe, die kommen ja dann bei bedarf wieder.

    TB! hat eine eigene Zertifikatsdatenbank, die man manuell bearbeiten kann. Man kann dort also neue Zertifikate hinzufügen oder welche löschen. Gelöschte bleiben dabei grundsätzlich gelöscht. Ritlabs aktualisiert die Zertifikatsdatenbank zwar ab und zu, aber nicht regelmäßig.

    Gespeichert in Trusted Root CA sind grundsätzlich nur sog. Wurzelzertifikate (daher Root). In deinem Fall muss dort z.B. das Zertifikat von AddTrust External CA Root enthalten und noch gültig sein (s. Zeile ROOT im Sendeprotokoll). Wenn es fehlen würde, würdest du eine entsprechende Fehlermeldung im Protokoll sehen. Dann musst du dieses Zertifikat manuell importieren. Ein Serverzertifikat hingegen muss auf dem Server ausgetauscht werden und da kann man mit TB! nichts machen.

  • So, ich kann wieder E-mails versenden.
    Nach dem ich alle Zertifikate manuell in die Zertifikatsdatenbank zurück kopiert und TB neu gestartet habe bekomme ich keine Fehlermeldung mehr.
    Ich hatte kurz zuvor eine Mail an meinen Provider mit den LOG von GwenDragon gesendet. Aber so schnell sind die nicht das Sie darauf reagiert haben.

    Ich habe auch noch keine Rückmeldung.


    Vielleicht war doch noch ein veraltest Zertifikat in der Datenbank. Bewusst habe ich dort nicht gelöscht oder verändert.

    Wenn ich eine Antwort von meinen WebProvider bekomme werde ich diese hier posten. Vielleicht liest er ja hier mit. :)

    Jedenfalls habe ich dadurch einiges gelernt.

    Danke und Grüße

  • Vielleicht war doch noch ein veraltest Zertifikat in der Datenbank. Bewusst habe ich dort nicht gelöscht oder verändert.

    Wie ich bereits geschrieben habe, wird die TB!-Zertifikatsdatenbank nicht automatisch aktualisiert. Wenn also ein Zertifikat fehlt oder abgelaufen ist, dann muss man sich selbst darum kümmern.


    So, ich kann wieder E-mails versenden.

    Kannst du einen Auszug aus dem Sendeprotokoll hier posten? Wie sieht es jetzt mit diesem servertools24.de Zertifikat aus?

  • ist jetzt um ein Jahr verlängert - und nächstes Jahr geht es von vorne los.

    Hier das Protokoll.

    SEND - Zertifikat S/N: 632684924FE9DCA991D441373A0C7AAC, Algorithmus: RSA (4096 Bits), ausgestellt von 01.04.2017 bis 01.04.2018 23:59:59, für 2 Host(s): *.servertools24.de, servertools24.de.
    SEND - Besitzer: "*.servertools24.de".
    SEND - Aussteller: "US", "GeoTrust Inc.", "RapidSSL SHA256 CA - G2". Gültig ab 10.06.2014 bis 09.06.2024 23:59:59.
    SEND - Root: "US", "GeoTrust Inc.", "(c) 2008 GeoTrust Inc. - For authorized use only", "GeoTrust Primary Certification Authority - G3" Gültig ab 02.04.2008 bis 01.12.2037 23:59:59.

  • Wenn dein Mailserver bald gültige Zertifikate bekommt, kannst du glücklich sein.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Leider bekomme ich keine gültigen Zertifikate.

    Man ist der Meinung, da ich ja wieder Mails per SSL versenden kann, ist alles gut.
    Es gab keine Reaktion auf den openssl-Tests von GwenDragon. Statt dessen schreiben sie,
    . . . "wir werlauben uns das Ticket zu schließen"

    Für meine HomePage nutze ich Lets encrypt.
    Ich habe gerade gelesen, dass ich mit Lets encrypt theoretisch auch Zertifikate (für max.90 Tage) für den Mailversand erstellen kann.

    Mal sehen ob ich die installieren kann.

  • Der Support hat wirklich keine Ahnung und der Anbieter ist nicht besonders kundenfreundlich.


    Wie kannst du LetsEncrypt verwenden? Ich dachte du administrierst den Server nicht?

    Ich nehme an, da wird Plesk verwendet.
    Unter https://HIERDEINEDOMAIN.DE:8443/admin/ssl-certificate/list kannst du dem Mailserver dein Zertfikat zuweisen.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Der Support hat wirklich keine Ahnung und der Anbieter ist nicht besonders kundenfreundlich.

    Ja das stimmt und ich werde der Thema auch noch einmal anmahnen.

    Und ja, ich nutze Plesk. Allerdings habe ich keine Rechte um auf /8443/admin/ zu zugreifen.
    Ich kann nur unter "SSL-Zertifikate" das wäre dann der Pfad 8443/smb/ssl-certificate/list/id/
    ein entsprechendes Zertifikat hochzuladen.
    Aber erst einmal ist der Support an der Reihe.

  • ……/smb/…… kommt wenn du als Nutzer bei deiner Domain eingeloggt bist.

    Ich dachte es ist dein Server, da musst du dich mit dem Nutzer admin einloggen.

    Hast du einen Server gemietet, bei dem du extra Support bezahlst oder ist das ein sog. Managed Server? Dann ist der Support dran, das zu regeln, aber schnellstens.
    Wenn du den Server ohne Support gebucht hast, ist es deine Verantwortung dafür zu sorgen, dass alles läuft. Nur ein bisschen in Plesk konfigurieren reicht nicht.
    Ich hab so das Gefühl, du betreibst den Server ohne Hintergrundwissen und könntest damit Probleme verursachen, wenn der Server nicht sicher ist.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.