☰

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 サーバーを再起動します。

答え2

@muruと@RomeoNinovのおかげで、NFSサーバーを少し調整して証明書を使用することができました。私のPastebinsは6ヶ月間のみ有効なので、ここに設定を公開します。

ネットワークで証明書を共有するためにまだNFSを使用しています。

首都ナミ/etc/export私の設定を開き、最後の行で次を使用してから最後に追加し/etc/letsencrypt IP-OF-REVERSE-PROXY (rw,sync,no_subtree_check)ました。no_root_squash(rw,sync,no_subtree_check,no_root_squash)

すべてのサーバーを再起動した後、サービスが実行されていることを確認しました。ブラウザに入り、ローカルIPを確認して証明書を確認しましたが、すべてが正確でした。
私も後で編集して読ん/etc/hosts.allowだ/etc/hosts.deny根のないカボチャ私のNFS共有へのアクセスを制限し、3つのサーバーが自分の共有にアクセスできるようにし、SFTPとSSHを介して自分の管理PCのリモートアクセスを許可し、他のすべてを拒否します。ホスト.NFSを許可

関連情報