Renew certificate - ZIMBRA

Help
#1

When I go to renew my certificate, among several commands I use the following:

su - zimbra -c "cd /opt/zimbra/ssl/letsencrypt/; /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem combined.pem"

However after running it I get the following error:

** Verifying 'cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'
Certificate 'cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' match.
** Verifying 'cert.pem' against 'combined.pem'
ERROR: Unable to validate certificate chain: cert.pem: CN = mail.xxxxxxxxx.com.yy
error 20 at 0 depth lookup:unable to get local issuer certificate

What should I do ?

Thanks

#2

Where does combined.pem come from?

2 Likes
#3

Try using:

su - zimbra -c "cd /opt/zimbra/ssl/letsencrypt/; \
/opt/zimbra/bin/zmcertmgr deploycrt comm fullchain.pem"

OR
Update your combined.pem to reflect the recent X3 to R3 intermediate cert change.

2 Likes
#4

This is were I was aiming for indeed :wink: However, not sure how to advice regarding to Zimbra to automate the retrieval of the intermediate automatically, therefore I asked where combined.pem came from :slight_smile:

3 Likes
#5

Yes, I just added a few more words to your hint :wink:
And I just don't think that is possible (yet); or at least not with the manual script/process being used.

1 Like
#6

Hmmmmm... I seem to recall [edit: here's where I encountered this before] that Zimbra requires the root to be included in the chain. So maybe some folks will need to replace a hard coded DST root in their scripts with the ISRG root. (On reflection this might not be relevant in this case)

#7

Hardcoding is never the solution :wink:

2 Likes
#8

I found the solution.

See below:

Until recently I used the script below with full success:

su - zimbra -c "zmcontrol stop"
/root/letsencrypt/letsencrypt-auto renew
echo "y" | cp /etc/letsencrypt/live/mail.domain.com/privkey.pem /opt/zimbra/ssl/letsencrypt/
echo "y" | cp /etc/letsencrypt/live/mail.domain.com/cert.pem /opt/zimbra/ssl/letsencrypt/
echo "y" | cp /opt/zimbra/ssl/letsencrypt/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key
chown zimbra:zimbra /opt/zimbra/ssl/letsencrypt/*
su - zimbra -c "cd /opt/zimbra/ssl/letsencrypt/; /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem combined.pem"
/opt/zimbra/libexec/zmfixperms
su - zimbra -c "zmcontrol start"
su - zimbra -c "zmupdateauthkeys"
su - zimbra -c "/opt/zimbra/libexec/zmloggerinit"
/opt/zimbra/libexec/zmsyslogsetup
rm -rf /var/lib/rsyslog/imjournal.state
/usr/bin/systemctl restart rsyslog
su - zimbra -c "zmcontrol stop"
/opt/zimbra/libexec/zmfixperms
su - zimbra -c "zmcontrol start"

On the last renewal of the certificate I received the error:

** Verifying 'cert.pem' against '/opt/zimbra/ssl/zimbra/commercial/commercial.key'
Certificate 'cert.pem' and private key '/opt/zimbra/ssl/zimbra/commercial/commercial.key' match.
** Verifying 'cert.pem' against 'combined.pem'
ERROR: Unable to validate certificate chain: cert.pem: CN = mail.domain.com
error 20 at 0 depth lookup:unable to get local issuer certificate

that occurs when the script executes the command

openssl verify /opt/zimbra/ssl/letsencrypt/cert.pem

Fortunately I just found the solution and the certificate was renewed at Zimbra!

I found the solution on the website https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate

Anyway, I have to thank everyone who helped me here, because it was through their comments that I was able to better understand the process and identify the solution.

thank you

Forgive my English

2 Likes
#9

Which part of the elaborate how-to was key to your solution exactly? (For future readers.)

1 Like
#10

This is the only difference I could find:
[which is inline with our thinking]

image
image783×35 2.34 KB

His previous script doesn't even show where combined.pem comes from.

1 Like
#11

But that alone apparently isn't enough for Zimbra @rg305. While using chain.pem from the certbot directory obviously would use the correct intermediate (as it's delivered by certbot), Zimbra apparently requires the root certificate to be in the chain too. I have no idea why, but if that step isn't automated it's just waiting for the next time Zimbra will fail.

However, it would be possible to use the AIA or Issuer information from chain.pem to identify the root certificate and automate that step.

2 Likes
#12

OMG, I almost fell out of my chair reading this:

image
image779×145 11.4 KB

Did the writer have a clue on how trusted CAs are supposed to be delivered?
Is there some alternate CA file being used by Zimbra that doesn't include the root CA they ask you to add?
Do they even use the O/S provided CA file?

1 Like
#13

Yeah, I read that to, almost made a facepalm.. :man_facepalming:

Does that even matter? Root certificates shouldn't be send in the chain: it should never be necessary. You wouldn't do anything with it. You can't rely on the server send root certificate to determine trust. Otherwise I could send my own self-signed root and Zimbra would accept it as trusted? Zeh #()$()#?

In any case, I have no idea what Zimbra is, how it works et cetera and frankly I don't want to know to be honest.

2 Likes
#14

I get that they need to validate the entire cert chain (not necessarily send the whole thing out).
But the default for every CA on the planet is NEVER to send you the ROOT cert.
You should already have that part and use it as needed / whenever needed.
They are somehow missing that step and want the user to do it for them.

I wonder if there is a simply hack to pass the concated file in the command line...
And just send it something like:
concat(cert.pem, /etc/ssl/certs/ca-certificates.crt)

and let them deal with it.

1 Like
#15

That's pretty simple:

$ openssl verify -CAfile <(cat chain.pem /etc/ssl/certs/ca-certificates.crt) -show_chain -no-CApath cert.pem 
cert.pem: OK
Chain:
depth=0: CN = example.com (untrusted)
depth=1: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
depth=2: O = Digital Signature Trust Co., CN = DST Root CA X3

I don't know where the "(untrusted)" comes from in the chain, as it clearly chains up to a trusted root.. Also, I had to add -no-CApath as my OpenSSL would validate anything I was feeding it.. :stuck_out_tongue:

2 Likes
#16

With no surprise, this actually worked:

(cat chain.pem /etc/ssl/certs/ca-certificates.crt) > test.pem
/opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem test.pem

Certificate chain
 0 s:/CN={some.do.main}
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
 2 s:/O=Digital Signature Trust Co./CN=DST Root CA X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
1 Like
#17

Interesting. Can you confirm that only the correct chain is installed into /opt/zimbra/ssl/zimbra/commercial and not the entire ca-certificates.pem from /etc/ssl/certs/?

1 Like
#18

It is the entirety.
And even though it seems to work via the OpenSSL test, the inter-workings between nodes fails.
So that's not a good "workaround" :frowning:

The web service was smart enough to only use the certs that chained together.
But other internal services aren't as "smart".

1 Like
#19

Zimbra -> :wastebasket:

1 Like
#20

Hey it's FREE :wastebasket:

ZIMBRA loosely translates to work in progress
LOL

1 Like