これが状況です。アプリケーションに変更を加えていますが、テスト環境がありません。テスト チームが使用する QA サーバーがありますが、ローカル マシンでアプリケーションをテストしたいと思います (そのサーバーに変更をデプロイすると、テスト担当者が中断する可能性があります)。ローカル マシンで環境をセットアップしましたが、問題があります。
アプリケーションは、サードパーティのアプリケーションからデータを読み取ります。サードパーティに接続するには SSL 証明書が必要です。
QA サーバーの SSL 証明書をローカル マシンで使用できないのはなぜですか?
Stack Overflow で大雑把に検索しましたが、証明書が CA から発行されると、どのコンピュータでも使用できるように思えます。私の推測では、SSL プロセスの一部を誤解しています。
SSL証明書は実際のホスト名にバインドされています。「qa.example.com」の SSL 証明書がある場合、「dev.example.com」という名前のマシンでは機能しません。
おそらくそれがあなたが抱えている問題です。
あなたが説明しているのは、リモートのサードパーティに対して SSL クライアント認証を実行していると想定しています。製品がクライアントとしてサード パーティへの接続を開始し、サード パーティが証明書が接続に十分かどうかを判断すること。
証明書は基本的に次の 3 つです。
つまり、単なるパスワードではありませんが、最終的にはすべてのデータです。
SSL クライアント証明書を複数の場所にインストールできるかどうかの答えは、はいでもあり、いいえでもあります。ほとんどの場合、サードパーティ システムのセキュリティ要件と、その秘密鍵の保存方法によって異なります。
秘密鍵と公開鍵のペアと証明書をファイルに保存することができます。これの標準の 1 つがPKCS #12です。通常、PKCS12 はパスワードで保護されます。多くのソフトウェア ツールを使用すると、キー ペアを作成して PKCS12 に保存し、サード パーティに証明書の発行を要求して完了するために必要なさまざまな証明書プロトコルを実行できます (サード パーティは、証明書に署名する必要があると思われます)。信頼できる発行者のリストのリスト)。私が見たすべてのアプリケーション サーバーでは、証明書ファイルをクライアント側の証明書として構成できます。
このように QA SSL 証明書が保存されている場合は、マシンへのインストールに問題はありません。
ここに問題があります。セキュリティ ポリシーによって、証明書をハードウェア トークンに格納することが義務付けられている場合があります。これは通常、1 つのエンティティのみが証明書を使用できることを保証するためのセキュリティ対策です。ソフトウェア証明書ファイルのコピーは、テスト環境では問題なく機能しますが、実際に製品をインストールするためのセキュリティ プラクティスとしてはかなり貧弱です。QA サーバーがハードウェア トークンを使用している場合、ハードウェアは秘密鍵ペアの別の場所へのコピーを保護する可能性があります。秘密鍵ペアにアクセスできないと、サードパーティへの SSL 要求を実行できません。秘密鍵へのアクセスのデモンストレーションは、プロトコルの一部です。
その場合、会社がハードウェア トークンを共有するメカニズムを提供していない限り、サード パーティにアクセスするための独自の証明書とキー ペアを要求する必要があります。すべてのサーバーは、ネットワーク化された共通の HSM (ハードウェア セキュリティ モジュール) を利用し、キー ペアを使用するように構成されています。多くの場合、これは SSL サイト証明書に当てはまり、コレクション内のすべてのサーバーが同じサーバーのように見えることがあります。秘訣は、その種のハードウェアがかなりハイエンドであることです。手早く汚いテストを実行している場合、そのようなシステムにアクセスできる可能性は低いと思います。
ソフトウェア証明書について、コピーを取得することが可能かどうかお尋ねします。それを禁止するポリシー上の理由があるかもしれません...しかし、それらをインストールするのは難しくありません。
これは古い投稿であり、何かが欠けている可能性があることは知っていますが、誰もがここで本当の答えを逃したようです. 複数のホスト名/ドメインを使用して複数のサーバーで機能する単一の証明書が必要な場合は、SAN 証明書を購入するだけです。私たちは仕事でいつもそれをしています...
これは間違いなく可能ですが、サーバーは Web ファームでどのように機能しますか? Web ファーム内のすべてのサーバーには、同じ証明書がインストールされています。
Apache の経験はありませんが、IIS のプロセスはここに文書化されていますhttp://support.microsoft.com/kb/313299
通常、SSL ハンドシェーク中に、証明書の一部であるホスト名が SSL 接続の反対側のホスト名と照合されます。そのため、証明書はホスト名に関連付けられています。
これにはいくつかの方法があります。
http://support.godaddy.com/help/article/567/what-is-a-wildcard-ssl-certificate およびhttp://docs.oracle.com/javase/7/docs/api/javax/netを参照してください。 /ssl/HostnameVerifier.html
SSL 証明書はホスト名にバインドされます。したがって、開発マシンで使用できるようにするには、ホスト名を開発マシンに解決する必要があります（つまり、hostsファイルを使用します）
@Kyle Jones -- 私の質問は、ローカル マシンで QA サーバーの SSL 証明書を使用できないのはなぜですか?
@autonomatt -- サブ質問: VeriSign や他の企業から、SSL 証明書をインストールしているサーバーの数を尋ねられます...奇妙な顧客から電話がかかってきて、ブラウザが証明書に関する問題を報告しているとのことです...
合法的？ SSL 証明書を複数のコンピューターにインストールできますが、合法的にインストールできない場合があります。Network Solutions と同様に、Signing CA の会社には、購入に関する法的制限があります。SSL 証明書を購入する場合は、1 台のコンピューターにのみインストールするために購入します。証明書を購入する署名 CA の条件を読む必要があります。
技術的に？ 技術的には、一部のハードウェア アクセラレーション SSL サーバーを除き、有効な SSL 接続を提供するために、キーと CRT を任意の Web サーバーにコピーできます。一部の SSL 証明書は、サーバー側にもインストールする必要がある証明書チェーンと共に CA から出荷/提供されることに注意してください。証明書チェーンがインストールされていないと、クライアント Web ブラウザーは SSL 証明書を適切に検証できません。CA チェーンに署名 CA から提供された SSL 証明書が提供されているかどうかを確認する必要があります。
IP 解決要件。また、SSL 証明書はホスト名にバインドされています。クライアント Web ブラウザがサーバーにリクエストを送信すると、ドメイン名から解決された IP アドレスに接続し、SSL/TLS ハンドシェイク プロセスを開始します。その IP アドレスで応答する Web サーバーは、クライアントの Web ブラウザーが IP アドレスを介して要求している共通名を持つ SSL 証明書を提示する必要があります。これは、1 つの IP アドレスにつき 1 つの SSL 証明書のみを構成できることを意味します。クライアントは暗号化された HTTP 1.1 リクエストのみを送信するため、サーバーは SSL/TLS ハンドシェイクが完了するまで、クライアントの実際のドメイン リクエストが何であるかを認識しません。
非実稼働 IP 解決。別の場所にインストールするには、Web ブラウザーがホスト名を IP アドレスに適切に解決する必要があります。したがって、非実稼働環境にいる場合、クライアントは実稼働環境とは異なる方法で IP アドレスを解決する必要があります。これは、代替 DNS サーバー、または代替 DNS 解決が必要なすべてのマシンのローカル ホスト ファイルで実行できます。
技術的なインストール プロセス。SSL 証明書を別のマシンにインストールするには、キー、SSL CRT、および CA チェーンを、Web サーバー用に構成された適切なファイルにコピーします。Apache の場合、SSL 証明書の 1 つの PEM ファイルにすべてを入れることができます。
次に、Web サーバーが、SSL 証明書の共通名を解決する IP アドレスでこの PEM ファイルを提供していることを確認します。
ワイルドカード SSL 証明書。一部の CA は、 *.domain.com などの Willdcard SSL 証明書も提供しています。Web ブラウザーはこのタイプの証明書を認識する必要があり、1 つのサブドメイン レベルのみを保護することに注意してください。したがって、www.domain.com は保護できますが、www.sub1.domain.com により、クライアントの Web ブラウザーがクライアント ユーザーに検証エラーを表示します。
クライアントの Web ブラウザーが SSL 証明書の検証エラーを受け取るいくつかの理由:
証明書には次の情報が含まれます。 1) 証明書を保持する会社/個人に関する名前、ドメイン、アドレス、キーの有効期限などの詳細。2) 公開鍵を持っている。3) 一部の暗号化されたデータ。これが核心です。
この暗号化されたデータは、すべてのユーザー情報と、証明書を発行した CA の秘密鍵によって署名された証明書に存在する公開鍵です。
ブラウザは証明書を受け取ると、ブラウザに埋め込まれている CA の公開鍵を使って暗号化データの設計を試みます。したがって、証明書に存在するすべての情報が署名後に一致する場合、証明書に記載されているそのドメインの所有者が、証明書内に記載されている公開鍵に対応する秘密鍵を持っていることが保証されます。
したがって、肝心なのは、誰かが（ウェブサイトのように）私が証明書の所有者であることを公開した場合、それは、個人/会社が対応する秘密鍵ペアを所有していることを意味します.
SO COMING BACK TO ISSUE: 本当の問題は、「アプリケーションがサードパーティのアプリケーションからデータを読み取ることです。サードパーティに接続するには SSL 証明書が必要です。」
これが証明書の目的です。基本的に、アプリケーションはサードパーティ アプリケーションとの SSL 接続を行いたいと考えており、証明書があれば準備は完了です。したがって、最初は、アプリケーションが証明書を読み取ることができず、サードパーティとの SSL 接続を確立できないように、証明書を間違ったディレクトリに配置したと想定します。または、設定ファイルの問題があります。
答えが役に立たないことはわかっていますが、私が感じていることを書いたほうがよいと思いました。
この質問に対する私の回答がスレッドで遅すぎることは理解しています..しかし、ロード バランサ構成、OS = Windows 2008/ IIS 7.5 で同じ証明書を 2 台のサーバーにインストールしているときに、今日同じ問題に遭遇し、把握することができました。ソリューション。
「Complete Certificate Request」をクリックし、証明書「abc.cer」がある場所に移動することで、最初のサーバーにインストールできました（証明書が既にあると仮定します）。次に、同じ「abc.cer」を 2 番目のサーバーにコピーし、「完全な証明書要求」を試みましたが、機能しませんでした。証明書はインストールされているように見えますが、IIS マネージャーを更新するとすぐに消えてしまいます。次に、最初のサーバーから証明書を「エクスポート」するオプションを試し (.pfx 拡張子ファイルを生成)、2 番目のサーバーに同じものをインポートしました。この方法はうまくいきました。
環境についてもう少し詳しく説明する必要があると思いますが、証明書の秘密鍵部分をローカル マシンにコピーしていない可能性があります。証明書を使用するには、秘密鍵と公開鍵の両方が必要です。「第三者から読み取る」と書いているので、クライアント証明書を使用していると思います。
技術的には、証明書 (これらの PKI ツールからエクスポートされたもの) には秘密鍵は含まれません。負荷分散された環境でも、単純に証明書をコピーしても役に立たないのでしょうか??
また、PKI ツールを使用して証明書を生成する場合、DN に任意の文字列を指定できます (「CN=xyz、OU=ttr、O=x」など)。異なるマシンが同じ DN を使用して証明書を作成した場合、どのような動作になるのだろうか?
このような状況では、サードパーティは通常、次の 2 つのいずれかを行います。証明書を必要としない QA サンドボックスへのアクセスを提供します。または、認証局によって検証されていない一時的な証明書を作成できるようにします。サード パーティの Web サービス プロバイダーが、異なる QA と製品の必要性を提供しないのは奇妙です。環境。