Zimbra Desktop client fails to recognize renewed LE cert

Running Zimbra 8.7.1 OS Edition on CentOS 7, we recently renewed the certificate for that server + another LAMP based server, using certbot on a separate server for generating certificates for two domains ( -d fqdn1 -d fqdn2 ).
Everything checked out OK but afterwards the Zimbra Desktop clients produced the error below, indicating mix up between the two domains. The error persists even after renewing with certbot for two single domains, one at the time

Error (some text is in Danish - I’ll translate pr best effort :wink: ):

Ugyldigt eller upålideligt SSL-servercertifikat. Gå til
redigeringsskærmbilledet af Indstilling af konto for at validere
indstillingerne igen.

Invalid or untrusted SSL server certificate. Go to Settings to to revalidate

debug message:
d2:CN13:cloud.eidi.fo1:O0:2:OU0:6:accept4:true5:alias48:post.eidi.fo:476586A3A5C48C62FAED9CA9AEA744979064:fromi1496735880000e4:host12:post.eidi.fo3:icn26:Let’s
Encrypt Authority X32:io13:Let’s
Encrypt3:iou0:3:md532:1C139CD81AC111EADCED7268A60813418:mismatch5:false1:s35:476586A3A5C48C62FAED9CA9AEA744979064:sha140:2BB23C2F1EB449DB1879E8207613F043176EE5F92:toi1504511880000ee

Undtagelse: /Exception

com.zimbra.common.service.ServiceException:
error while proxying request to target server:
java.security.cert.CertificateException:
d2:CN13:cloud.eidi.fo1:O0:2:OU0:6:accept4:true5:alias48:post.eidi.fo:476586A3A5C48C62FAED9CA9AEA744979064:fromi1496735880000e4:host12:post.eidi.fo3:icn26:Let’s
Encrypt Authority X32:io13:Let’s
Encrypt3:iou0:3:md532:1C139CD81AC111EADCED7268A60813418:mismatch5:false1:s35:476586A3A5C48C62FAED9CA9AEA744979064:sha140:2BB23C2F1EB449DB1879E8207613F043176EE5F92:toi1504511880000ee
ExceptionId:btpool0-2:1496855345555:1bc9ceab347efea8
Code:service.PROXY_ERROR Arg:(url, STR, “https://post.eidi.fo/service/soap/”)
at com.zimbra.common.service.ServiceException.PROXY_ERROR(ServiceException.java:318)
at com.zimbra.cs.mailbox.ZcsMailbox.sendRequest(ZcsMailbox.java:705)
at com.zimbra.cs.mailbox.ZcsMailbox.sendRequest(ZcsMailbox.java:652)
at com.zimbra.cs.mailbox.ZcsMailbox.sendRequest(ZcsMailbox.java:647)
at com.zimbra.cs.mailbox.ZcsMailbox.sendRequest(ZcsMailbox.java:640)
at com.zimbra.cs.mailbox.ZcsMailbox.sendRequest(ZcsMailbox.java:636)
at com.zimbra.cs.mailbox.ZcsMailbox.getAuthToken(ZcsMailbox.java:177)
at com.zimbra.cs.account.offline.OfflineProvisioning.getProxyAuthToken(OfflineProvisioning.java:2769)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:230)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.java:158)
at com.zimbra.soap.SoapServlet.doWork(SoapServlet.java:303)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.java:217)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at com.zimbra.cs.servlet.ZimbraServlet.service(ZimbraServlet.java:206)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:814)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:218)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:422)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.handler.rewrite.RewriteHandler.handle(RewriteHandler.java:230)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:585)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:988)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:415)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:429)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451)
Caused
by: javax.net.ssl.SSLHandshakeException:
java.security.cert.CertificateException:
d2:CN13:cloud.eidi.fo1:O0:2:OU0:6:accept4:true5:alias48:post.eidi.fo:476586A3A5C48C62FAED9CA9AEA744979064:fromi1496735880000e4:host12:post.eidi.fo3:icn26:Let’s
Encrypt Authority X32:io13:Let’s
Encrypt3:iou0:3:md532:1C139CD81AC111EADCED7268A60813418:mismatch5:false1:s35:476586A3A5C48C62FAED9CA9AEA744979064:sha140:2BB23C2F1EB449DB1879E8207613F043176EE5F92:toi1504511880000ee
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLSocketImpl.fatal(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.Handshaker.fatalSE(Unknown Source)
at sun.security.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at sun.security.ssl.ClientHandshaker.processMessage(Unknown Source)
at sun.security.ssl.Handshaker.processLoop(Unknown Source)
at sun.security.ssl.Handshaker.process_record(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.zimbra.common.net.CustomSSLSocket.startHandshake(CustomSSLSocket.java:90)
at com.zimbra.common.net.CustomSSLSocket.getInputStream(CustomSSLSocket.java:341)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:745)
at

org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at com.zimbra.common.soap.SoapHttpTransport.invoke(SoapHttpTransport.java:243)
at com.zimbra.common.soap.SoapHttpTransport.invoke(SoapHttpTransport.java:164)
at com.zimbra.common.soap.SoapTransport.invoke(SoapTransport.java:407)
at com.zimbra.common.soap.SoapTransport.invokeWithoutSession(SoapTransport.java:393)
at com.zimbra.cs.mailbox.ZcsMailbox.sendRequest(ZcsMailbox.java:690)
… 32 more
Caused
by: java.security.cert.CertificateException:
d2:CN13:cloud.eidi.fo1:O0:2:OU0:6:accept4:true5:alias48:post.eidi.fo:476586A3A5C48C62FAED9CA9AEA744979064:fromi1496735880000e4:host12:post.eidi.fo3:icn26:Let’s
Encrypt Authority X32:io13:Let’s
Encrypt3:iou0:3:md532:1C139CD81AC111EADCED7268A60813418:mismatch5:false1:s35:476586A3A5C48C62FAED9CA9AEA744979064:sha140:2BB23C2F1EB449DB1879E8207613F043176EE5F92:toi1504511880000ee
at com.zimbra.common.net.CustomTrustManager.checkServerTrusted(CustomTrustManager.java:91)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(Unknown Source)
… 52 more

I made a fresh install of the client on a new Windows PC and that worked fine.
This issue will also be reported to Zimbra devs but is there anyone in this forum, who might have experienced this behaviour, then I’d like to hear about it.

I will try to be brief:

80.77.137.250:443 (without SNI) shows:
subject=/CN=cloud.eidi.fo
issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIE/TCCA+WgAwIBAgISBHZYajpcSMYvrtnKmup0SXkGMA0GCSqGSIb3DQEBCwUA
…shortened for breviry…
WSIFHw03fo0Cv2L+LuIrRz3q3gQ9xfVdZw6tPFxj2Ijq
-----END CERTIFICATE-----

80.77.137.250:443 (with SNI) shows:
subject=/CN=post.eidi.fo
issuer=/C=US/O=Let’s Encrypt/CN=Let’s Encrypt Authority X3
-----BEGIN CERTIFICATE-----
MIIE+zCCA+OgAwIBAgISBPayj+GqHzfDPgi9AUU0UEHfMA0GCSqGSIb3DQEBCwUA
…shortened for breviry…
YpNlcCIbx4JGcIjpz+10h5JBFSiYj3qGDLHmOZ11BA==
-----END CERTIFICATE-----

https://crt.sh/?q=cloud.eidi.fo shows early certs had dual SAN (thru 2017/05/30) but starting on 2017/06/06 it’s an individual cert.
https://crt.sh/?q=post.eidi.fo shows early certs had dual SAN (thru 2017/05/30) but starting on 2017/06/06 it’s an individual cert.

So, I’m thinking your clients who used to connect via either name to either server can no longer do so.
If they hit one other system, with the other name, it will not like it.
And complain about the name mismatch and such.
You have to review your clients’ configuration - the names they use in their connections.
And ensure they are all set properly.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.