Securing a public application with HTTPS is not complete when a certificate request shows “Issued.” The certificate must match the hostname clients use, be attached to the service that terminates TLS, and remain valid through a renewal that reaches the actual endpoint. AWS Certificate Manager (ACM) manages important parts of this process for supported AWS services, but administrators still control domain validation, permissions, listener configuration and production testing. This guide follows those decisions from requesting a certificate through confirming that users receive the correct one.
Choose the certificate and TLS termination point first
Start with the traffic path. An internet-facing application might terminate HTTPS at an Application Load Balancer, at an Amazon CloudFront distribution, or at an Amazon API Gateway custom domain. In each case the client sees a certificate at that front-end endpoint. Issuing a certificate somewhere in an AWS account does not connect it to every service automatically, and securing the browser-to-edge hop does not necessarily encrypt the hop from the edge or load balancer to the application.
For a public website that uses a supported integrated service, a public ACM-issued certificate is usually the simplest choice. The service can select and deploy the certificate without exposing its private key to an EC2 instance operator. A privately trusted application inside an organization may instead need certificates issued under AWS Private Certificate Authority, with its own trust distribution and charges. If the private key must run on infrastructure outside an integrated AWS endpoint, examine ACM exportable public certificates or a supported ACME workflow rather than assuming every managed public certificate can be copied to a server.
Write down the exact requested hostnames before opening the request form. A certificate for www.example.com does not automatically cover example.com. A wildcard such as *.example.com covers a single subdomain level, not the apex domain or nested names such as api.dev.example.com. Include the appropriate names explicitly as subject alternative names, and review who is authorized to request certificates for sensitive production domains.
Request a public certificate and complete domain validation
Open AWS Certificate Manager in the Region required by the destination service. Choose to request a public certificate, enter the fully qualified domain names, and select a suitable validation method. DNS validation is a strong default for domain names the team administers because the validation records can remain in place for later renewals. Domain ownership is not established simply because the DNS zone exists inside the same AWS account; the validation record must be visible at the authoritative DNS location for the name.
For DNS validation, ACM supplies a CNAME record for each applicable domain name. Copy the record name and value exactly into the authoritative DNS zone, whether that zone is hosted in Route 53 or with another provider. Check whether the DNS console automatically appends the zone name to record labels; an accidentally doubled suffix is a common source of delays. Do not replace the ACM validation CNAME with an A record pointing at the load balancer. The validation record proves domain control, while the application routing record sends clients to the endpoint.
After the records propagate, inspect the ACM certificate status and the validation status for all names. A request can remain pending because of a missing name, an incorrect CNAME, inaccessible authoritative DNS, or limits affecting the request. Do not attach an unissued certificate to a production change plan. Record the certificate ARN, the domain names, the AWS Region and the application that will consume it, then keep validation DNS entries in place when the chosen managed-renewal method requires them.
Deploy the certificate on an Application Load Balancer
An Application Load Balancer terminates the client TLS connection using an HTTPS listener. Create or edit a listener, commonly on port 443, select a TLS security policy, choose the issued ACM certificate in the load balancer’s Region, and forward requests to the intended target group. A load balancer needs a default server certificate for its secure listener. When several hostnames share one listener, you can supply additional compatible certificates and use Server Name Indication to present an appropriate certificate to modern clients.
Certificate selection and application reachability are separate tests. Confirm the public DNS name resolves to the intended load balancer, the listener receives traffic on its configured port, and security groups and routing permit the required connections. The backend target group must have healthy targets and an application path that responds. A valid certificate cannot correct an unhealthy target, an incorrect listener rule, or an HTTP-to-HTTPS redirect loop.
Decide whether the connection from the load balancer to the backend may be HTTP or must be HTTPS under the workload’s security requirements. If back-end encryption is required, configure and test a suitable HTTPS target group and server certificates for that connection separately; ACM certificate deployment on the front end is not evidence of end-to-end encryption. Keep the chosen listener and target-group settings in infrastructure-as-code or an equivalent change record so renewals and replacements are not dependent on somebody remembering console clicks.
Account for CloudFront and API Gateway differences
CloudFront presents a certificate to viewers at the edge. An ACM certificate used for the viewer-facing custom domain must be requested or imported in us-east-1, even if the application’s origins run in other Regions. Configure the distribution’s alternate domain names, select the certificate, and check that the DNS alias and distribution settings agree. This is different from a regional Application Load Balancer certificate. The CloudFront delivery path also has its own origin TLS settings, which should be verified separately from the viewer certificate.
API Gateway custom domains likewise require a certificate compatible with the configured endpoint type and Region. First decide whether the API uses an applicable regional or edge-optimized endpoint, then associate the correct ACM certificate and API mapping. Test the hostname and mapping together: a certificate may validate successfully while the API still returns a route or authorization error. For either service, check that the attached certificate covers the exact name requested by the client instead of relying on the certificate’s presence in the AWS console.
Document the place where TLS terminates for every public hostname. In a multi-environment account it is possible to have two valid certificates for the same name, yet only one is attached to the live listener or distribution. Your inventory should map the hostname to the endpoint, certificate ARN, Region, validation method, owner, and renewal process. This small record is more useful during an incident than a list of unrelated certificates sorted only by creation date.
Plan for the 2026 validity and renewal changes
ACM public certificates issued under the February 18, 2026 validity change are valid for 198 days, replacing the older 395-day period. ACM ordinarily begins the managed-renewal process 45 days before expiration for 198-day public certificates. Previously issued 395-day public certificates have different timing during transition, so check the certificate’s actual dates rather than assuming every certificate in the account shares one schedule. The shortened lifetime makes reliable validation records and a tested deployment path more important than a once-a-year manual checklist.
Managed renewal is conditional, not a promise that every certificate will renew regardless of configuration. For DNS-validated integrated certificates, ACM checks that the certificate remains in qualifying use and that the required validation CNAME records can be resolved from public DNS. Removing a CNAME during a DNS migration or leaving a certificate unattached can interfere with the process. Email-validated certificates may require domain-owner action; use the renewal status and AWS notifications to distinguish automated progress from manual requirements.
Set an operational rule for failures: the responsible team should investigate renewal warnings well before expiration, check authoritative DNS, examine the associated service, and record the corrective action. Use AWS Health and EventBridge events where supported, and incorporate certificate state into existing monitoring. CloudWatch can help correlate application availability and load-balancer symptoms, but service health metrics alone do not prove which certificate a client is receiving. Test the presented TLS certificate independently.
Distinguish imported, exportable and private certificates
An imported third-party certificate can be attached to compatible ACM-integrated services, but ACM does not perform managed renewal of imported certificates. The owner must obtain a replacement from the issuer, validate the certificate chain and private key, and reimport or attach the replacement through a controlled procedure. When reimporting into the existing certificate resource is supported, the ARN and service association can be preserved; verify the actual behavior and expiration date rather than assuming that an import action has completed all operational checks.
Exportable ACM public certificates are a different product choice. Exporting the key and certificate gives the operator a deployment responsibility outside the integrated service: protect the private key, arrange renewal delivery, install updated material on the consuming server, and test the resulting endpoint. Issuance or renewal of exportable public certificates can incur separate charges. AWS Private CA is intended for private trust use cases and involves managing the client trust relationship and applicable private-CA costs; a private certificate is not automatically trusted by public browsers.
Certificate permissions should be least-privileged. Separate the people who can request certificates, validate sensitive domain ownership, export a private key, and alter production listeners. An IAM policy that limits certificate access and endpoint updates helps make unauthorized replacement less likely, but it needs verification against the exact actions and services in use. Do not place exported keys in chat transcripts, source repositories, build logs or broad shared storage.
Verify the served certificate and prepare recovery
After deployment, test the public hostname from outside the application network with a client that sends the expected Server Name Indication. Inspect the served certificate’s subject alternative names, issuer, validity dates and chain, then confirm that the requested hostname is covered. Follow HTTP redirects and verify that the final application endpoint responds over HTTPS. A browser padlock by itself is not proof that target health, redirect rules, API authorization or the backend security boundary are configured as intended.
Run a negative test before signing off. Try a hostname that should not match the certificate, a deliberately unauthorized path on a nonproduction endpoint, and a simulated renewal or replacement in an isolated environment. The goal is to confirm how the team will recognize incorrect certificate selection, expired material, missing DNS validation and application outage. Record how to restore the previous listener association or deploy an approved replacement without changing unrelated DNS records or production routing.
For the change record, keep the certificate ARN, domain list, endpoint type, AWS Region, validation CNAME ownership, renewal event routing, private-key handling where relevant, and the date of the last observed live TLS check. That evidence closes the gap between “ACM issued a certificate” and “the application is reliably serving a valid certificate.” Certificate management becomes dependable when domain validation, deployment, monitoring and recovery are verified as one operational process.