AWS Private CA 証明書失効方法の計画 - AWS Private Certificate Authority
要件

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Private CA 証明書失効方法の計画

でプライベート PKI を計画するときは AWS Private CA、エンドポイントのプライベートキーが公開されるときなど、エンドポイントが発行された証明書を信頼しなくなった場合の処理方法を検討する必要があります。この問題に対する一般的なアプローチは、有効期間の短い証明書を使用するか、証明書失効を設定することです。有効期間が短い証明書は、数時間または数日という短い期間で期限切れになるため、失効しても意味がありません。エンドポイントに失効を通知するのとほぼ同じ時間で証明書が無効になります。このセクションでは、設定やベストプラクティスなど、 AWS Private CA ユーザー向けの失効オプションについて説明します。

失効方法が必要な場合、オンライン証明書ステータスプロトコル (OCSP)、証明書失効リスト (CRL)、またはその両方を選択できます。

注記

失効を設定せずに CA を作成した場合は、後からいつでも設定できます。詳細については、「でプライベート CA を更新する AWS Private Certificate Authority」を参照してください。

  • オンライン証明書ステータスプロトコル (OCSP)

    AWS Private CA は、お客様がインフラストラクチャ自体を運用することなく、証明書が取り消されたことをエンドポイントに通知するフルマネージド OCSP ソリューションを提供します。お客様は、 AWS Private CA コンソール、API、CLI、または を使用して、単一オペレーションで新規または既存の CAs で OCSP を有効にできます AWS CloudFormation。CRL はエンドポイントで保存および処理されるため古くなることがありますが、OCSP のストレージと処理の要件はレスポンダーのバックエンドで同期的に処理されます。

    CA で OCSP を有効にすると、 は発行された新しい証明書ごとに、OCSP レスポンダーの URL を Authority Information Access (AIA) 拡張機能に AWS Private CA 含めます。拡張により、ウェブブラウザなどのクライアントは、レスポンダーにクエリを実行して、エンドエンティティおよび下位 CA 証明書が信頼できるかどうかを判断できるようになります。レスポンダーは、本物であることを保証するための暗号的に署名されたステータスメッセージを返します。

    AWS Private CA OCSP レスポンダーは RFC 5019 に準拠しています。

    OCSP に関する考慮事項

    • OCSP ステータスメッセージは、発行元の CA が使用するように設定されているのと同じ署名アルゴリズムを使用して署名されます。 AWS Private CA コンソールで作成された CA は、デフォルトで SHA256WITHRSA 署名アルゴリズムを使用します。サポートされている他のアルゴリズムについては、CertificateAuthorityConfiguration API ドキュメントに記載されています。

    • OCSP レスポンダーが有効になっていると、APIPassthrough および CSRPassthrough 証明書テンプレートは AIA 拡張では機能しません。

    • マネージド OCSP サービスのエンドポイントには、パブリックインターネットからアクセスできます。OCSP を必要としていても、パブリックエンドポイントが必要ないユーザーは、独自の OCSP インフラストラクチャを運用する必要があります。

  • 証明書失効リスト (CRL)

    証明書失効リスト (CRL) は、スケジュールされた有効期限より前に取り消された証明書のリストを含むファイルです。CRL には、信頼されなくなった証明書のリスト、失効の理由、およびその他の関連情報が含まれています。

    認証機関 (CA) を設定するときに、 が完全またはパーティション化された CRL AWS Private CA を作成するかどうかを選択できます。選択によって、認証機関が発行および取り消すことができる証明書の最大数が決まります。詳細については、AWS Private CA クォータを参照してください。

    CRL に関する考慮事項

    • メモリと帯域幅に関する考慮事項: CRLsローカルのダウンロードと処理の要件により、OCSP よりも多くのメモリを必要とします。ただし、CRLs、接続ごとにステータスを確認する代わりに失効リストをキャッシュすることで、OCSP と比較してネットワーク帯域幅を減らす可能性があります。特定の IoT デバイスなど、メモリに制約のあるデバイスの場合は、パーティション化された CRLs。

    • CRL タイプの変更: 完全な CRL からパーティション化された CRL に変更すると、 は必要に応じて新しいパーティション AWS Private CA を作成し、IDP 拡張機能を元のものを含むすべての CRLs に追加します。パーティション分割から 1 つの CRL のみの更新に変更し、以前のパーティションに関連付けられた証明書の今後の失効を防止します。

注記

OCSP と CRL はどちらも、失効してからステータス変更が可能になるまでに多少の遅延があります。

  • 証明書を取り消すと、OCSP レスポンスに新しいステータスが反映されるまでに最大 60 分かかることがあります。一般に、OCSP は失効情報の配信が速い傾向があります。これは、クライアントが数日間キャッシュすることがある CRL とは異なり、OCSP レスポンスは通常クライアントによってキャッシュされないためです。

  • CRL は通常、証明書が取り消された約 30 分後に更新されます。何らかの理由で CRL 更新が失敗した場合、 は 15 分ごとにさらに試行 AWS Private CA を行います。

失効設定の一般要件

すべての失効設定には、次の要件が適用されます。

  • CRL または OCSP を無効にする設定には Enabled=False パラメータのみを含める必要があり、CustomCname や ExpirationInDays などの他のパラメータが含まれていると失敗します。

  • CRL 構成では、S3BucketName パラメータは Amazon Simple Storage Service バケットの命名規則に準拠している必要があります。

  • CRL または OCSP 用のカスタムの正規名 (CNAME) パラメータを含む設定は、CNAME での特殊文字の使用に関する RFC7230 の制限に準拠する必要があります。

  • CRL や OCSP 構成では、CNAME パラメーターの値には、CNAME パラメーターの値には、「http://」や「https://」などのプロトコルプレフィックスを含めることはできません。

トピック