SSL/TLS Certificates for Beginners: AWS
What is a certificate, and why do I need one?
A certificate is a digital ID card for a website or service. When you open https://mybank.com, your browser asks the site, “Prove you are really mybank.com.” The site answers with its certificate, and that lets two things happen:
• Identity. The browser confirms it is talking to the real site, not an imposter.
• Encryption. The certificate carries a public key, which sets up an encrypted connection (TLS) so nobody in the middle can read or change the traffic.
That is the padlock in the address bar. Without a valid certificate, browsers show a scary warning page and most API clients refuse to connect.
Who vouches for the certificate?
Anyone can create a certificate that says “I am mybank.com.” So the browser only believes certificates signed by a Certificate Authority (CA) it already trusts.
Think of a passport. You can’t print your own and expect border control to accept it. They accept passports issued by governments they recognize. A CA is the government in this picture, and your certificate is the passport.
There are two kinds of CA, and this is the whole topic in one sentence:
• Public CA: trusted by every browser and device automatically. Use it for things the whole internet visits.
• Private CA: a CA you run yourself. Only devices you configure to trust it will accept its certificates. Use it for things only your own systems talk to.
AWS gives you one service for each: AWS Certificate Manager (ACM) for public certificates and AWS Private CA for private ones.
AWS ACM: public certificates made easy
ACM issues public certificates that every browser trusts, and the default ones, used with integrated AWS services, are free. You don’t generate keys, manage files or schedule renewals by hand.
How you get one:
1. In the ACM console (or with the CLI or Terraform), request a public certificate for your domain, for example www.example.com or *.example.com.
2. Prove you own the domain. The easiest way is DNS validation: ACM gives you a CNAME record, you add it to your DNS zone (one click if the zone is in Route 53), and ACM sees it and issues the certificate.
3. Attach the certificate to an integrated service, such as an Application Load Balancer, CloudFront or API Gateway.
Why beginners love it: as long as the validation CNAME stays in DNS, ACM renews the certificate automatically before it expires. No more 2 a.m. expiry outages.
Good to know:
• By default, ACM public certificates are non-exportable: you can’t download the private key, so they work only with integrated services such as ALB, CloudFront and API Gateway. Since June 2025 you can instead mark a new certificate as exportable when you request it, which lets you use it on EC2, containers or on-premises servers. Exportable certificates carry a per-certificate fee and have a shorter validity period, and you must deploy and renew them yourself, so check the ACM pricing page and docs first. Certificates issued before that launch can’t be exported.
Get Rajesh Gundeti’s stories in your inbox
Join Medium for free to get updates from this writer.
• Certificates used by CloudFront must be requested in the us-east-1 region; load balancers use a certificate in their own region.
• The domain name must be publicly registered, and the certificate will appear in public Certificate Transparency logs.
AWS Private CA: your own certificate authority
Suppose you have internal services such as orders.internal.example.com, containers talking to each other, or employee laptops connecting to a private VPN. You don’t need the whole internet to trust them, only your own machines. AWS Private CA lets you run your own CA without building and securing the servers yourself.
How it works:
1. Create a root CA in AWS Private CA. This is the top of your trust chain, so you keep it locked down.
2. Create a subordinate CA under the root for everyday issuing. If it is ever compromised, you replace it without throwing away the root.
3. Issue certificates from the subordinate CA. You can request them through ACM (so AWS can attach and renew them on integrated services), OR use the Private CA API for servers, containers and devices.
4. Make your clients trust the root. Install the root certificate on the laptops, servers or container images that need to connect. This step is the one beginners forget.
The trade-offs are real. Unlike public ACM certificates, a Private CA is a paid service: you pay a monthly fee for each CA, plus a charge for each private certificate issued. Check current pricing on the AWS Private CA page before you design anything large. You are also the one deciding who can issue certificates, so set IAM permissions carefully and enable audit logging.
In return you get freedom: private hostnames, short lifetimes, certificates for mutual TLS (where both sides prove who they are), and no exposure of internal names in public logs.
Which one should I pick?
Ask one question: who needs to trust this certificate? If it is anyone outside your control, use ACM. If only your own systems, consider Private CA.
Common beginner mistakes
• Using a private certificate on a public website. Visitors will see a browser warning because their devices don’t trust your CA.
• Creating a Private CA but never installing its root certificate on clients.
• Deleting the DNS validation record, which stops ACM auto-renewal.
• Requesting a CloudFront certificate in the wrong region (it must be us-east-1).
• Creating a Private CA for a single internal app when a public certificate on an internal load balancer would have been simpler and cheaper.
Wrap-up and next steps
A certificate is an ID card, and a CA is the authority that vouches for it. ACM gives you public certificates the whole internet trusts, with free issuance and automatic renewal. AWS Private CA gives you your own authority for internal systems, which you must teach your clients to trust.
To practice, request a free ACM certificate for a test domain with DNS validation and attach it to an Application Load Balancer. Once that feels easy, build a small root and subordinate CA in a sandbox account, issue one certificate, and watch a client reject it until you install the root.
