Gelöst 1.3.18.0: Bug beim Versenden von SSL EMail

[DITH-Shop]

Bis einschl. 1.3.17.1 hat der EMail Versand (SMTP - Port 465) problemlos funktioniert.

Seit dem Update ist das nicht mehr möglich. Fehlermeldung:

"Authenticate as SSL client failed. You might be connecting to non SSL Port."

Aber mein eigener Mailserver ist definitiv über 465 ein SSL Port


Als Workaround muss ich nun ungesichert über Port 25 gehen, das ist aber nun wirklich alles andere als gewünscht.

 

[derjoe]

Hallo,
das tritt bei uns auch auf einem Rechner mit Windows 7 auf. Bei Windows 10 dagegen nicht.
Erst seit ich heute morgen 1.3.18.0 installiert habe. Egal ob Port 587 oder 25 mit STARTTLS.
Wurde etwas geändert?

Gruß,
Ronald

 

[frank-idevice]

Bei uns geht nur noch SSL auf 465. Bei STARTTLS geht gar nichts mehr. Laut Support wurde an der TLS Verschlüsselung gearbeitet.

 

[Stephan K.]

Ich habe bereits ein Ticket dazu geöffnet, wofür es jedoch noch keinen Fix gibt.
Port 465 mit SSL-Verschlüsselung geht. Alternativ Port 25 ohne Verschlüsselung.

Das Verschlüsselungsprotokoll in der Wawi wurde von TLS 1.1 auf 1.2 umgestellt. Auch, wenn das Windows 7 Update dazu bereits ein Jahr alt ist und im System aktiviert ist, schafft es die Wawi nicht, die Registry-Flag zur Verwendung TLS 1.2 zu setzen. Es wird also versucht etwas zu nutzen, was nicht freigegeben wurde.

Edit: Hier das obligatorische Win7-Update

https://support.microsoft.com/de-de...tls-1-2-as-a-default-secure-protocols-in#easy

 

[MESSBAR]

Bei uns funktioniert auch SSL über Port 465 sowohl auf Windows 7 als auch Windows 8.1 seit der gestrigen Umstellung auf 1.3.18.0 nicht mehr, lediglich Windows 10 funktioniert auch bei uns.

Es gab diesmal auch keinen letzten Beta-Test der 1.3.18.0, jedenfalls kam bei uns keine Info darüber, insofern bin ich sehr verwundert, wer diese Version freigegeben hat ??? Das ist doch mist, wenn der Laden steht weil jemand nicht fertig getestete Software freigibt.

 

[Stephan K.]

Bei uns funktioniert auch SSL über Port 465 sowohl auf Windows 7 als auch Windows 8.1 seit der gestrigen Umstellung auf 1.3.18.0 nicht mehr, lediglich Windows 10 funktioniert auch bei uns.

Es gab diesmal auch keinen letzten Beta-Test der 1.3.18.0, jedenfalls kam bei uns keine Info darüber, insofern bin ich sehr verwundert, wer diese Version freigegeben hat ??? Das ist doch mist, wenn der Laden steht weil jemand nicht fertig getestete Software freigibt.

Ach, ich bin ganz allgemein von meinen Hosting-Einstellungen ausgegangen. Das kann natürlich jeder Hoster unterschiedlich handhaben. Schau am besten mal nach, welche alternativen Möglichkeiten gegeben sind bei deinem Hoster.

 

[MESSBAR]

Äh, deine Antwort verstehe ich nicht.

Es geht nicht um alternative Einstellungen (Port 25, unverschlüsselt geht, klar aber das ist ja wohl keine Lösung), sondern darum, das bei uns SSL über Port 465 seit 1.3.18.0 ebenfalls nicht geht. Oder anders ausgedrückt: Keine einzige Verschlüsselungs-Variante funktioniert aktuell mit 1.3.18.0 unter Wind 7 - 8.1.

 

[delaware]

Bei uns genau das selbe. Was war das den für ein Update ?
Anstatt das was besser wird ist alles schlimmer..

Ich habe eben ein Ticket dazu geschrieben..

Nachdem sich keiner meldete habe ich auch den Port geändert auf 465 und auf SSL statt auf Start TLS geändert

danach lief es endlich

 

[NewBuy]

Bei uns funktioniert auch SSL über Port 465 sowohl auf Windows 7 als auch Windows 8.1 seit der gestrigen Umstellung auf 1.3.18.0 nicht mehr, lediglich Windows 10 funktioniert auch bei uns.

Es gab diesmal auch keinen letzten Beta-Test der 1.3.18.0, jedenfalls kam bei uns keine Info darüber, insofern bin ich sehr verwundert, wer diese Version freigegeben hat ??? Das ist doch mist, wenn der Laden steht weil jemand nicht fertig getestete Software freigibt.

Es gab sehr wohl einen "Beta-Test" für Piloten. Aber hier scheinen alle auf der Windows 10 zu sein, denn dann wäre der Fehler da aufgefallen.

 

[Stephan K.]

Es gab sehr wohl einen "Beta-Test" für Piloten. Aber hier scheinen alle auf der Windows 10 zu sein, denn dann wäre der Fehler da aufgefallen.

Ich denke, wenn man sich die globalen Zahlen anschaut (de.statista.com), dann ist noch ca. 34% mit Windows7 unterwegs. Dagegen 27% Windows 10. Win 8 (ebenfalls betroffen) mit 8%. Also knapp 42% Win 7+8, dagegen 27% Win10.

 

[Rico Giesler]

Hier gibt’s eine Hotfix-Version dazu: https://forum.jtl-software.de/threads/jtl-wawi-1-3-18-1-dsgvo.111104/#post-614126

 

[mschop]

@Rico Giesler Wir haben das Problem hier immer noch, trotz Update auf die 1.3.18.1. Hinweis: Wir arbeiten mit RDP-Sitzungen auf dem Server (Windows Server 2016 Standard mit allen Updates installiert)

 

[DITH-Shop]

In der 1.3.19.3 auch.

 

[Rico Giesler]

In dem Fall bitte direkt an unseren Support wenden, damit die Kollegen sich das genauer anschauen können.
Wichtige Infos wie "Welche Updates wurden genau installiert" und "Welches Betriebssystem wird genutzt" helfen bei der Analyse.

 

[MESSBAR]

Offensichtlich ist man bei JTL zu dröselig, sich an die eigenen Fehler zu erinnern.
Wir haben gerade das Update auf 1.3.20 gemacht und festgestellt, dass der SSL-Versand von E-Mails wieder nicht funktioniert. Offensichtlich wurde der Hotfix aus der 1.3.18.1 nicht in die weiteren Versionen fortgeschrieben.
Bitte dringend nachholen und diesen Hotfix auch für alle zukünftigen Versionen integrieren. Ihr zwingt gerade einen riesen Teil eurer Kunden die SSL-Verschlüsselung abzuschalten.
Solange Windows nur scheinbar 1.2 korrekt unterstützt, experimentiert bitte irgendwo im Beta-Bereich damit rum.

Mit AMTANGEE als Mail-Server funktioniert es derzeit jedenfalls weder auf Windows 8, 10 oder Windows Server 2012

 

[Rico Giesler]

Wichtig ist dass die Clients TLS 1.2 unterstützen. Wenn ihr hier dennoch Probleme mit der aktuellen Version habt, dann möchte ich euch bitten euch an unseren Support zu wenden, damit genau geprüft werden kann woran es hängt.

 

[MESSBAR]

Das ist längst passiert aber vergesst doch bitte solche Aussagen wie „die Clients müssen TLS 1.2 unterstützen“.
Bereits vor 3 Monaten mussten wir alle feststellen, dass die TLS 1.2 Unterstützung unter Windows bestenfalls zwischen Microsoft-Produkten funktioniert.
Warum muss hier jemand bei JTL unbedingt mit dem Kopf durch die TLS-Wand gehen und warum taucht der Wegfall des TLS-Hotfixes in keinem Changelog auf ? Genau für solche Hinweise ist doch der Changelog da.

 

[SebastianB]

Hallo,

also: Es ist nicht so, dass wir die Clients auf TLS 1.2 zwingen. Wir erlauben einzig TLS 1.2 - das ist nunmal im Zuge der DGSVO auch nicht mehr anders zu regeln, da TLS 1.2 unterm Strich das letzte sichere Übertragungsprotokoll ist. Somit sind wir darauf angewiesen, TLS 1.2 zu unterstützen. Wenn der Client nur TLS 1.1 anbietet funktioniert das ebenfalls problemlos. Problematisch wird es nur dann, wenn der Client TLS 1.2 vorgibt, es dann aber zu Problemen im weiteren Verlauf der TLS-Sitzung kommt.

Nun ist es tatsächlich so, dass Windows mit dem TLS 1.2 mehrere Probleme hat - insbesondere ging mit der 1.3.19.x - also auch mit dem "Hotfix" - kein Mailversand mehr auf diversen Rechnern mit Windows Server 2016. Deshalb mussten wir hier nachbessern und haben entsprechend in der 1.3.20.0 hier nachgebessert durch das Update der E-Mail-Komponente. Wenn es jetzt dadurch bei einzelnen Personen zu anderen Systemen kommt, dann wendet Euch doch bitte an den Support, damit wir uns das anschauen können - wir haben hier leider nicht die Möglichkeit, jede Kombination von Server und Client zu testen.

LG
Sebastian

 

[LED-Arena]

Hallo Zusammen ich habe immer noch die fehlermeldung das mein Antivieruns oder firrewall die emails blockt das die nicht rausgehen können
warum kommt das jetzt hatte ich früher nie ich habe avira antivirus und standart windows firewall.
das komische ist ich habe den rechner mal von einem andereen roiuter aus wersucht da gings irgendwie in der Frizbox von Kbelbw gibts glaub ein problem weis einer wo man das einstellen kann?
weil im normalen outlook funktoniert der email versand tadellos egal von wo nur über die wawi habe ich so probleme .

das nervt tierisch vorallen wenn man unter zeitdruck steht.
und aufträge raus müssen.