# Troubleshoot issues with AWS Certificate Manager
Consult the following topics if you encounter problems using AWS Certificate Manager.
**Note**
If you don't see your issue addressed in this section, we recommend visiting the [AWS Knowledge Center](https://aws.amazon.com/premiumsupport/knowledge-center/).
**Topics**
+ [
# Troubleshoot certificate requests
](troubleshooting-cert-requests.md)
+ [
# Troubleshoot certificate validation
](certificate-validation.md)
+ [
# Troubleshoot managed certificate renewal
](troubleshooting-renewal.md)
+ [
# Troubleshoot other problems
](misc-problems.md)
+ [
# Handling exceptions
](exceptions.md)
# Troubleshoot certificate requests
Consult the following topics if you encounter problems when requesting an ACM certificate.
**Topics**
+ [
## Certificate request times out
](#troubleshooting-timed-out)
+ [
## Certificate request fails
](#troubleshooting-failed)
## Certificate request times out
Requests for ACM certificates time out if they are not validated within 72 hours. To correct this condition, open the console, find the record for the certificate, click the checkbox for it, choose **Actions**, and choose **Delete**. Then choose **Actions** and **Request a certificate** to begin again. For more information, see [AWS Certificate Manager DNS validationDNS validation](dns-validation.md) or [AWS Certificate Manager email validation](email-validation.md). We recommend that you use DNS validation if possible.
## Certificate request fails
If your request fails ACM and you receive one of the following error messages, follow the suggested steps to fix the problem. You cannot resubmit a failed certificate request – after resolving the problem, submit a new request.
**Topics**
+ [
### Error message: No Available Contacts
](#failed-no-available-contacts)
+ [
### Error message: Additional Verification Required
](#failed-additional-verification-required)
+ [
### Error message: Invalid Public Domain
](#failed-invalid-domain)
+ [
### Error message: Other
](#failed-other)
### Error message: No Available Contacts
You chose email validation when requesting a certificate, but ACM could not find an email address to use for validating one or more of the domain names in the request. To correct this problem, you can do one of the following:
+ Ensure your domain is configured to receive email. Your domain's name server must have a mail exchanger record (MX record) so ACM's email servers know where to send the [domain validation email](email-validation.md).
Accomplishing just one of the preceding tasks is enough to correct this problem; you don't need to do both. After you correct the problem, request a new certificate.
For more information about how to ensure that you receive domain validation emails from ACM, see [AWS Certificate Manager email validation](email-validation.md) or [Not receiving validation email](troubleshooting-email-validation.md#troubleshooting-no-mail). If you follow these steps and continue to get the **No Available Contacts** message, then [report this to AWS](https://console.aws.amazon.com/support/home) so that we can investigate it.
### Error message: Additional Verification Required
ACM requires additional information to process this certificate request. This happens as a fraud-protection measure if your domain ranks within the [Alexa top 1000 websites](https://aws.amazon.com/marketplace/pp/Amazon-Web-Services-Alexa-Top-Sites/B07QK2XWNV). To provide the required information, use the [Support Center](https://console.aws.amazon.com/support/home) to contact Support. If you don't have a support plan, post a new thread in the [ACM Discussion Forum](https://forums.aws.amazon.com/forum.jspa?forumID=206).
**Note**
You cannot request a certificate for Amazon-owned domain names such as those ending in amazonaws.com, cloudfront.net, or elasticbeanstalk.com.
### Error message: Invalid Public Domain
One or more of the domain names in the certificate request is not valid. Typically, this is because a domain name in the request is not a valid top-level domain. Try again to request a certificate, correcting any spelling errors or typos that were in the failed request, and ensure that all domain names in the request are for valid top-level domains. For example, you cannot request an ACM certificate for `example.invalidpublicdomain` because "**invalidpublicdomain**" is not a valid top-level domain. If you continue to receive this failure reason, contact the [Support Center](https://console.aws.amazon.com/support/home). If you don't have a support plan, post a new thread in the [ACM Discussion Forum](https://forums.aws.amazon.com/forum.jspa?forumID=206).
### Error message: Other
Typically, this failure occurs when there is a typographical error in one or more of the domain names in the certificate request. Try again to request a certificate, correcting any spelling errors or typos that were in the failed request. If you continue to receive this failure message, use the [Support Center](https://console.aws.amazon.com/support/home) to contact Support. If you don't have a support plan, post a new thread in the [ACM Discussion Forum](https://forums.aws.amazon.com/forum.jspa?forumID=206).
# Troubleshoot certificate validation
If the ACM certificate request status is **Pending validation**, the request is waiting for action from you. If you chose email validation when you made the request, you or an authorized representative must respond to the validation email messages. These messages were sent to the common email addresses for the requested domain. For more information, see [AWS Certificate Manager email validation](email-validation.md). If you chose DNS validation, you must write the CNAME record that ACM created for you to your DNS database. For more information, see [AWS Certificate Manager DNS validationDNS validation](dns-validation.md).
**Important**
You must validate that you own or control every domain name that you included in your certificate request. If you chose email validation, you will receive validation email messages for each domain. If you do not, then see [Not receiving validation email](troubleshooting-email-validation.md#troubleshooting-no-mail). If you chose DNS validation, you must create one CNAME record for each domain.
**Note**
Public ACM certificates can be installed on Amazon EC2 instances that are connected to a [Nitro Enclave](acm-services.md#acm-nitro-enclave). You can also [export a public certificate](export-public-certificate.md) to use on any Amazon EC2 instance. For information about setting up a standalone web server on an Amazon EC2 instance not connected to a Nitro Enclave, see [Tutorial: Install a LAMP web server on Amazon Linux 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-lamp-amazon-linux-2.html) or [Tutorial: Install a LAMP web server with the Amazon Linux AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-LAMP.html).
We recommend that you use DNS validation rather than email validation.
Consult the following topics if you experience validation problems.
**Topics**
+ [
# Troubleshoot DNS validation problems
](troubleshooting-DNS-validation.md)
+ [
# Troubleshoot email validation problems
](troubleshooting-email-validation.md)
+ [
# Troubleshooting HTTP validation problems
](troubleshooting-HTTP-validation.md)
# Troubleshoot DNS validation problems
Consult the following guidance if you are having trouble validating a certificate with DNS.
The first step in DNS troubleshooting is to check the current status of your domain with tools such as the following:
+ **dig** — [Linux](https://linux.die.net/man/1/dig), [Windows](https://help.dyn.com/how-to-use-binds-dig-tool/)
+ **nslookup** — [Linux](https://linux.die.net/man/1/nslookup), [Windows](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/nslookup)
**Topics**
+ [
## Underscores prohibited by DNS provider
](#underscores-prohibited)
+ [
## Default trailing period added by DNS provider
](#troubleshooting-trailing-period)
+ [
## DNS validation on GoDaddy fails
](#troubleshooting-DNS-GoDaddy)
+ [
## ACM Console does not display "Create records in Route 53" button
](#troubleshooting-route53-1)
+ [
## Route 53 validation fails on private (untrusted) domains
](#troubleshooting-route53-2)
+ [
## Validation is successful but issuance or renewal fails
](#troubleshooting-dns-pending-violation)
+ [
## Validation fails for DNS server on a VPN
](#troubleshooting-vpn)
## Underscores prohibited by DNS provider
If your DNS provider prohibits leading underscores in CNAME values, you can remove the underscore from the ACM-provided value and validate your domain without it. For example, the CNAME value `_x2.acm-validations.aws` can be changed to `x2.acm-validations.aws` for validation purposes. However, the CNAME name parameter must always begin with a leading underscore.
You can use either of the values on the right side of the table below to validate a domain.
| Name | Type | Value |
| --- | --- | --- |
| `_.example.com.` | CNAME | `_.acm-validations.aws.` |
| `_.example.com.` | CNAME | `.acm-validations.aws.` |
## Default trailing period added by DNS provider
Some DNS providers add by default a trailing period to the CNAME value that you provide. As a result, adding the period yourself causes an error. For example, "`.acm-validations.aws.`" is rejected while "`.acm-validations.aws`" is accepted.
## DNS validation on GoDaddy fails
DNS validation for domains registered with Godaddy and other registries may fail unless you modify the CNAME values provided by ACM. Taking example.com as the domain name, the issued CNAME record has the following form:
```
NAME: _ho9hv39800vb3examplew3vnewoib3u.example.com. VALUE: _cjhwou20vhu2exampleuw20vuyb2ovb9.j9s73ucn9vy.acm-validations.aws.
```
You can create a CNAME record compatible with GoDaddy by truncating the apex domain (including the period) at the end of the NAME field, as follows:
```
NAME: _ho9hv39800vb3examplew3vnewoib3u VALUE: _cjhwou20vhu2exampleuw20vuyb2ovb9.j9s73ucn9vy.acm-validations.aws.
```
## ACM Console does not display "Create records in Route 53" button
If you select Amazon Route 53 as your DNS provider, AWS Certificate Manager can interact directly with it to validate your domain ownership. Under some circumstances, the console's **Create records in Route 53** button may not be available when you expect it. If this happens, check for the following possible causes.
+ You are not using Route 53 as your DNS provider.
+ You are logged into ACM and Route 53 through different accounts.
+ You lack IAM permissions to create records in a zone hosted by Route 53.
+ You or someone else has already validated the domain.
+ The domain is not publicly addressable.
## Route 53 validation fails on private (untrusted) domains
During DNS validation, ACM searches for a CNAME in a publicly hosted zone. When it doesn't find one, it times out after 72 hours with a status of **Validation timed out**. You cannot use it to host DNS records for private domains, including resources in an Amazon VPC [private hosted zone](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-private-hosted-zones), untrusted domains in your private PKI, and self-signed certificates.
AWS does provide support for publicly untrusted domains through the [AWS Private CA](https://aws.amazon.com/certificate-manager/private-certificate-authority/) service.
## Validation is successful but issuance or renewal fails
If certificate issuance fails with "Pending validation" even though DNS is correct, check that issuance is not being blocked by a Certification Authority Authorization (CAA) record. For more information, see [(Optional) Configure a CAA record](setup.md#setup-caa).
## Validation fails for DNS server on a VPN
If you locate a DNS server on a VPN and ACM fails to validate a certificate against it, check if the server is publicly accessible. Public certificate issuance using ACM DNS validation requires that the domain records be resolvable over the public internet.
# Troubleshoot email validation problems
Consult the following guidance if you are having trouble validating a certificate domain with email.
**Topics**
+ [
## Not receiving validation email
](#troubleshooting-no-mail)
+ [
## Persistent initial timestamp for email validation
](#initial-dates)
+ [
## I can't switch to DNS validation
](#troubleshoot-switch-to-dns)
## Not receiving validation email
When you request a certificate from ACM and choose email validation, domain validation email is sent to the five common administrative addresses. For more information, see [AWS Certificate Manager email validation](email-validation.md). If you are experiencing problems receiving validation email, review the suggestions that follow.
**Where to look for email**
ACM sends validation email messages to your requested domain name. You can also specify a superdomain as a validation domain if you wish to receive these emails at that domain instead. Any subdomain up to the minimal website address is valid, and is used as the domain for the email address as the suffix after @. For example, you can receive an email to admin@example.com if you specify example.com as the validation domain for subdomain.example.com. Review the list of email addresses that are displayed in the ACM console (or returned from the CLI or API) to determine where you should be looking for validation email. To see the list, click the icon next to the domain name in the box labeled **Validation not complete**.
**The email is marked as spam**
Check your spam folder for the validation email.
**GMail automatically sorts your email**
If you are using GMail, the validation email may have been automatically sorted into the **Updates** or **Promotions** tabs.
**Contact the Support Center**
If, after reviewing the preceding guidance, you still don't receive the domain validation email, please visit the [Support Center](https://console.aws.amazon.com/support/home) and create a case. If you don't have a support agreement, post a message to the [ACM Discussion Forum](https://forums.aws.amazon.com/forum.jspa?forumID=206).
## Persistent initial timestamp for email validation
The timestamp of a certificate's first email-validation request persists through later requests for validation renewal. This is not evidence of an error in ACM operations.
## I can't switch to DNS validation
After you create a certificate with email validation, you cannot switch to validating it with DNS. To use DNS validation, delete the certificate and then create a new one that uses DNS validation.
# Troubleshooting HTTP validation problems
Consult the following guidance if you're having trouble validating a certificate with HTTP.
The first step in HTTP troubleshooting is to check the current status of your domain with tools such as the following:
+ **curl** — [Linux and Windows](https://curl.se/docs/manpage.html)
+ **wget** — [Linux and Windows](https://www.gnu.org/software/wget/manual/wget.html)
**Topics**
+ [
## Content mismatch between RedirectFrom and RedirectTo locations
](#http-validation-content-mismatch)
+ [
## Incorrect CloudFront configuration
](#http-validation-cloudfront-configuration)
+ [
# HTTP redirect issues
](http-validation-redirect-issues.md)
+ [
# Validation timeout
](http-validation-timeout.md)
## Content mismatch between RedirectFrom and RedirectTo locations
If the content at the `RedirectFrom` location doesn't match the content at the `RedirectTo` location, validation will fail. Ensure that the content is identical for each domain in the certificate.
## Incorrect CloudFront configuration
Make sure your CloudFront distribution is correctly configured to serve the validation content. Check that the origin and behavior settings are correct and that the distribution is deployed.
# HTTP redirect issues
If you're using a redirect instead of serving the content directly, follow these steps to verify your configuration.
**To verify redirect configuration**
1. Copy the `RedirectFrom` URL and paste it into your browser's address bar.
1. In a new browser tab, paste the `RedirectTo` URL.
1. Compare the content at both URLs to ensure they match exactly.
1. Verify that the redirect returns a 302 status code.
# Validation timeout
HTTP validation may time out if the content isn't available within the expected time frame. To troubleshoot validation issues, follow these steps.
**To troubleshoot validation timeout**
1. Do one of the following to check which domains are pending validation:
1. Open the ACM console and view the certificate details page. Look for domains marked as **Pending validation**.
1. Call the `DescribeCertificate` API operation to view the validation status of each domain.
1. For each pending domain, verify that the validation content is accessible from the internet.
# Troubleshoot managed certificate renewal
ACM tries to automatically renew your ACM certificates before they expire so that no action is required from you. Consult the following topics if you have trouble with [Managed certificate renewal in AWS Certificate Manager](managed-renewal.md).
## Preparing for automatic domain validation
Before ACM can renew your certificates automatically, the following must be true:
+ Your certificate must be associated with an AWS service that is integrated with ACM. For information about the resources that ACM supports, see [Services integrated with ACM](acm-services.md).
+ For email-validated certificates, ACM must be able to reach you at an administrator email address for each domain listed in your certificate. The email addresses that will be tried are listed in [AWS Certificate Manager email validation](email-validation.md).
+ For DNS-validated certificates, make sure that your DNS configuration contains the correct CNAME records as described in [AWS Certificate Manager DNS validationDNS validation](dns-validation.md).
+ For HTTP-validated certificates, make sure that your redirects are configured as described in [AWS Certificate Manager HTTP validation](http-validation.md).
## Handling failures in managed certificate renewal
As the certificate nears expiration (45 days for DNS, 45 for EMAIL and 60 days for Private), ACM attempts to renew the certificate if it meets the [eligibility criteria](managed-renewal.md). You might have to take actions for the renewal to succeed. For more information, see [Managed certificate renewal in AWS Certificate Manager](managed-renewal.md).
## Managed certificate renewal for email-validated certificates
ACM certificates are valid for 198 days. Renewing a certificate requires action by the domain owner. ACM begins sending renewal notices to the email addresses associated with the domain 45 days before expiration. The notifications contain a link that the domain owner can click for renewal. Once all listed domains are validated, ACM issues a renewed certificate with the same ARN.
See [Validate with Email](email-validation.md) for instructions on identifying which domains are in the `PENDING_VALIDATION` state and repeating the validation process for those domains.
## Managed certificate renewal for DNS-validated certificates
ACM does not attempt TLS validation for DNS-validated certificates. If ACM fails to renew a certificate you validated with DNS validation, it is most likely due to missing or inaccurate CNAME records in your DNS configuration. If this occurs, ACM notifies you that the certificate could not be renewed automatically.
**Important**
You must insert the correct CNAME records into your DNS database. Consult your domain registrar about how to do this.
You can find the CNAME records for your domains by expanding your certificate and its domain entries in the ACM console. Refer to the figures below for details. You can also retrieve CNAME records by using the [DescribeCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_DescribeCertificate.html) operation in the ACM API or the [describe-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/describe-certificate.html) command in the ACM CLI. For more information, see [AWS Certificate Manager DNS validationDNS validation](dns-validation.md).
![\[Select the target certificate from the console.\]](http://docs.aws.amazon.com/acm/latest/userguide/images/Dns-renewal-1.png)
![\[Expand the certificate window to find the certificate's CNAME information.\]](http://docs.aws.amazon.com/acm/latest/userguide/images/Dns-renewal-2.png)
If the problem persists, contact the [Support Center](https://console.aws.amazon.com/support).
## Managed certificate renewal for HTTP-validated certificates
ACM attempts to renew HTTP-validated certificates automatically. If renewal fails, it's likely due to issues with the HTTP validation records. In such cases, ACM notifies you that the certificate couldn't be renewed automatically.
**Important**
You must ensure that the content at the `RedirectFrom` location matches the content at the `RedirectTo` location for each domain in the certificate.
You can find the HTTP validation information for your domains by expanding your certificate and its domain entries in the ACM console. You can also retrieve this information using the [DescribeCertificate](https://docs.aws.amazon.com/acm/latest/APIReference/API_DescribeCertificate.html) operation in the ACM API or the [describe-certificate](https://docs.aws.amazon.com/cli/latest/reference/acm/describe-certificate.html) command in the ACM CLI. For more information, see [AWS Certificate Manager HTTP validation](http-validation.md).
If the problem persists, contact the [Support Center](https://console.aws.amazon.com/support).
## Understanding renewal timing
[Managed certificate renewal in AWS Certificate Manager](managed-renewal.md) is an asynchronous process. This means that the steps don't occur in immediate succession. After all domain names in an ACM certificate have been validated, there might be a delay before ACM obtains the new certificate. An additional delay can occur between the time when ACM obtains the renewed certificate and the time when that certificate is deployed to the AWS resources that use it. Therefore, changes to the certificate status can take up to several hours to appear in the console.
# 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*.
# Handling exceptions
An AWS Certificate Manager command might fail for several reasons. For information about each exception, see the table below.
## Private certificate exception handling
The following exceptions can occur when you attempt to renew a private PKI certificate issued by AWS Private CA.
**Note**
AWS Private CA is not supported in the China (Beijing) Region and the China (Ningxia) Region.
| ACM failure code | Comment |
| --- | --- |
| `PCA_ACCESS_DENIED` | The private CA has not granted ACM permissions. This triggers a AWS Private CA `AccessDeniedException` failure code. To remedy the problem, grant the necessary permissions to the ACM service principal using the AWS Private CA [CreatePermission](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CreatePermission.html) operation. |
| `PCA_INVALID_DURATION` | The validity period of the requested certificate exceeds the validity period of the issuing private CA. This triggers a AWS Private CA `ValidationException` failure code. To remedy the problem, [install a new CA certificate](https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html) with an appropriate validity period. |
| `PCA_INVALID_STATE` | The private CA being called is not in the correct state to perform the requested ACM operation. This triggers a AWS Private CA `InvalidStateException` failure code. Resolve the issue as follows: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/acm/latest/userguide/exceptions.html) |
| `PCA_LIMIT_EXCEEDED` | The private CA has reached an issuance quota. This triggers a AWS Private CA `LimitExceededException` failure code. Try repeating your request before proceeding with this help. If the error persists, contact [Support](https://console.aws.amazon.com/support/home#/) to request a quota increase. |
| `PCA_REQUEST_FAILED` | A network or system error occurred. This triggers a AWS Private CA `RequestFailedException` failure code. Try repeating your request before proceeding with this help. If the error persists, contact [Support](https://console.aws.amazon.com/support/home#/). |
| `PCA_RESOURCE_NOT_FOUND` | The private CA has been permanently deleted. This triggers a AWS Private CA `ResourceNotFoundException` failure code. Verify that you used the correct ARN. If that fails, you won't be able to use this CA. To remedy the problem, [create a new CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCreateCa.html). |
| SLR\$1NOT\$1FOUND | In order to renew a certificate signed by a private CA that resides in another account, ACM requires a Service Linked Role (SLR) on the account where the certificate resides. If you need to recreate a deleted SLR, see [Creating the SLR for ACM](acm-slr.md#create-slr). |