PuppyIP Resource Center
Cloud Operations 11 min Published 2026-08-22

Migrating AWS ACM Email Validation to DNS: Checks That Keep the Original ARN

AWS Certificate Manager now supports switching existing ACM-issued public TLS certificates from email to DNS validation in place, without reissuing the certificate or changing its ARN. The real work is not a single button click: inventory eligible certificates, correctly publish every domain's CNAME within 72 hours, and confirm that renewal now follows the DNS path.

AWS ACM DNS validation TLS certificates CNAME Certificate migration

Service eligibility and regional restrictions

PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.

Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.

Key Takeaways

  • This in-place migration applies only to ACM-issued public certificates currently using email validation. Do not apply it unchanged to imported certificates, private CA certificates or other validation paths.
  • The certificate ARN stays the same after migration. Load balancers, CloudFront or CI/CD configurations referencing that ARN generally do not need replacement.
  • After you trigger the update, ACM provides CNAME records for the certificate's domains. The team has up to 72 hours to publish them in publicly resolvable DNS.
  • Missing the 72-hour window does not immediately interrupt the current certificate: it continues using email validation and you can retry after fixing DNS. This is not a reason to miss the renewal deadline.
  • ACM will stop issuing new email-validated certificates on March 31, 2027, and stop renewing existing email-validated certificates on September 30, 2027.

Who needs to migrate, and who should not use these steps

This guide is for cloud-platform, SRE, security and domain teams managing ACM public certificates. Inventory certificates in every Region whose Type is Amazon Issued and Validation method is Email. Only these existing certificates are targets for this in-place migration.

Imported certificates are renewed by external CAs, private CA certificates do not validate public domain ownership, and CloudFront HTTP validation is a different path again. Including these objects in the batch creates incorrect expectations about CNAME records.

Why the new rules can conflict with older documentation

AWS announced the capability on August 13, 2026: existing email-validated ACM public certificates can move to DNS validation in place through the console or UpdateCertificateOptions API. Some older DNS-validation documentation still says switching is impossible and the certificate must be recreated. Check the page's update time and the new migration entry point during implementation; do not mistake an old restriction for the current rule.

Record the deadlines separately: new email-validated issuance stops on March 31, 2027, and renewal of existing email-validated certificates stops on September 30, 2027. The CA/B Forum industry deadline is March 15, 2028. ACM users should base their execution plan on the first two AWS dates.

An unchanged ARN does not mean zero risk

The in-place switch neither reissues the certificate nor changes its existing ARN, so integrations referencing that ARN generally continue to work. The current certificate continues operating normally with email validation during the migration window.

Risk shifts to DNS ownership, complete records for every SAN and subsequent renewal. Incorrectly deleting or changing CNAMEs, placing them in a private hosted zone, omitting a domain or letting the DNS provider append the domain twice can prevent validation or future automatic renewal.

Seven migration steps, from inventory to completion

First, export the Amazon Issued, Email certificate inventory by account and Region. Second, record the ARN, domains, SANs, expiry date, attached resources and DNS owner. Third, batch by approaching expiry and business criticality. Fourth, trigger Update validation method. Fifth, download or read every domain's CNAME. Sixth, publish it in public DNS and check resolution. Seventh, wait for all domains to validate, then record certificate status, renewal ownership and change evidence in the register.

Start with a small, low-risk batch. Do not change certificate attachments, DNS hosting provider and validation method simultaneously. Route 53 can create records through the console. For third-party DNS, first check whether the Name field automatically appends the zone, to avoid creating example.com.example.com.

The 72-hour window and stop conditions

AWS allows up to 72 hours to publish the CNAMEs. If DNS is incomplete when the window expires, the certificate retains its existing email validation and the migration can be retried. This is neither migration success nor immediate certificate invalidation.

Stop expanding the batch if the SAN list is incomplete, public-DNS write access is missing, CAA or delegation is abnormal, or critical domains return inconsistent resolution results. Keep existing certificate attachments, repair the records and validate again. Do not delete a certificate still serving traffic or request a new ARN without completed attachment verification just to meet the window.

Acceptance checks, limitations and common mistakes

Acceptance should verify at least: unchanged ARN; a correct CNAME for every domain; visibility through public recursive resolvers; completed validation; normal business TLS handshakes; unchanged attached resources; and renewal monitoring plus protection against accidental DNS-record deletion. Automatic renewal with DNS validation still requires the certificate to be in use in a way eligible for ACM managed renewal, with the CNAME retained long term.

Common mistakes include treating an unchanged ARN as a reason to skip testing, interpreting 72 hours as the certificate's remaining lifetime, validating only the primary domain and missing SANs, writing records in a private zone, or reissuing and replacing every integration solely because older documentation says so.

Separate DNS, permission and proxy problems

For AccessDenied from UpdateCertificateOptions, check IAM first. If the CNAME is absent from public DNS, check authoritative DNS, the zone and the record name. If validation remains pending, check every SAN, CAA and the resolution chain. Only when AWS API requests show DNS, TLS, timeout or proxy-authentication evidence should you use the proxy connection troubleshooting checklist for the network layer.

A fixed egress can improve the stability of operational access. Visit the PuppyIP website to learn about related services. It cannot create DNS records, grant IAM permissions or replace certificate-renewal acceptance checks.

Sources

Frequently Asked Questions

Will the ACM certificate ARN change after migration?

No. AWS explicitly describes an in-place switch without reissuance, retaining the existing ARN.

Will the production certificate immediately become invalid if the CNAMEs are not ready within 72 hours?

No. The current certificate continues using email validation, and you can retry after correcting DNS. Still complete the migration before AWS stops renewal.

Can every ACM certificate migrate this way?

No. First restrict the scope to ACM-issued, email-validated public certificates. Imported and private CA certificates are not eligible.

Is adding only the primary domain's CNAME enough?

Not necessarily. Check every domain and SAN in the certificate and publish the complete records returned by ACM.

When must migration be completed?

ACM will stop renewing existing email-validated certificates on September 30, 2027. Complete batches in advance according to expiry dates and business risk.

Can changing proxies resolve Pending validation?

Usually not. First verify public DNS records, the domain list, CAA, IAM and migration status. Check the proxy only when API network requests fail.