Let's Encrypt SSL 証明書をドメイン インスタンス (Ubuntu 14.4) に正常にインストールしましたが、同じドメインの別の仮想インスタンスに同じ証明書をインストールしたいと考えています。
質問: 同じドメインに複数の仮想インスタンスがある場合、(Let's Encrypt ツールを使用して) 最初のイニシャルから証明書をコピーするだけでよいですか、それとも別のより良い方法がありますか?
Let's Encrypt に新しい証明書を照会することはできないと思います。そうしないと、最初の証明書が無効になります。
私は現在、機能する証明書を共有しています。
SSL/TLS 証明書の共通理解という観点から、この質問は非常に興味深いと思います。個人的には、複数のコンピューターまたは仮想インスタンスで同じ SSL/TLS 証明書を共有することに一般的な問題はないと思います。唯一の問題は、証明書のサブジェクト代替名 (DNS 名) などの証明書の一部のプロパティにのみ存在する可能性があります (つまり、 のようなオプションを意味します)。
rfc2818のセクション3.1 (サーバー ID):
クライアントがサーバーの予想される ID に関する外部情報を持っている場合、ホスト名のチェックは省略できます。(たとえば、クライアントはアドレスとホスト名が動的であるマシンに接続している可能性がありますが、クライアントはサーバーが提示する証明書を知っています。)
...
タイプ dNSName の subjectAltName 拡張が存在する場合、それを ID として使用する必要があります。それ以外の場合は、証明書の Subject フィールドの (最も具体的な) Common Name フィールドを使用する必要があります。Common Name の使用は既存の慣行ですが、推奨されておらず、証明機関は代わりに dNSName を使用することをお勧めします。
唯一の問題は、Let's Encrypt がまだワイルドカード証明書をサポートしていないように見えることです ( FAQを参照)。制限がまだ存在するかどうかはわかりませんが、DNS Name=www.yourdomain.com や DNS Name=*.yourdomain.com のような Subject Alternative Name (``) を使用して Let's Encrypt を本当に作成することはできません。したがって、質問に対する正確な答えは、証明書のプロパティに依存する可能性があります。
2 つのサーバーに同じ証明書を使用すると、TLS のセッション キャッシュの使用に関して追加の問題が発生する可能性があります。これにより、TLS のパフォーマンスが向上し、クライアントとサーバーの両方が同じセッション ID を使用できるため、TLS のパフォーマンスが向上します。 . セッション ID に問題があるかどうかを正確に判断できるように、使用する正確なシナリオを説明する必要があります。