27

あまりにも多くの情報を漏らさずに、インターネット全体のエンド ユーザーが使用することを目的とした Web サーバー システムをセットアップする必要があります。

ユースケースは次のようなものです。

  • システムに接続するとき、エンド ユーザーは (通常) ローカル ファイアウォールの背後にある自宅にいます。
  • システムは、厳密にhttps経由で（SSLを使用）、当社がホストするリモートサーバーで構成されています
  • 認証メカニズムでは、リモート サーバー上でユーザー アカウントを自己作成する必要があります。アカウントの作成が成功すると、エンド ユーザーのコンピューターにソフトウェアをダウンロードしてインストールする必要があります。このソフトウェアには、特にローカル Web サーバーが含まれています。
  • この「ローカル」Web サーバーは、ユーザーのブラウザーへの https 接続のみを許可する必要もあります。

配布されたソフトウェアは個々のユーザーのマシンごとに一意の Web サーバーになるため、ユーザーが接続したときに信頼性エラーを引き起こさないサード パーティの署名付き SSL 証明書を取得する方法、または可能かどうかさえわかりません。ウェブブラウザ経由。もちろん、自己署名 SSL 証明書を使用できますが、ブラウザーの警告を回避して、エンド ユーザーが SSL を介して Web サーバーを実行している独自のアプリケーションからのデータを暗黙的に "信頼" するようにすることを目的としています。

これは可能ですか？

4

5 に答える 5

15

これと同じ要件がありました。したがって、SSL を使用する必要がある理由は、http リソースが localhost にある場合でも、https を使用して http リソースに接続しようとすると、ほぼすべてのブラウザーが barfs になるためです。

JS SOP により、localhost Web サーバーは js ファイルを提供し、webapp 内の JS はこの localhost Web サーバーを呼び出すことができます。

そのため、local.example.com が 127.0.0.1 を指すようにし、実際にこのホスト名の SSL 証明書を購入しました。次に、ユーザーのコンピューターにインストールされるこの Web サーバー内の秘密鍵を発送します。はい、私たちはクレイジーです。

これらはすべて、実際には非常にうまく機能します。約 6 か月間、数百人のユーザーでこのような運用を行っています。

ときどき遭遇する唯一の問題は、ユーザーがプロキシ サーバーを使用しているときにこれが正しく機能しないことです。リクエストはプロキシ サーバーに送信され、プロキシ サーバーで 127.0.0.1 に接続しようとしますが、明らかに機能しません。回避策は、local.example.com へのリクエストでプロキシ サーバーをバイパスするように、プロキシ サーバー構成に除外を追加することです。

ユーザーが Citrix またはターミナル サービスを使用しようとする場合は、少し厄介なシナリオになります。各ユーザーの Web サーバーが異なるポートで実行されていることを確認してから、リモート Web サーバーにポート番号を通知して、サーバー上で生成されたページが正しいポート番号を持つようにする必要があります。幸いなことに、まだこれに遭遇していません。また、最近では、Citrix の代わりに仮想マシンを使用する人が増えているようです。

より良い方法を見つけたことがありますか？

于 2014-03-07T18:51:10.950 に答える
2

おそらく、GlobalSign が提供するこのサービスを利用できます(他の CA も同等のサービスを提供しています)。簡単に言うと、このオファリングでは、GlobalSign 証明書によって署名される CA 証明書を取得できます (および localhost などのエンドユーザー証明書を登録できます)。ただし、コストはかなりの額になる可能性があります（ケースバイケースで決定すると思います）。

于 2011-07-22T16:45:21.157 に答える