- Key Takeaways
- What Is an SSL Certificate?
- What Is a TLS Certificate?
- How to Get a Free SSL Certificate for an AWS-Hosted Site
- Benefits and Limits of ACM's Free Certificates
- Why This Matters for Enterprise Certificate Lifecycle Management
- Expert Take: Where ACM's Automation Actually Stops
- Owner/Action Matrix: Who Does What
- Quick Checklist Before You Deploy
- Handling This in Multi-Cloud or Hybrid PKI Environments
- What to Do Next
- Encryption Consulting's AWS Consulting, Managed PKI, and Certificate Lifecycle Management
- Conclusion
- Frequently Asked Questions
Quick answer: AWS gives you a free public SSL/TLS certificate through AWS Certificate Manager (ACM) for any domain you own, as long as you attach it to an ACM-integrated resource such as an Elastic Load Balancer, CloudFront distribution, or API Gateway. ACM cannot issue a certificate for a bare EC2 instance with no supporting AWS resource, and it handles renewal automatically only while the certificate stays attached to that resource. The certificate itself never expires, but validation can, and manual tracking of validation and attachment is where most AWS-hosted sites still see outages.
Key Takeaways
- AWS Certificate Manager issues free public SSL/TLS certificates for domains you control, but only for use with ACM-integrated services like ELB, CloudFront, and API Gateway, not for a standalone EC2 instance.
- ACM-issued certificates auto-renew as long as the certificate stays attached to a supported resource and DNS validation records remain in place; detach the resource or let DNS drift and renewal silently fails.
- 45% of enterprises reported service downtime from certificate-related incidents in the past year, and 37.5% of those outages traced back to expired certificates, according to DigiCert’s July 2025 Trust Pulse Survey.
- The CA/Browser Forum’s Ballot SC-081v3 is cutting maximum public TLS certificate validity from 398 days to 200 days (March 2026), 100 days (March 2027), and 47 days (March 2029), which will affect certificates you issue for any custom domains you point at AWS resources.
- ACM’s automation covers only what sits inside AWS. Multi-cloud and hybrid environments still need a vendor-neutral certificate lifecycle management (CLM) platform to avoid the manual gaps ACM alone leaves behind.
This guide covers what SSL and TLS certificates are, how to get a free public certificate for an AWS-hosted site through AWS Certificate Manager, where ACM’s automation stops, and what PKI, security, platform, and compliance teams each need to do to keep certificates from becoming an outage.
What Is an SSL Certificate?
An SSL certificate is a digital certificate that proves a website or server owns a specific public key, letting a browser encrypt data before sending it and confirm it is talking to the real server rather than an impostor. SSL stands for Secure Sockets Layer, the original protocol for encrypting data in transit between a browser and a server, or between two servers exchanging sensitive data such as payment or personal information. The certificate itself is the credential; the encrypted connection it enables is what actually protects the data.
What Is a TLS Certificate?
TLS (Transport Layer Security) is the modern, more secure successor to SSL, and “TLS certificate” and “SSL certificate” now refer to the same type of credential in everyday use, even though the underlying protocol is TLS. A TLS certificate is built on Public Key Infrastructure (PKI) and typically contains:
- The subject domain name
- The subject organization (for organization- or extended-validation certificates)
- The name of the issuing Certificate Authority (CA)
- Additional or alternative domain names, including subdomains, if any
- Issue date and expiry date
- The public key (the private key is never included and must stay secret)
- The CA’s digital signature
TLS uses a combination of asymmetric cryptography (to establish trust and exchange keys) and symmetric cryptography (to encrypt the actual session data), which balances security against performance. For a deeper walkthrough of how the handshake works and where SSL, TLS, and HTTPS diverge, see EC’s SSL, TLS, and HTTPS guide.
How to Get a Free SSL Certificate for an AWS-Hosted Site
AWS Certificate Manager issues free public certificates for any domain you own, provided you attach the certificate to an ACM-integrated resource. You need a domain you control and one of the following: an Application Load Balancer, Network Load Balancer, Amazon CloudFront distribution, or API Gateway custom domain. A single ACM certificate can cover up to 10 domain names, including subdomains and wildcards, and AWS will not let you edit a certificate’s domain list after issuance, so you create a new certificate rather than modify an existing one.
Prerequisites Before You Start
You need an app or website hosted on AWS with a dedicated port and full control over that resource. The application platform underneath (Node.js, Django, PHP, and so on) does not matter to ACM, only the AWS resource in front of it does.
Steps to Get a Free SSL Certificate on AWS
Step 1: Set Up an Amazon EC2 Instance
- Log in to the AWS console, open the “EC2” service, and click “Launch Instance” to create a new instance.
- Choose an Amazon Machine Image (AMI) for the operating system the instance will run.
- Select the RAM, processing power, size, and instance type, or accept the default settings.
- Click “Launch,” then create or select a key pair. Download the .pem file and store it somewhere accessible on your machine.
- Change directory to the .pem file’s location in your terminal, connect to the instance, and deploy your application code.
Step 2: Set Up Your AWS Elastic IP Address
Allocate an Elastic IP so your instance has a stable public address, then associate it with your EC2 instance from the Elastic IPs panel. Edit the instance’s security group to allow inbound traffic on the port your application uses. At this point your site is reachable over plain HTTP at that IP address, but not yet encrypted.
Step 3: Request and Attach a Free Certificate in AWS Certificate Manager
An EC2 instance alone cannot terminate an ACM certificate directly; you attach the certificate to an Application Load Balancer, CloudFront distribution, or API Gateway in front of the instance. With that resource in place:
- Search for “AWS Certificate Manager” from the AWS console, under “Security, Identity & Compliance.”
- Click “Request a certificate” and choose “Request a public certificate.”
- Add your domain names. Include both the root domain and the “www” version if you need both covered, up to 10 names per certificate.
- Choose your validation method. DNS validation is faster and renews automatically as long as the validation record stays in your DNS zone; email validation requires manual action from an address on file for the domain and does not support automatic renewal reminders as reliably.
- Add optional tags for certificate management, then review and confirm the request.
- Once validation completes, attach the certificate to your load balancer’s HTTPS listener, your CloudFront distribution, or your API Gateway custom domain.
DNS validation is the method to choose whenever you have access to the domain’s DNS zone, because it is what allows ACM to renew the certificate automatically for as long as the CNAME record and the attached resource both remain in place.
Benefits and Limits of ACM’s Free Certificates
ACM’s free public certificates give AWS-hosted sites the core benefits of any trusted TLS certificate, with the specific advantage of built-in renewal automation as long as the certificate stays attached to a supported resource:
-
Encrypted traffic and secondary authentication
HTTPS shows visitors your site has a valid certificate and protects data in transit. It works alongside broader Public Key Infrastructure (PKI) controls to ensure information reaches only the intended server.
-
Domain authentication
A valid certificate confirms the browser is connecting to the domain it expects, reducing the risk of traffic being silently redirected to an impostor server.
-
Customer trust signals
Visitors entering sensitive information are more likely to trust a site showing the padlock and a valid certificate chain.
-
Automatic renewal, conditionally
ACM renews DNS-validated certificates automatically, but only while the certificate remains attached to a supported AWS resource and the validation CNAME stays in your DNS zone. Detach the resource, migrate DNS providers, or let a validation record get cleaned up, and the renewal silently stops.
-
Regulatory baseline for PCI DSS
PCI DSS requires strong encryption on any page collecting cardholder data. A properly deployed and maintained certificate is a baseline control, not the entire compliance picture.
The limitation enterprises run into is not the certificate itself but everything ACM does not cover: certificates for services outside AWS, private/internal PKI, code signing, or SSH key management. For a full breakdown of where ACM’s automation stops for larger or multi-cloud environments, see EC’s AWS Certificate Manager Limitations guide. For the complete category, see the Education Center’s SSL/TLS certificates explainer.
Why This Matters for Enterprise Certificate Lifecycle Management
A single AWS-hosted site with one ACM certificate is low risk. The risk shows up at scale, when an organization has hundreds or thousands of certificates spread across AWS, other clouds, and on-premises infrastructure, and ACM’s automation only reaches the fraction that lives inside AWS and stays attached to a supported resource.
DigiCert’s July 2025 Trust Pulse Survey found that 45% of enterprises experienced service downtime from certificate-related incidents in the past year, and 37.5% of those outages were caused specifically by expired certificates, one of the most preventable failure modes in the entire category. The same survey found 60% of organizations manage between 1,000 and 10,000 certificates, and roughly half of those that suffered a certificate-related incident reported financial losses starting at $50,000. (Source: DigiCert Trust Pulse Survey, July 2, 2025.)
That volume of certificates, combined with shrinking validity windows, is what turns “just renew it when it expires” into an operational liability. The CA/Browser Forum’s Ballot SC-081v3 is phasing the maximum public TLS certificate validity down from 398 days to 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. (Source: Sectigo, April 14, 2025.) ACM-issued certificates that stay attached to a supported resource ride this change out automatically. Certificates issued outside ACM, or ACM certificates whose resource gets migrated or decommissioned without anyone updating the certificate inventory, do not.
This is where 47-day TLS certificate readiness stops being a future problem and becomes a present one: a manual renewal process that was merely annoying at 398 days becomes unworkable at 47 days, because the same certificate now needs to be issued, validated, and deployed seven to eight times a year instead of roughly once.
Expert Take: Where ACM’s Automation Actually Stops
ACM is genuinely good at what it is built for: free, auto-renewing public certificates for AWS-native resources. The mistake we see enterprise teams make is treating ACM as their certificate lifecycle management (CLM) strategy rather than one component of it. ACM has no visibility into certificates issued by other CAs, no cross-cloud inventory, no support for private/internal PKI at enterprise scale, and no mechanism to alert you when a certificate is orphaned because its underlying resource was deleted. Those gaps do not show up in a demo. They show up eighteen months later as an unplanned outage, usually right after a reorg or a migration that nobody remembered to check against the certificate inventory.
Our recommendation for any team running AWS alongside other clouds or on-premises PKI: use ACM for what it is good at, and put a vendor-neutral certificate lifecycle management platform in front of the whole estate for discovery, alerting, and renewal orchestration that ACM cannot see.
Owner/Action Matrix: Who Does What
Free ACM certificates touch more teams than the one that clicked “Request a certificate.” Use this matrix to assign ownership before your next AWS deployment, not after an outage.
| Use Case | Recommendation | Operational Owner | Expected Outcome |
|---|---|---|---|
| Single AWS-hosted site behind an ALB or CloudFront | Use ACM with DNS validation for automatic renewal | Platform / DevOps team | Certificate renews without manual intervention as long as the resource and DNS record are unchanged |
| Certificate for a resource outside ACM’s supported list (bare EC2, on-prem server) | Issue via a CLM platform or public CA with automated renewal, not ACM | PKI team | Renewal tracked centrally instead of relying on manual calendar reminders |
| Multi-cloud or hybrid environment (AWS plus Azure/GCP/on-prem) | Deploy a vendor-neutral CLM platform for unified discovery and renewal across all environments | Security / PKI team | Single inventory and alerting layer instead of per-cloud blind spots |
| Resource decommissioning or migration involving an ACM certificate | Update the certificate inventory and reassign or revoke the certificate as part of the migration runbook | Platform team, with security sign-off | No orphaned or forgotten certificates left attached to decommissioned infrastructure |
| Preparing for the 47-day certificate validity mandate | Audit current renewal processes now and move manual workflows to automation before March 2027 | Compliance / PKI team | Renewal cadence that survives seven to eight issuances a year without added headcount |
Quick Checklist Before You Deploy
- Confirm the AWS resource in front of your site (ALB, CloudFront, or API Gateway) actually supports ACM certificate attachment before you request one.
- Use DNS validation, not email validation, wherever you control the domain’s DNS zone.
- Record which resource each ACM certificate is attached to in your certificate inventory, not just in the AWS console.
- Add a step to every decommissioning or migration runbook that checks for attached certificates before deleting the resource.
- If you operate outside AWS as well, confirm who owns certificate discovery and renewal for those environments, since ACM will not see them.
- Revisit your renewal process against the 200-day (2026), 100-day (2027), and 47-day (2029) validity milestones, not just today’s requirements.
Handling This in Multi-Cloud or Hybrid PKI Environments
ACM’s automation is scoped to AWS. Once certificates need to cover Azure, Google Cloud, on-premises servers, or a private internal CA, treat ACM as one issuance source among several rather than the system of record. Standardize on a CLM platform that can discover certificates across every cloud and on-prem environment, correlate them against a single inventory, and alert on upcoming expirations regardless of which CA issued them. This also matters for post-quantum cryptography readiness: an accurate cross-cloud certificate and algorithm inventory is the starting point for any PQC readiness plan, since you cannot migrate algorithms you have not accounted for. EC’s CBOM Secure platform builds that inventory across certificates, keys, and algorithms in one pass; see from discovery to action: turning a CBOM into intelligence for how that inventory becomes a prioritized remediation plan rather than a static spreadsheet.
What to Do Next
The right next step depends on which team you are on:
- PKI teams: Confirm every ACM certificate is mapped to its attached resource in your central certificate inventory, and flag any certificate issued outside ACM for the same domains.
- Security teams: Add certificate checks to decommissioning and migration runbooks so a deleted resource cannot leave an orphaned, unmonitored certificate behind.
- Platform teams: Standardize on DNS validation for new ACM requests and document which resources are ACM-eligible before the next deployment.
- Compliance teams: Build the 200-day, 100-day, and 47-day validity milestones into your audit calendar now, rather than reacting when the next phase takes effect.
Encryption Consulting’s AWS Consulting, Managed PKI, and Certificate Lifecycle Management
Encryption Consulting LLC (EC) helps organizations run PKI across on-premises, cloud, and hybrid environments without taking on the full operational burden of managing it internally. Alongside AWS consulting and managed PKI, EC’s CertSecure Manager platform gives security and platform teams a single, vendor-neutral view of every certificate across AWS, other clouds, and on-prem infrastructure, with automated discovery, renewal, and alerting that ACM alone cannot provide outside its own ecosystem.
EC deploys and supports PKI using documented, audited processes. Admin rights to your Active Directory are never required, and control over your PKI and its associated business processes always remains with you. CA keys are held in FIPS 140-2 Level 3 HSMs, hosted either in your secure data center or in EC’s data center in Dallas, Texas.
Conclusion
AWS Certificate Manager makes it genuinely simple to get a free, auto-renewing SSL/TLS certificate for anything sitting behind an ACM-supported resource, and for a single site that is often all you need. The gap opens up at enterprise scale and across multiple clouds, where ACM’s automation cannot follow. Encryption Consulting’s AWS consulting, certificate management, PKI-as-a-Service, and managed PKI let you keep the benefits of a well-run PKI, including readiness for the 47-day certificate validity mandate, without carrying the full operational load of tracking every certificate manually.
Frequently Asked Questions
What is the main takeaway from “How to Get a Free SSL Certificate for AWS Hosted Websites?”
AWS Certificate Manager provides free, auto-renewing public SSL/TLS certificates for domains attached to ACM-integrated resources such as load balancers, CloudFront, and API Gateway. The automation only holds as long as the certificate stays attached to that resource and its DNS validation record remains in place; it does not extend to certificates outside AWS or to resources ACM does not support.
Why does this matter for enterprise certificate lifecycle management?
At enterprise scale, certificates rarely live in a single cloud. ACM’s renewal automation is scoped to AWS, so any certificate issued elsewhere, or any ACM certificate detached from its resource during a migration, falls outside ACM’s visibility. DigiCert’s 2025 Trust Pulse Survey found 45% of enterprises experienced certificate-related downtime in the past year, which is exactly the risk a fragmented, per-cloud approach creates.
What teams are responsible for acting on this guidance?
Platform or DevOps teams typically own the initial ACM request and resource attachment. PKI and security teams own the cross-environment certificate inventory and renewal monitoring. Compliance teams own tracking the CA/Browser Forum validity milestones against internal audit and renewal calendars. All four need visibility into the same certificate inventory to avoid gaps at handoff points.
What risks increase if this topic is handled manually?
Manual tracking increases the risk of expired-certificate outages, the single most preventable cause identified in DigiCert’s 2025 survey at 37.5% of reported incidents. It also increases the risk of orphaned certificates left attached to decommissioned resources, missed validation record cleanup during DNS migrations, and compliance findings when auditors cannot confirm which certificates are active across environments.
How does automation reduce certificate outage risk?
Automation removes the dependency on a person remembering a renewal date. Within AWS, ACM’s DNS-validated auto-renewal already does this for supported resources. Across a multi-cloud or hybrid estate, a certificate lifecycle management platform extends the same principle: continuous discovery, expiration alerting, and automated reissuance across every environment, not just the one automation happens to cover natively.
What metrics should teams track after implementation?
Track total certificate count and where each is issued and hosted, the percentage covered by automated renewal versus manual tracking, count of certificates within 30 days of expiry at any given time, count of orphaned or unattached certificates, and any certificate-related downtime incidents over a rolling 12-month window.
How does this connect to 47-day TLS certificate readiness?
The CA/Browser Forum’s Ballot SC-081v3 cuts maximum public TLS certificate validity to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. ACM certificates that stay attached to a supported resource with DNS validation ride out these changes automatically. Certificates managed manually, inside or outside AWS, will need to be issued and deployed seven to eight times a year once the 47-day maximum takes effect, which is not sustainable without automation.
How should this be handled in multi-cloud or hybrid PKI environments?
Use ACM for AWS-native resources where its free issuance and automatic renewal apply, but do not rely on it as the certificate inventory for the whole organization. Deploy a vendor-neutral CLM platform that can discover and manage certificates across AWS, other clouds, and on-premises PKI from a single pane, so renewal and compliance tracking do not depend on which cloud issued a given certificate.
- Key Takeaways
- What Is an SSL Certificate?
- What Is a TLS Certificate?
- How to Get a Free SSL Certificate for an AWS-Hosted Site
- Benefits and Limits of ACM's Free Certificates
- Why This Matters for Enterprise Certificate Lifecycle Management
- Expert Take: Where ACM's Automation Actually Stops
- Owner/Action Matrix: Who Does What
- Quick Checklist Before You Deploy
- Handling This in Multi-Cloud or Hybrid PKI Environments
- What to Do Next
- Encryption Consulting's AWS Consulting, Managed PKI, and Certificate Lifecycle Management
- Conclusion
- Frequently Asked Questions
- What is the main takeaway from "How to Get a Free SSL Certificate for AWS Hosted Websites?"
- Why does this matter for enterprise certificate lifecycle management?
- What teams are responsible for acting on this guidance?
- What risks increase if this topic is handled manually?
- How does automation reduce certificate outage risk?
- What metrics should teams track after implementation?
- How does this connect to 47-day TLS certificate readiness?
- How should this be handled in multi-cloud or hybrid PKI environments?
