0

クライアント/サーバー アプリケーションで SSL 証明書を使用しています。クライアントとサーバーの両方が、間もなく期限切れになる 2 つの証明書を使用しています。通常、証明書を新しいものに置き換えるだけですが、膨大な数のクライアントがあるため、これを一度に行うことはできません。そのため、サーバーと一部のクライアントのみが更新されると、残りのクライアントは認証できなくなります。

手っ取り早い解決策は、証明書の有効期限を単純に無視するバージョンにバイナリを置き換えることです。クライアントの更新は、証明書の有効期限が切れる前に終了する限り、順次実行できます。

私が考えた長期的な解決策：

  1. Puppet を使用してクライアントに新しい証明書をプッシュする

    • 残念ながら、すべてのクライアントが Puppet を介して管理されている、または管理されるわけではないため、実行可能ではありません

  2. 2 番目の証明書セットを使用する

    • 最初のセットが期限切れの場合は、2 番目のセットを使用します
    • このように、サーバーには新しい証明書があり、一部のクライアントには新しい証明書があり、残りのクライアントには古い証明書がありますが、すべてが機能します

  3. 現在の証明書の有効期限が切れている場合、クライアントはサーバーに新しい証明書を要求します。

他の解決策はありますか？

4

1 に答える 1

0

HTTPS や SFTP などのオンライン SSL 接続に SSL 証明書を使用していると仮定します。

大きな問題は、サーバー側のキーをまだ信頼して使用したいかどうかです。その場合は、古いキーを引き続き使用して新しい有効期限でサーバー証明書を再発行し、寿命を延ばすことができます。問題は、古いキーをまだ信頼しているか、それとも交換する必要があるかです。古いクライアントは、その時点でまだあなたに接続している可能性があります..あなたはまだ同じ公開鍵/秘密鍵のペアを使用しています.証明書の新しい「ライフタイムバージョン」を作成しただけです. （それはほとんどの公開サーバーが行うことです..）

サーバー側で異なるキーに対して 2 セットのアクティブな SSL 証明書を使用することは実際には実行可能ではなく、クライアント側でハンドシェイク プロセスを適切に制御でき、サーバー アプリケーションがそれをサポートしている場合にのみ可能です。問題は、SSL ネゴシエーション中に、サーバーが最初に証明書を送信する必要があり、クライアントから取得できる唯一の兆候は、ClientHello 中の ServerName 拡張です。(クライアントが実際に送信すると仮定します)。そうしないと、サーバーは相手側が何をサポートするか、またはサポートしないかについて「途方に暮れています」。(サポートされている CA 証明書を示すのに役立つ他の拡張機能がいくつかありますが、クライアントはそれらをサポートする必要があります)。

1 つ目は、それをサポートするクライアントにとって最も実用的です。証明書 (およびおそらくキー) を更新してプッシュするだけです。そして、あなたはそれらで終わりました。

それ以外の場合は、クライアント ソフトウェアを更新し、新しいキーを生成して、必要なときに (または事前に) サーバーに新しい証明書を要求することを確認することが最善の解決策かもしれません。

于 2012-12-14T12:06:23.970 に答える