Having struggled with this for the past few hours, I figured I'd document the process that succeeded, based on what I didn't find while searching around. This will loosely follow http://wiki.zimbra.com/wiki.Preexist...for_Zimbra_6.0, with a small pile of consolidated digressions along the way.
Scenario: New deployment of Zimbra8 NEA. Have existing 4096 bit wildcard SSL cert on an exchange server.
Challenge: There's no 4096 option in the web console. And the key... nevermind. For yucks, we'll convert a PFX ripped from a live IIS install.
To make this work, Zimbra will want us to provide a total of three files.
commercial.key, which is a secret,
commercial.crt, which is the cert we bought from the vendor (godaddy),
and commercial_ca.crt, which is the chain that validates everything.
First up, get the existing stuff from the Windows box.
Win32 - Certificates snap-in.
Export your (wildcard) cert from Local Computer personal certificates.
- Include private key
- Use Personal Information Exchange (PFX). Do not include certs in path, do not enable strong prot, do NOT DELETE the private key lol.
- Pick a pass, any pass, and remember it
- Pick a filename, save it (I'll say, wincertfile.pfx)
You'll now have a .pfx file.
On the Zimbra box, we are going to need a working directory that is reasonably safe to store bad things.
Fetch the pfx file from the windows machine. Once here, you can (should) delete the pfx file on that windows machine.
I've no idea if it is actually necessary, but we'll probably want to make a CSR file. Info should match the original as best you can.
If you need a refresher, in the Win certificate manager, right-click the cert and choose Open, select the Details pane.
The subject field will contain the CN, O, etc.
Back on the Zimbra box, make sure you note the size of the key, in my case 4096.
/opt/zimbra/bin/zmcertmgr createcsr comm -new -keysize 4096 "/C=US/ST=NY/L=MyCity/O=*.your.com/OU=YourOU/CN=*.your.com"
Next goal - extract "commercial.key".
We need to get the key from pfx bundle.
That'll rip it into a file by itself (EprivateKey.pem), but still encrypted. Next, we need to make that key get naked for us.
openssl.exe pkcs12 -in wincertfile.pfx -nocerts -out EprivateKey.pem
That commerical.key file will be the unencrypted, very dangerous, do-not-post-on-facebook private key.
openssl.exe rsa -in EprivateKey.pem -out commercial.key
Verify success with "cat commercial.key". If you cat it, you should see something akin to
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
One file down, let's put it where Zimbra wants it:
cp commercial.key /opt/zimbra/ssl/zimbra/commercial/
Next up, we need to isolate the certificate into "commerical.crt".
openssl.exe pkcs12 -in wincertfile.pfx -clcerts -nokeys -out commercial.crt
It is presumed that you've already have a valid commercial_ca.crt file. Typically the vendor will provide this (godaddy gives you gd_bundle.crt); you can likely just rename it to "commercial_ca.crt" and call it done.
So, let's idiot check things:
At this point, you are ready to proceed with Preexisting Certificate Installation, beginning at "Now deploy the certificates".
root@zimbra:~/certs# /opt/zimbra/bin/zmcertmgr verifycrt comm commercial.key commercial.crt commercial_ca.crt
** Verifying commercial.crt against commercial.key
Certificate (commercial.crt) and private key (commercial.key) match.
Valid Certificate: commercial.crt: OK
In a nutshell:
and if success,
/opt/zimbra/bin/zmcertmgr deploycrt comm commercial.crt commercial_ca.crt
If the deployment encounters
** Saving server config key zimbraSSLCertificate...failed.
** Saving server config key zimbraSSLPrivateKey...failed.
...it probably means that ldap has hosed up.
Proceed with the /etc/init.d/zimbra restart, verify that ldap (and everything else) comes up,
and then deploy again. You should see that those two entries succeed this time. Remember to restart again.
Cheers and good luck,