[SOLVED] After install ssl, ldap can't start

[hoangkk]

My system use Ubuntu 8.04 - 64 TLS + ZCS 6.0.1 GA 1816

Affter install ssl cert via web admin : it said successfull install
zmcontrol stop
and then
zmcontrol start

zimbra@mail:~$ zmcontrol start
Host mail.xxxxxx.com
Starting ldap...Done.
Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Starting logger...Done.
Starting mailbox...Done.
Starting antispam...Done.
Starting antivirus...Done.
Starting snmp...Done.
Starting spell...Done.
Starting mta...Done.
Starting stats...one.

Help me

[ewilen]

You don't say if the server is working otherwise. Try searching the forum for ldap unable determine services and you'll find that the error message can be benign, or if not in your case, what info you need to post for folks to troubleshoot.

[hoangkk]

You don't say if the server is working otherwise. Try searching the forum for ldap unable determine services and you'll find that the error message can be benign, or if not in your case, what info you need to post for folks to troubleshoot.

This is trash reply. Anybody can help me?

[liteforce]

I have the same issue - albeit on a 32-bit CentOS 5.3 install.

The cert is a GlobalSign wildcard certificate that installs and works just fine in Exim, Apache, lighttpd, Courier-IMAP and Dovecot - had problems getting it to install at first due to Zimbra not using OpenSSL's own root CA repository.

Our GlobalSign cert required the GlobalSign root cert adding to the intermediate cert in order for Zimbra to verify and install it - something which I didn't anticipate but I'm not averse to going a little out of my way to sorting something simple like a cert trust path.

Nevertheless, the certificate installed with no issues once I did that but like you, I'm seeing the exact same issue - which magically goes away when I do a '/opt/zimbra/bin/zmcertmgr deploycrt' and Zimbra generates/installs a new self-signed cert.

The documentation is horrible - a product geared towards enterprise use should have extensive docs (especially on the SSL parts; we manage/install/support 500+ SSL certs as a GlobalSign partner and like to think we know what we are doing but this issue has us well and truly stumped).

The closest I can get to finding the problem is:

zmmtaconfig.log:Sat Oct 3 10:43:38 2009 gs:*******.example.com ERROR: service.FAILURE (system failure: ZimbraLdapContext) (cause: javax.net.ssl.SSLHandshakeException sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderE xception: unable to find valid certification path to requested target)

(why oh why don't you echo this to stderr rather than dumping it in a logfile - at least print something to stderr to say, something bad happened, you can see what in /opt/zimbra/log/blahblah.log)

Which I suspect is due to the root/intermediate certificate problem I detailed earlier, but according to the zmcertmgr documentation, if our certificate and associated root/intermediate certs pass a 'verifycrt' and 'verifycrtchain' like so:

[root@****** certs]# /opt/zimbra/bin/zmcertmgr verifycrt comm commercial.key commercial.crt
** Verifying commercial.crt against commercial.key
Certificate (commercial.crt) and private key (commercial.key) match.
Valid Certificate: commercial.crt: OK

[root@******* certs]# /opt/zimbra/bin/zmcertmgr verifycrtchain commercial_ca.crt commercial.crt
Valid Certificate Chain: commercial.crt: OK

... why does it not work as expected ?

Add to that, the cavalier attitude of the Zimbra devs towards an officially supported deployment platform of RHEL5 (that of Xen virtualization) and the fact that the issue as detailed in Bug 23683 – Use posix mutexes on Linux builds to avoid Xen issues is still not fixed in Zimbra 6.0.1 NE even though the Bugzilla entry is marked as 'FIXED' does not give me any confidence in the quality of the binaries they are throwing out.

It isn't a pretty sight watching a dual Xeon 3.0GHz machine with 4GB of RAM fall to its' knees while the zmlogger process periodically eats 90%+ of CPU time due to this particular issue.

For one thing, Red Hat ship only *one* copy of OpenLDAP with their distro - it works perfectly with both non-Xen and Xen-enabled kernels; Zimbra's binary packages are specially customized for each distribution of Linux they support and the fact that they couldn't be bothered to investigate and implement the same fixes that OpenLDAP/Red Hat made to their binaries makes me feel that this attitude may be the same across the entire product.

I'll point out to the Zimbra folks that while I'm running this on CentOS 5.3/i386, I can certainly duplicate both of the above issues on a genuine RHEL 5.3/i386 install also.

We are currently seven days in to a 60-day Network Edition evaluation license and definitely not liking it because we can't even get the thing installed and working with SSL-only webmail (our one and only 'must have') due to the aforementioned cert problems - eventually plan to become a Zimbra Hosting Partner but if *I* don't feel comfortable in the quality of the product or even using it internally within our own organization, there is no way I am going to ask our customers to make such a leap of faith when we aren't prepared to do it ourselves.

Sorry to the OP for 'semi-hijacking' this thread with a 'me too!' response but hopefully my response will get someone to look into this as a matter of urgency.

To any non-Zimbra folks who want to reply with 'you should search the forum for the answer'; I would like to inform you that I have searched for every single combination of SSL/LDAP issues on this forum but cannot find any solution which I have not already tried that does not work - removing .zmcontrol.cache, etc, etc.

I look forward to a helpful and informative response from a Zimbra staffer.

Regards,
Terry Froy
Spilsby Internet Solutions

[quanah]

My system use Ubuntu 8.04 - 64 TLS + ZCS 6.0.1 GA 1816

Affter install ssl cert via web admin : it said successfull install
zmcontrol stop
and then
zmcontrol start

zimbra@mail:~$ zmcontrol start
Host mail.xxxxxx.com
Starting ldap...Done.

Run "ldap start" by itself, and see what error is reported. Most commonly, the cert provider failed to provide the full CA chain required for validating the cert, including whomever signed their CA.

[quanah]

Add to that, the cavalier attitude of the Zimbra devs towards an officially supported deployment platform of RHEL5 (that of Xen virtualization) and the fact that the issue as detailed in Bug 23683 – Use posix mutexes on Linux builds to avoid Xen issues

Actually, this issue has been fixed for ages. That doesn't mean Xen does not have its own issues that make it problematic for use. Your rant against Xen is entirely off topic for this thread. My guess is you are referring to the hack Xen has in place for 32-bit oses and how it deals with thread local storage.

For one thing, Red Hat ship only *one* copy of OpenLDAP with their distro - it works perfectly with both non-Xen and Xen-enabled kernels; Zimbra's binary packages are specially customized for each distribution of Linux they support

Eh, again, you are incorrect here. We build OpenLDAP with the same options for all of our Linux builds. The only platform we do differently is Mac OSX, because it doesn't support epoll().

And if you think RedHat's build of OpenLDAP "works perfectly", you've obviously never used it. As a member of the OpenLDAP development team, I've first hand experience with the multitude of issues the way in which the RedHat packagers have completely bypassed safeguards and hacked OpenLDAP with patches that were broken have caused.

and the fact that they couldn't be bothered to investigate and implement the same fixes that OpenLDAP/Red Hat made to their binaries makes me feel that this attitude may be the same across the entire product.

I spent quite a bit of time investigating the thread local storage issue. It's clearly a hack in Xen, and it only pertains to 32-bit systems. Again, not a specific issue with what Zimbra does, but with how RedHat implemented its virtualization product.

I'll point out to the Zimbra folks that while I'm running this on CentOS 5.3/i386, I can certainly duplicate both of the above issues on a genuine RHEL 5.3/i386 install also.

As noted several times now, this is a problem with the way Xen handles 32-bit linux implementations and thread local storage.

--Quanah

[quanah]

See also Bug 39498 – 4gb seg fixup, process slapd immediately after install

[hoangkk]

I was try to many way like
cp cert file to /opt/zimbra/mailboxd/webapps/zimbraAdmin/tmp/ on

[SOLVED] Trouble installing commercial certificates on Zimbra

or clean out older cert files on

[SOLVED] New Cert install - LDAP "Unable to determine enabled services from ldap

or use command to deploy commercial cert

but my system status is

Unable to determine enabled services from ldap.
Enabled services read from cache. Service list may be inaccurate.
Host mail.domain.com
	antispam                Running
	antivirus               Running
	ldap                    Running
	logger                  Running
	mailbox                 Running
	mta                     Running
	snmp                    Running
	spell                   Running
	stats                   Running

and my system is still down : can't access via web, can't send and recive email

---------------------------------
---------------------------------

Overcome many way to fix this problem, now I was fix it with unfamiliar way.