web-dev-qa-db-ja.com

SSL証明書は、X.509チェーンの親よりも長い有効期間を持つことができますか?

X.509証明書チェーンがX1、X2 ... Xnで構成され、XnがルートCAである場合、下位レベルの証明書の有効期間はその親よりも長くできますか?少なくとも実際には、低レベルは高レベルの適切なサブレンジである必要があると思います。

RFC2459でそのような義務を見つけることはできませんが、その仮定に依存できますか?

コメントをいただければ幸いです。

36
Chul-Woong Yang

これは歴史的に論争されているポイントです。

RFC 5280の 検証アルゴリズム(ちなみに、RFC 2459に取って代わります)では、有効範囲の要件はありませんネスティング。ただし、いくつかの歴史的な実装はそれを主張しました。たとえば、Peter Gutmannの X.509スタイルガイド を参照してください。

これはどの規格でも指定されていませんが、一部のソフトウェアでは有効期間の入れ子が必要であり、サブジェクトの有効期間は発行者の有効期間内にあります。ただし、ほとんどのソフトウェアは、特定の時点(通常は現在の時刻)で証明書チェーンが有効かどうかをチェックする単純なポイントワイズチェックを実行します。有効性のネストを維持するには、階層内の証明書の連続する世代間で重複する有効期間を設計する際に、ある程度の注意を払う必要があります。既存のCAのルートを変更したり、親を変更したりすると、さらに複雑になります(たとえば、部門のCAが企業のCAに従属している場合など)。

Microsoft PKI( "ADCS"、別名Active Directory Certificate Services)は、有効期間のネストを強制します。つまり、証明書を発行するとき、有効期限の終了を許可しません。その証明書の日付が現在のCA証明書の日付を超える(実際には、そのような状況につながる場合は、テンプレートで義務付けられている有効期間を切り捨てます)。

ただし、CA証明書を更新するときに、同じCA名とCAキーを保持することは可能です。その場合、以前と以前の両方で発行されたEE証明書で、古いCA証明書と新しいCA証明書の両方が期限切れにならない限り交換可能に使用できます。リニューアル後。つまり、古いCA証明書がCA1で、新しいCA証明書がCA2である場合、更新前に証明書EE1が発行され、更新後に証明書EE2が発行され、次にCA1-> EE1、CA1-> EE2、CA2-> EE1およびCA2->となります。 EE2はすべて検証する必要があります。これはスムーズな移行を保証するのに非常に便利です。有効期間のネストは、CA1-> EE1およびCA2-> EE2がネストすることを意味しますが、CA1-> EE2およびCA2-> EE1はネストしない場合があります-これは問題ありません。

概要:有効期間のネストに依存することはできず、検証時にネストを強制しないでください証明書。

36
Tom Leek

うーん、この情報は RFC 5280 4.1.2.5。Validity で見つかると思いました。 (ちなみに、RFC 5280はRFC 3280を廃止しましたが、これはRFC 2459を廃止したので、これ以上2459を見る必要はありません)。

つまり、これを論理的に理解することができます(少なくとも標準のTLSのような設定の場合)。エンドユーザーが証明書を検証するとき、ルートまでのチェーンをたどる必要があり、途中のすべての証明書が確実に有効。 X2がX1の前に期限切れになるとしましょう(X2がX1の発行者であると仮定します)。 X2の有効期限が切れると、X1からXnへの検証チェーンを構築する方法がないため、X1は役に立たなくなります。

CAがルートよりも長いライフタイムで証明書を発行する可能性があるケースを次に示します。要件では、A)すべてのリーフ証明書のライフタイムは3年でなければならない(たとえば、組み込みデバイスに移行する)B)すべてのリーフ証明書は同じルートから発行されます(1つのルートを固定するスペースしかないとしましょう)。現在、CA証明書の有効期限は2年で、その期間内に、同じCAキーに対して新しいCA証明書を発行する予定です。その場合、2年間のルートから3年間のリーフ証明書を発行しても問題はありません。


あなたが求めている質問は、CA /発行者が「有効性ネスト」ルールを実施するのか、それともクライアント/ベリファイアがそれを実施するのかについて、少しあいまいです。

  1. あなたがCA /発行者の場合::それはあなた次第です。多くのCAは、自身よりも長いライフタイムの証明書を発行しません。とはいえ、これを実行したいシナリオが想像できます。

  2. あなたがクライアント/検証者である場合:これについて厳格になることは何も得られないと思います。 「有効な入れ子」に従わないクライアントとCA間の互換性の問題を意図的に引き起こしています... _(チェーン内のすべての証明書が検証時に有効期間内である必要があると仮定すると、これはコメントで「標準検証」と呼んでいるものだと思います)。

15
Mike Ounsworth