kopano-gateway ssl problem



  • 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?



  • @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
    
    


  • 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…


Log in to reply