Zimbra 8.7 - Script doesn't work properly

[virento]

Hello, it appears this script doesn't run properly due to 'zmcertmgr' being required to run as the zimbra user and not as root (it complains about this and the script exits), a change implemented with the release of Zimbra 8.7. I believe I was able to work around this problem by inserting 'sudo -u zimbra' at the front of the lines that run 'zmcertmgr' however I also learned during this process that since it runs as the zimbra user, you have to change the permissions for the temp directory the script creates to allow the zimbra user to read those files as well as read the 'commercial.key' file.

To combat this, I had the script chmod the temp directory and the commercial.key file to allow reads by other users other than the user/group (which is root).

Unfortunately, I hit the letsencrypt certificate request limit which apparently is 5 certs in 7 days so I wasn't able to confirm the script could fully execute with these modifications. :(

If you could resolve this issue, that would be fantastic!

[VojtechMyslivec]

Hi @virento. Thank you for that detailed report.

My friend uses zimbra 8.6 and it works under root user well. Adding a read permission to others is generally bad idea (especially when you work with certs and keys). But changing ownership of the temp directory to zimbra user seems to be a good one.

I will make a special branch for version 8.7 with chown and sudo for you (but I don't have an environment to test it well right now).

PS: there is a --staging parameter for letsencypt-auto tool, which will lead to use of the staging environment (fake CA and 'no limits'). I will put this info in README.md at master.

[VojtechMyslivec]

Hi @virento. Can you please checkout zimbra-v8.7_dev branch and try it if it fix this issue?

PS: you can add --staging parameter for letsencypt-auto at line 235. I have add both comment in code and best practices in README.md to master branch already.

[barrydegraaff]

Looking into this on 8.7, it seems the letsencypt-auto tools wants me to answer questions, only those questions are never shown on the tty.

e.g. running the ps command shows:
/usr/bin/dialog --no-label Cancel --yes-label Agree --yesno Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf. You must agree in order to register with the ACME server at ht/...

That was after I added the --staging and also --register-unsafely-without-email to avoid another dialog.

So the zimbra-v8.7_dev branch does not seem to work on 8.7

Also I needed to :

mkdir -p /opt/zimbra/ssl/zimbra/commercial/
ln -s /opt/zimbra/ssl/zimbra/server/server.key /opt/zimbra/ssl/zimbra/commercial/commercial.key

@VojtechMyslivec So I am guessing this script needs some love, I can provide you with a test environment if you want. Barry

[barrydegraaff]

Adding --staging --register-unsafely-without-email --non-interactive --agree-tos

would get rid of the dialog.. then the script returns warning my dns is not correct, that is true, havent set that up for the dev server.

[barrydegraaff]

So summary, the script needs to look for the .key file in a different place, and some more ignore switches should be added.

[VojtechMyslivec]

Hi @barrydegraaff and thanks for the report. You have probably encounter similar issue like in #6.

• You must to manually run certbot/letsencrypt-auto once (to create an account) or use --email "$email" --agree-tos --non-interactive in the script
  • The latter choice is currently presented in dev branch, but I have not time and environment to test it right now.
  • --email appears to be better idea then --register-unsafely-without-email
• You should create a (dummy) CSR in zimbra web interface (so-called commercial), which leads to required directory structure and secret key. But, yes, I agree that a little "how-to" is missing in the README.md
  • It is maybe possible to generate the key in the script but I can not confirm that zimbra will not miss anything else.

To Do list:

• Test and merge the dev branch.
• Generate the secret key, if it is missing.
• Add the "installation" process manual in the README.md

[barrydegraaff]

To generate the csr and key file, we could run from the script as Zimbra user:
/opt/zimbra/bin/zmcertmgr createcsr comm -new

I suggest to only run this command in case the required csr and key file for this script are not present on the server.

@VojtechMyslivec I can test the dev branch, but to do so, I guess it needs to be merged here first, can you arrange that, I can than add the above zmcertmgr createcsr and we should get pretty close to a working solution then. Thanks

[MACscr]

So it does work with 8.7 now?

[VojtechMyslivec]

I have just rebased zimbra-v8.7_dev onto dev branch. You can profit from automation parameters for certbot but you must to create zimbra secret key.

To do this, generate a CSR in zimbra web administration - it will generate the desired key. Checkout zimbra-v8.7_dev branch and the script should work then.

Use --staging parameter to test it first. If it work well, uncomment it and run the script again.

[lightonflux]

Using it with 8.7 on Ubuntu 16.04 works after i changed how zimbra is started. But that is unrelated to this issue. (Use of service does not work with 16.04 and wrong path for sendmail in 8.7 #8).

[drphr4ud]

Testing 8.7_dev branch I get

obtain-and-deploy-letsencrypt-cert.sh: line 128: $2: unbound variable

The section in question is

# is $1 a executable ordinary file? (optionaly for user $2)
executable_file() {
    if [ -z "$2" ]; then
        [ -f "$1" -a -x "$1" ]
    else
        su -c \
          "[ -f '$1' -a -x '$1' ]" \
          - "$2"
    fi
}

Only modifications i made after checking out was to edit the location of letsencrypt. I have it in /root rather than /opt

[VojtechMyslivec]

Thanks @drphr4ud for the report. I fixed the unbound variable issue in 479fcd8.

If you install it in another location, you can freely edit the proper variable to desired value. The script uses a lot of checks before it start to do something.

[drphr4ud]

Thanks! Script runs without error now and restarts services.

But: Certificate being served in browser is still the old (soon expiring) letsencrypt certificate.
I was monitoring /var/log/letsencrypt/letsencrypt.org while it ran and it reported success.

Should the certificate paths in the script be modified ? When doing things manually I always saw the certs placed in /etc/letsencrypt/live/my.domain.com/ with a bunch of symlinks there linking to the actual revisions of certs. But in the script it asks for filenames without an absolute path so I did not modify it:

# the name of file which letsencrypt will generate
letsencrypt_issued_cert_file="0000_cert.pem"
# intermediate CA
letsencrypt_issued_intermediate_CA_file="0000_chain.pem"

/var/log/letsencrypt/letsencrypt.org talks of certs being placed in some random folders in /tmp/:

2016-11-16 13:06:57,674:INFO:certbot.client:Server issued certificate; certificate written to /tmp/tmp.DydRLpCzJ6/0000_cert.pem

[drphr4ud]

Just tried again and it seems Letsencrypt is happy.

2016-11-17 06:50:54,643:INFO:certbot.client:Server issued certificate; certificate written to /tmp/tmp.MRONLipVR3/0000_cert.pem
2016-11-17 06:50:54,644:INFO:certbot.client:Cert chain written to
2016-11-17 06:50:54,644:INFO:certbot.client:Cert chain written to
2016-11-17 06:50:54,645:DEBUG:certbot.reporter:Reporting to user: Congratulations! Your certificate and chain have been saved at /tmp/tmp.MRONLipVR3/0001_chain.pem. Your cert will expire on 2017-02-15. To obtain a new or tweaked version of this certificate in the future, simply run letsencrypt-auto again. To non-interactively renew all of your certificates, run "letsencrypt-auto renew"

obtain-and-deploy-letsencrypt-cert.sh reports no errors. But zmcontrol throws some non-fatal warnings when restarting nginx:

nginx: [warn] conflicting server name "imap" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "webmail" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "smtp" on 0.0.0.0:80, ignored
nginx: [warn] conflicting server name "imap" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "webmail" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "smtp" on 0.0.0.0:443, ignored
nginx: [warn] conflicting server name "imap" on 0.0.0.0:9071, ignored
nginx: [warn] conflicting server name "webmail" on 0.0.0.0:9071, ignored
nginx: [warn] conflicting server name "smtp" on 0.0.0.0:9071, ignored

Restart takes a few minutes and when it's all back up the certificate being served is still the old, soon expiring LetsEncrypt certificate. Checking Zimbra and nginx logs now to see if there is any clues but my assumption was that any errors in validating or installing the cert would have been reported obtain-and-deploy-letsencrypt-cert.sh when it does the zmcertmgr calls.

Update:
Whatever is going on is a local issue on my end. When I access the admin console on port 7071 the new cert is served. The new cert also shows inside the admin UI. I think the URL that is serving the old cert has a domain certificate set in Zimbra (multi tenancy). obtain-and-deploy-letsencrypt-cert.sh is not aware of that (and doesn't need to be).

[VojtechMyslivec]

I am really not sure what is happening. If you need more verbose input, remove all redirection to /dev/null

If you need to test it, use --staging certbot parameter (at line 275). Otherwise you will reach letsencrypt CA limits.

Try to look in Zimbra web administration for the installed certificates. Maybe you will find some more info what is happening.

[drphr4ud]

What's happening is that there are some domain-certificates defined in Zimbra (multi tenancy) and the script is not aware of them. As long as one is aware of that it is all good. 💃

[ba1020]

the default setting of the letsencrypt tools point to /opt while they usually are in /root

[VojtechMyslivec]

@ba1020 it depends on sysadmin nature. I would avoid installing applications/scripts into the root home. /opt is suitable for this.

Anyway, you can just change the variable in the script - or in the config file if you use the dev branch.

[YoShiiro]

Line 328 of obtain-and-deploy-letsencrypt-cert.sh you forgot the su -c zimbra to execute the restart result in errors :
Run as the zimbra user!
obtain-and-deploy-letsencrypt-cert.sh[err]: Restarting zimbra failed.

[VojtechMyslivec]

ok, thanks