1つのSSL証明書を複数のマシンで使用できないのはなぜですか？
これが状況です。アプリケーションに変更を加えていますが、テスト環境がありません。テストチームが使用する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
@カイル・ジョーンズ-私の質問は、ローカルマシンのQAサーバーからのSSL証明書を使用できないのはなぜですか？
@autonomatt-サブ質問：VeriSignや他の企業は、SSL証明書をインストールするサーバーの数を尋ねます...奇妙な顧客が、ブラウザーが証明書付きの問題を報告していると言って電話をかけます...
法的に？複数のコンピューターにSSL証明書をインストールできますが、法的にはできない場合があります。 Network Solutionsと同様に、署名CAの会社では、購入に関して法的な制限があります。 SSL証明書を購入すると、1台のコンピューターにのみインストールするために購入します。証明書を購入する署名CAの条件を読む必要があります。
技術的には？技術的には、一部のハードウェアアクセラレーションSSLサーバーを除いて、有効なSSL接続を提供するために、KEYと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証明書を別のマシンにインストールするには、Web用に構成された適切なファイルにKEY、SSL CRT、およびCAチェーンをコピーします。サーバ。 Apacheの場合、SSL証明書用の1つのPEMファイルにすべて入れることができます。
次に、SSL証明書の共通名を解決するIPアドレスでWebサーバーがこのPEMファイルを提供していることを確認します。
ワイルドカードSSL証明書。一部のCAは、* .domain.comのようなウィルドカードSSL証明書も提供しています。 Webブラウザはこのタイプの証明書を認識する必要があり、1つのサブドメインレベルのみを保護することに注意してください。したがって、www.domain.comは保護できますが、www.sub1.domain.comにより、クライアントのWebブラウザーがクライアントユーザーに検証エラーを表示します。
クライアントWebブラウザーがSSL証明書検証エラーを受け取るいくつかの理由：
- cAチェーンが必要だがWebサーバーによって提供されない場合。
- ルート署名CAがクライアントのWebブラウザーSSL認証局で信頼できるCAでない場合-これは自己署名SSL証明書に常に当てはまります。
- クライアントのWebブラウザが、SSL証明書の一般名と一致しないSSL経由のドメインを要求している場合。
- クライアントブラウザが署名CAからx509 CRL配布ポイントにアクセスできない場合-制限されたネットワークまたは閉じたネットワーク上のクライアントはSSL証明書の検証に失敗します。 CRLのURLは、SSL/TLSハンドシェイク中に提供されます。参照： http://en.wikipedia.org/wiki/Revocation_list#Problems_with_CRLs 。
通常、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ファイルを使用します）。
証明書には次の情報が含まれています。1）名前、ドメイン、住所、キーの有効期限など、証明書を保持する会社/個人に関する詳細。 2）公開鍵を持っている。 3）一部の暗号化されたデータ。これが核心です。
この暗号化されたデータは、すべてのユーザー情報と、証明書を発行したCAの秘密鍵によって署名された証明書に存在する公開鍵です。
ブラウザは証明書を受け取ると、すでにブラウザに埋め込まれているCAの公開鍵を使用して暗号化されたデータの署名を解除しようとします。したがって、証明書に存在するすべての情報が署名解除後に一致する場合、証明書に記載されているそのドメインの所有者が、証明書に記載されている公開鍵に対応する秘密鍵を持っていることが保証されます。
つまり、重要なのは、誰かが（ウェブサイトのように）公開した場合、それが私が証明書の所有者であること、つまり、個人/会社が対応する秘密キーのペアを所有していることです。
問題に戻る：本当の問題は、「アプリケーションがサードパーティのアプリケーションからデータを読み取る。サードパーティに接続するにはSSL証明書が必要である」ということです。
これが証明書の目的です。基本的に、アプリケーションはサードパーティのアプリケーションとSSL接続を行いたいと考えています。証明書があれば、準備は完了です。したがって、最初は、証明書を間違ったディレクトリに配置したため、アプリケーションが証明書を読み取れず、サードパーティとsslで接続できないと想定しています。または、いくつかの設定ファイルの問題があります。
私は答えが役に立たないことを知っていますが、私は自分が感じることを書いたほうがいいと思いました。
これはあなたが何を意味するかによります
1つのワイルドカード証明書を、異なるAレコードを持つ複数のホストに使用できます。
たとえば、ドメイン*.stackoverflow.com.のワイルドカード証明書がある場合、実行している新しいサーバーがドメインstackoverflow.comのサブドメインを使用している限り、CAにTLSを承認させることができます。
例：mail-server.stackoverflow.com
この質問への回答がスレッドでは遅すぎることを理解しています。しかし、ロードバランサ構成の2つのサーバーに同じ証明書をインストールしているときに、今日同じ問題に遭遇しました。OS= Windows 2008/IIS 7.5そして、解決策を理解することができました。
「Complete Certificate Request」をクリックし、証明書「abc.cer」がある場所に移動することで、最初のサーバーにインストールできました（すでに証明書を持っていると想定しています）。次に、同じ「abc.cer」を2番目のサーバーにコピーし、「証明書リクエストの完了」を試行しましたが、機能しませんでした。証明書はインストールされているように見えますが、IIS Managerを更新するとすぐに消えます。次に、最初のサーバーから証明書を「エクスポート」するオプションを試し（.pfx拡張子ファイルが生成されます）、2番目のサーバーに同じものをインポートしました。この方法はうまくいきました。
環境についてもう少し詳しく説明する必要があると思いますが、証明書の秘密鍵の部分をローカルマシンにコピーしていない可能性があります。証明書を使用するには、秘密鍵と公開鍵の両方が必要です。 「サードパーティからの読み取り」と書いているので、クライアント証明書を使用していると思います。
これらの状況では、サードパーティは通常、2つのことのいずれかを行います。証明書を必要としないQAサンドボックスへのアクセスを提供します。または、認証局によって検証されていない、彼らが受け入れる一時的な証明書を作成できるようにします。サードパーティのWebサービスプロバイダーが別のQAと製品を用意する必要がないことは奇妙です。環境。
技術的には、証明書（これらのPKIツールからエクスポートされたもの）には秘密キーが含まれていません。したがって、負荷分散された環境でも、証明書の単純なコピーは役に立ちませんか？
また、PKIツールを使用して証明書を生成する場合、DNに任意の文字列を指定できます（「CN = xyz、OU = ttr、O = x」など）。異なるマシンが同じDNを使用して証明書を作成するとどうなるのでしょうか。