[SOLVED] Failed 4.5.11 to 5.0.4 GoDaddy Commercial Certificate Upgrade

[LMStone]

We just upgraded one of our Zimbra servers from 4.5.11 to 5.0.4, and like others who have posted here, the GoDaddy commercial certificates failed to be incorporated as part of the upgrade.

The good news (I hope) is that we did the upgrade by going from 32-bit SuSE ES9 on one server to 64-bit SuSE ES10 on a second server, so the original SLES9 server is still there, along with all the csr files, certificate bundles, etc. (FWIW We did the upgrade by following the Zimbra Certified 32-bit to 64-bit migration document, and then just upgrading 4.5.11 on the new server to 5.0.4.)

I've read through a lot of bug reports and forum posts in the past few hours on this, and no one else's scenario quite matches ours, hence, this post.

The 5.0.4 Install Certificate Wizard is nice, but it won't let me install a certificate if I didn't use the wizard to generate a csr.

Perhaps there is a way I can "fool" the Wizard by copying the csr file from the old server to the new one?

The wiki article on CLI certificate installs looks promising, but is not clear to me how to concatenate the various GoDaddy files, nor in which order. There is a forum post about the concatenation not putting in a proper CRLF, and enough other posts indicating that messing up certs can be a bear to fix.

So, I'm more keen to "measure twice and cut once" rather than experiment!

The output of:
keytool -list -keystore /opt/zimbra/mailboxd/etc/keystore -storepass `zmlocalconfig -s -m nokey mailboxd_keystore_password`

shows four certificates: root, cross, intermed and our server's. But the admin UI shows only the two Zimbra self-signed certs (MTA and LDAP).

Any takers on a Sunday with nothing better to do? :-)

TIA!

With best regards to all,
Mark

[mmorse]

So what files do you have? (gd_cross_intermediate.crt, gd_intermediate.crt, <server_name>.crt, gd_bundle.crt, RootCA.crt)

Disclaimer - I don't have a GoDaddy cert to test (so feel free to wait for more examples or support would happily walk you through it) but generally the manual method is like:

1. Download GoDaddy bundle from their primary Repo

2. Reverse the certificate chain in an editor so that your the chain of trust goes from general to specific. (e.g. Root CA, Intermediate, Intermeidate_cross, your cert). Save this file as commercial.crt under /opt/zimbra/ssl/zimbra/commercial

(Or if you don't have a bundle: cat root.crt intermediate.crt cross_intermediate.crt server.crt > commercial.crt or open an editor and append.)

3. Copy your private key (must be named commercial.key) to /opt/zimbra/ssl/zimbra/commercial

4. Copy files to other misc locations:

cp commercial.crt /opt/zimbra/mailboxd/webapps/zimbraAdmin/tmp/current.crt
cp commercial.crt /opt/zimbra/jetty/webapps/zimbraAdmin/tmp/current.crt
cp commercial.crt /opt/zimbra/mailboxd/webapps/zimbraAdmin/tmp/current_chain.crt

5. Always good to just have it test first
/opt/zimbra/bin/zmcertmgr verifycrt comm

6. Install the cert
/opt/zimbra/bin/zmcertmgr install com

7. zmcontrol stop/start

[LMStone]

Hi Mike, thanks for the fast reply. Re your numbered action items:

1. I already have these files.
2. Done, with the CRLF cleanup work done in a text editor.
3. On the old server, where would Zimbra have stored the private key?
4. and beyond. Pending completion of 3. :-)

Thanks,
Mark

[mmorse]

Check your old box for a /opt/zimbra/conf/my.key if not you'll probably need to export it from the old keystore/decrypt it.

[LMStone]

In the conf directory on the old box are:
perdition.key
slapd.key
smtpd.key

There is also /opt/zimbra/conf/ca/ca.key

The perdition, slapd and smtpd keys are identical to each other. The ca.key is unique.

How can I test if the ca.key file is the one I need?

Thanks,
Mark

[mmorse]

You could run them through /opt/zimbra/bin/zmcertmgr verifycrt comm

Extract_the_private_key - Commercial Certificates - Zimbra :: Wiki (might have to use the base64 method) > your perdition/sldap/smtpd.key is the same as using my.key

Do you still have the old /opt/zimbra/tomcat/conf/keystore or /opt/zimbra/ssl/ssl/commercial.keystore?

[LMStone]

Hi Mike,

No joy... The verification process claims there is a mismatch between the key and the bundle.

I've opened a ticket with support.

Did I miss something in the 5.0.4 Release Notes about this problem?

All the best, and thanks again!
Mark

[mmorse]

On your 5.0.x box, check whether the tomcat alias still exist in the keystore. You can check with this command:
keytool -list -keystore /opt/zimbra/mailboxd/etc/keystore -storepass `zmlocalconfig -s -m nokey mailboxd_keystore_password`

If the above command returns two aliases (tomcat and jetty), you may need to delete the tomcat alias with this command:
keytool -delete -alias tomcat -keystore /opt/zimbra/mailboxd/etc/keystore -storepass `zmlocalconfig -s -m nokey mailboxd_keystore_password`

[mmorse]

Just saw the ticket, someone will reply shortly to give you a hand remotely.

[LMStone]

Mike,

Thanks for all your help; thought it was best to open up a ticket once the private key issue reared its head.

FWIW:

keytool -list -keystore /opt/zimbra/mailboxd/etc/keystore -storepass `zmlocalconfig -s -m nokey mailboxd_keystore_password`

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 4 entries

root, May 1, 2007, trustedCertEntry,
Certificate fingerprint (MD5): <snip>
cross, May 1, 2007, trustedCertEntry,
Certificate fingerprint (MD5): <snip>
<hostname>, May 1, 2007, PrivateKeyEntry,
Certificate fingerprint (MD5): <snip>
intermed, May 1, 2007, trustedCertEntry,
Certificate fingerprint (MD5): <snip>


I'll post here once this is resolved so others can benefit.

Please enjoy the rest of your weekend, and thanks again! Zimbra folks jumping in on a volunteer forum on a Sunday speaks volumes for the kind of dedication there is, and is one of the key reasons we are happy to be a paying customer!

All the best,
Mark