# Troubleshoot other problems
This section includes guidance for problems not related to issuing or validating ACM certificates.
**Topics**
+ [Certification Authority Authorization (CAA) problems](troubleshooting-caa.md)
+ [Certificate import problems](troubleshoot-import.md)
+ [Certificate pinning problems](troubleshooting-pinning.md)
+ [API Gateway problems](troubleshoot-apigateway.md)
+ [What to do when a working certificate fails unexpectedly](unexpected-failure.md)
+ [Problems with the ACM service-linked role (SLR)](slr-problems.md)
# Certification Authority Authorization (CAA) problems
You can use CAA DNS records to specify that the Amazon certificate authority (CA) can issue ACM certificates for your domain or subdomain. If you receive an error during certificate issuance that says **One or more domain names have failed validation due to a Certification Authority Authorization (CAA) error**, check your CAA DNS records. If you receive this error after your ACM certificate request has been successfully validated, you must update your CAA records and request a certificate again. The **value** field in your CAA record must contain one of the following domain names:
+ amazon.com
+ amazontrust.com
+ awstrust.com
+ amazonaws.com
For more information about creating a CAA record, see [(Optional) Configure a CAA record](setup.md#setup-caa).
**Note**
You can choose to not configure a CAA record for your domain if you do not want to enable CAA checking.
# Certificate import problems
You can import third-party certificates into ACM and associate them with [integrated services](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html). If you encounter problems, review the [prerequisites](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-prerequisites.html) and [certificate format](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate-format.html) topics. In particular, note the following:
+ You can import only X.509 version 3 SSL/TLS certificates.
+ Your certificate can be self–signed or it can be signed by a certificate authority (CA).
+ If your certificate is signed by a CA, you must include an intermediate certificate chain that provides a path to the root of authority.
+ If your certificate is self-signed, you must include the private key in plaintext.
+ Each certificate in the chain must directly certify the one preceding.
+ Do not include your end-entity certificate in the intermediate certificate chain.
+ Your certificate, certificate chain, and private key (if any) must be PEM–encoded. In general, PEM encoding consists of blocks of Base64-encoded ASCII text that begin and end with plaintext header and footer lines. You must not add lines or spaces or make any other changes to a PEM file while copying or uploading it. You can verify certificate chains using the [OpenSSL verify utility](https://www.openssl.org/docs/manmaster/man1/openssl-verify.html).
+ Your private key (if any) must not be encrypted. (Tip: if it has a passphrase, it's encrypted.)
+ Services [integrated](https://docs.aws.amazon.com/acm/latest/userguide/acm-services.html) with ACM must use ACM-supported algorithms and key sizes. See the AWS Certificate Manager User Guide and the documentation for each service to make sure that your certificate will work.
+ Certificate support by integrated services might differ depending on whether the certificate is imported into IAM or into ACM.
+ The certificate must be valid when it is imported.
+ Detail information for all of your certificates is displayed in the console. By default, however, if you call the [ListCertificates](https://docs.aws.amazon.com/acm/latest/APIReference/API_ListCertificates.html) API or the [list-certificates](https://docs.aws.amazon.com/cli/latest/reference/acm/list-certificates.html) AWS CLI command without specifying the `keyTypes` filter, only `RSA_1024` or `RSA_2048` certificates are displayed.
# Certificate pinning problems
To renew a certificate, ACM generates a new public-private key pair. If your application uses [Certificate pinning](acm-bestpractices.md#best-practices-pinning), sometimes known as SSL pinning, to pin an ACM certificate, the application might not be able to connect to your domain after AWS renews the certificate. For this reason, we recommend that you don't pin an ACM certificate. If your application must pin a certificate, you can do the following:
+ [Import your own certificate into ACM](import-certificate.md) and then pin your application to the imported certificate. ACM doesn't provide managed renewal for imported certificates.
+ If you're using a public certificate, pin your application to all available [ Amazon root certificates](https://www.amazontrust.com/repository/). If you're using a private certificate, pin your application to the CA's root certificate.
# API Gateway problems
When you deploy an *edge-optimized* API endpoint, API Gateway sets up a CloudFront distribution for you. The CloudFront distribution is owned by API Gateway, not by your account. The distribution is bound to the ACM certificate that you used when deploying your API. To remove the binding and allow ACM to delete your certificate, you must remove the API Gateway custom domain that is associated with the certificate.
When you deploy a *regional* API endpoint, API Gateway creates an application load balancer (ALB) on your behalf. The load balancer is owned by API Gateway and is not visible to you. The ALB is bound to the ACM certificate that you used when deploying your API. To remove the binding and allow ACM to delete your certificate, you must remove the API Gateway custom domain that is associated with the certificate.
# What to do when a working certificate fails unexpectedly
If you have successfully associated an ACM certificate with an integrated service, but the certificate stops working and the integrated service begins returning errors, the cause may be a change in the permissions that the service needs in order to use an ACM certificate.
For example, Elastic Load Balancing (ELB) requires permission to decrypt an AWS KMS key that, in turn, decrypts the certificate's private key. This permission is granted by a resource-based policy that ACM applies when you associate a certificate with ELB. If ELB loses the grant for that permission, it will fail the next time it attempts to decrypt the certificate key.
To investigate the problem, check the status of your grants using the AWS KMS console at [https://console.aws.amazon.com/kms](https://console.aws.amazon.com/kms). Then take one of the following actions:
+ If you believe that permissions granted to an integrated service have been revoked, visit the integrated service's console, disassociate the certificate from the service, then re-associate it. This will reapply the resource-based policy and put a new grant in place.
+ If you believe that permissions granted to ACM have been revoked, contact Support at https://console.aws.amazon.com/support/home\$1/.
# Problems with the ACM service-linked role (SLR)
When you issue a certificate signed by a private CA that has been shared with you by another account, ACM attempts on first use to set up a service-linked role (SLR) to interact as a principal with an AWS Private CA [resource-based access policy](https://docs.aws.amazon.com/privateca/latest/userguide/pca-resource-sharing.html#pca-rbp). If you issue a private certificate from a shared CA and the SLR is not in place, ACM will be unable to automatically renew that certificate for you.
ACM might alert you that it cannot determine whether an SLR exists on your account. If the required `iam:GetRole` permission has already been granted to the ACM SLR for your account, then the alert will not recur after the SLR is created. If it does recur, then you or your account administrator might need to grant the `iam:GetRole` permission to ACM, or associate your account with the ACM-managed policy `AWSCertificateManagerFullAccess`.
For more information, see [Service-Linked Role Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) in the *IAM User Guide*.