I can confirm that the file does not exist:

$ ls ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/
$ locate Barrier.pem

I thought this could be similar to #142 but allowing barrier.exe and barriers.exe through the firewall did not change the message in the logs.

'171 also looked related but I cannot work out where the Barrier.pem shown there comes from. Following the supplied link did not really change anything.

I can at least confirm this is related to having the SSL config enabled. With that disabled I am able to get the client and server to work together.

That's interesting, I'm a daily user of the flatpak and barrier managed to generate an SSL certificate for me just fine.

alc@am1m-s2h ~ % ls -l .var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem 
-rw-rw-r--. 1 alc alc 1649 May 21  2018 .var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem

As a workaround, I used the synergy instructions from this page: https://wiki.archlinux.org/index.php/synergy#Set_up_encryption_on_server

TL;DR:

mkdir -p ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints
openssl req -x509 -nodes -days 365 -subj /CN=Barrier-newkey rsa:4096-keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
openssl x509 -fingerprint -sha2 -noout -in ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem > ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints/Local.txt

Then enable encryption from the settings on both the client and server, restart both, and accept the new server certificate from your client ... should be good to go from there.

Edit:
change keylength from 1024 to 4096
change -sha1 to -sha2

I'll leave this issue open just in case someone else also has this issue. Also you might want to bump that key-length from 1024 to 4096, and use sha2 instead of sha1.

fair point. I usually use the 4K keys ... I just got lazy this time around and copy/pasted. Comment updated with @AdrianKoshka 's suggestions.

Edit: punctuation.

When I run the openssl req command I get an error message:

$ openssl req -x509 -nodes -days 365 -subj /CN=Barrier-newkey rsa:4096-keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
req: Use -help for summary.

It looks like you have lost a couple of spaces from the command. The following works:

$ openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
Generating a 4096 bit RSA private key
......................................................................................................................................................++
.......................................................................................................................................................................++
writing new private key to '/home/thomas/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem'
-----

The openssl x509 command then also fails.

$ openssl x509 -fingerprint -sha2 -noout -in ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem > ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints/Local.txt
x509: Unknown digest sha2
x509: Use -help for summary.

I believe that the workaround advice should be updated to:

mkdir -p ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints
openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
openssl x509 -fingerprint -sha1 -noout -in ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem > ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints/Local.txt

At least in my case.

Now does the absence of sha2 support explain the cause of my issue? If whatever is expected to automatically generate the keys is trying to use sha2 and silently failing.

I have version 1.1.0g of OpenSSL.

$ openssl version
OpenSSL 1.1.0g  2 Nov 2017

What version is expected to have the sha2 support? It seems that I can use either -sha256 or -sha512 in the command line without getting an error.

I am pleased to report that with the workaround in place (using sha512 in this case) I have been able to connect the Windows client to the flatpak version of barrier.

Thank you for your help in getting me up and running. Please let me know if there is anything more I can do to help find the cause of the issue and possible solution.

Same setup and same behaviour as in the bug description here.

I had this same issue. Both client and server were version 2.2.0-snapshot-53ebc47a. Using the commands in the post by @TafThorne did the trick.

I had the same issue, it worked for me too!

This just crept up on me out of the blue after this past update. Had to follow the instructions above as well.

Hey, I tried @TafThorne 's commands and I'm getting this:

[2019-06-15T17:20:12] INFO: OpenSSL 1.1.1b 26 Feb 2019
[2019-06-15T17:20:12] ERROR: could not use ssl certificate
[2019-06-15T17:20:12] ERROR: error:0909006C:PEM routines:get_name:no start line

anyone knows what's the issue?

Not trying to sound rude but why this hasn't been fixed in the official Flatpak build as it seems to affect all new installs, including me today and is a real _barrier_ to entry for new users?

So, as was probably obvious, the openssl command-line tools aren't shipped, which prevents the certificate from being generated, I'm working on fixing this finally. I'm sorry.

Truly sorry this was an issue for so long, it really shouldn't have been. After work it can be hard to find the energy to work on OSS.

Indeed, thank you for fixing the issue.

My point was that the Flatpak package is likely one of the main channels to install Barrier and since it was effectively broken for all new users it was a bit frustrating to find the issue had been open for so long.

Fixed for me on a personal machine at work, before I had no cert.

openssl is shipped with barriers flatpak, and I believe this has been fixed.

Hey people, I just ran into this issue on a fresh install using snapd on fedora!

mkdir -p /home/fbidu/snap/barrier-kvm/2/.local/share/barrier/SSL/ 
cd /home/fbidu/snap/barrier-kvm/2/.local/share/barrier/
openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout Barrier.pem -out Barrier.pem

Worked for me!