Probleme bei Javamail und StartTLS
Alexander
ich versuche gerade eine Mail über einen SMTP-Server mit TLS (Port 25)
zu versenden. Zum Testen habe ich einfach mal eine Klasse probeweise
runtergetippt ... sicherlich noch mit einigen Formfehlern, aber ich will
ja nur die Funktion ergründen ;-)
import java.util.Properties;
import javax.mail.*;
import javax.mail.internet.*;
import com.sun.mail.smtp.*;
public class Mailtest {
public static void main (String args[]) throws Exception {
Properties props = System.getProperties();
Session session = Session.getDefaultInstance(props, null);
MimeMessage message = new MimeMessage(session);
message.setFrom(new InternetAddress("b...@bla.de", "bla"));
message.addRecipient(Message.RecipientType.TO,
new InternetAddress("bl...@bla2.de"));
message.setSubject("Test");
message.setContent("Test", "text/plain");
SMTPTransport transport = new SMTPTransport(session, new
URLName("bla.host.de"));
transport.setStartTLS(true);
transport.connect("bla.host.de", "user", "pass");
transport.sendMessage(message, message.getAllRecipients());
transport.close();
}
}
Nach mehreren vergeblichen Versuchen die Javamail-Api zu verstehen bin
ich dann zumindest ein wenig durchgestiegen ... Leider bekomme ich aber
eine Fehlermeldung mit der ich nichts anfangen kann:
xception in thread "main" javax.mail.MessagingException: Can't send
command to SMTP host;
nested exception is:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1365)
at com.sun.mail.smtp.SMTPTransport.sendCommand(SMTPTransport.java:1353)
at com.sun.mail.smtp.SMTPTransport.ehlo(SMTPTransport.java:794)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:336)
at javax.mail.Service.connect(Service.java:236)
at javax.mail.Service.connect(Service.java:137)
at Mailtest.main(Mailtest.java:48)
Ich bin für Hilfe sehr dankbar ...
Gruß
Alexander
Klaus Mueller
habe das selbst noch nicht getestet. Sieht aber aehnlich aus, wie bei HTTPS.
Das Problem duerfte sein, dass Java das Zertifikat des Mailservers nicht
kennt und damit einfach die SSL Verbindung nicht aufbauen kann. Du musst
also erst dem Java-Keystore die Zertifikate beibringen, welche dem
Zertifizierungspfad des Webservers entspricht.
Als Beispiel mal https://meine.deutsche-bank.de/ . Wenn Du da eine
Verbindung mit Java aufbauen willst, dann muss im Keystore das Zertifikat
fuer Verisign enthalten sein.
Klaus
Alexander
> Das Problem duerfte sein, dass Java das Zertifikat des Mailservers nicht
> kennt und damit einfach die SSL Verbindung nicht aufbauen kann. Du musst
> also erst dem Java-Keystore die Zertifikate beibringen, welche dem
> Zertifizierungspfad des Webservers entspricht.
Oje ... :-(
Damit hab ich ja noch gar nicht gearbeitet ... Gibt es da verständliche
Tutorials?
Kann man Java eigentlich sagen, das es von einem bestimmten Server ein
Zertifikat immer automatisch akzeptiert, auch wenn es der
Serverbetreiber mal ändert?
Gruß
Alexander
Frank Buss
> Kann man Java eigentlich sagen, das es von einem bestimmten Server ein
> Zertifikat immer automatisch akzeptiert, auch wenn es der
> Serverbetreiber mal ändert?
das ist nicht Sinn der Sache, aber zu Testzwecken kannst du jedem
Zertifikat vertrauen:
http://devcentral.f5.com/weblogs/joe/archive/2005/07/06/1345.aspx
Einfach die Klasse ins Projekt kopieren, "XTrustProvider.install()"
aufrufen und nicht beschweren, wenn deine eMail durch eine
man-in-the-middle-Attacke mitgelesen wurden :-) Aber die Weiterleitung der
eMail wird ja sowieso nicht sicher sein, daher ist das vielleicht sogar
unkritisch.
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Alexander Neid
> Alexander wrote:
>
>> Kann man Java eigentlich sagen, das es von einem bestimmten Server ein
>> Zertifikat immer automatisch akzeptiert, auch wenn es der
>> Serverbetreiber mal ändert?
>
> das ist nicht Sinn der Sache,
Da hast Du recht, aber diesen Server kann ich vertrauen. Der Server und
das Programm laufen im gleichen Subnetz (255.255.255.0).
> aber zu Testzwecken kannst du jedem
> Zertifikat vertrauen:
>
> http://devcentral.f5.com/weblogs/joe/archive/2005/07/06/1345.aspx
>
> Einfach die Klasse ins Projekt kopieren, "XTrustProvider.install()"
> aufrufen und nicht beschweren, wenn deine eMail durch eine
> man-in-the-middle-Attacke mitgelesen wurden :-) Aber die Weiterleitung der
> eMail wird ja sowieso nicht sicher sein, daher ist das vielleicht sogar
> unkritisch.
Das werde ich mir mal ansehen.
Gruß
Alexander
Olaf Willuhn
> Kann man Java eigentlich sagen, das es von einem bestimmten Server ein
> Zertifikat immer automatisch akzeptiert, auch wenn es der
> Serverbetreiber mal ändert?
Fuer diesen Fall sind ja CAs wie Thawte, Verisign und Co. "erfunden"
worden. Um eine Vertrauenskette zu erzeugen, die das manuelle Absegnen
jedes Server-Zertifikats erspart. Sprich: Dein Programm wird auch dann
funktionieren, wenn nicht das Server-Zertifikat selbst in deinem
Keystore steht, es aber von einer vertrauenswuerdigen CA signiert
wurde und sich deren Zertifikat stattdessen in deinem Keystore befindet.
Wenn der Server-Betreiber seine Zertifikate also von einer anerkannten
CA signieren laesst, kann es dir egal sein, wenn sich das Server-Zertifikat
aendert. Vorausgesetzt natuerlich, dass alle weiteren Kriterien
(Gueltigkeits-Zeitraum, Hostname bzw CN, etc) stimmen. Jeder etablierte
Webbrowser macht das genauso.
Gruss
Olaf