[SOLVED] Commercial SSL certificates - to clear out misunderstanding in file layout

[j2b]

I wonder, if anybody from Zimbra stuff can provide feedback on this issue.

Recently I was dealing with Commercial SSL certificate installation on Zimbra Proxy only in Multiserver setup. Zimbra proxy - separate server, no other services are running there.

I was going through all of the SSL stuff here in forum, and somehow managed to install certs and deploy them. As far as I can understand, OpenSSL is used in Zimbra as a basis, with additional deployment scripts provided by Zimbra itself. I have passed successfuly through all OpenSSL and zmcertmgr verification of certs and deployment without any errors, as somebody were getting.

Applied keytool command on Proxy, restarted zimbra services and everything was ok, until I tested connection to this server.

All services worked, but there was a problem (even with commercial certificate - Thawte) - Safari nor Mac Mail application (IMAP/POP) could not connect to server corectly, throwing out an error with a notice, that "Certificate was signed by an untrusted issuer".

Investigating further this problem and keeping in touch with Thawte fantastic support, I came to the following conclusion:

1. By provisioning to zmcertmgr: commercial.crt (pure server cert) and commercial_ca.crt (root & intermediary servers), zmcertmgr somehow concatenated all this stuff together in one file.

2. After checking of commercial.crt file in /opt/zimbra/ssl/zimbra/commercial, I noticed, that this file is not only server cert any more. It includes root and intermediary servers.

3. After deployment, I noticed, that the same file was copied in /opt/zimbra/conf/nginx.crt (which probably is automatic process to provide SSL for Nginx configuration, on base of which Zimbra Proxy is providing services).

4. Probably some additional files were copied to /opt/zimbra/conf/ca folders, but still further didn't discovered it, as for each commercial_ca, several files were created.

So far I discovered some errors on file concatenation, described in other posts of this forum.

!!!!
Remember to include last LF symbol (Line Feed) in your certs' files, as concatenation will be incorect, and your joined certificates will not be recognized. -----Begining----- and -----End----- of certificate in such file should be on new line. This was my first finding and personal error.

But what I would like to ask Zimbra people?

According to what principles chained certificate files are joined in other prepared files, as some other forum posts were missleading in this? In other posts admins were defining, that you should concatenate root_ca file with intermediary_ca certs, by sych order creating one file, which starts with Root, and all subsequent intermediary certificates are added. But as far as I can understand, the final version (corect one) of chained cert file should be in the following order:

1. Server certificate;
2. Secondary intermediary certificate;
3. Primary intermediary certificate;
4. Root CA certificate.

Deploying certs by zmcertmgr position 2 to 4 were mixed up vice versa, thus leading to incorrect order of chained certs, giving the following: server, root, primary int, secondary int., and as a consequence - unability to verify issuer.

Althoug verification before deployment went OK. Verified with zmcertmgr and OpenSSL commands.

So my questions:

1. Does it make sense to Zimbra the order of certs in a chained file?

2. What files and to what location zmcertmgr copies to (currently found out only one file - /opt/zimbra/conf/nginx.crt)?

3. How to make correct deployment of certificate order in final crt files manually?

I would like to make manual editions of deployed crt files in correct order, but in which locations should I do it? Is it enough to change nginx.crt file, as I suppose, that /opt/zimbra/ssl/zimbra/commercial is just a repository of certificates to be used on updates or upgrades of Zimbra.

Would appreciate Zimbra comments and other people help.

[Ramadan Mansoura]

Please see bug https://bugzilla.zimbra.com/show_bug.cgi?id=57271

[j2b]

Thank your Ramadan Mansoura for reminding me on this issue. When I was struggling about this thing, nodoby was available for discussion. I was trying to connect to Thawte support, which has fantastic response time, but nevertheless, I had to leave this issue with a thought, that there something is wrong, and I've spent money for incorrect working of SSL. Thawte at that time could not help for a month, talking about result or solution. Oddly enought, before one of my other cert renewal, Thawte became active again, and it turned out, that they've provided me with wrong Root Certificate hash. They passed me MD5 hash file, instead of sha1. In December, when we returned to this issue, this was solved in a couple of days, and it turned out, that Zimbra had nothing to do with this issue.

Probably this issue were somewhere discussed in their knowledga base pages, but for person, who is not dealing with this in day-to-day manner, it was hard to find such info. And more bad words to Thawte - they could not too.

For others, if something similar happens - e.g. if ssl checks are OK, but browsers can not verify root cert signer, please check hashes of your CA cert. But this could be probably only one of the cases.