Dear Maintainer,

I have Barrier server version 2.1.2+dfsg-1~bpo9+1 on a Debian box
and Barrier client version 2.3.3 on a Mac (from Homebrew).

After restarting the Mac, Barrier failed to start. Its log says
repeatedly:

ERROR: ssl error occurred (system call failure)
ERROR: failed to connect to secure socket

On the Debian system, syslog shows:

ERROR: ssl certificate doesn't exist: /home/phil/.local/share/barrier/SSL/Barrier.pem

But that file does exist:

The reason for the too-many-open-files appears to be that
sockets are leaked when client connections fail due to SSL
errors.

The particular SSL error in my case seemed to be due to the
server certificate having expired. Barrier seems to automagically
create SSL certs that are valid for one year.

I have been starting the Barrier server from my .config/openbox/autostart :
barriers -c /home/phil/.synergy.conf --enable-crypto

It appears that that doesn't do anything about expired SSL
certs. On the other hand, if I start the barrier GUI:
$ barrier --no-tray

then something does seem to create a certificate - at least,
it did when I removed the expired cert; I'm not sure if it
actually checks the expiry date. (Looking at the source the
only attempt to generate certs is in the GUI code, but I'm
not sure if that is run on expiry or only if no cert exists.)

In summary there are three issues here:

1. Misleading error reporting on server when too-many-open-files
prevents the SSL certificate file from being read.

2. Server socket leak when SSL error (certificate expired?) causes
client connection to fail.

3. Server SSL certificate expiry does not seem to be handled when
barriers is invoked directly, rather than the barrier GUI; it does
not attempt to generate new certificates, nor does it report any
useful error about expired certs to syslog when client connections
fail. (Nor do clients when they receive expired certs.)


Thanks, Phil.