# Ensure ACM certificates use a secure key algorithm - Source: https://support.icompaas.com/support/solutions/articles/a_1793292229011324-ensure-acm-certificates-use-a-secure-key-algorithm - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that every AWS Certificate Manager (ACM) certificate in use has a strong public key algorithm. A certificate is flagged when its key algorithm exactly matches an entry on the configured list of insecure algorithms, by default RSA-1024 and P-192; key sizes are not compared, so any algorithm not on the list passes. Certificates that are not in use are not evaluated. Certificates with weak keys must be replaced with certificates that use RSA 2048-bit or larger, or ECDSA P-256 or larger. **Rationale** A weak certificate key reduces the protection that TLS provides. If an attacker can factor or otherwise recover the private key, they can impersonate the website or service, decrypt traffic and carry out man-in-the-middle attacks, leading to data exposure and tampering. Using RSA 2048-bit or stronger keys, or ECDSA P-256 or P-384 keys, keeps certificates resistant to these attacks. **Impact** - Protects TLS connections against private key recovery, impersonation and traffic decryption - Replacing a certificate requires updating each service that uses it, such as load balancers, CloudFront distributions and API Gateway custom domains - Some old clients may not support ECDSA certificates; use RSA 2048-bit if such clients must be supported **Default Value** Certificates requested from ACM use RSA 2048-bit keys unless another algorithm is selected, and ACM does not issue certificates with weak keys. Weak keys normally come from imported certificates. **Pre-Requisites** - IAM permissions: acm:ListCertificates, acm:DescribeCertificate, acm:RequestCertificate, acm:ImportCertificate and acm:DeleteCertificate - Permissions to update the services that use the certificate (for example elasticloadbalancing:ModifyListener) - For imported certificates: a new certificate with a strong key from the issuing certificate authority - For ACM-issued certificates: access to the DNS records or email used for domain validation **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS Certificate Manager (ACM) console. 3. Select each certificate that is in use and check its **Key algorithm** in the certificate details. 4. Repeat for each region in use. Certificates used by CloudFront are in the **US East (N. Virginia)** region. 5. If any certificate in use has the key algorithm **RSA 1024**, follow the implementation steps. **CLI:** List all certificates with their key algorithm and usage: aws acm list-certificates --region --includes keyTypes=RSA\_1024,RSA\_2048,RSA\_3072,RSA\_4096,EC\_prime256v1,EC\_secp384r1,EC\_secp521r1 --query "CertificateSummaryList\[\].\[DomainName,Type,InUse,KeyAlgorithm,CertificateArn\]" --output table A certificate fails if it is in use and its key algorithm exactly matches an entry on the insecure list, by default RSA-1024 and P-192; key sizes are not compared, so every other algorithm passes. ACM does not support ECDSA P-192 keys, so in practice only RSA 1024-bit certificates are flagged. Certificates that are not in use are not evaluated. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the AWS Certificate Manager (ACM) console. 3. To replace the certificate with an ACM-issued one: - choose **Request a certificate**, select **Request a public certificate** and enter the same domain names, - under **Key algorithm**, select **RSA 2048** or **ECDSA P 256**, - complete domain validation (DNS validation is recommended). 4. To replace an imported certificate, obtain a new certificate with a strong key from your certificate authority and import it. 5. In each service that uses the old certificate (load balancer listener, CloudFront distribution or API Gateway custom domain), select the new certificate and save. 6. When the old certificate is no longer in use, select it and choose **Delete**. 7. Repeat for each affected certificate in each region in use. **Backout Plan** 1. Do not delete the old certificate until the new certificate is working in all services. 2. If problems occur, open the settings of each affected service (load balancer listener, CloudFront distribution or API Gateway custom domain) and select the previous certificate again. 3. Save the change. Note: rolling back restores the weak key and its risks. Use it only as a temporary measure while client compatibility issues are resolved. **Reference** - [https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) - [https://docs.aws.amazon.com/acm/latest/userguide/data-protection.html](https://docs.aws.amazon.com/acm/latest/userguide/data-protection.html) - [https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.