zmcreatecert usage of keytool

[efoo]

We recently got ZCS (Open Source Edition) installed and working for non-profit use, and we have to say that we are very impressed with it thus far. It is a huge improvement over our current installation. However, we ran into a problem while creating our self-signed SSL certificate and would like to know what the "official" way to get this working is.

Essentially, our issue arise from the need for virtual hosting. We handle email for several domains, and all of them require https:// access, as well as imap-ssl and smtp-ssl. So this time around, we thought that we would insert the needed changes to zmssl.conf and recreate our certs using the method outlined in the wiki. However, our SubjectAltName extensions were not getting into the final certificates, and we spent a lot of time figuring out why. Essentially, zmcreatecert uses Java's keytool (not openssl) to generate certificate requests, and keytool doesn't use zmssl.cnf, meaning that any/all SSL extensions we specified in zmssl.cnf will never get included in any server certs.

However, we worked around the problem for now by adding the extensions at the signing stage in zmcreatecert, adding the following arguments to the second call of openssl in signCertReq():

-extensions v3_req -extfile ${BASE}/zmssl.cnf

This causes openssl to append the extensions (the same ones it did to the smtpd certificate request) to the signed Tomcat certificate.

So, we have two questions:

(1) Why does Zimbra use different certs for smtpd vs. httpd in a self-signed installation? The instructions posted on the Wiki actually use one certificate for both smtpd and Tomcat if using a commercial cert. Is there any reason why we could not do the same for a self-signed installation?

(2) How can we get the same end result without having to make local changes to zmcreatecert? We would rather not have to play the local patch game, particularly when upgrading to future versions of the ZCS.

Thanks in advance, and again, this is a great product.

[marcmac]

We recently got ZCS (Open Source Edition) installed and working for non-profit use, and we have to say that we are very impressed with it thus far. It is a huge improvement over our current installation. However, we ran into a problem while creating our self-signed SSL certificate and would like to know what the "official" way to get this working is.

Essentially, our issue arise from the need for virtual hosting. We handle email for several domains, and all of them require https:// access, as well as imap-ssl and smtp-ssl. So this time around, we thought that we would insert the needed changes to zmssl.conf and recreate our certs using the method outlined in the wiki. However, our SubjectAltName extensions were not getting into the final certificates, and we spent a lot of time figuring out why. Essentially, zmcreatecert uses Java's keytool (not openssl) to generate certificate requests, and keytool doesn't use zmssl.cnf, meaning that any/all SSL extensions we specified in zmssl.cnf will never get included in any server certs.

However, we worked around the problem for now by adding the extensions at the signing stage in zmcreatecert, adding the following arguments to the second call of openssl in signCertReq():

-extensions v3_req -extfile ${BASE}/zmssl.cnf

This causes openssl to append the extensions (the same ones it did to the smtpd certificate request) to the signed Tomcat certificate.

So, we have two questions:

(1) Why does Zimbra use different certs for smtpd vs. httpd in a self-signed installation? The instructions posted on the Wiki actually use one certificate for both smtpd and Tomcat if using a commercial cert. Is there any reason why we could not do the same for a self-signed installation?

Postfix requires a cert, without private key, and the private key in an unencrypted file. Tomcat wants the cert and the key in it's keystore.

(2) How can we get the same end result without having to make local changes to zmcreatecert? We would rather not have to play the local patch game, particularly when upgrading to future versions of the ZCS.

Thanks in advance, and again, this is a great product.

Go to bugzilla.zimbra.com and file this as an RFE, and we'll try to get it in as soon as possible. (IF you include the purpose of the change, and what you added to zmssl.cnf, I'll have a better idea of how to set this up.)

[ericding]

Postfix requires a cert, without private key, and the private key in an unencrypted file. Tomcat wants the cert and the key in it's keystore.

Just to clarify the issue: we added some X.509 extensions to the certificate request (including subjectAltName) in order to get a certificate request which includes alternative hostnames; we also had to edit zmssl.cnf to get those extensions copied over to the signed certificate. This was all well and good, except that Tomcat's using an altogether different certificate request (and therefore a different self-signed certificate as well).

I think I understand that Tomcat needs the certificate and key in its keystore, but why does the certificate request for Tomcat need to be generated by keytool rather than openssl? Is the certificate request tightly bound to the signed certificate? Wouldn't this mean that you need to submit two separate requests for any given server for commercial signing, and then install two distinct signed certificates on the server?

Why can't the script generate a single certificate request with openssl for both Postfix and Tomcat, then optionally self-sign the certificate with openssl, then finally leave zminstallcert to simply import the signed certificate into the Tomcat keystore?

[marcmac]

Mostly because I haven't fixed it.

Originally, all I was creating was the tomcat cert, thus I used keytool for simplicity.

When I added the postfix cert, I realized keytool wouldn't give me the key, which I needed, so I used openssl, but didn't bother to change the tomcat cert creation (since it was working).

Add this to your RFE, and I'll fix it.

[marcmac]

Eric - how did you (or did you?) get the openssl cert into a keystore that tomcat would use?

[efoo]

Marc,

Eric is offline (and generally just as busy/overworked as me) at the moment, but here is the email he sent me when he originally got this working last Saturday. I helped with the initial investigation but wasn't around for the eureka moment, so I'll let Eric comment on his own words instead of trying to do that myself. Text follows:

Hey Edwin,

First, I made a few minor edits to the default zmssl.cnf.in:

1) uncomment the line

copy_extensions = copy

in the [CA_default] section, which causes openssl to copy any
extensions in a certificate request to the signed certificate.

2) uncomment the line

req_extensions = v3_req

in the [req] section, which causes certificate requests to be
generated with any extensions specified in the [v3_req] section.

3) add the line

subjectAltName=DNS:host.domain1.com,DNS:host.domain2.com,etc..

in the [v3_req] section, resulting in the Subject Alt Name extension
being added to any generated certificate requests.

4) This was the part that stumped me: why wasn't the web server showing
any X.509 extensions in its SSL certificate? It turns out that this
was because zmcreatecert uses Java's keytool (not openssl) to generate
certificate requests, and keytool doesn't use zmssl.cnf, meaning that
it didn't even look for extensions.

However, I worked around the problem for now by adding the extensions
at the signing stage in zmcreatecert, adding the following arguments
to the second call of openssl in signCertReq():

-extensions v3_req -extfile ${BASE}/zmssl.cnf

This causes openssl to append the extensions (the same ones it did
to the smtpd certificate request) to the signed Tomcat certificate.
Voila!

[marcmac]

Thanks - I've been trying to get a pkcs12 cert to work, but tomcat isn't cooperating. (Every time I go back into this script, I hate my life.)

[efoo]

(Every time I go back into this script, I hate my life.)

That makes 3 of us. What I didn't quote from Eric's email to me was the sentence "I can't believe I just spent 6 hours on this...". Granted, we're not paying customers for the Network Edition, so I'm not going to blame you guys for the time we spent on it, but this was definitely one of those rabbit holes that turned out be a whole lot deeper than the two of us thought and were prepared to spend (especially since we're donating our time to these organizations ourselves).

Please let us know if you need any further information. We did solve this for ourselves, but our solution is not anywhere near clean enough to survive an upgrade to future versions of Zimbra and I don't have time to maintain local patchsets. So we'd love to see this integrated into future releases.

[marcmac]

I'm working on integrating it now (what I really want to do is allow an admin to, by default, get a self-signed cert for their hostname - but if they want, they can supply additional names on the command line).

Good news on the upgrade front, though - I retain existing certs, so you're ok there.

EDIT - though, prudence would dictate that you keep a copy of the cert in a safe place...

[efoo]

That sounds like a nice feature - I presume you'll insert the SubjectAltName lines during the generation of zmssl.cnf from zmssl.cnf.in based on the cmdline args to zmcreatecert? What about existing SubjectAltName lines or other settings in zmssl.cnf.in?

Good to hear about the existing certs though; I'll be glad to overwrite this hack when 3.0.2 (or whatever version this gets released in) shows up.