Error loading SSL context, POP3S and IMAPS will be disabled on Kopano Core: 8.7.80.307

Drethaldier

Hello everyone on board,

normally I can fix every problem myself regarding Kopano or at least find a fix on google but this one drives me crazy.

Today I updated Kopano to Version 8.7.80.307 from 8.6.81 running on debian 9.
Everything works except imaps. When I restart kopano-gateway the log shows the following errors:

Mon Dec 17 16:18:53 2018: [=======] Starting kopano-gateway version 8.7.80 (pid
Mon Dec 17 16:18:53 2018: [error  ] ECChannel::HrSetCtx(): cannot open key file
Mon Dec 17 16:18:53 2018: [error  ] Error loading SSL context, POP3S and IMAPS w

Before upgrading it worked fine.
I am using Lets Encrypt.
Here’s my gateway.cfg

##############################################################
# GATEWAY SETTINGS

#server_bind    = 0.0.0.0

# Please refer to the administrator manual or manpage why HTTP is used rather than the UNIX socket.
server_socket = http://localhost:236/kopano

# Set this value to a name to show in the logon greeting to clients.
# Leave empty to use DNS to find this name.
server_hostname =

# Whether to show the hostname in the logon greeting to clients.
server_hostname_greeting = no

# drop privileges and run the process as this user
run_as_user = kopano

# drop privileges and run the process as this group
run_as_group = kopano

# create a pid file for stopping the service via the init.d scripts
pid_file = /var/run/kopano/gateway.pid

# run server in this path (when not using the -F switch)
running_path = /var/lib/kopano

# create memory coredumps upon crash [no, systemdefault, yes]
coredump_enabled = no

# enable/disable POP3, and POP3 listen port
#pop3_listen = *:110

# enable/disable Secure POP3, and Secure POP3 listen port
#pop3s_listen = *:995

# enable/disable IMAP, and IMAP listen port
imap_listen = *:143

# enable/disable Secure IMAP, and Secure IMAP listen port
imaps_listen = *:993

# Only mail folder for IMAP or all subfolders (calendar, contacts, tasks, etc. too)
imap_only_mailfolders = yes

# Show Public folders for IMAP
imap_public_folders = yes

# IMAP clients may use IDLE command
imap_capability_idle = yes

# The maximum size of an email that can be uploaded to the gateway
imap_max_messagesize = 128M

# Internally issue the expunge command to directly delete e-mail marked for deletion in IMAP.
imap_expunge_on_delete = no

# Maximum count of allowed failed IMAP command counts per client
imap_max_fail_commands = 10

# Some MUAs are sending commands via idle causing the connection
# to reach imap_max_fail_commands and leaves the client in a
# broken state. The clients include Apple Mail. If you experience
# problems or uses Apple Mail set this option to yes
#imap_ignore_command_idle = no

# Disable all plaintext authentications unless SSL/TLS is used
disable_plaintext_auth = yes

# File with RSA key for SSL
ssl_private_key_file = /etc/kopano/ssl/privkey.pem

#File with certificate for SSL
ssl_certificate_file = /etc/kopano/ssl/cert.pem

# Verify client certificate
#ssl_verify_client = no

# Client verify file and/or path
#ssl_verify_file =
#ssl_verify_path =

# SSL protocols to use, space-separated list of protocols
# (SSLv3 TLSv1 TLSv1.1 TLSv1.2); prefix with ! to lock out a protocol.
ssl_protocols = !SSLv3

# SSL ciphers to use, set to 'ALL' for backward compatibility
#ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL

As you can see the key fles are located in the Kopano SSL folder. This was just a test to see if it works with symlinks. Normaly I use the letsencrypt live folder.

I hope somebody can help me tho its not that important since only one user uses imap.

dw2412

@Drethaldier Please show us a ls -lA /etc/kopano/ssl/*.pem and check the access rights for user / group kopano to /etc/kopano/ssl folder.

Andreas

Drethaldier

@dw2412

ls -la /etc/kopano/ssl/*.pem shows:

lrwxrwxrwx 1 root root  8 Dez 17 16:12 /etc/kopano/ssl/cert.pem -> cert.pem
lrwxrwxrwx 1 root root 11 Dez 17 16:12 /etc/kopano/ssl/privkey.pem -> privkey.pem

/etc/kopano/ssl

drwx------ 2 kopano root    4096 Dez 17 16:12 ssl

and just to show you the letsencrypt permissions which is normaly used.

ls -la /etc/letsencrypt/live/ shows:

drwxr-xr-x 2 root root 4096 Dez  1 00:50 domain.xx

ls -la /etc/letsencrypt/live/domain.xx/

lrwxrwxrwx 1 root root   38 Dez  1 00:50 cert.pem -> ../../archive/domain.xx/cert4.pem
lrwxrwxrwx 1 root root   39 Dez  1 00:50 chain.pem -> ../../archive/domain.xx/chain4.pem
lrwxrwxrwx 1 root root   43 Dez  1 00:50 fullchain.pem -> ../../archive/domain.xx/fullchain4.pem
lrwxrwxrwx 1 root root   41 Dez  1 00:50 privkey.pem -> ../../archive/domain.xx/privkey4.pem

Just to clarify.
I changed nothing on the permission of the Letsencrypt folder before or after the upgrade. Before the upgrade it worked with that. After the upgrade it didnt.
My normal gateway.cfg on ssl is:

# File with RSA key for SSL
ssl_private_key_file = /etc/letsencrypt/live/domain.xx/privkey.pem

#File with certificate for SSL
ssl_certificate_file = /etc/letsencrypt/live/domain.xx/fullchain.pem

dw2412

@Drethaldier said in Error loading SSL context, POP3S and IMAPS will be disabled on Kopano Core: 8.7.80.307:

ls -la /etc/kopano/ssl/*.pem shows:
lrwxrwxrwx 1 root root 8 Dez 17 16:12 /etc/kopano/ssl/cert.pem -> cert.pem
lrwxrwxrwx 1 root root 11 Dez 17 16:12 /etc/kopano/ssl/privkey.pem -> privkey.pem

Hmmm… this looks like a never ending link on the file itself (which actually means that the privkey is not formatted as expected so the gateway message might be a little bit missleading but actually it means that the privkey cannot be opened in the end). If you still use the gateway.cfg from first post, please change the symlinks to the proper files in /etc/letsencrypt/live/domain.xx/

Andreas

Drethaldier

@dw2412

Now I have this:

# File with RSA key for SSL
ssl_private_key_file = /etc/letsencrypt/live/domain.xx/privkey.pem

#File with certificate for SSL
ssl_certificate_file = /etc/letsencrypt/live/domain.xx/cert.pem

Logfile still shows:

Mon Dec 17 19:12:38 2018: [=======] Starting kopano-gateway version 8.7.80 (pid 2825 uid 999)
Mon Dec 17 19:12:38 2018: [error  ] ECChannel::HrSetCtx(): cannot open key file
Mon Dec 17 19:12:38 2018: [error  ] Error loading SSL context, POP3S and IMAPS will be disabled

And imaps can’t be used.

fbartels

https://forum.kopano.io/topic/1763/error-connecting-to-imaps-via-gateway-core-8-6-81-416/

Drethaldier

@fbartels
I saw that post when I looked for an answer. It didn’t help me. Maybe I understood something wrong in it or overlooked.

dw2412

@Drethaldier I’ve tested it on the Supported 8.6.9 that I’m running in a container (multitenant setup, no archive server, no multi server) and it works with ssl in there:

ssl_private_key_file    =       /etc/kopano/gateway/privkey.pem
ssl_certificate_file    =       /etc/kopano/gateway/cert.pem
-rw-r--r-- 1 root root 5513 Nov 28 10:16 /etc/kopano/gateway/cert.pem
-rw-r--r-- 1 root root 3243 Nov 28 10:16 /etc/kopano/gateway/privkey.pem
kopano-gateway 8.6.9

Maybe not a goot idea regarding the file rights but as loong as the server can access and read the files and their content is valid it seems to work in latest supported version on Ubuntu 16.04. I just remember that once I’ve an issue with letsencrypt certificates on my mail server because there was an issue with access rights in the folder structure within that the certificate was stored. The main cert folder has had 700 access rights and because of this the symlinked cert access by an unpriviliged user was impossible… Since that I’m using dehydrated script, hooks for either cp or chown to have the files at right place and check them with openssl prior all this to limit issues with automated service restarts…

Andreas

thctlo

yes, you need the set the correct rights.
@dw2412 you allowing WORLD access to your keyfile… thats not good.

what you can do… Example shown what i do on my Debian system

/etc/ssl/cert ( 775 ) root:root

/etc/ssl/private 750 root:ssl-certs

if you installed ca-certificates you should see ssl-certs as group also.
Now its getting more simple.
My local certs.
/etc/ssl/local/certs ( 775 ) root:root
/etc/ssl/local/private 710 root:ssl-cert ( Folder )
/etc/ssl/local/private 440 root:ssl-cert (Files) ( or 640, some programs my complain about 440 )
adduser kopano ssl-certs
you can do the same for apache, postfix etc.

my kopano setup :
ssl-cert:x:113:mysql,postfix,kopano,www-data

Done and safe setup.
Now, i dont use letsencrypt my server atm ,so check if you can set a group for the keyfiles and add the service user in it.

dw2412

@thctlo I’m aware of this and as I said “Maybe not a goot idea regarding the file rights”…

I changed it already in the meantime - it was just some leftover from some “lets do this change quickly…”

Andreas

Drethaldier

@thctlo said in Error loading SSL context, POP3S and IMAPS will be disabled on Kopano Core: 8.7.80.307:

yes, you need the set the correct rights.
@dw2412 you allowing WORLD access to your keyfile… thats not good.

what you can do… Example shown what i do on my Debian system

/etc/ssl/cert ( 775 ) root:root

/etc/ssl/private 750 root:ssl-certs

if you installed ca-certificates you should see ssl-certs as group also.
Now its getting more simple.
My local certs.
/etc/ssl/local/certs ( 775 ) root:root
/etc/ssl/local/private 710 root:ssl-cert ( Folder )
/etc/ssl/local/private 440 root:ssl-cert (Files) ( or 640, some programs my complain about 440 )
adduser kopano ssl-certs
you can do the same for apache, postfix etc.

my kopano setup :
ssl-cert:x:113:mysql,postfix,kopano,www-data

Done and safe setup.
Now, i dont use letsencrypt my server atm ,so check if you can set a group for the keyfiles and add the service user in it.

I’ll try that when I find the time. I have to verify that it works with letsencrypt in a test vm. Was a dumd Idea to upgrade so close to christmas.
I tested it by running kopano-gateway as root and it worked again.
I will get back when I have more information about the solution.

fbartels

@Drethaldier the important part is that both the certificate and all the folders leading to it are readable by either the kopano user or group.

dw2412

@Drethaldier Exactly if you’re running the gateway as a root user it is exactly what thctlo and I say… A matter of access rights. Please try the following:

sudo -u kopano /bin/bash
cat /etc/letsencrypt/live/domain.xx/privkey.pem

If you’re able to cat the file as user kopano and gateway is running as user kopano your issue should be solved. if you cannot cat the file as user kopano please check the access rights for each part of the folderlist and for the privkey.pem itself. If you want to have a quick solution for your christmas eve to happen without any thought about this certificate just copy the privkey.pem and cert.pem to /etc/kopano/gateway, do a “chown kopano.kopano /etc/kopano/gateway -r”, a “chmod 600 /etc/kopano/gateway/privkey.pem” and a “chmod 655 /etc/kopano/gateway/cert.pem”. Afterwards check that gateway will run as user kopano and group kopano and restart the gateway service.

Andreas