☰

NFS暗号化ワイルドカード証明書を試してみましょう。 [U 18.04]

tag-icon • tag-icon ubuntu wildcards nfs reverse-proxy letsencrypt
NFS暗号化ワイルドカード証明書を試してみましょう。 [U 18.04]

現在NFSを介して共有し、LetsEncryptのワイルドカード証明書を使用しようとしていますが、それを使用するようになっているサーバーはそうすることはできません。

私の設定の場合：3台の仮想マシン（今後4台程度）が実行されています。 1つは、すべてのhttpおよびhttpsトラフィックを取得し、私のメールサーバーとKanboardにリダイレクトするリバースプロキシです。私のメールサーバーはiRedMailを使用して実行されます。

私の問題は、KanboardとiRedMailサーバーに証明書を配布できないことです。 Kanboard（APACHE2）は次のように言います。

SSLCertificateFile: file '/mnt/letsencrypt/live/domain.com/fullchain.pem' does not exist or is empty

iRedMail（NGINX）は次のとおりです。

nginx: [emerg] BIO_new_file("/etc/ssl/certs/iRedMail.crt") failed (SSL: error:0200100D:system library:fopen:Permission denied:fopen('/etc/ssl/certs/iRedMail.crt'

私はこの投稿が長すぎるのを望まなかったので、私の設定と私が行ったことを使って貼り付けボックスを作成しました。 リバースプロキシ、赤いメール、コンバード：すべてのコンテンツは6ヶ月間利用可能です。

domain.com（リバースプロキシを意味する）へのHTTPSアクセスは正しく機能します。

出力は次のとおりですsudo ls -l /etc/letsencrypt/（生きる）

drwxrwxrwx 3 administrator root 4096 Feb 13 16:25 live

3つのサーバーすべてがUbuntu 1804 Serverを実行しており、「管理者」ユーザーは同じ資格情報を使用します。

より多くの情報が必要な場合は、お気軽にお問い合わせください。 編集する

  1. namei -lx /path/to/private/key の出力

ベストアンサー1

リストのデーモンはルート（メールおよびWebリスニングポート< 1024）として実行され、これらのデーモンはNFSからデータを読み取ろうとするため、通常は次に完了するオプションno_root_squashなしでNFS共有が作成されるため、問題が発生します。アイデアは、NFSがローカル（クライアント）のrootユーザーを0以外のIDを持つ匿名ユーザーにマップすることです。そして、ローカルrootユーザーはNFS共有ファイルとディレクトリにアクセスできず、その権限はrootに制限されます。したがって、OPは2つの方法でこの問題を解決できます。

  1. 世界中でファイルを読み取れるように、ファイルとディレクトリの権限を変更します。

または

  1. NFS 共有に no_root_squash を追加し、NFS サーバーを再起動します。

おすすめ記事