Ich kann bestätigen, dass die Datei nicht existiert:

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

Ich dachte, dies könnte ähnlich zu # 142 sein, aber das Zulassen von barriere.exe und barriere.exe durch die Firewall hat die Nachricht in den Protokollen nicht geändert.

Ich sah auch verwandt aus, aber ich kann nicht herausfinden, woher das dort gezeigte Barrier.pem kommt. Das Folgen des angegebenen Links hat nichts wirklich geändert.

Ich kann zumindest bestätigen, dass dies mit der Aktivierung der SSL-Konfiguration zusammenhängt. Wenn dies deaktiviert ist, kann ich den Client und den Server dazu bringen, zusammenzuarbeiten.

Das ist interessant, ich bin ein täglicher Benutzer des Flatpak und Barrier hat es geschafft, ein SSL-Zertifikat für mich zu generieren.

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

Als Problemumgehung habe ich die Synergie-Anweisungen auf dieser Seite verwendet: 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

Aktivieren Sie dann die Verschlüsselung über die Einstellungen auf dem Client und dem Server, starten Sie beide neu und akzeptieren Sie das neue Serverzertifikat von Ihrem Client.

Bearbeiten:
Ändern Sie die Schlüssellänge von 1024 in 4096
Ändern Sie -sha1 in -sha2

Ich werde dieses Problem offen lassen, falls auch jemand anderes dieses Problem hat. Vielleicht möchten Sie auch diese Schlüssellänge von 1024 auf 4096 erhöhen und sha2 anstelle von sha1 .

gutes Argument. Normalerweise benutze ich die 4K-Tasten ... Diesmal bin ich nur faul geworden und habe kopiert / eingefügt. Kommentar aktualisiert mit @AdrianKoshkas Vorschlägen.

Bearbeiten: Interpunktion.

Wenn ich den Befehl openssl req ausführe, wird eine Fehlermeldung angezeigt:

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

Es sieht so aus, als hätten Sie ein paar Leerzeichen aus dem Befehl verloren. Folgendes funktioniert:

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

Der Befehl openssl x509 schlägt dann ebenfalls fehl.

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

Ich bin der Meinung, dass die Problemumgehungsempfehlung aktualisiert werden sollte, um:

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

Zumindest in meinem Fall.

Erklärt das Fehlen von sha2-Unterstützung die Ursache meines Problems? Wenn erwartet wird, dass die Schlüssel automatisch generiert werden, wird versucht, sha2 zu verwenden, und dies schlägt stillschweigend fehl.

Ich habe Version 1.1.0g von OpenSSL.

$ openssl version
OpenSSL 1.1.0g  2 Nov 2017

Welche Version wird voraussichtlich die sha2-Unterstützung haben? Es scheint, dass ich entweder -sha256 oder -sha512 in der Befehlszeile verwenden kann, ohne einen Fehler zu erhalten.

Ich freue mich, Ihnen mitteilen zu können, dass ich mit der vorhandenen Problemumgehung (in diesem Fall mit sha512) den Windows-Client mit der Flatpak-Version von Barrier verbinden konnte.

Vielen Dank für Ihre Hilfe, um mich zum Laufen zu bringen. Bitte lassen Sie mich wissen, ob ich noch etwas tun kann, um die Ursache des Problems und eine mögliche Lösung zu finden.

Gleiches Setup und gleiches Verhalten wie in der Fehlerbeschreibung hier.

Ich hatte das gleiche Problem. Sowohl Client als auch Server waren Version 2.2.0-snapshot-53ebc47a. Die Verwendung der Befehle im Beitrag von @TafThorne hat den Trick getan.

Ich hatte das gleiche Problem, es hat auch bei mir funktioniert!

Dies hat sich nach diesem letzten Update aus heiterem Himmel auf mich eingeschlichen. Musste auch die obigen Anweisungen befolgen.

Hey, ich habe die Befehle von erhalte Folgendes :

[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

weiß jemand was das Problem ist?

Ich versuche nicht, unhöflich zu klingen, aber warum wurde dies im offiziellen Flatpak-Build nicht behoben, da es anscheinend alle Neuinstallationen betrifft, einschließlich mir heute, und ein echtes Hindernis für den Einstieg neuer Benutzer darstellt?

Wie wahrscheinlich offensichtlich war, werden die Befehlszeilentools openssl nicht ausgeliefert, wodurch verhindert wird, dass das Zertifikat generiert wird. Ich arbeite daran, dies endgültig zu beheben. Es tut mir Leid.

Es tut mir wirklich leid, dass dies so lange ein Problem war, dass es eigentlich nicht hätte sein sollen. Nach der Arbeit kann es schwierig sein, die Energie zu finden, um an OSS zu arbeiten.

Vielen Dank, dass Sie das Problem behoben haben.

Mein Punkt war, dass das Flatpak-Paket wahrscheinlich einer der Hauptkanäle für die Installation von Barrier ist, und da es für alle neuen Benutzer effektiv kaputt war, war es ein bisschen frustrierend festzustellen, dass das Problem so lange offen war.

Für mich auf einem Personalcomputer bei der Arbeit behoben, bevor ich kein Zertifikat hatte.

openssl wird mit Barrieren Flatpak geliefert, und ich glaube, dies wurde behoben.

Hey Leute, ich bin gerade bei einer Neuinstallation mit snapd auf Fedora auf dieses Problem gestoßen!

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

Hat für mich gearbeitet!