-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ordering issue of chains #79
Comments
Hello, I am not sure it should be the way you mentioned here. Common order of a certificate chain is from the leaf to the root. Any subsequent certificate should "sign"/"verify" the one before. In fact, this order was introduced in #18 about 5 years ago and no one has reported this issue since then. If your Zimbra installation report some error, would you be so kind and share an error message here? Vojtech |
I’ve had some issues with verify command. Then I found this page As you can see the ROOT comes first and then comes the intermediate certificates. When I changed the ordering of the chain, it all worked back perfectly. |
What Zimbra version do you use? The article you linked is from 2015 and marked as WIP, so it's hard to tell if it is up-to date source 😕 |
v8.7 |
@moparlakci In over 15 years of managing SSL and TLS certificates, I have only ever been confused as to what certificate should go where by one product: zimbra. It requires the inclusion of the trusted root certificate in the certificate chain, even though that is neither necessary nor good practice. To make things worse, the instructions are often misleading or contain straight-out errors. The correct order is to put the intermediate certificate or certificates first, in order so that the first is signed by the second and so on. The trusted root certificate goes last. As to your depth-error, and for more information about Let's Encrypt certificates, the following articles might be helpful: https://wiki.zimbra.com/wiki/Installing_a_RapidSSL_Commercial_Certificate (see the comment about errors at the bottom) https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate If you would like help figuring out why the correct order of certificates was causing errors for you, please post the exact sequence of commands you ran along with their output. |
@sjbronner thanks you very much for the info
exactly 👍
I agree with that as well. Some of these wiki articles seems to be misleading, as you noted. |
Closing this as it seems the discussion is over and the issue wasn't confirmed |
Confirming I needed exactly the change @moparlakci suggested above in order for zmcertmgr verifycrt / deploycrt to succeed Without it, I was getting:
My Zimbra 8.8.15_GA_4232 (build 20220204072400) on Ubuntu 16.04 needs the chain to be written in this order for verifycrt / deploycrt to work. |
Thanks for your comment. This is really weird. Some installations works as expected while some others needs the reversed order of the certs 🤷 |
I get this error could you guide me how to resolve this issue?
zimbra version : Release 8.8.15.GA.3869.UBUNTU18.64 UBUNTU18_64 FOSS edition, Patch 8.8.15_P11. |
Since i just ran into the same problem at a client i couldn't (and still can't) make sense of unless the clocks run backwards at Zimbra:
Zimbra expects:
so:
which indeed is the wrong way around! Chain goes intermediate(s) -> root, not root -> intermediate(s) otherwise your tree stands on its head. chain.pem (from certbot)
which is the proper order.
This is zmcertmgr on Zimbra |
I prepared the branch reverse-cert-order with revert of efc0b92 commit. Sadly, I don't have a Zimbra instance to test it now so I would leave it in the open branch for a while to not break other deployments where it works in the original order. |
Looks like LE is about to get rid of the cross-signed X1, effectively shortening the chain of trust, so this should fix itself eventually: https://letsencrypt.org/2023/07/10/cross-sign-expiration.html |
Maintainer's noteQuestion in this post is moved to #83. Original text (which is not related to this issues) is below Hi
Neither works:
On top of this, the currents certs expires tomorrow, great.... 8.8.15.GA.4581.FOSS Thanks! |
Dude below you have an ordering issue
create one CA chain file
should be
Then it will work fine ;)
The text was updated successfully, but these errors were encountered: