翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# その他の問題のトラブルシューティング
このセクションでは、ACM 証明書の発行や検証に関連しない問題についてガイダンスを示します。
**Topics**
+ [CAA (Certification Authority Authorization) の問題](troubleshooting-caa.md)
+ [証明書のインポートの問題](troubleshoot-import.md)
+ [証明書のピンニングの問題](troubleshooting-pinning.md)
+ [API Gateway の問題](troubleshoot-apigateway.md)
+ [作業証明書が予期せず失敗した場合の対処方法](unexpected-failure.md)
+ [ACM のサービスにリンクされたロール (SLR) に関する問題](slr-problems.md)
# CAA (Certification Authority Authorization) の問題
CAA DNS レコードを使用して、Amazon 認証局 (CA) によるドメインまたはサブドメイン用の ACM 証明書の発行を指定できます。証明書の発行中に、「**CAA (Certification Authority Authentication) エラーにより、1 つまたは複数のドメイン名の検証に失敗しました。**」というメッセージが表示された場合は、CAA DNS レコードを調べてください。ACM 証明書リクエストが正常に検証された後でこのエラーが表示された場合は、CAA レコードを更新して、証明書を再度リクエストする必要があります。CAA レコードの [**value**] フィールドに、次のいずれかのドメイン名が含まれている必要があります。
+ amazon.com
+ amazontrust.com
+ awstrust.com
+ amazonaws.com
CAA レコード作成についての詳細は、[(オプション) CAA レコードの設定](setup.md#setup-caa) を参照してください。
**注記**
CAA チェックを実行しない場合は、ドメインの CAA レコードを設定しないことができます。
# 証明書のインポートの問題
サードパーティーの証明書を ACM にインポートし、[統合されたサービス](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)と関連付けることができます。問題が発生した場合は、[前提条件](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html)と[証明書形式](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-format.html)に関するトピックを確認してください。特に、以下の点に注意してください。
+ X.509 バージョン 3 の SSL/TLS 証明書のみをインポートすることができます。
+ 証明書は自己署名するか、認証局 (CA) によって署名できます。
+ 証明書が CA によって署名されている場合は、認証機関のルートへのパスを提供する中間証明書チェーンを含める必要があります。
+ 証明書が自己署名証明書である場合は、プライベートキーをプレーンテキストに含める必要があります。
+ チェーンの各証明書は、先行する 1 つの証明書を直接認定する必要があります。
+ 中間証明書チェーンにエンドエンティティ証明書を含めないでください。
+ 証明書、証明書チェーン、およびプライベートキー (存在する場合) は PEMエンコードされている必要があります。一般に、PEMエンコーディングは、プレーンテキストのヘッダー行とフッター行で始まって終わる Base64 でエンコードされた ASCII テキストのブロックで構成されています。PEM ファイルをコピーまたはアップロードするときに、行やスペースを追加したり、その他の変更を加たりすることはできません。[OpenSSL 検証ユーティリティ](https://www.openssl.org/docs/manmaster/man1/openssl-verify.html)を使用して、証明書チェーンを確認することができます。
+ プライベートキー (存在する場合) は暗号化されていない必要があります。(ヒント：パスフレーズがある場合は、暗号化されます)。
+ ACM と[統合された](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html)サービスは、ACM がサポートするアルゴリズムとキーサイズを使用する必要があります。証明書が機能することを確認するには、 AWS Certificate Manager ユーザーガイドと各サービスのドキュメントを参照してください。
+ 統合されたサービスによる証明書のサポートは、証明書のインポート先が IAM であるか ACM であるかによって異なる場合があります。
+ 証明書は、インポート時に有効である必要があります。
+ すべての証明書の詳細情報が、コンソールに表示されます。ただし、デフォルトでは、`keyTypes`フィルターを指定せずに [ListCertificates](https://docs.aws.amazon.com/acm/latest/APIReference/API_ListCertificates.html) API または [list-certificates](https://docs.aws.amazon.com/cli/latest/reference/acm/list-certificates.html) AWS CLI コマンドを呼び出すと、 `RSA_1024` または `RSA_2048`証明書のみが表示されます。
# 証明書のピンニングの問題
証明書を更新するために、ACM は新しいパブリックキーとプライベートキーのペアを生成します。アプリケーションが SSL ピン留めとも呼ばれる を使用して ACM 証明書を固定[証明書のピンニング](acm-bestpractices.md#best-practices-pinning)する場合、 が証明書 AWS を更新した後、アプリケーションはドメインに接続できない場合があります。このため、ACM 証明書をピンニングしないことをお勧めします。アプリケーションで証明書をピンニングする必要がある場合は、次の操作を実行できます。
+ [保持する証明書を ACM にインポート](import-certificate.md)し、アプリケーションをインポートした証明書にピンニングします。ACM はインポートした証明書にマネージド更新を提供しません。
+ パブリック証明書を使用している場合は、アプリケーションを利用可能なすべての [Amazon ルート証明書](https://www.amazontrust.com/repository/)に固定化します。プライベート証明書を使用している場合は、アプリケーションを CA のルート証明書にピンニングします。
# API Gateway の問題
*エッジ最適化*された API エンドポイントをデプロイすると、API Gateway は CloudFront ディストリビューションを設定します。CloudFront ディストリビューションは、アカウントではなく、API Gateway によって所有されています。ディストリビューションは、API のデプロイ時に使用した ACM 証明書にバインドされます。バインドを削除して、ACM が証明書を削除できるようにするには、証明書に関連付けられている API Gateway カスタムドメインを削除する必要があります。
*リージョン* API エンドポイントをデプロイすると、ユーザーに代わって API Gateway により Application Load Balancer (ALB) が作成されます。API Gateway によって所有されているロードバランサーは、ユーザーからは見えません。ALB は、API のデプロイ時に使用した ACM 証明書にバインドされます。バインドを削除して、ACM が証明書を削除できるようにするには、証明書に関連付けられている API Gateway カスタムドメインを削除する必要があります。
# 作業証明書が予期せず失敗した場合の対処方法
ACM 証明書を統合サービスに関連付けたのに、証明書が機能しなくなり、統合サービスがエラーを返し始めた場合は、ACM 証明書を使用するためにサービスが必要とするアクセス許可の変更が原因である可能性があります。
たとえば、Elastic Load Balancing (ELB) には、証明書のプライベートキーを復号 AWS KMS key する を復号するアクセス許可が必要です。このアクセス許可は、証明書を ELB に関連付けるときに ACM が適用するリソースベースのポリシーによって付与されます。ELB がそのアクセス許可の付与を失った場合、ELB は次に証明書キーの復号を試みるときに失敗します。
問題を調査するには、 の AWS KMS コンソールを使用して許可のステータスを確認します[https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms)。次に、次のいずれかのアクションを実行します。
+ 統合サービスに対して付与されたアクセス許可が失効したと思われる場合は、統合サービスのコンソールにアクセスし、サービスから証明書の関連付けを解除してから、再関連付けします。これにより、リソースベースのポリシーが再適用され、新しい許可が設定されます。
+ ACM に付与されたアクセス許可が取り消されたと思われる場合は、https://console.aws.amazon.com/support/home\$1/ サポート の にお問い合わせください。
# ACM のサービスにリンクされたロール (SLR) に関する問題
別のアカウントによって共有されているプライベート CA によって署名された証明書を発行すると、ACM は最初に を使用してサービスにリンクされたロール (SLR) を設定し、プリンシパルとして AWS Private CA [リソースベースのアクセスポリシー](https://docs.aws.amazon.com/privateca/latest/userguide/pca-resource-sharing.html#pca-rbp)とやり取りしようとします。共有 CA からプライベート証明書を発行し、SLR が設定されていない場合、ACM はその証明書を自動的に更新できません。
ACM では、アカウントに SLR が存在するかどうかを判断できないという警告が表示されることがあります。必要な `iam:GetRole` アクセス許可がすでにアカウントの ACM SLR に付与されている場合、SLR の作成後にアラートは再発しません。再発する場合は、ユーザーまたはアカウント管理者が `iam:GetRole` アクセス許可を ACM に付与するか、アカウントを ACM 管理ポリシー `AWSCertificateManagerFullAccess` に関連付けます。
詳細については、「*IAM ユーザーガイド*」の「[サービスにリンクされたロールの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)」を参照してください。