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



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



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



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


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



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


  • Kopano



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



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



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



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



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


  • Kopano

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



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


Log in to reply