webdevqa.jp.net

localhostまたは127.0.0.1のサードパーティ署名SSL証明書?

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

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

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

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

これは可能ですか?

24
Rimer

ローカルホスト

Localhostの適切なhttps証明書が発行されることはありません。 厳禁 です。 理由 だからです。

要するに:

  • ローカルホストを/etc/hostsから解決する前にルックアップを待機する、誤設定されたデバイスが実際に存在します
  • ルーターがlocalhost.foo.localを定義している場合、localhostが正しく解決されない可能性があります(このクラスのエラーはおそらく以前に見たことがあるでしょう)。

ルート証明書を作成し、次にいわゆる「自己署名」証明書を作成できます。作成したルートCAによって署名されます。醜い警告画面が表示されますが、機能します。

localhost.YOURSITE.com(127.0.0.1を指す)

実際のlocalhost証明書の代わりに、Eugeneが提案することを行います-パブリックドメインに127.0.0.1レコードを作成します。

Let-s Encryptでlocalhost.YOURSITE.comのHTTPS証明書を無料で入手できます https://greenlock.domains 。 HTTP File Uploadオプションの代わりにDNSオプションを選択するだけです

Localhost.MY-SLD.MY-TLDが127.0.0.1を指すようにします

  • *.localhost.example.com証明書を購入し、各インストールにシークレットxyz.localhost.example.comを発行します(example.comへの攻撃を防ぐために、公開サフィックスリストに含めます)
  • greenlock-enabled app を使用して、そのような証明書をオンザフライで( https://letsencrypt.org を介して)クライアント上で直接生成します(またはクライアントに渡します)。

PSLに含まれていない場合は、次の点に注意してください。

  • セッション、localstorage、indexeddbなどはドメインで共有されます
  • ポートを変更しても、共有性は変わりません

自分のルート証明書になる

Update:ACME/Let's Encryptを使用する greenlock のようなもので、これはもはや特に関係ありません。

ユーザーがルートCAを無用にインストールすることに慣れることを望まないので(これは Lenovoで判明 わかっています)、企業/クローンマシンでは合理的な低予算オプション。

25
CoolAJ86

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

JS SOP=のため、ローカルホストWebサーバーはjsファイルを提供し、Webアプリケーション内のJSはこのローカルホストWebサーバーを呼び出すことができます。

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

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

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

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

これまでにもっと良い方法を見つけましたか?

15
Sarel Botha

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

ローカルホストを使用しているので、必要な証明書を信頼するようにブラウザに指示できます。

Localhostの自己署名証明書を作成し、ブラウザーにそれを信頼するように伝えます。

CoolAJ86によって提供される によって提供されるソリューション「Point your localhost.MY-SLD.MY-TLD to 127.0.0.1」は正常に機能し、ここでより詳細な説明が表示されます。
PLEXがすべてのユーザーに対してhttpsを実行する方法

PS: 同様のシナリオを持つ誰か がキーが侵害されたかのようにCAによって取り消されたため、これがどれだけ持続可能なかわかりません。

0
drizin