kopano-gateway ssl problem

gduran

Have read a couple of threads regarding this issue but none bring a solution.

root@application:~# tail -f /var/log/kopano/gateway.log
Thu Jun 13 22:05:24 2019: [kopano-gateway|T26887] [notice ] POP3/IMAP Gateway shutdown complete
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [=======] Starting kopano-gateway version 8.7.80 (pid 27004 uid 0)
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [info   ] Coredump status left at system default.
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [error  ] SSL CTX private key file error: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [error  ] Error loading SSL context, POP3S and IMAPS will be disabled
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [debug  ] Reexecing /usr/sbin/kopano-gateway
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [=======] Starting kopano-gateway version 8.7.80 (pid 27004 uid 999)
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [info   ] Coredump status left at system default.
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [error  ] ECChannel::HrSetCtx(): cannot open key file
Thu Jun 13 22:05:24 2019: [kopano-gateway|T27004] [error  ] Error loading SSL context, POP3S and IMAPS will be disabled

These complaints are invalid as these (official) certs are used everywhere else in this server without complaints.
Kopano-server version core-8.7.80.529 is in use.
Any suggestions where to look for?

thctlo

@gduran said in kopano-gateway ssl problem:

These complaints are invalid as these (official) certs are used everywhere else in this server without complaints.

I think, your missing rights on the keyfile. ( recheck gateway.cfg )
What i use to setup my certs is this, im assuming here we use 1 certificate for the server and gateway and others services. Do note, below is a work in progress and in stead of Symlinks, i might change to Copy commands. Not desided this yet, that depends a bit on how the rights are done.

And working ahead for next Debian release, for example Debian Buster shows ( see the folder output below).
Where for the key file access you now can add user kopano in ssl-cert group and your rights are set.

/etc/ssl
drwx--x---   2 root ssl-cert  4096 Dec 17 11:11 private

The group ssl-cert to protect the key files better, but that might confilct the certs are setup to /etc/ssl.
and/or we might need changed in apparmor ( for buster ).

#!/bin/bash

# Setup your certificates like this: 
# source : https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/
# requirements : apt install ca-certificates
# 
# Below setting are setup to match the kopano defaults as close as possible..
# Certs basis is for hostname host.domain.tld

# Original Certificates are placed in /etc/kopano/ssl  and add the cert names here in the script.
NAME_CERT="hostname-domain-tld-cert-2019.pem"
NAME_PRIVKEY="hostname-domain-tld-key-2019.pem"
# Now run the script. 

if [ ! -d /etc/kopano/ssl/ ]
then
    mkdir -p /etc/kopano/ssl
    cd /etc/kopano/ssl|| exit 1
else
    cd /etc/kopano/ssl|| exit 1
fi

#  (CA cert), linked to the defaults ca bundel 
if [ ! -L /etc/kopano/ssl/cacert.pem ]
then
    ln -s /etc/ssl/certs/ca-certificates.crt /etc/kopano/ssl/cacert.pem
else
    echo "Symlinked file /etc/ssl/certs/cacert.pem already exists"
fi

# kopano-server 
### PRIVKEY and SERVER Certs to match Kopano defaults.
# Keyfile
if [ ! -L /etc/kopano/ssl/privkey.pem ]
then
    ln -s /etc/kopano/ssl/"${NAME_PRIVKEY}" /etc/kopano/ssl/privkey.pem
else
    echo "Symlinked file /etc/kopano/ssl/privkey.pem already exists"
fi

# Cert file, 
if [ ! -L /etc/kopano/ssl/cert.pem ]
then
    ln -s /etc/kopano/ssl/"${NAME_CERT}" /etc/kopano/ssl/cert.pem
else
    echo "Symlinked file /etc/kopano/ssl/cert.pem already exists"
fi

# Create Server Key+Cert chain.
if [ -f /etc/kopano/ssl/cert.pem ]||[ -f /etc/kopano/ssl/privkey.pem ]
then
    cat "$NAME_PRIVKEY" "${NAME_CERT}" > /etc/kopano/ssl/server.pem
else
    echo "File /etc/kopano/ssl/server.pem already exists."
fi

# Kopano-gateway
if [ ! -d /etc/kopano/gateway/ ]
then
    mkdir -p /etc/kopano/gateway
    cd /etc/kopano/gateway|| exit 1
else
    cd /etc/kopano/gateway|| exit 1
fi
if [ ! -L /etc/kopano/gateway/privkey.pem ]
then
    ln -s /etc/kopano/gateway/"${NAME_PRIVKEY}" /etc/kopano/ssl/privkey.pem
else
    echo "Symlinked file /etc/kopano/gateway/privkey.pem already exists"
fi

# Cert file, indien deze symlink niet bestaat.
if [ ! -L /etc/kopano/gateway/cert.pem ]
then
    ln -s /etc/kopano/gateway/"${NAME_CERT}" /etc/kopano/ssl/cert.pem
else
    echo "Symlinked file /etc/kopano/gateway/cert.pem already exists"
fi

gduran

Hi,
Thanks for your response however, it turns out it’s NOT a rights issue. I’m also able to open and read the key file as user kopano.
Kopano service was running fine through June 10th and I just now noticed in my /var/log/apt/history.log that there was an OpenSSL and various related packages upgrade applied (i.e. Python amongst others) on June 10th late evening (Kopano is running on Ubuntu 18.04). The following day the problem occurred. That hardly can’t be a coincidence. As I don’t have these issues with other applications I start to wonder whether Gateway is using it’s own verification routine and that that has broken due to the aforementioned upgrades.
Just a thought…