Incident: kopano-server not able to connect to kopano-search via https

Date Seen
Approximately 05.12.2016.

Versions
Ubuntu 16.04.1 LTS
Kopano 8.3.0-534
Apache 2.4.18
MySQL 5.7.16

Bug Description
kopano-server is not able to communicate with kopano-search over https. This worked in earlier 8.2.x versions of Kopano.

Severity
Minor

Steps to Reproduce
Create a self-signed certificate like described in the Kopano Core Administrator Manual.

Configure kopano-search to bind on https port 1238, restart the service and check for port 1238 to open:
0_1483740928412_upload-e4e8d3a6-78d2-4c0b-ae0a-ebd490c54ea9
0_1483741189140_putty.png

Test if a connection could be made:
0_1483741498285_upload-3486eb76-d997-42a1-8b2f-99a488ded6df

Configure kopano-server to use the https port to connect to kopano-search and restart the service:
0_1483741606517_upload-13a9dfdb-f842-4ffb-a1eb-88c2715aacd7

Actual Behavior
kopano-server is not able to connect to kopano-search and only reports the following log lines, even on log_level 6:
0_1483742165500_upload-4fc9c8af-07d4-4831-aefc-5b6820d03f51

Expected Behavior
Communication between kopano-server and kopano-search is encrypted over https and working like in earlier 8.2.x versions of Kopano.

Troubleshooting/Testing Steps Attempted
Port binding on port 238 doesn’t work, it seems that it will only bind on high ports (above 1024). Binding to port 1238 via http works and kopano-server is able to connect.

Workaround
As a workaround we could fall back to unix socket or http socket.

Hello Richard,

thanks for your detailed report. Since KC-156 (ticket not public, but title is “libmapi client does not check SSL certificate subject name”) we are enforcing that the subjectAltNames and/or cn matches for ssl connections. Since you connect to “localhost” this probably fails for you. To “fix” it you need to connect to the hostname the certificate was created for.

EDIT: I also have to ask. Why do you want to use the http socket, when still running everything on the same machine? Performance-wise unix sockets outperform http sockets. See https://blog.myhro.info/2017/01/how-fast-are-unix-domain-sockets for example data.

Hi Felix,

i am using a self signed certificate and i think my configuration is fine:
0_1483974842459_upload-6679c0d9-411b-47d2-bb3c-f31f2cc12010
0_1483974889117_upload-f5442a2f-a613-4138-a737-f5ff89a0458c

I don’t want to use unix sockets for security reasons. It’s not mandantory for me and i am just “playing” around. But i am sure there are companies with security policies wich enforce the use of secured sockets.

Regards
Richard

Hello Richard,

can you explain why you think an unauthenticated http socket could be more secure than a unix socket?

PS: please also post logs in clear text and not putty screenshots.

Hi Felix,

sorry i meant “i don’t want to use http sockets”. In my case using a unix socket is fine and as i said i am just playing around. But in a larger environment if the kopano-search service is installed on a different node the traffic should be encrypted using a ssl tcp socket.

Do you need more logs?

Regards
Richard

I have created https://jira.kopano.io/browse/KC-454, so that we can try to reproduce this internally.

Even in large setups the usual install pattern is to run search on the same system that the server is running on. So the unix socket is indeed used in 99,9999% of all cases.

Hi Felix,

i see.

Just to clarify:

I submitted this thread because Kopano is offering an option wich isn’t working. This could be a bug on the software side or a configuration issue on my side. For me i virtually have no problem because i can just use a unix socket. The reason why i submitted this thread is to improve the software. Because Kopano is open source and i am very happy with it i felt reporting bugs/problems is an advantage for the Kopano staff.

Thank you for creating a ticket.

Regards
Richard

Yes, it seems not to work, thats why I created the ticket. And we were also able to solve your misconception of using an http(s) socket. So win-win I would say ;-)