ファイルが存在しないことを確認できます：

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

これは＃142に似ていると思いましたが、ファイアウォールを介してbarrier.exeとbarriers.exeを許可しても、ログのメッセージは変更されませんでした。

'171も関連しているように見えましたが、そこに示されているBarrier.pemがどこから来ているのかわかりません。 提供されたリンクをたどっても、実際には何も変わりませんでした。

少なくとも、これがSSL構成を有効にすることに関連していることを確認できます。 これを無効にすると、クライアントとサーバーを連携させることができます。

それは興味深いことです。私はフラットパックとバリアの毎日のユーザーであり、SSL証明書を問題なく生成することができました。

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

回避策として、次のページの相乗効果の説明を使用しました： https ：

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

次に、クライアントとサーバーの両方の設定から暗号化を有効にし、両方を再起動して、クライアントから新しいサーバー証明書を受け入れます...そこから始めてください。

編集：
キーの長さを1024から4096
-sha1を-sha2

他の誰かがこの問題を抱えている場合に備えて、この問題は開いたままにしておきます。 また、そのキーの長さを1024から4096に増やし、 sha1代わりにsha2を使用することもできます。

フェアポイント。 私は通常4Kキーを使用します...今回は怠惰になってコピー/貼り付けしました。 コメントは@AdrianKoshkaの提案で更新されました。

編集：句読点。

openssl reqコマンドを実行すると、次のエラーメッセージが表示されます。

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

コマンドからいくつかのスペースを失ったようです。 次の作品：

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

その後、 openssl x509コマンドも失敗します。

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

回避策のアドバイスは次のように更新する必要があると思います。

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

少なくとも私の場合は。

sha2サポートがないことが私の問題の原因を説明していますか？ キーを自動的に生成することが期待される場合は、sha2を使用しようとして、サイレントに失敗します。

私はバージョン1.1.0gのOpenSSLを持っています。

$ openssl version
OpenSSL 1.1.0g  2 Nov 2017

どのバージョンがsha2をサポートすると予想されますか？ エラーが発生することなく、コマンドラインで-sha256または-sha512いずれかを使用できるようです。

回避策（この場合はsha512を使用）を実行すると、Windowsクライアントをflatpakバージョンのバリアに接続できたことを報告できてうれしく思います。

私を立ち上げて実行するのにあなたの助けをありがとう。 問題の原因と考えられる解決策を見つけるために私にできることが他にあるかどうか教えてください。

ここのバグの説明と同じセットアップと同じ動作。

私はこれと同じ問題を抱えていました。 クライアントとサーバーの両方がバージョン2.2.0-snapshot-53ebc47aでした。 @TafThorneによる投稿のコマンドを使用してトリックを行いました。

私も同じ問題を抱えていました、それは私にとってもうまくいきました！

これは、この過去の更新の後で、突然私に忍び寄りました。 上記の指示にも従わなければなりませんでした。

ねえ、私は@TafThorneのコマンドを試し

[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

誰かが問題が何であるか知っていますか？

失礼に聞こえようとはしていませんが、今日の私を含むすべての新規インストールに影響を及ぼし、新規ユーザーの参入障壁となるため、これが公式のFlatpakビルドで修正されていないのはなぜですか？

そのため、おそらく明らかなように、 opensslコマンドラインツールは出荷されていないため、証明書が生成されません。最終的にこれを修正する作業を行っています。 申し訳ありません。

本当に申し訳ありませんが、これは長い間問題でしたが、実際にはそうではなかったはずです。 仕事の後、OSSで働くエネルギーを見つけるのは難しいかもしれません。

確かに、問題を修正していただきありがとうございます。

私のポイントは、Flatpakパッケージはバリアをインストールするための主要なチャネルの1つである可能性が高く、すべての新規ユーザーにとって事実上壊れていたため、問題が長い間開いていたのを見つけるのは少しイライラしました。

証明書がなくなる前に、職場のパーソナルマシンで修正しました。

opensslはバリアフラットパックが付属しており、これは修正されたと思います。

ねえ、私はfedoraでsnapdを使用した新規インストールでこの問題に遭遇しました！

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

私のために働いた！