OpenVPN証明書の有効期限を延長する

OpenVPN証明書の有効期限を延長する

私は OpenVPN サーバーを使用しており、クライアントは SSL 証明書を使用して認証します。クライアント証明書の有効期限が切れるたびに、新しい証明書を発行してクライアントに送信する必要があります。

私はopenvpnのeasyrsaが更新するコマンドですが、私の知る限りでは実際には更新されません。Easyrsa の「renew」は誤解を招く名前です · 問題 #345 · OpenVPN/easy-rsa

そこで質問です。クライアント ユーザーに新しいファイルを送信しないようにするために、SSL 証明書の有効期限が切れているかどうかに関係なく、SSL 証明書の有効期限を延長することは技術的に可能ですか?

答え1

これはとても良い質問です:-)。

Technically : yes (at the end the client could use expired one to connect)
Easily : no

原則として、CA は証明書要求に特定の有効期限を署名するため、延長することはできません。新しい証明書を作成することはできますが、発行プロセスと有効性の確認プロセスが難しい場合があります。

最初に言っておきますが、以下の内容は技術的には証明書全般に関連しており、openvpn でテストしていません。合格しない場合は、全体的な答えは「いいえ」になります :-(。

openVPN 構成には、証明書に関連する ca、key、c​​ert の 3 つのパラメーターがあります。

  • 鍵: データ署名用の秘密鍵。証明書

  • cert: 公開鍵() は、キーによって署名されたデータの有効性を確認するために使用されます。これは、キーのデータを暗号化するために使用できます。これは、安全な接続ネゴシエーション中に「もう一方の端」に提供されます。/ このシナリオは、有効な証明書がリモート エンドで既にわかっている場合に機能します。そのため、証明書の送信はオプションであり、期限切れの証明書は無視できます。/

  • ca : 安全な接続ネゴシエーション中に提供された証明書の有効性を確認するために使用されます。

クライアント証明書の有効期限が切れると、証明書古くなっています。キーは原則として期限切れにならず、CA も期限切れにはなりません (その場合はまったく別のユースケースになります ;-) )。証明書には有効期間が含まれており、CA によって x.509 構造で署名された「エンベロープ」の一部です。

新しい証明書を生成するときに新しいキーを生成するのは良い習慣ですが、この手順を強制するものは何もありません。そのため、実際に期限切れの証明書と同じキーを使用して CSR (証明書署名要求) を作成することは技術的には問題ありません。古い CSR が利用可能な場合は、それを新しい証明書に直接使用できます。この CSR が CA で署名されると、新しい証明書は「古い」キーから派生します。

難しいのは、次のいずれかが必要であることです。

  • この新しい証明書を現在のユーザーに配信して証明書を置き換えます

  • この証明書についてサーバーに知らせ、クライアントが提供した期限切れの証明書の代わりに使用できるようにします (これがこのユースケースの理論部分です ;-) )

私が知っているのは、複数のCA証明書を組み合わせることができるということですサーバーの構成に問題なくリンクされたファイル (PEM 形式)。技術的には、「ユーザー」証明書と「ca」証明書は、CA として使用できるかどうかを示すパラメーターが異なります。したがって、技術的には、CA 証明書とこの新しく生成された証明書を 1 つのファイルに組み合わせることができます...

このファイルが配置されたら (おそらく openvpn サーバーの再起動が必要になります)、新しい接続を確立できます。キーを持つクライアントが接続を試みると、サーバーにあるこのクライアント証明書とペアになっているハッシュに基づいてサーバーがキーを「識別」し、クライアントから提供された証明書を無視することがあります (これはテストする必要があります)。技術的には (証明書をテクノロジーとして見ると) 機能しますが、openVPN では試していません。openVPN は SSL 関連の外部ライブラリを使用しているため、これは機能するアプローチかもしれません ;-)。

クライアント側では、サーバー側を証明するための CA (期限切れではない)、通信に署名して復号化するためのキー (期限切れではない) が必要です。また、ローカル操作には独自の証明書は実際には必要ないため、期限切れは問題になりません。サーバーの証明書は SSL ネゴシエーション中に取得され、ローカル CA 証明書を使用してチェックされるため、必要なものはすべて利用できます (ローカル キー、リモート証明書)。

このアプローチの欠点は、クライアント証明書の検証用の単一の証明書として CA を使用する利点が少し失われることです (サーバー側で CA 証明書の横にリストされている必要があります)。ただし、その一方で、証明書を更新できる可能性がプラスになります...

お試しいただく場合は、お気軽にフィードバックをお寄せください。

幸運を!


計画の場合のもう 1 つのアプローチは、有効期間の長い証明書を発行し、CRL (証明書再配置リスト) を使用して、その期間中に有効でない証明書を取り消すことです。ただし、これはこの質問の範囲ではありません...

関連情報