私はserver1のSelssl7.exeを使用してSSL証明書を作成しましたが、Server2としてCnを使用し、server2で証明書をホストしました。私が言ってLinuxのFirefoxのから閲覧する際に証明書エラーを取得するために開始しました：別のHTTPSサーバー上で自己署名X.509証明書を使用できますか？
この証明書が無効である、証明書が信頼されていないと、自己署名され、証明書と、server1
しかし、ときにのみ有効です私はWindows IEからURLを参照しています。ただ、それは信頼できないと言っている普通のエラーを受け取り、例外に簡単に追加することができます。
server1で生成された自己署名証明書を別のサーバーで使用できますか？
あなたはそうすることができますが、真実性のあらゆる面をかなり損なう可能性があります。
他のユーザーがこの証明書を事前に知ることはないため、自己署名証明書は一般的に問題になります。そこでブラウザは忠実に警告を出します。そのため、認識されるTLS証明書の支払いが必要です。証明書がブラウザのデフォルトのトラストストアに含まれているCAによって発行されます。 CAは「クラブの一員になろう」と支払う必要がありましたが、それ以外の人は誰でも証明書を作成できます。それは単にデフォルト設定で認識されることです。
ただし、別のサーバーの専用サーバー用に発行された証明書を再利用して別の穴を開けます。 TLS証明書のサブジェクトの識別名は、配備されているサーバーのホスト名と一致する必要があります。これは、TLSを使用しているときの中間者攻撃を防ぐための唯一の効果的な措置であるため、TLSの仕様に準拠しています。サーバーへのTLS接続を開くと、コードは、接続先のホスト名が、送信されたサーバー証明書の件名DNと一致するかどうかをチェックします。それが正しい場合にのみ、適切なサーバーと通信することができます。
したがって、異なるホスト上でサーバー証明書を再利用すると、TLSのセキュリティに深刻な影響を与えます。それでもなお可能ですが、セキュリティをこのように弱体化させてしまうと、最初は単純なHTTPを使うほうが良いでしょう。
クライアントに、事前に自己署名証明書に関連付けられた公開鍵を知ってもらうことをお勧めします。それは、非常に制限された展開以外のものでは全くの悪夢ですが、少なくとも受動的な盗聴を防ぐことは可能です。 OTOH、私はちょうど適切で（単一ホスト）証明書を持っています。安くて使いやすく展開しやすいからです。 –
それは、一度、メンテナンスの悪夢を試してみました。これがおそらくうまく終わる唯一の方法は、クライアントがトラストストアにインポートする「自己署名」CAを作成する場合です。このようにして、時間の経過と共に維持する必要がある証明書は1つだけであることが保証されます。しかし、自己署名エンドエンティティ証明書をインポートするように強制するのは、単に問題を求めているだけです。問題は、次のサーバーが別の自己署名証明書を使用したいときに開始され、その次は...自分の（自己署名された）企業CAを開始するのが最善です。 10000人以上の人々の環境では、ちょっとしたサニティを維持する唯一の方法です:) – emboss