We have installed a zimbra server, and its name is something like zimbra-1.domain.com, however, when we started using it in production, we wanted to just change the "mail.domain.com" certificate to point there and not have our users make changes to their clients. When we installed the commercial certificate using the magical wizard, it broke mail because postfix could not connect to the ldap server due to certificate errors. We installed the original certificate (was also a "commercial" certificate from the zimbra perspective, but signed by our internal CA) and things started flowing again, except of course users got certificate errors when they tried to connect.
After some thought, we decided to back up the slapd.crt/slapd.key, then install the proper user facing certificate using the wizard, then restore the slapd.crt/slapd.key file. Oh we thought we were smart, but *still* no mail flowage.. even though the certificate "trick" worked. (connections to the zimbra LDAP server did present the correct certificate) The problem turned out to be in the conf/ca directory, where Zimbra keeps its "trusted certificate authorities." The wizard replaced the commercial ca cert file, but failed to remove the old hash entry pointing to that file, and thus caused the certificate validation to fail when postfix tried to connect to the ldap server. We copied in the internal CA cert into that directory, then removed and re-linked the "hash.0" to the internal ca cert file and everything worked.
I am not sure, but I think I would file a bug against the certificate wizard for not removing the hash link before creating a new one. The error would have just been that there was a "self signed certificate" rather than an invalid certificate in that case, right?
It would be nice if there was a place to manage trusted CA certs rather than this hocus pocus magic trick that the wizard tries to pull off. It would also be nice if there was a way to upload a key in the wizard type interface without using scp to some pre-determined filename (again with the hocus pocus magic).
Also I wondered whether the jetty process used a java keystore for CA certs, meaning that I would have to add the internal CA to that as well or if it uses the same openssl style CA directory.. or maybe it just doesn't validate certs? (or use SSL when it connects to LDAP?)