Wrong data in CSR

[gracedman]

Hello, all. We have been struggling a bit to integrate Zimbra with our existing OpenCA based PKI. We have a two server environment right now: a main Zimbra server with all services installed and activated except AntiSPAM on the MTA and then a second Zimbra server functioning as an Internet MTA in the DMZ. Generating the CSR for the main system went as expected.

However, when we created the Internet MTA and generated a CSR via the administration console, all seemed fine until we went to approve the CSR. The CSR has the cn of the main server and not the Internet MTA! We double checked by re-issuing the CSR but, sure enough, the same thing.

Argh!!! We attempted to issue the cert anyway by editing the request. We normally do this anyway in order to change the geographically oriented C=, O= into DC syntax, to add the missing subjAltName fields, to add non FQDN fields to the subjAltName (so the devices can be access via hostname by those in the same domain), and to add IP addresses to the subjAltName. We were assuming the problem was simply putting the wrong cn into the CSR and not passing the wrong key. WRONG! Zimbra is passing the main server key for the CSR for the separate MTA server. Our CA flags it as a duplicate key. Perhaps this is the way it is supposed to work but I assume it is a bug.

We'll try living with using the internally generated certs for the Internet MTA; it does not appear to be affecting communication yet.

We are running Zimbra GA16 on CentOS 5.3 in a VServer 2.3.x guest with kernel 2.6.28.7 - John

PS - we also noticed the subjAltName was missing from both requests

[Meaulnes]

I had this same issue with a very similar setup, until I tried the entire processing using zmcertmgr via ssh directly on the mta machine.

I am still having the same issue with subjectAltName (which is baffling me some what), but I do have a cert installed on my MTA.

[Klug]

Did you open a bug (or vote for an existing bug, if it exists) about the missing subjectAltName in the CSR ?

[Meaulnes]

I suppose I should clarify that my subjecAltName issue is not the same. Mine show up in the CSR, but not in the signed cert.

[gracedman]

We have finally found a work around. We did everything from the command line with the poorly documented zmcertmgr. The following is adapted from our internal documentation:

We can try to do this from the command line as root:
cd /opt/zimbra/bin
[root@smtp bin]# ./zmcertmgr createcsr comm -new "/C=US/O=MyCompany/OU=MailServers/CN=smtp.mycompany.com" -subjectAltNames "smtp.mycompany.com,smtp"
The CSR is stored in /opt/zimbra/ssl/zimbra/commercial/commercial.csr
Copy it to the configurating computer so we can generate the cert.

Edit the request in the CA as it does not appear the SubjAltName fields actually make it into the CSR.

Copy the new cert and the CA.pem file to root's home directory on the server. The do as root:
cd /opt/zimbra/bin
./zmcertmgr deploycrt comm ~/smtp.pem ~/CA.pem

It isn't a fix but it is a workaround. Hope this helps - John

[hodd]

I too have had the same problem issuing a CSR from the CLI that includes the SubjAltNames. My problem is that I'm using GoDaddy to sign the Cert and can't edit the CA.

Did anyone bug this in bugzilla? I'll vote for it!

[gracedman]

I've not reported it.

It would be pretty ugly but I wonder if you could take the CSR into something like OpenCA (OpenCA Research Labs - Home Page), edit the CSR, extract it and then submit it to GoDaddy?