物理ホスト上のクライアント TLS 証明書に関する「鶏が先か卵が先か」の問題を解決するにはどうすればよいですか?

物理ホスト上のクライアント TLS 証明書に関する「鶏が先か卵が先か」の問題を解決するにはどうすればよいですか?

サーバーのインストールを自動化するときに、鶏が先か卵が先か問題をどのように解決すればよいのかわかりません。

私は PXE で再構築できる一連のサーバーを持っています。マシンが再構築されるとき、マシンは必要なすべての設定 (後でさまざまなサービスを使用するときに認証に使用するプライベート証明書を含む) を Apache サーバーから読み込みます。この Apache サーバーは、IP アドレスでクライアントを識別し、特定のサーバー用の設定または証明書を提供するか、提供を拒否します。

ただし、クライアントの IP アドレスは偽装される可能性があります。将来的にこの種の検証も追加する場合は、MAC アドレスも同様です。

PXE 経由で起動するマシンは、構成とプライベート証明書を安全に取得するために、Apache サーバーとの通信時に使用できる証明書をすでに持っている必要があります。ただし、PXE から起動するマシンは新しいか、インストール中にディスクをフォーマットするため、これは不可能のようです。

何か見落としているのでしょうか? なりすましのリスクなしに、新しいマシンを識別するにはどうすればよいでしょうか?

秘密鍵を含む常時接続の USB キーを使用する必要がありますか? または、他のオプションはありますか?

答え1

私たちは職長のブートディスクプラグインこの目的のために。これが正しい、またはユニークな方法であると言っているのではなく、私たちがうまく使っている方法です。

ホストを (再) プロビジョニングする必要があるたびに、短期間のトークンが生成され、ホストに連結されたデータベースに保存されます。このトークンは、ipxe バイナリと、プロビジョニング ホストが識別子として正しいトークンを提供する場合にのみ、プロビジョニング ホストから kicstart ファイルをダウンロードするスクリプトとともに、iso ファイルに格納されます。ホストがプロビジョニングされると、トークンは削除されます。一定時間 (調整可能、私の記憶ではデフォルトで 60 分) が経過すると、トークンは無効になります。

これは BIOS と UEFI ファームウェアの両方で動作し、PXE は必要なく、http(s) のみなので、ほとんど変更を加えることなくインターネット展開が可能になります (遠隔地にハードウェアを展開する場合に便利です)。

関連情報