Je peux confirmer que le fichier n'existe pas:

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

Je pensais que cela pourrait être similaire à # 142, mais autoriser barrière.exe et barrières.exe à travers le pare-feu n'a pas changé le message dans les journaux.

171 avait également l'air lié, mais je ne peux pas savoir d'où vient le Barrier.pem montré ici. Suivre le lien fourni n'a vraiment rien changé.

Je peux au moins confirmer que cela est lié à l'activation de la configuration SSL. Avec cette désactivation, je peux faire fonctionner le client et le serveur ensemble.

C'est intéressant, je suis un utilisateur quotidien du flatpak et la barrière a réussi à générer un certificat SSL pour moi très bien.

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

Pour contourner ce problème, j'ai utilisé les instructions de synergie de cette 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

Ensuite, activez le cryptage à partir des paramètres à la fois sur le client et le serveur, redémarrez les deux et acceptez le nouveau certificat de serveur de votre client ... cela devrait être bon à partir de là.

Éditer:
changer la longueur de clé de 1024 à 4096
changer -sha1 en -sha2

Je vais laisser ce problème ouvert au cas où quelqu'un d'autre aurait également ce problème. Vous pouvez également faire passer cette longueur de clé de 1024 à 4096 , et utiliser sha2 au lieu de sha1 .

juste point. J'utilise généralement les touches 4K ... Je suis juste paresseux cette fois-ci et copié / collé. Commentaire mis à jour avec les suggestions de @AdrianKoshka .

Edit: ponctuation.

Lorsque j'exécute la commande openssl req j'obtiens un message d'erreur:

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

Il semble que vous ayez perdu quelques espaces à cause de la commande. Les travaux suivants:

$ 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'
-----

La commande openssl x509 échoue alors également.

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

Je pense que les conseils de contournement doivent être mis à jour pour:

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

Au moins dans mon cas.

Maintenant, l'absence de support sha2 explique-t-elle la cause de mon problème? Si tout ce qui est censé générer automatiquement les clés essaie d'utiliser sha2 et échoue silencieusement.

J'ai la version 1.1.0g d'OpenSSL.

$ openssl version
OpenSSL 1.1.0g  2 Nov 2017

Quelle version devrait avoir le support sha2? Il semble que je puisse utiliser -sha256 ou -sha512 dans la ligne de commande sans obtenir d'erreur.

Je suis heureux d'annoncer qu'avec la solution de contournement en place (en utilisant sha512 dans ce cas), j'ai pu connecter le client Windows à la version flatpak de la barrière.

Merci de votre aide pour me mettre en marche. Veuillez me faire savoir si je peux faire autre chose pour vous aider à trouver la cause du problème et une solution possible.

Même configuration et même comportement que dans la description du bogue ici.

J'ai eu ce même problème. Le client et le serveur étaient tous deux version 2.2.0-snapshot-53ebc47a. L'utilisation des commandes dans le message de @TafThorne a fait l'affaire.

J'ai eu le même problème, cela a fonctionné pour moi aussi!

Cela m'est venu à l'improviste après cette dernière mise à jour. J'ai dû suivre les instructions ci-dessus également.

Hé, j'ai essayé les commandes de @TafThorne et

[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

quelqu'un sait quel est le problème?

Je n'essaie pas de paraître impoli, mais pourquoi cela n'a pas été corrigé dans la version officielle de Flatpak, car cela semble affecter toutes les nouvelles installations, y compris moi aujourd'hui et est une véritable barrière à l'entrée pour les nouveaux utilisateurs?

Donc, comme il était probablement évident, les outils de ligne openssl commande

Vraiment désolé, c'était un problème depuis si longtemps, cela n'aurait vraiment pas dû l'être. Après le travail, il peut être difficile de trouver l'énergie nécessaire pour travailler sur OSS.

En effet, merci d'avoir résolu le problème.

Mon point était que le package Flatpak est probablement l'un des principaux canaux pour installer Barrier et comme il était effectivement cassé pour tous les nouveaux utilisateurs, il était un peu frustrant de constater que le problème était ouvert depuis si longtemps.

Correction pour moi sur une machine personnelle au travail, avant que je n'avais aucun certificat.

openssl est livré avec des barrières flatpak, et je pense que cela a été corrigé.

Salut les gens, je viens de rencontrer ce problème sur une nouvelle installation en utilisant snapd sur 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

A travaillé pour moi!