翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS Private CA 証明書失効方法を計画する
でプライベート PKI を計画するときは AWS Private CA、エンドポイントのプライベートキーが公開されるときなど、エンドポイントが発行された証明書を信頼しなくなった状況に対処する方法を検討する必要があります。この問題に対する一般的なアプローチは、有効期間の短い証明書を使用するか、証明書失効を設定することです。有効期間が短い証明書は、数時間または数日という短い期間で期限切れになるため、失効しても意味がありません。エンドポイントに失効を通知するのとほぼ同じ時間で証明書が無効になります。このセクションでは、設定やベストプラクティスなど、 AWS Private CA ユーザー向けの失効オプションについて説明します。
失効方法が必要な場合、オンライン証明書ステータスプロトコル (OCSP)、証明書失効リスト (CRL)、またはその両方を選択できます。
**注記**
失効を設定せずに CA を作成した場合は、後からいつでも設定できます。詳細については、「[でプライベート CA を更新する AWS Private Certificate Authority](PCAUpdateCA.md)」を参照してください。
+ **オンライン証明書ステータスプロトコル (OCSP)**
AWS Private CA は、フルマネージド型の OCSP ソリューションを提供し、お客様がインフラストラクチャ自体を運用することなく、証明書が取り消されたことをエンドポイントに通知します。お客様は、 AWS Private CA コンソール、API、CLI、または を使用して 1 回のオペレーションで、新規または既存の CAs で OCSP を有効にできます CloudFormation。CRL はエンドポイントで保存および処理されるため古くなることがありますが、OCSP のストレージと処理の要件はレスポンダーのバックエンドで同期的に処理されます。
CA で OCSP を有効にすると、 は発行された各新しい証明書の *Authority Information Access* (AIA) 拡張機能に OCSP レスポンダーの URL AWS Private CA を含めます。拡張により、ウェブブラウザなどのクライアントは、レスポンダーにクエリを実行して、エンドエンティティおよび下位 CA 証明書が信頼できるかどうかを判断できるようになります。レスポンダーは、本物であることを保証するための暗号的に署名されたステータスメッセージを返します。
AWS Private CA OCSP レスポンダーは [RFC 5019 ](https://datatracker.ietf.org/doc/html/rfc5019)に準拠しています。
**OCSP に関する考慮事項**
+ OCSP ステータスメッセージは、発行元の CA が使用するように設定されているのと同じ署名アルゴリズムを使用して署名されます。 AWS Private CA コンソールで作成された CA は、デフォルトで SHA256WITHRSA 署名アルゴリズムを使用します。サポートされている他のアルゴリズムについては、[CertificateAuthorityConfiguration](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html) API ドキュメントに記載されています。
+ OCSP レスポンダーが有効になっていると、[APIPassthrough および CSRPassthrough](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#template-varieties) 証明書テンプレートは AIA 拡張では機能しません。
+ マネージド OCSP サービスのエンドポイントには、パブリックインターネットからアクセスできます。OCSP を必要としていても、パブリックエンドポイントが必要ないユーザーは、独自の OCSP インフラストラクチャを運用する必要があります。
+ **証明書失効リスト (CRL)**
証明書失効リスト (CRL) は、スケジュールされた有効期限より前に取り消された証明書のリストを含むファイルです。CRL には、信頼されなくなった証明書のリスト、失効の理由、およびその他の関連情報が含まれています。
認証機関 (CA) を設定するときに、 が完全またはパーティション分割された CRL AWS Private CA を作成するかどうかを選択できます。選択により、認証機関が発行および取り消すことができる証明書の最大数が決まります。詳細については、[AWS Private CA クォータ](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca)を参照してください。
**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 バケットの命名規則](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)に準拠している必要があります。
+ CRL または OCSP 用のカスタムの正規名 (CNAME) パラメータを含む設定は、CNAME での特殊文字の使用に関する [RFC7230](https://www.ietf.org/rfc/rfc7230.txt) の制限に準拠する必要があります。
+ CRL や OCSP 構成では、CNAME パラメーターの値には、CNAME パラメーターの値には、「http://」や「https://」などのプロトコルプレフィックスを含めることはできません。
**Topics**
+ [失効設定の一般要件](#revocation-requirements)
+ [の CRL を設定する AWS Private CA](crl-planning.md)
+ [の OCSP URL をカスタマイズする AWS Private CA](ocsp-customize.md)
# の CRL を設定する AWS Private CA
[CA 作成プロセス](create-CA.md)の一環として証明書失効リスト (CRL) を設定する前に、いくつかの事前設定が必要になる場合があります。このセクションでは、CRL が添付された CA を作成する前に理解しておくべき前提条件とオプションについて説明します。
CRL の代替または補足としてオンライン証明書ステータスプロトコル (OCSP) を使用する方法については、「[](create-CA.md#PcaCreateRevocation)」および「[の OCSP URL をカスタマイズする AWS Private CA](ocsp-customize.md)」を参照してください。
**Topics**
+ [CRL タイプ](#crl-type)
+ [CRL 構造](#crl-structure)
+ [Amazon S3 の CRL のアクセスポリシー](#s3-policies)
+ [CloudFront で S3 パブリックアクセスブロック (BPA) を有効にする](#s3-bpa)
+ [CRL ディストリビューションポイント (CDP) URI の決定](#crl-url)
+ [](#crl-ipv6)
## CRL タイプ
+ **完了** - デフォルト設定。 は、失効した CA によって発行された期限切れでないすべての証明書について、パーティション分割されていない 1 つの CRL ファイル AWS Private CA を維持します。 AWS Private CA 発行する各証明書は、[RFC 5280 で定義されているように、CRL ディストリビューションポイント (CDP) 拡張機能を介して特定の CRL ](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9)にバインドされます。完全な CRL が有効になっている CA ごとに最大 100 万のプライベート証明書を持つことができます。詳細については、「ク[AWS Private CA ォータ](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca)」を参照してください。
+ **パーティション分割 **- 完全な CRLs と比較して、パーティション分割された CRLsはプライベート CA が発行できる証明書の数を大幅に増やし、CAs を頻繁にローテーションしないようにします。
**重要**
パーティション化された CRLs を使用する場合は、CRL に関連付けられた発行ディストリビューションポイント (IDP) URI が証明書の CDP URI と一致することを検証して、適切な CRL が取得されたことを確認する必要があります。 は IDP 拡張機能を重要として AWS Private CA マークし、クライアントが処理できるようにする必要があります。
## CRL 構造
各 CRL は、DER でエンコードされたファイルです。ファイルをダウンロードし、[OpenSSL](https://www.openssl.org/) を使用して表示するには、次のようなコマンドを使用します。
```
openssl crl -inform DER -in path-to-crl-file -text -noout
```
CRL の形式は次のとおりです。
```
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/ST=WA/L=Seattle/O=Example Company CA/OU=Corporate/CN=www.example.com
Last Update: Feb 26 19:28:25 2018 GMT
Next Update: Feb 26 20:28:25 2019 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65
X509v3 CRL Number:
1519676905984
Revoked Certificates:
Serial Number: E8CBD2BEDB122329F97706BCFEC990F8
Revocation Date: Feb 26 20:00:36 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: F7D7A3FD88B82C6776483467BBF0B38C
Revocation Date: Jan 30 21:21:31 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Signature Algorithm: sha256WithRSAEncryption
82:9a:40:76:86:a5:f5:4e:1e:43:e2:ea:83:ac:89:07:49:bf:
c2:fd:45:7d:15:d0:76:fe:64:ce:7b:3d:bb:4c:a0:6c:4b:4f:
9e:1d:27:f8:69:5e:d1:93:5b:95:da:78:50:6d:a8:59:bb:6f:
49:9b:04:fa:38:f2:fc:4c:0d:97:ac:02:51:26:7d:3e:fe:a6:
c6:83:34:b4:84:0b:5d:b1:c4:25:2f:66:0a:2e:30:f6:52:88:
e8:d2:05:78:84:09:01:e8:9d:c2:9e:b5:83:bd:8a:3a:e4:94:
62:ed:92:e0:be:ea:d2:59:5b:c7:c3:61:35:dc:a9:98:9d:80:
1c:2a:f7:23:9b:fe:ad:6f:16:7e:22:09:9a:79:8f:44:69:89:
2a:78:ae:92:a4:32:46:8d:76:ee:68:25:63:5c:bd:41:a5:5a:
57:18:d7:71:35:85:5c:cd:20:28:c6:d5:59:88:47:c9:36:44:
53:55:28:4d:6b:f8:6a:00:eb:b4:62:de:15:56:c8:9c:45:d7:
83:83:07:21:84:b4:eb:0b:23:f2:61:dd:95:03:02:df:0d:0f:
97:32:e0:9d:38:de:7c:15:e4:36:66:7a:18:da:ce:a3:34:94:
58:a6:5d:5c:04:90:35:f1:8b:55:a9:3c:dd:72:a2:d7:5f:73:
5a:2c:88:85
```
**注記**
CRL は、それを参照する証明書が発行された後にのみ Amazon S3 に保管されます。それ以前は、Amazon S3 バケットに表示される `acm-pca-permission-test-key` ファイルのみが存在します。
## Amazon S3 の CRL のアクセスポリシー
CRL を作成する場合は、保存する Amazon S3 バケットを準備する必要があります。 は、指定した Amazon S3 バケットに CRL AWS Private CA を自動的に預金し、定期的に更新します。詳細については、「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html)」を参照してください。
S3 バケットは、アタッチされた IAM アクセス許可ポリシーによって保護されている必要があります。許可されたユーザーとサービスプリンシパルには、 がバケットにオブジェクトを配置 AWS Private CA するための`Put`アクセス許可と、オブジェクトを取得する`Get`アクセス許可が必要です。
**注記**
IAM ポリシーの設定は、 AWS リージョン 関連する によって異なります。リージョンは次の 2 つのカテゴリに分類されます。
**デフォルトが有効なリージョン** – すべての に対してデフォルトで*有効*になっているリージョン AWS アカウント。
**デフォルト無効リージョン** — デフォルトでは無効になっているが、ユーザーが手動で有効にできるリージョン。
詳細とデフォルト無効リージョンのリストについては、「[AWS リージョンの管理](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)」を参照してください。IAM のコンテキストにおけるサービスプリンシパルの説明については、「[オプトインリージョンのAWS サービスプリンシパル](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services-in-opt-in-regions)」を参照してください。
証明書失効方法として CRL を設定すると、 AWS Private CA は CRL を作成して S3 バケットに公開します。S3 バケットには、 AWS Private CA サービスプリンシパルがバケットに書き込むことを許可する IAM ポリシーが必要です。サービスプリンシパルの名前は使用するリージョンによって異なり、すべてのオプションがサポートされているわけではありません。
****
| PCA | S3 | サービスプリンシパル |
| --- | --- | --- |
| どちらも同じリージョンにあります。 | `acm-pca.amazonaws.com` |
| 有効 | 有効 | `acm-pca.amazonaws.com` |
| 無効 | 有効 | `acm-pca.Region.amazonaws.com` |
| 有効 | 無効 | サポートされていません |
デフォルトポリシーでは CA に `SourceArn` 制限は適用されません。特定の AWS アカウントと特定のプライベート CA の両方へのアクセスを制限する、次のような制限の少ないポリシーを適用することをお勧めします。または、[aws:SourceOrgID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) 条件キーを使用して、 の特定の組織へのアクセスを制限することもできます AWS Organizations。バケットポリシーの詳細については、[「Amazon Simple Storage Service のバケットポリシー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html)」を参照してください。
デフォルトポリシーを許可することを選択した場合は、後でいつでも[変更](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)できます。
## CloudFront で S3 パブリックアクセスブロック (BPA) を有効にする
新しい Amazon S3 バケットは、パブリックアクセスのブロック (BPA) 機能が有効化された状態でデフォルトで設定されます。Amazon S3 の[セキュリティベストプラクティス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)に含まれている BPA は、ユーザーが S3 バケット内のオブジェクトやバケット全体へのアクセスの微調整に使用できるアクセス制御のセットです。BPA がアクティブで正しく設定されている場合、承認されたユーザーと認証された AWS ユーザーのみがバケットとそのコンテンツにアクセスできます。
AWS では、潜在的な攻撃者に機密情報が公開されないように、すべての S3 バケットで BPA を使用することをお勧めします。ただし、PKI クライアントがパブリックインターネット経由で CRLsを取得する場合 (つまり、 AWS アカウントにログインしていない場合）、追加の計画が必要です。このセクションでは、コンテンツ配信ネットワーク (CDN) である Amazon CloudFront を使用してプライベート PKI ソリューションを設定し、認証されたクライアントが S3 バケットにアクセスせずに CRL を処理できるようにする方法について説明します。
**注記**
CloudFront を使用すると、 AWS アカウントに追加のコストが発生します。詳細については、「[Amazon CloudFront の料金](https://aws.amazon.com/cloudfront/pricing/)」を参照してください。
BPA が有効な S3 バケットに CRL を保存し、CloudFront を使用しないでおく場合は、別の CDN ソリューションを構築して PKI クライアントが CRL にアクセスできるようにする必要があります。
### BPA 用 CloudFront のセットアップ
プライベート S3 バケットにアクセスでき、認証されていないクライアントに CRL を提供できる CloudFront ディストリビューションを作成します。
**CRL 用の CloudFront ディストリビューションを設定するには**
1. 「Amazon CloudFront 開発者ガイド」の「[ディストリビューションの作成](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html)」の手順を使用して、新しい CloudFront ディストリビューションを作成します。
手順を完了する際、以下の設定を適用します。
+ **[オリジンドメイン名]** で S3 バケットを選択します。
+ **[バケットアクセスの制限]** で、**[はい]** を選択します。
+ **[オリジンアクセスアイデンティティ]** で **[新しいアイデンティティを作成]** を選択します。
+ **[バケットへの読み取り権限の付与]** で **[はい、バケットポリシーを更新します]** を選択します。
**注記**
この手順では、CloudFront はバケットポリシーを変更して、バケットオブジェクトにアクセスできるようにします。このポリシーを[編集](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)して、`crl` フォルダ内のオブジェクトにのみアクセスを許可することも検討してください。
1. ディストリビューションが初期化されたら、CloudFront コンソールでそのドメイン名を見つけて保存し、次の手順に備えます。
**注記**
S3 バケットが us-east-1 以外のリージョンで新しく作成された場合、CloudFront を介して公開アプリケーションにアクセスすると、HTTP 307 の一時的なリダイレクトエラーが発生する可能性があります。バケットのアドレスが反映されるまでに数時間かかることがあります。
### BPA 用に CA を設定する
新しい CA を設定する際には、CloudFront ディストリビューションにエイリアスを含めてください。
**CloudFront 用の CNAME を使用して CA を設定するには**
+ [でプライベート CA を作成する AWS Private CA](create-CA.md) を使用して CA を作成します。
このプロシージャを実行する場合、非パブリック CRL オブジェクトを指定し、CloudFront のディストリビューションエンドポイントに URL を提供する次の行を失効ファイル `revoke_config.txt` に含める必要があります。
```
"S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL",
"CustomCname":"abcdef012345.cloudfront.net"
```
その後、この CA で証明書を発行すると、次のようなブロックが含まれます。
```
X509v3 CRL Distribution Points:
Full Name:
URI:http://abcdef012345.cloudfront.net/crl/01234567-89ab-cdef-0123-456789abcdef.crl
```
**注記**
この CA が発行した古い証明書を持っている場合、その証明書は CRL にアクセスできなくなります。
## CRL ディストリビューションポイント (CDP) URI の決定
ワークフローで CRL ディストリビューションポイント (CDP) URI を使用する必要がある場合は、その証明書で CRL URI を使用する証明書を発行するか、次の方法を使用できます。これは、完全な CRLs。パーティション化された CRLs にはランダムな GUID が追加されています。
CA の CRL ディストリビューションポイント (CDP) として S3 バケットを使用する場合、CDP URI は次の形式のいずれかになります。
+ `http://amzn-s3-demo-bucket.s3.region-code.amazonaws.com/crl/CA-ID.crl`
+ `http://s3.region-code.amazonaws.com/amzn-s3-demo-bucket/crl/CA-ID.crl`
CA にカスタム CNAME を設定している場合、CDP URI には CNAME が含まれます。たとえば、 `http://alternative.example.com/crl/CA-ID.crl`
##
デフォルトでは、 は IPv4-onlyエンドポイントを使用して CDP 拡張機能を AWS Private CA 書き込みます`amazonaws.com`。IPv6 経由で CRLs を使用するには、次のいずれかの手順を実行してCDPs が [S3 のデュアルスタックエンドポイント](https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html)を指す URLs で書き込まれます。
+ [CRL カスタム名](create-CA.md#PcaCreateRevocation)を S3 デュアルスタックエンドポイントドメインに設定します。例: `bucketname.s3.dualstack.region-code.amazonaws.com`
+ 関連する S3 デュアルスタックエンドポイントを指す独自の CNAME DNS レコードを設定し、CRL カスタム名として使用します。
# の OCSP URL をカスタマイズする AWS Private CA
**注記**
このトピックは、ブランド化やその他の目的でオンライン証明書ステータスプロトコル (OCSP) レスポンダーエンドポイントのパブリック URL をカスタマイズしたいお客様を対象としています。 AWS Private CA マネージド OCSP のデフォルト設定を使用する場合は、このトピックをスキップし、[「失効の設定](create-CA.md#PcaCreateRevocation)」の設定手順に従います。
デフォルトでは、OCSP を有効にすると AWS Private CA、発行する各証明書に OCSP レスポンダーの URL AWS が含まれます。これにより、暗号的に安全な接続を要求するクライアントは、OCSP 検証クエリを AWSに直接送信できます。ただし、最終的には OCSP クエリを AWSに送信するものの、証明書に別の URL を記載したほうがよい場合もあります。
**注記**
OCSP の代替または補足として証明書失効リスト (CRL) を使用する方法については、「[失効の設定](create-CA.md#PcaCreateRevocation)」および「[証明書失効リスト (CRL) の計画](crl-planning.md)」を参照してください。
OCSP のカスタム URL の設定には 3 つの要素が含まれます。
+ **CA 設定** — [でプライベート CA を作成する AWS Private CA](create-CA.md) の [例 2: OCSP とカスタム CNAME が有効な CA を作成する](create-CA.md#example_2) で説明されているように、`RevocationConfiguration` のカスタム OCSP URL をユーザーの CA に指定します。
+ **DNS** — CNAME レコードをドメイン設定に追加して、証明書に記載されている URL をプロキシサーバーの URL にマッピングします。詳細については、「[でプライベート CA を作成する AWS Private CA](create-CA.md)」の [例 2: OCSP とカスタム CNAME が有効な CA を作成する](create-CA.md#example_2) を参照してください。
+ **転送プロキシサーバー** — 受信した OCSP トラフィックを AWS OCSP レスポンダーに透過的に転送できるプロキシサーバーを設定します。
次の図は、これらの要素がどのように連携するかを示しています。
![\[カスタム OCSP トポロジー\]](http://docs.aws.amazon.com/ja_jp/privateca/latest/userguide/images/ocsp.png)
図に示すように、カスタマイズされた OCSP 検証プロセスには次の手順が含まれます。
1. クライアントはターゲットドメインの DNS にクエリを実行します。
1. クライアントはターゲット IP を受信します。
1. クライアントはターゲットとの TCP 接続を開きます。
1. クライアントはターゲット TLS 証明書を受け取ります。
1. クライアントは、証明書に記載されている OCSP ドメインの DNS にクエリを実行します。
1. クライアントはプロキシ IP を受信します。
1. クライアントは OCSP クエリをプロキシに送信します。
1. プロキシは OCSP レスポンダにクエリを転送します。
1. レスポンダーは証明書の状態をプロキシに返します。
1. プロキシは証明書の状態をクライアントに転送します。
1. 証明書が有効な場合、クライアントは TLS ハンドシェイクを開始します。
**ヒント**
この例は、前述のように CA を設定した後、 [Amazon CloudFront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) と [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) を使用して実装できます。
CloudFront で、ディストリビューションを作成し、次のように設定します。
カスタム CNAME と一致する代替名を作成します。
証明書をそれにバインドします。
をオリジン`ocsp.acm-pca..amazonaws.com`として設定します。
IPv6 接続を使用するには、デュアルスタックエンドポイントを使用します。 `acm-pca-ocsp..api.aws`
`Managed-CachingDisabled` ポリシーを適用します。
**[ビューワーのプロトコルポリシー]** を **[HTTP および HTTPS]** に設定します。
**[許可される HTTP メソッド]** を **[GET、HEAD、OPTIONS、PUT、POST、PATCH、DELETE]** に設定します。
Route 53 で、カスタム CNAME を CloudFront ディストリビューションの URL にマッピングする DNS レコードを作成します。
## IPv6 での OCSP の使用
デフォルトの OCSP AWS Private CA レスポンダー URL は IPv4-onlyです。IPv6 経由で OCSP を使用するには、CA のカスタム OCSP URL を設定します。URL は次のいずれかになります。
+ 形式をとるデュアルスタック PCA OCSP レスポンダーの FQDN `acm-pca-ocsp.region-name.api.aws`
+ 上記のように、デュアルスタック OCSP レスポンダーを指すように設定した CNAME レコード。