ZD untrusted Verisign SSL cert

[JaymeH]

6.0.8_GA_2661.RHEL5_64_20100820052503 CentOS5_64 FOSS edition

Zimbra Desktop 1.0(build 1593)

Background:
Yesterday I updated my Verisign SSL cert to a VeriSign Class 3 Secure Server CA - G3. First I grabbed my old CSR from /opt/zimbra/ssl/zimbra/commercial/commercial.csr and sent it to VeriSign. VeriSign sent me back my new cert which I just called commercial.crt. I then went back to VeriSign and got their new root.ca, primary_intermediate.ca, and seconday_intermediate.ca. Next I concatenated the three ca files together into commercial_ca.crt. I edited commercial_ca.crt and made sure there were no gaps and each cert had a -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- on separate lines. Then I ran, as root,

zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key commercial.crt commercial_ca.crt

and everything came back as valid. Passing that test I decided to deploy with

zmcertmgr deploycrt comm commercial.crt commercial_ca.crt

which seemed to install without error so I

su - zimbra
zmcontrol stop
zmcontrol start

The Zimbra service came back up fine. I checked the new SSL cert out in a few different browsers and all behaved as should be expected.

Problem:
ZD pukes with "Invalid or Untrusted SSL Certificate". Now I know I can just except the "untrusted" cert and carry on but I would prefer this to work properly. Below is the attached log.

2010-11-19 09:18:33,937 ERROR [sync-timer-dir] [] offline - sync failure: example@example.com
com.zimbra.common.service.RemoteServiceException: d2:CN19:mail.example.com1:O20:Example Laboratories2:OU42:Terms of use at www.verisign.com/rpa (c)056:accept4:true5:alias51:mail.example.com:C4D68D7A4D237818BC7A89275BB3EB84:fromi1289865600000e4:host19:mail.examle.com3:icn38:VeriSign Class 3 Secure Server CA - G32:io9:"VeriSign3:iou50:Terms of use at https://www.verisign.com/rpa (c)103:md532:CE4BA9F5B0E7D8CD4FCEABCB1C23EF598:mismatch5:false1:s31:C4D68D7A4D237818BC7A89275BB3EB84:sha140:220414C6AC6CAC3C4DF9FBF6BF8CE077D27304192:toi1353369599000ee
ExceptionId:sync-timer-dir:1290183513937:c83e5e50d2c41cbf
Code:remote.SSLCERT_ERROR
	at com.zimbra.common.service.RemoteServiceException.SSLCERT_ERROR(RemoteServiceException.java:74)
	at com.zimbra.common.service.RemoteServiceException.doSSLFailures(RemoteServiceException.java:154)
	at com.zimbra.cs.zclient.ZMailbox.invoke(ZMailbox.java:520)
	at com.zimbra.cs.zclient.ZMailbox.invoke(ZMailbox.java:508)
	at com.zimbra.cs.zclient.ZMailbox.getAccountInfo(ZMailbox.java:895)
	at com.zimbra.cs.account.offline.DirectorySync.syncAccount(DirectorySync.java:210)
	at com.zimbra.cs.account.offline.DirectorySync.sync(DirectorySync.java:175)
	at com.zimbra.cs.account.offline.DirectorySync.syncAllAccounts(DirectorySync.java:137)
	at com.zimbra.cs.account.offline.DirectorySync.access$000(DirectorySync.java:55)
	at com.zimbra.cs.account.offline.DirectorySync$1.run(DirectorySync.java:70)
	at java.util.TimerThread.mainLoop(Unknown Source)
	at java.util.TimerThread.run(Unknown Source)
Caused by: java.security.cert.CertificateException: d2:CN19:mail.example.com1:O20:Example Laboratories2:OU42:Terms of use at www.verisign.com/rpa (c)056:accept4:true5:alias51:mail.example.com:C4D68D7A4D237818BC7A89275BB3EB84:fromi1289865600000e4:host19:mail.example.com3:icn38:VeriSign Class 3 Secure Server CA - G32:io9:"VeriSign3:iou50:Terms of use at https://www.verisign.com/rpa (c)103:md532:CE4BA9F5B0E7D8CD4FCEABCB1C23EF598:mismatch5:false1:s31:C4D68D7A4D237818BC7A89275BB3EB84:sha140:220414C6AC6CAC3C4DF9FBF6BF8CE077D27304192:toi1353369599000ee
	at com.zimbra.common.util.CustomTrustManager.checkServerTrusted(CustomTrustManager.java:91)
	at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(Unknown Source)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
	at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
	at com.zimbra.common.util.CustomSSLSocket.startHandshake(CustomSSLSocket.java:197)
	at com.zimbra.common.util.CustomSSLSocket.getInputStream(CustomSSLSocket.java:331)
	at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:744)
	at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:386)
	at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:170)
	at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
	at com.zimbra.common.soap.SoapHttpTransport.invoke(SoapHttpTransport.java:276)
	at com.zimbra.common.soap.SoapHttpTransport.invoke(SoapHttpTransport.java:230)
	at com.zimbra.common.soap.SoapTransport.invoke(SoapTransport.java:318)
	at com.zimbra.cs.zclient.ZMailbox.invoke(ZMailbox.java:514)
	... 9 more

The error message is vague to me. Did I create my cert chain file wrong? Did I miss a step somewhere? Do I need to restart the whole server and not just the Zimbra service? Should I have generated a brand new CSR for my cert request? Do I need a newer version of ZD? Why are the web browsers fine with the new cert but ZD is having a heart attack? Any help or insight will be much appreciated.

[phoenix]

You really should use ZD 2.x, details on the download are in the Zimbra Desktop forums - please make sure you read the installation documentation and the FAQ before installing it.

[JaymeH]

Thanks for the reply!

I un-installed my ZD 1.0 completely and then installed a fresh ZD 2.0(build 10580). However, I get an "untrusted" certificate when trying to establish my account. I wish that error message was a little more clear.

[chris.wilson@rochester.edu]

We are experiencing the same problem after a cert upgrade this past weekend.

Our cert is also "Verisign SSL cert to a VeriSign Class 3 Secure Server CA - G3", and our zDesktop users are having the same issue. All our users who use zDesktop are currently using Zimbra Desktop 2.0 (build 10580).

Our users who use IE or Firefox are not experiencing this problem. We haven't had any of our Outlook Connector users report problems yet, but it's still early Monday morning, so time will tell.

I use zDesktop myself, same build as our user-base, and I was presented with the cert error myself.

JaymeH - Are you still experiencing this problem, or have you somehow resolved it? (...and how?)

Zimbra Folks - Any suggestions?

Thanks much,

--
Chris Wilson
University IT / DC
_______________________________________

[chris.wilson@rochester.edu]

Just an FYI; Upgrading to zDesktop 2.0.1 build 10659 has not resolved the problem.

[JaymeH]

Confirmed! ZD 2.0.1 build 10659 fixes this problem. Thanks for the awesome work guys.

[chris.wilson@rochester.edu]

Hrm... Too bad for me, it did _not_ fix my problems. I've tested browsers as old as Safari 3.0 and no cert problems. Right now it's _just_ zDesktop that complains, and I'm not sure what to look at.

Zimbra folks - is there anything I can collect from the client that would help determine what ZD is complaining about (logs/output files/etc.)?

I had to tell ZD to "accept the invalid cert" during the "Validate and Save" process instead.

[JaymeH]

Hmm. Maybe I missed something then. I did a complete uninstall of ZD before I installed 2.0.1. I setup my account, it didn't bark at me this time, and is currently syncing. Your comment however, makes me wander if the uninstall removed everything or if it conveniently left behind the previously accepted chain in some ZD directory. I will re-test.

I must say I feel like an ass now. For whatever reason my brain did not read the "not" part of your comment. Reading comprehension for the win! Anyways, hopefully I will have time to try this again in the next hour or two and then I will post my findings here.

[chris.wilson@rochester.edu]

JaymeH - no worries. That's a very good possibility about the previous "accept" being left-over somewhere within your AppData/Profile area, as opposed to the installation area.

I hadn't done the manual "accept" until after I tried the upgrade to ZD v2.0.1, at-which point I basically just needed to get things to work.

I've had to relay to our organization's IT Helpdesk to walk our end-users through the same "accept the invalid cert" process as well, unfortunately. Folks who use ZD in our environment have gotten very addicted to the "offline" capabilities, especially with the "Local Folders" area for holding older data.

It's a shame that, as far as I can tell so far, it's _just_ ZD complaining about things at the moment. It's almost as if it's completely ignoring the cert-chain, which even browsers as old as Safari 3.0 are properly accepting.

[JaymeH]

Yup. I was hasty. After I uninstalled ZD I also deleted all Zimbra related folders in Application Data and Local Settings land. Upon reinstalling ZD I again received the beloved warning about the cert being untrusted. But you're right, young and old browsers alike are OK with this chain.

Time to do some more poking around.