Invalid or untrusted server SSL certificate

[jjzhuang]

No I haven't received anything. Thanks!

[GaryParr]

Traveling... haven't had time to send anything. Sorry.

[pjunker]

hi,

i have the same problem under linux with zdesktop_0_92_build_1418.

i'm using no ssl-encryption and to send a email doesn't work anymore.

the logfile says:

2008-12-11 17:15:48,076 DEBUG [btpool0-13] [mid=2;] offline - smtp: failed to send mail (1889): test
com.zimbra.common.service.ServiceException: system failure: MessagingException
ExceptionId:btpool0-13:1229012148076:63b5e0e4f4a4ae3c
Code:service.FAILURE
at com.zimbra.common.service.ServiceException.FAILURE (ServiceException.java:253)
at com.zimbra.cs.mailbox.MailSender.sendMimeMessage(M ailSender.java:330)
at com.zimbra.cs.mailbox.LocalMailbox.sendPendingMess ages(LocalMailbox.java:209)
at com.zimbra.cs.account.offline.OfflineDataSource.ch eckPendingMessages(OfflineDataSource.java:326)
at com.zimbra.cs.datasource.ImapFolderSync.fetchMessa ges(ImapFolderSync.java:833)
at com.zimbra.cs.datasource.ImapFolderSync.fetchMessa ges(ImapFolderSync.java:820)
at com.zimbra.cs.datasource.ImapFolderSync.syncMessag es(ImapFolderSync.java:218)
at com.zimbra.cs.datasource.ImapSync.syncMessages(Ima pSync.java:214)
at com.zimbra.cs.datasource.ImapSync.syncFolders(Imap Sync.java:156)
at com.zimbra.cs.datasource.ImapSync.importData(ImapS ync.java:117)
at com.zimbra.cs.datasource.DataSourceManager.importD ata(DataSourceManager.java:154)
at com.zimbra.cs.mailbox.LocalMailbox.importData(Loca lMailbox.java:367)
at com.zimbra.cs.mailbox.LocalMailbox.syncAllLocalDat aSources(LocalMailbox.java:340)
at com.zimbra.cs.mailbox.LocalMailbox.sync(LocalMailb ox.java:401)
at com.zimbra.cs.service.offline.OfflineSync.handle(O fflineSync.java:48)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:429)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:286)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:160)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:269)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:727)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:190)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(Ser vletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle(Se rvletHandler.java:362)
at org.mortbay.jetty.security.SecurityHandler.handle( SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(Se ssionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(Co ntextHandler.java:716)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebA ppContext.java:406)
at org.mortbay.jetty.handler.ContextHandlerCollection .handle(ContextHandlerCollection.java:211)
at org.mortbay.jetty.handler.HandlerCollection.handle (HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:139)
at org.mortbay.jetty.handler.RewriteHandler.handle(Re writeHandler.java:176)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:313)
at org.mortbay.jetty.HttpConnection.handleRequest(Htt pConnection.java:506)
at org.mortbay.jetty.HttpConnection$RequestHandler.co ntent(HttpConnection.java:844)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser. java:644)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpPa rser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnec tion.java:381)
at org.mortbay.io.nio.SelectChannelEndPoint.run(Selec tChannelEndPoint.java:396)
at org.mortbay.thread.BoundedThreadPool$PoolThread.ru n(BoundedThreadPool.java:442)
Caused by: com.zimbra.cs.mailbox.MailSender$SafeMessagingExce ption: java.security.cert.CertificateExpiredException: NotAfter: Wed May 02 21:53:56 GMT+01:00 2007; chained exception is:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Wed May 02 21:53:56 GMT+01:00 2007
at com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTrans port.java:1326)
at com.sun.mail.smtp.SMTPTransport.protocolConnect(SM TPTransport.java:407)
at javax.mail.Service.connect(Service.java:297)
at javax.mail.Service.connect(Service.java:156)
at javax.mail.Service.connect(Service.java:105)
at javax.mail.Transport.send0(Transport.java:168)
at javax.mail.Transport.send(Transport.java:98)
at com.zimbra.cs.mailbox.MailSender.sendMessage(MailS ender.java:535)
at com.zimbra.cs.mailbox.MailSender.sendMimeMessage(M ailSender.java:253)
... 39 more
2008-12-11 17:15:40,480 INFO [btpool0-13] [mid=2;] offline - SMTP send failure: test

[bobby]

your mta has a certificate that expired 18 months ago:

Caused by: com.zimbra.cs.mailbox.MailSender$SafeMessagingExce ption: java.security.cert.CertificateExpiredException: NotAfter: Wed May 02 21:53:56 GMT+01:00 2007; chained exception is:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Wed May 02 21:53:56 GMT+01:00 2007

[colker]

pjunker's certificate has expired, but that shouldn't prevent him from anything, as he is not using SSL.

[jjzhuang]

It's the correct behavior, because pjunker's smtp server is doing STARTTLS which is a variation of SSL.

[colker]

I disagree that it's the correct behavior. According to RFC 2487, "The STARTTLS keyword is used to tell the SMTP client that the SMTP server allows use of TLS."

It seems to me that just because the command is issued does not mean that the server is obligated to use TLS; it is allowed to use TLS. If the end user has not chosen to use TLS, the fact that the server is expired should be ignored because TLS is not going to be used.

I don't think that an option over which the end user has no control (the server sending STARTTLS) should prevent the user from sending mail. The end user is led to believe by the lack of checkmarks in the SSL-related checkboxes in Zimba that SSL in not going to be used. Yet because the SMTP server is sending a STARTTLS command that the user is not aware of actually leads Zimbra to do SSL-related checking (leading to prevention of sending mail). This is very misleading and confusing.

[jjzhuang]

Originally Posted by colker

I disagree that it's the correct behavior. According to RFC 2487, "The STARTTLS keyword is used to tell the SMTP client that the SMTP server allows use of TLS."

It seems to me that just because the command is issued does not mean that the server is obligated to use TLS; it is allowed to use TLS. If the end user has not chosen to use TLS, the fact that the server is expired should be ignored because TLS is not going to be used.

I don't think that an option over which the end user has no control (the server sending STARTTLS) should prevent the user from sending mail. The end user is led to believe by the lack of checkmarks in the SSL-related checkboxes in Zimba that SSL in not going to be used. Yet because the SMTP server is sending a STARTTLS command that the user is not aware of actually leads Zimbra to do SSL-related checking (leading to prevention of sending mail). This is very misleading and confusing.

First of all, in comment #9 I already provided workaround for any invalid certs.

Secondly, when any server advertises STARTTLS our policy is we will rely on it. It's a security policy we as a client take. There's a feature request open to optionally skip STARTTLS but that won't happen in 1.0.

[jjzhuang]

My desire is to help users as best as I can. Our mail client is first and foremost designed to work with well behaving mail servers, and at the same time we also try to provide workarounds for the not-so-well-behaving servers. Those workarounds are considered backdoors, so they are not always prominently listed. The way to find out about these backdoors is to ask on forum.

[pjunker]

@jjzhuang: your workaround doesn't work as i posted in my first comment. have you another solution for me? before the update (with build 1416) it worked fine for me.