Issued certificate is not readable about letsencrypt-zimbra HOT 7 CLOSED

I'm running certbot 0.31.0-1+ubuntu16.04.1+certbot+1
Zimbra 8.8.15_GA_3899.FOSS
Ubuntu 16.04 is the OS .

from letsencrypt-zimbra.

A fix is to wait for the "IMPORTANT INFORMATION" banner from certbot which says "Congratulations!"

At that moment suspend the task by typing ctrl-z

With a seperate terminal window as root go to the temporary directory which the message has been displaying : example:

• Congratulations! Your certificate and chain have been saved at:
  /tmp/tmp.Z6AfjXtDOS/0001_chain.pem

so you would cd to /tmp/tmp.Z6AfjXtDOS
then chown root.zimbra 0*
(that was a zero)
Then back into the origional terminal window and type
fg %1
(This brings back to the foreground process number 1 from the terminal window)

So this will probably get this working for me.
I've had several different methods installed for managing letsencrypt on this zimbra server over the years. Maybe this has something to do with the irregular situation I may have found myself in.

I think this will triage me for the next 90 days.

from letsencrypt-zimbra.

Hello and thank you for the report. I see 0000_cert.pem is not readable fot others so the script running as zimbra user can not read and manipulate it. I am glad you are able to find a temporary workaround, yet it won't work for non-interactive renewal.

I will try to find out why certbot generates a certificate with restrict permissions.

from letsencrypt-zimbra.

I have made some tests on my instance which is really similar to yours (ubuntu 16 with certbot 0.31):

certbot respects umask configuration while creating certificate files and letsencrypt-zimbra script sets correct umask before calling certbot to make sure certificate file would be readable.

My only idea is you have some more restrictive environment, such as sudo forcing some umask configuration. You can try search for umask_override and/or umask options in your sudo configuration:

# grep -r umask /etc/sudoers*

from letsencrypt-zimbra.

Well I do ssh to the server as root.
Then I launch "screen -dRR"

Here's what my environment varriables look like as root
root@mail3:/tmp/tmp.DMZWk5QoJ4# env
XDG_SESSION_ID=59124
TERM=xterm-256color
SHELL=/bin/bash
SSH_CLIENT=XXX.XXX.XXX.XXX 38896 22
SSH_TTY=/dev/pts/4
USER=root
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=00:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:.tar=01;31:.tgz=01;31:.arc=01;31:.arj=01;31:.taz=01;31:.lha=01;31:.lz4=01;31:.lzh=01;31:.lzma=01;31:.tlz=01;31:.txz=01;31:.tzo=01;31:.t7z=01;31:.zip=01;31:.z=01;31:.Z=01;31:.dz=01;31:.gz=01;31:.lrz=01;31:.lz=01;31:.lzo=01;31:.xz=01;31:.bz2=01;31:.bz=01;31:.tbz=01;31:.tbz2=01;31:.tz=01;31:.deb=01;31:.rpm=01;31:.jar=01;31:.war=01;31:.ear=01;31:.sar=01;31:.rar=01;31:.alz=01;31:.ace=01;31:.zoo=01;31:.cpio=01;31:.7z=01;31:.rz=01;31:.cab=01;31:.jpg=01;35:.jpeg=01;35:.gif=01;35:.bmp=01;35:.pbm=01;35:.pgm=01;35:.ppm=01;35:.tga=01;35:.xbm=01;35:.xpm=01;35:.tif=01;35:.tiff=01;35:.png=01;35:.svg=01;35:.svgz=01;35:.mng=01;35:.pcx=01;35:.mov=01;35:.mpg=01;35:.mpeg=01;35:.m2v=01;35:.mkv=01;35:.webm=01;35:.ogm=01;35:.mp4=01;35:.m4v=01;35:.mp4v=01;35:.vob=01;35:.qt=01;35:.nuv=01;35:.wmv=01;35:.asf=01;35:.rm=01;35:.rmvb=01;35:.flc=01;35:.avi=01;35:.fli=01;35:.flv=01;35:.gl=01;35:.dl=01;35:.xcf=01;35:.xwd=01;35:.yuv=01;35:.cgm=01;35:.emf=01;35:.ogv=01;35:.ogx=01;35:.aac=00;36:.au=00;36:.flac=00;36:.m4a=00;36:.mid=00;36:.midi=00;36:.mka=00;36:.mp3=00;36:.mpc=00;36:.ogg=00;36:.ra=00;36:.wav=00;36:.oga=00;36:.opus=00;36:.spx=00;36:.xspf=00;36:
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
PWD=/tmp/tmp.DMZWk5QoJ4
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
SSH_CONNECTION=XXX.XXX.XXX.XXX 38896 XXX.XXX.XXX.XXX 22
LESSOPEN=| /usr/bin/lesspipe %s
XDG_RUNTIME_DIR=/run/user/0
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/env
OLDPWD=/tmp

And then when I su - zimbra here's the environment varriables from there:

zimbra@mail3:~$ env
MANPATH=/opt/zimbra/common/share/man:
SHELL=/bin/bash
TERM=xterm-256color
PERL5LIB=/opt/zimbra/common/lib/perl5/x86_64-linux-gnu-thread-multi:/opt/zimbra/common/lib/perl5
LC_ALL=C
USER=zimbra
SNMPCONFPATH=/opt/zimbra/conf
USERNAME=zimbra
JYTHONPATH=/opt/zimbra/common/lib/jylibs
MAIL=/var/mail/zimbra
PATH=/opt/zimbra/bin:/opt/zimbra/common/lib/jvm/java/bin:/opt/zimbra/common/bin:/opt/zimbra/common/sbin:/usr/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
PWD=/opt/zimbra
JAVA_HOME=/opt/zimbra/common/lib/jvm/java
LANG=C
PERLLIB=/opt/zimbra/common/lib/perl5/x86_64-linux-gnu-thread-multi:/opt/zimbra/common/lib/perl5
SHLVL=1
HOME=/opt/zimbra
LOGNAME=zimbra
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
HISTTIMEFORMAT=%y%m%d %T
_=/usr/bin/env

Thanks for the information about the UMASK. I'm going to check on the server 13 days before the expiration to see how automatic renewal is going.
So to test some of these things out I was inserting echo commands in the script so I could see what exactly was being passed to a command such as the zmcertmgr .
Maybe I coudl do the same just before the issuance of the certbot command to test if the umask is being set.

from letsencrypt-zimbra.

oh... I am sorry for misunderstanding. By "environment", I do not mean exactly environment variables, but some overall configuration of your server/s.

So, as you are able to run custom commands, try that one I mentioned above:

grep -r umask /etc/sudoers*

which will just search for umask-related sudo configuration.

And probably to simulate what letsencrypt-zimbra certificate does:

bash
umask 0022; sudo -u zimbra sh -c 'umask'
umask 0027; sudo -u zimbra sh -c 'umask'
exit

from letsencrypt-zimbra.

Closed due to several months without any activity. Feel free to reopen or file another issue if new facts appear.

from letsencrypt-zimbra.