# Mail senden funktioniert nicht mit SSL



## gschmi01 (26. Jul 2014)

Hallo Leute

Ich habe in einer Java-Applikation einen Mailclient implementiert. Bisher hat alles tadellos funktioniert. Nachdem t-online die SSL-Verschlüsselung eingeführt hat, wollte ich das Programm dahingehend anpassen. Leider ist mir das bisher nicht gelungen. Da in diesem Forum die Suche nach SSL keine Treffer brachte und ich mit googlen nicht weiter gekommen bin, poste ich das Problem. Ich verwende die Java-Version 1.6.0.25 und JavaMail 1.4.1.

SMTP-Server und Port sind gemäß dieser Veröffentlichung von t-online gesetzt:
Wie lauten die Server für ein- und ausgehende E-Mails? (Posteingangsserver und Postausgangsserver)


Hier die relevanten Code-Zeilen:

props = System.getProperties();
props.setProperty("mail.smtps.host", "securesmtp.t-online.de");
props.setProperty("mail.smtps.port", "465");
props.setProperty("mail.transport.protocol", "smtps");
props.setProperty("mail.smtps.auth", "true");
props.setProperty("mail.smtps.ssl.trust", "securesmtp.t-online.de");
auth = new SimpleAuthenticator();
session = Session.getInstance(props, auth);
...
(Mailmessage aufbauen)
...
transport = session.getTransport("smtps");
transport.connect();
transport.sendMessage(mmsg, mmsg.getAllRecipients());
transport.close();


Bereits beim Aufruf von transport.connect() wird eine Exception geworfen. Hier das Debug-Protokoll:

DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtps,com.sun.mail.smtp.SMTPSSLTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "securesmtp.t-online.de", port 465, isSSL true
DEBUG SMTP: exception reading response: javax.net.ssl.SSLException: Server key


Kann mir jemand einen Tipp geben, wie ich da weiter komme?


----------



## Topfpflanze (26. Jul 2014)

Du könntest versuchen die MAils vorher mit PGP zu verschlüsseln.


----------



## ceving (26. Jul 2014)

gschmi01 hat gesagt.:


> DEBUG SMTP: exception reading response: javax.net.ssl.SSLException: Server key



Entscheidend ist was denn nun genau mit dem Server key ist! Wie geht die Meldung denn weiter?

Manchmal fehlt einfach das CA-Zertifikat von der CA, die das Server-Zertifikat der Gegenstelle ausgestellt hat. Das muss man dann lediglich in den lokalen Java-Keystore importieren. Das geht mit dem keytool-Befehl.


----------



## Anti-Banane (27. Jul 2014)

wow ... typisch DTAG ... ich glaub denen müsste man echtmal so ne kleine H-bombe auf den chef-sessel schmuggeln

nicht nur das diese absoluten versager es nicht auf die reihe bekommen ne dsl-line zu schalten (da ich ja mitlerweile nicht mehr für die 1&1 arbeite kann ich ja mal interna ausplaudern) ... diese absoluten voll-****** schaffen es auch nicht mal im rahmen dieser (in meinen augen längst überfälligen) EmiG-aktion mal das wort SICHERHEIT zu verstehen


als kleine erklärung : TCP/465 ist SMTPS > SMTP over SSL
ein ur-altes und mitlerweile eigentlich eingestampftes verfahren was auf grund bekannter sicherheitsprobleme nicht genutzt werden sollte

alle anderen provider von EmiG (E-Mail made in Germany) sind wenigstens so vernünftig und nutzen mit TCP/587 SMTP over TLS
was zwar auch unnötig ist da korrekt eingerichtete mail-server auch normal über TCP/25 STARTTLS verarbeiten ... aber naja ... sei es drum ... vermutlich als abgrenzung dafür das TCP/25 für die inter-server-kommunikation genutzt wird und eigentlich nicht (mehr) für die client-kommunikation



@TO
auch wenn du deinen code mal in code-tags hättest schreiben können ... kann ich keinen fehler erkennen ... und auch die fehlermeldung lässt auf einen fehler seitens DTAG schließen

ich gehe von aus das hier java bewusst das DTAG-zertifikat blockieren wird da es vermutlich ungültig sein wird


// EDIT
ok .. ich habs gerade mal mit JavaMail 1.5.1 unter Java1.8u11 ausprobiert : bei mir läufts soweit bis zum login was natürlich abgelehnt wird da ich kein login bei DTAG habe

ergo : es ist möglich das es an deiner veralteten Java(-Mail) version liegt
bringt mal java und javamail auf den aktuellen stand

zusätzlich würde ich auch die beiden zeilen mit dem ssl.trust und dem authenticator rausnehmen ... wenn die verbindung sauber läuft sollten diese überflüssig sein


----------



## gschmi01 (27. Jul 2014)

Hallo

Danke zunächst für Eure Antworten!

@Topfpflanze:
PGP lasse ich mal außen vor. Ich habe eine reine Java-Applikation entwickelt und dabei soll es auch bleiben.

@ceving:
Die Debug-Meldung umfasst genau den geposteten Umfang. Die aufgetretene Exception wird in einer catch-Clause abgefangen und die Kommunikation zum Mailserver bricht ab.
Zum keytool siehe mein weiteres Vorgehen.

@Anti-Banane:
Ein Upgrade der JavaVM und JavaMail sehe ich derzeit noch nicht als erforderlich an. Ich werde es dann machen, wenn die Notwendigkeit strikt gegeben ist: Meine Java-Applikation ist ein Vereinsverwaltungsprogramm, welches von mehreren vereinsinternen Anwendern benutzt wird. Den Aufwand, JavaVM und JavaMail dort auszuwechseln, vermeide ich, so lange es geht.


Aktueller Stand:
Aufgrund der Beiträge von ceving und Anti-Banane habe ich mich heute Nachmittag durch Dokumentationen und Websites gewühlt. Ergebnis:
Im JSDK kommt die Datei ...\lib\security\cacerts mit, welche nur "Basis-Zertifikate" enthält. Das Zertifikat von t-online ist jedoch selbst zertifiziert und daher dort nicht enthalten.

Weiteres Vorgehen:
Ich werde mit keytool versuchen, das Zertifikat von t-online zu importieren und die so modifizierte Datei über System.setProperty() anwenden zu lassen.


Dabei sehe ich noch folgende Hürden:

Ich habe Zertifikate von t-online gefunden -> https://www.telesec.de/de/public-key-infrastruktur/support/root-zertifikate
Dort gibt es mehrere Zertifikate. Ob für den Server "securesmtp.t-online.de" das Richtige dabei ist, kann ich nicht sagen. Im Zweifelsfall werde ich mal auf gut Glück alle 4 importieren.

Dem derzeit beobachteten Connect-Versuch stehe ich noch misstrauisch gegenüber. Der SSL-Handshake ist in -> JSSE Reference Guide for Java SE 6 im Abschnitt "The SSL Protocol" grafisch dargestellt. Demnach sollte es ein Client- und Server-Hello geben, bevor mit Zertifikaten begonnen wird. Diese anfänglichen "Hellos" habe ich im Debug-Protokoll nicht gefunden. Es gab sofort die Exception wegen dem Server key.

Fall jemand zu den beiden genannten Hürden etwas sagen könnte, wäre das fein.


----------



## Anti-Banane (29. Jul 2014)

1) hier selbst was mit keytool und irgendwelche zertifikaten rumzuspielen ist schon mal definitiv der FALSCHE ansatz > schlag dir diese idee bitte sofort wieder aus dem kopf

2) JavaMail ist nur eine kleine lib ... die du vermutlich als bundle mit deiner app lieferst ... ergo : bist du als entwickler durchaus in der lage diese abhängigkeit zu ändern und eine aktuelle version beizulegen
oder hat wirklich jeder der deinen code nutzt JavaMail so in seinem system "installiert" das diese lib von java genutzt werden kann ?
wenn ja : wie genau (ich wette das hier einige auf die sehr falsche idee gekommen sind es ins java-home zu werfen ... noch falschere idee)

3) die EmiG-aktion ist noch gar nicht so alt ... und es wurden dafür auch teilweise neue zertifikate erstellt die in alten java-versionen nicht enhalten sind
klar kann man diese nachträglich einrichten
die sehr viel bessere idee wäre allerdings das komplette system upzudaten
sollte also noch XP genutzt werden > sollte dringends auf mindestens vista oder besser gleich auf 7 upgegraded werden
sollte noch Java6 genutzt werden > hier schon alleine aus diveresen sicherheitskreterien auf mindestens Java7 oder besser gleich Java8 updaten


du bist leider mal wieder so ein kandidat was ich jeden tag auf arbeit erlebe wenn es um das thema geht oder auch im freundes kreis : mit EmiG haben die "großen" endlich mal ne zwangsaktion durchgesetzt ... und wenn man es weiter nutzen will MUSS man halt hinter her und seinen ur-alt-krams mal auf den aktuellen stand der technik bringen ...
der fehler liegt hier eindeutig am user ...


bezüglich des fehlenden HELLO

noch mal für zivilisten der unterschied zwischen SSL und STARTTLS :

SSL : ein sicherer kanal über den eine unsicherer verbindung abläuft
hier muss also ERST mit den zertifikaten die verbindung hergestellt und gesichert werden und DANN läuft das eigentliche SMTP ab

STARTTLS : eine sichere kommunikation über einen unsicheren kanal
hier wird ganz normal eine unsichere verbindung hergestellt und sich erstmal begrüßt ... es kommt also sofort das HELLO ... und erst danach mit STARTTLS der punkt an dem das protokoll selbst mit TLS abgesichert wird


und wie ich in meinem rage-post zum ausdruck gebracht habe : DTAG nutzt halt SSL und nicht STARTTLS ... weshalb ERST das zertifikat kommt und DANN das HELLO ... (bzw korrekterweise das EHLO)
schon alleine aus diesem grund würde ich den mail-provider wechseln oder einen eigenen aufsetzen


----------



## gschmi01 (29. Jul 2014)

Hallo Anti-Banane

Auch wenn der Umgangston in der letzten Antwort für mein Empfinden unpassend war, inhaltlich wurde der "Pudel's Kern" getroffen.

Ich habe heute meine Java-Plattform auf JRE 1.8.0-11 und JavaMail 1.5.2 hochgezogen. Damit konnte ich SSL-Mailverbindungen zu t-online und TLS-Mailverbindungen zu Web.de nahezu ad hoc zum Laufen bringen. Mit Zertifikaten musste ich nichts machen.

Danke!


----------



## Anti-Banane2 (30. Jul 2014)

worüber ich mich so extrem aufgeregt habe ist das du dir deinen fehler selbst nicht eingestehen wolltest


> Ein Upgrade der JavaVM und JavaMail sehe ich derzeit noch nicht als erforderlich an.


es war ja scheinbar wohl eben doch notwendig

anstatt es einfach mal auszuprobieren wenn der hinweis schon von jemanden kommt der das produktiv nutzt und auch gewisse hintergründe kennt ... nein .. lieber erstmal flamen nach dem motto : "an mir kann es ja nicht liegen"

glaub mir ... ich hatte schon mit genug leuten zu tun die genau so gedacht haben ... und fast alle (bis auf wirklich wenige ausnahmen) hatten ein ähnliches problem wie du : ich hab gesagt woran es liegt ... das wurde erstmal abgestritten und jede andere völlig sinnlose möglichkeit und erklärung versucht ... und am ende war es genau das was ich gesagt hatte ... sei es nun der punkt : "wie wäre es mal mit nem system-update" oder "DSL-probleme ? überhaupt richtig verkabelt ?" .. das prinzip bleibt das gleiche


----------

