AWS Certificate Manager (ACM)

Managing SSL/TLS Certificates for Secure Applications

What is AWS Certificate Manager?

AWS Certificate Manager (ACM) is a service that lets you easily provision, manage, and deploy public and private SSL/TLS certificates for use with AWS services and your internal connected resources.

Key Features

  • Free public certificates for AWS services
  • Automatic certificate renewal
  • Easy deployment to integrated services
  • Centralized certificate management
  • Private certificate authority option
  • Certificate import capability
  • Wildcard certificate support

Certificate Types

Public Certificates

Issued by a trusted public certificate authority (CA) and used for public-facing websites and applications.

  • Free with ACM when used with AWS services
  • Issued by Amazon Trust Services
  • Automatic renewal
  • Domain validation required
  • Wildcard and multi-domain support

Private Certificates

Issued by AWS Private Certificate Authority (PCA) for internal resources and applications.

  • Complete control over your certificate authority
  • Ideal for internal applications
  • Integration with AWS services
  • Managed certificate revocation
  • Additional fees apply

Certificate Lifecycle

┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐
│                   │     │                   │     │                   │     │                   │
│  Request          │────▶│  Validate         │────▶│  Issue            │────▶│  Deploy           │
│  Certificate      │     │  Domain Ownership │     │  Certificate      │     │  Certificate      │
│                   │     │                   │     │                   │     │                   │
└───────────────────┘     └───────────────────┘     └───────────────────┘     └───────────────────┘
                                                                                       │
                                                                                       │
                                                                                       ▼
┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐     ┌───────────────────┐
│                   │     │                   │     │                   │     │                   │
│  Revoke           │◀────│  Monitor          │◀────│  Renew            │◀────│  Use              │
│  (if needed)      │     │  Certificate      │     │  Certificate      │     │  Certificate      │
│                   │     │                   │     │                   │     │                   │
└───────────────────┘     └───────────────────┘     └───────────────────┘     └───────────────────┘

Request & Validation

  • Request certificate in ACM console or API
  • Specify domain names
  • Choose validation method:
    • DNS validation (recommended)
    • Email validation
  • Complete validation process

Issuance & Deployment

  • Certificate issued after validation
  • Deploy to supported AWS services:
    • Elastic Load Balancing
    • CloudFront
    • API Gateway
    • And more
  • No manual certificate installation

Renewal & Management

  • Automatic renewal for ACM-issued certificates
  • 60-day renewal window
  • Managed certificate rotation
  • Expiration notifications
  • Certificate tagging
  • Revocation if needed

Key Terminology

Term Definition
SSL/TLS Secure Sockets Layer/Transport Layer Security - Protocols for establishing authenticated and encrypted links between networked computers
Certificate Authority (CA) An entity that issues digital certificates that verify a digital entity's identity on the internet
Public Key Infrastructure (PKI) A framework for managing digital certificates and public key encryption
Domain Validation (DV) Verification that the certificate applicant controls the domain name in the certificate request
Server Name Indication (SNI) An extension to TLS that allows a server to host multiple SSL certificates for different domains on the same IP address
Subject Alternative Name (SAN) An extension to X.509 that allows multiple domain names to be protected by a single SSL certificate
Wildcard Certificate A certificate that secures a domain and all its first-level subdomains (e.g., *.example.com)

SSL/TLS Overview

What is SSL/TLS?

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols designed to provide secure communication over a computer network.

  • Encrypts data in transit
  • Authenticates the server (and optionally the client)
  • Ensures data integrity
  • Prevents eavesdropping and tampering

SSL vs TLS

SSL TLS
Developed by Netscape Developed by IETF
SSL 1.0, 2.0, 3.0 (all deprecated) TLS 1.0, 1.1, 1.2, 1.3
Less secure, vulnerable More secure, actively maintained
No longer used in practice Current standard (TLS 1.2/1.3)

Note: "SSL" is still commonly used as a general term for both SSL and TLS protocols.

How SSL/TLS Works

TLS Handshake Process

  1. Client Hello: Client sends supported TLS versions, cipher suites, and a random value
  2. Server Hello: Server selects TLS version, cipher suite, and sends its own random value
  3. Certificate: Server sends its SSL/TLS certificate
  4. Key Exchange: Client and server exchange keys for symmetric encryption
  5. Finished: Both sides confirm the handshake is complete
  6. Secure Communication: Data is now encrypted using the established session keys

TLS 1.3 Improvements

  • Reduced handshake latency (1-RTT, 0-RTT)
  • Removed obsolete and insecure features
  • Improved privacy with encrypted handshake
  • Simplified cipher suite negotiation
  • Perfect forward secrecy by default
  Client                                                Server
    │                                                     │
    │               Client Hello                          │
    │─────────────────────────────────────────────────────▶
    │                                                     │
    │               Server Hello                          │
    │               Certificate                           │
    │               Server Key Exchange                   │
    │               Server Hello Done                     │
    │◀─────────────────────────────────────────────────────
    │                                                     │
    │               Client Key Exchange                   │
    │               Change Cipher Spec                    │
    │               Finished                              │
    │─────────────────────────────────────────────────────▶
    │                                                     │
    │               Change Cipher Spec                    │
    │               Finished                              │
    │◀─────────────────────────────────────────────────────
    │                                                     │
    │               Application Data                      │
    │◀────────────────────────────────────────────────────▶
    │                                                     │

SSL/TLS Certificate Structure

Certificate Components

  • Version: The X.509 certificate version
  • Serial Number: Unique identifier assigned by the CA
  • Signature Algorithm: Algorithm used to sign the certificate
  • Issuer: The entity that verified and signed the certificate
  • Validity Period: Not before/after dates
  • Subject: Entity identified by the certificate
  • Subject Public Key Info: Public key and algorithm
  • Extensions: Additional attributes (SAN, key usage, etc.)
  • Certificate Signature: Digital signature by the issuer

Certificate Chain

A certificate chain is a sequence of certificates, where each certificate in the chain is signed by the entity identified by the next certificate in the chain.

┌───────────────────┐
│                   │
│  Root CA          │ (Self-signed)
│  Certificate      │
│                   │
└─────────┬─────────┘
          │
          │ signs
          ▼
┌───────────────────┐
│                   │
│  Intermediate CA  │
│  Certificate      │
│                   │
└─────────┬─────────┘
          │
          │ signs
          ▼
┌───────────────────┐
│                   │
│  End-Entity       │
│  Certificate      │
│                   │
└───────────────────┘

The chain establishes trust: if you trust the Root CA, you can trust the entire chain.

Certificate Types by Validation Level

Type Validation Use Cases Issuance Time
Domain Validation (DV) Verifies domain ownership only Basic websites, blogs, personal sites Minutes to hours
Organization Validation (OV) Verifies domain ownership and organization Business websites, e-commerce 1-3 days
Extended Validation (EV) Rigorous verification of legal entity Banking, financial services, healthcare 1-2 weeks

ACM primarily issues DV certificates. For OV or EV certificates, you can import them into ACM.

Server Name Indication (SNI)

What is SNI?

Server Name Indication (SNI) is an extension to the TLS protocol that allows a client to specify the hostname it is attempting to connect to at the beginning of the handshake process.

  • Enables multiple SSL certificates on a single IP address
  • Client indicates which hostname it's connecting to
  • Server presents the correct certificate for that hostname
  • Essential for virtual hosting with HTTPS

The Problem SNI Solves

Before SNI, a server could only present one SSL certificate per IP address, which meant:

  • Each secure website needed a dedicated IP address
  • IP address exhaustion issues
  • Higher costs for hosting multiple secure sites
  • Complications for shared hosting environments

SNI solved this by allowing the client to specify which hostname it wants to connect to before the server selects a certificate.

How SNI Works

SNI Handshake Process

  1. Client initiates TLS connection
  2. Client includes the hostname in the ClientHello message
  3. Server identifies the requested hostname
  4. Server selects the appropriate certificate for that hostname
  5. Server presents the selected certificate to the client
  6. TLS handshake continues as normal
  Client                                                Server
    │                                                     │
    │  ClientHello + SNI: "example.com"                   │
    │─────────────────────────────────────────────────────▶
    │                                                     │
    │                                      ┌─────────────┐│
    │                                      │ Select cert ││
    │                                      │ for         ││
    │                                      │ example.com ││
    │                                      └─────────────┘│
    │                                                     │
    │  ServerHello + Certificate for example.com          │
    │◀─────────────────────────────────────────────────────
    │                                                     │
    │  Rest of TLS handshake                              │
    │◀────────────────────────────────────────────────────▶
    │                                                     │

SNI in AWS

AWS services that support SNI include:

  • Application Load Balancer: Supports multiple TLS certificates using SNI
  • CloudFront: Supports multiple certificates for different domain names
  • API Gateway: Custom domain names with SNI-based certificates
  • Elastic Beanstalk: With ALB or single instance environments

SNI Compatibility

Client Support

Most modern clients support SNI, but some older ones don't:

Client SNI Support
Chrome Yes (all versions)
Firefox Yes (v2.0+)
Safari Yes (v3.0+)
Edge/IE Yes (IE 7+ on Windows Vista+)
Android Yes (v2.3+)
iOS Yes (all versions)
Java Yes (Java 7+)
IE on Windows XP No

SNI Limitations

Potential Issues

  • Older clients don't support SNI
  • Some security scanners may not support SNI
  • Some IoT devices may lack SNI support
  • SNI information is sent in plaintext (privacy concern)
  • TLS 1.3 encrypted SNI (ESNI) is not widely supported yet

Fallback Options

For clients that don't support SNI, you can:

  • Use dedicated IP addresses with Classic Load Balancers
  • Configure a default certificate for non-SNI clients
  • Use CloudFront with dedicated IP addresses (additional cost)
  • Consider upgrading legacy clients if possible

Implementing SNI with AWS Services

Application Load Balancer

ALB supports multiple certificates through SNI:

# AWS CLI command to add certificates to ALB listener
aws elbv2 add-listener-certificates \
  --listener-arn arn:aws:elasticloadbalancing:region:account-id:listener/app/my-load-balancer/50dc6c495c0c9188/f2f7dc8efc522ab2 \
  --certificates CertificateArn=arn:aws:acm:region:account-id:certificate/5cc54884-f4a3-4072-80be-05b9ba72f705

CloudFront

CloudFront supports SNI for custom domain names:

# CloudFront distribution configuration
{
  "ViewerCertificate": {
    "ACMCertificateArn": "arn:aws:acm:us-east-1:account-id:certificate/certificate-id",
    "SSLSupportMethod": "sni-only",
    "MinimumProtocolVersion": "TLSv1.2_2021"
  }
}

HTTP Listeners

What are HTTP Listeners?

HTTP listeners are components of load balancers that check for connection requests using the HTTP/HTTPS protocol and port you configure.

  • Define how the load balancer accepts incoming traffic
  • Specify protocol (HTTP/HTTPS) and port
  • Configure SSL/TLS certificates for HTTPS listeners
  • Define routing rules to target groups
  • Support for content-based routing

Listener Components

  • Protocol: HTTP or HTTPS
  • Port: Typically 80 (HTTP) or 443 (HTTPS)
  • Default Action: What happens when a request matches the listener
  • Rules: Conditions and actions for routing requests
  • SSL Certificate: For HTTPS listeners
  • Security Policy: Defines SSL/TLS protocols and ciphers

HTTPS Listeners

Certificate Requirements

To create an HTTPS listener, you need:

  • An SSL/TLS certificate from ACM or imported into ACM
  • Certificate must cover the domain names of your application
  • Certificate must be in the same region as the load balancer
  • For multiple domains, you can use:
    • Multiple certificates with SNI
    • A wildcard certificate
    • A multi-domain (SAN) certificate

Security Policies

Security policies define the SSL/TLS protocols and ciphers that the load balancer supports:

  • ELBSecurityPolicy-TLS13-1-2-2021-06: TLS 1.3 and 1.2 (recommended)
  • ELBSecurityPolicy-TLS13-1-2-Res-2021-06: TLS 1.3 and 1.2 with restricted ciphers
  • ELBSecurityPolicy-TLS13-1-1-2021-06: TLS 1.3, 1.2, and 1.1
  • ELBSecurityPolicy-FS-1-2-Res-2020-10: TLS 1.2 with forward secrecy
  • ELBSecurityPolicy-FS-1-2-Res-2019-08: Older TLS 1.2 policy

Listener Rules

Rule Components

  • Priority: Determines the order of rule evaluation
  • Conditions: When the rule applies:
    • Host header
    • Path pattern
    • HTTP headers
    • Query parameters
    • Source IP
  • Actions: What happens when conditions match:
    • Forward to target groups
    • Redirect to another URL
    • Return a fixed response
    • Authenticate users

Example Rule Configuration

# AWS CLI command to create a rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:region:account-id:listener/app/my-load-balancer/50dc6c495c0c9188/f2f7dc8efc522ab2 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-targets/73e2d6bc24d8a067

Listener Actions

Forward Action

Routes requests to one or more target groups:

  • Can forward to multiple target groups with weighted distribution
  • Supports sticky sessions
  • Used for A/B testing or blue/green deployments
{
  "Type": "forward",
  "ForwardConfig": {
    "TargetGroups": [
      {
        "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/blue-targets/73e2d6bc24d8a067",
        "Weight": 80
      },
      {
        "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/green-targets/73e2d6bc24d8a067",
        "Weight": 20
      }
    ]
  }
}

Redirect Action

Redirects HTTP requests to another URL:

  • Commonly used to redirect HTTP to HTTPS
  • Can redirect to different domains
  • Supports status codes 301 (permanent) or 302 (temporary)
{
  "Type": "redirect",
  "RedirectConfig": {
    "Protocol": "HTTPS",
    "Port": "443",
    "Host": "#{host}",
    "Path": "/#{path}",
    "Query": "#{query}",
    "StatusCode": "HTTP_301"
  }
}

HTTP to HTTPS Redirection

Why Redirect?

  • Improved security by enforcing encryption
  • Better SEO (Google prefers HTTPS)
  • Avoid mixed content warnings
  • Compliance with security standards
  • User trust with padlock icon in browser

Implementation Steps

  1. Create an HTTP listener on port 80
  2. Create an HTTPS listener on port 443 with your ACM certificate
  3. Configure the HTTP listener with a redirect action to HTTPS
  4. Configure the HTTPS listener with a forward action to your target group
# AWS CLI command to create HTTP to HTTPS redirect
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:region:account-id:loadbalancer/app/my-load-balancer/50dc6c495c0c9188 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=redirect,RedirectConfig="{Protocol=HTTPS,Port=443,Host='#{host}',Path='#{path}',Query='#{query}',StatusCode=HTTP_301}"
  Client                                                Application Load Balancer                                Target Group
    │                                                             │                                                  │
    │  HTTP Request (port 80)                                     │                                                  │
    │────────────────────────────────────────────────────────────▶│                                                  │
    │                                                             │                                                  │
    │  HTTP 301 Redirect to HTTPS                                 │                                                  │
    │◀────────────────────────────────────────────────────────────│                                                  │
    │                                                             │                                                  │
    │  HTTPS Request (port 443)                                   │                                                  │
    │────────────────────────────────────────────────────────────▶│                                                  │
    │                                                             │  Forward Request                                 │
    │                                                             │─────────────────────────────────────────────────▶│
    │                                                             │                                                  │
    │                                                             │  Response                                        │
    │                                                             │◀─────────────────────────────────────────────────│
    │  HTTPS Response                                             │                                                  │
    │◀────────────────────────────────────────────────────────────│                                                  │
    │                                                             │                                                  │

ACM Integration with AWS Services

Integrated Services

ACM certificates can be used with the following AWS services:

  • Elastic Load Balancing
    • Application Load Balancers
    • Network Load Balancers
    • Classic Load Balancers
  • Amazon CloudFront
  • Amazon API Gateway
  • AWS Elastic Beanstalk
  • Amazon CloudFront
  • AWS App Runner
  • Amazon Cognito
  • AWS Amplify

Integration with Load Balancers

Application Load Balancer

  • Supports multiple certificates using SNI
  • Automatic certificate renewal
  • Smart certificate selection based on client request
  • Support for HTTP/2 and WebSockets

Network Load Balancer

  • TLS termination at the load balancer
  • Preserves client IP address
  • Supports multiple certificates using SNI
  • Ultra-low latency with TLS offloading

Netflix

Implementation

  • Uses ACM with CloudFront for content delivery
  • Multiple certificates for different domains
  • TLS 1.2+ for secure streaming
  • SNI for efficient certificate management
  • Load balancers with HTTPS listeners

Amazon.com

Implementation

  • ACM certificates with Elastic Load Balancing
  • HTTPS for all user interactions
  • API security with TLS
  • Automatic certificate renewal
  • SNI for multiple service endpoints

Audible

Implementation

  • ACM with CloudFront for content delivery
  • Secure streaming with TLS encryption
  • Multiple domain certificates
  • API Gateway with custom domain certificates
  • Mobile app API security with mutual TLS

Prime Video

Implementation

  • CloudFront with ACM for video delivery
  • DRM integration with secure certificates
  • Multiple regional certificates
  • TLS 1.2+ for secure content streaming
  • Certificate-based authentication for devices

Goodreads

Implementation

  • ACM certificates with Elastic Load Balancing
  • HTTPS for all user interactions
  • API security with TLS
  • Automatic certificate renewal
  • SNI for multiple service endpoints

Netflix

Implementation

  • Uses ACM with CloudFront for content delivery
  • Multiple certificates for different domains
  • TLS 1.2+ for secure streaming
  • SNI for efficient certificate management
  • Load balancers with HTTPS listeners

Amazon.com

Implementation

  • ACM certificates with Elastic Load Balancing
  • HTTPS for all user interactions
  • API security with TLS
  • Automatic certificate renewal
  • SNI for multiple service endpoints

Audible

Implementation

  • ACM with CloudFront for content delivery
  • Secure streaming with TLS encryption
  • Multiple domain certificates
  • API Gateway with custom domain certificates
  • Mobile app API security with mutual TLS

Prime Video

Implementation

  • CloudFront with ACM for video delivery
  • DRM integration with secure certificates
  • Multiple regional certificates
  • TLS 1.2+ for secure content streaming
  • Certificate-based authentication for devices

Goodreads

Implementation

  • ACM certificates with Elastic Load Balancing
  • HTTPS for all user interactions
  • API security with TLS
  • Automatic certificate renewal
  • SNI for multiple service endpoints

Advantages of AWS Certificate Manager

Cost Benefits

  • Free public certificates for use with AWS services
  • No additional charges for certificate renewals
  • Eliminates costs of third-party certificates
  • No need for dedicated certificate management infrastructure
  • Reduced operational overhead

Operational Benefits

  • Automatic certificate renewal
  • Managed certificate deployment
  • Centralized certificate management
  • Easy integration with AWS services
  • No manual certificate installation
  • Simplified validation process
  • Wildcard and multi-domain certificate support

Security Benefits

  • Managed private certificate authorities
  • Integration with AWS IAM for access control
  • AWS CloudTrail logging for certificate operations
  • Managed certificate revocation
  • Compliance with industry standards
  • Secure key storage

Limitations of AWS Certificate Manager

Service Limitations

  • Certificates can only be used with supported AWS services
  • Cannot export private keys for ACM-issued certificates
  • Regional restrictions (CloudFront certificates must be in us-east-1)
  • Limited to 2000 certificates per account by default
  • No Extended Validation (EV) certificates
  • No Organization Validation (OV) certificates

Operational Challenges

  • DNS validation requires DNS access
  • Email validation requires access to domain contact emails
  • Imported certificates require manual renewal
  • Private CA requires additional setup and costs
  • Certificate request rate limits
  • Limited certificate lifecycle hooks

Cost Considerations

  • Private CA has monthly fees
  • Private certificates have issuance fees
  • CloudFront dedicated IP SSL has additional costs
  • Cross-region certificate usage may incur data transfer costs
  • API Gateway custom domain names have additional costs

Test Your Knowledge

1. Which AWS service provides free SSL/TLS certificates for use with AWS services?

A) AWS Certificate Manager
B) AWS Key Management Service
C) AWS Secrets Manager
D) AWS Identity and Access Management

2. What is Server Name Indication (SNI) used for in AWS Certificate Manager?

A) To validate domain ownership
B) To serve multiple SSL certificates from a single IP address
C) To encrypt private keys
D) To manage certificate revocation lists

3. Which validation method is recommended for ACM certificates?

A) DNS validation
B) Email validation
C) HTTP validation
D) Manual validation

4. Which of the following is NOT a feature of AWS Certificate Manager?

A) Automatic certificate renewal
B) Integration with Elastic Load Balancing
C) Ability to export private keys for ACM-issued certificates
D) Support for wildcard certificates

5. In which region must ACM certificates be requested for use with CloudFront?

A) Any region
B) The region closest to your users
C) US East (N. Virginia) / us-east-1
D) US West (Oregon) / us-west-2

6. What is the difference between SSL and TLS?

A) They are completely different protocols with no relationship
B) TLS is the successor to SSL and provides improved security
C) SSL is used for websites while TLS is only for email
D) SSL is free while TLS requires payment

7. Which AWS service does NOT integrate with ACM?

A) Elastic Load Balancing
B) Amazon CloudFront
C) Amazon API Gateway
D) Amazon S3 (direct integration)

8. What happens when an ACM-issued certificate approaches its expiration date?

A) AWS sends you the new certificate via email
B) You must manually request a new certificate
C) ACM automatically attempts to renew the certificate
D) The certificate is permanently deleted

9. What is the purpose of an HTTP listener in relation to SSL/TLS certificates?

A) To generate new certificates
B) To validate certificate requests
C) To check for connection requests and handle SSL/TLS termination
D) To store certificates securely

10. Which of the following is a best practice for using AWS Certificate Manager?

A) Always use email validation for certificates
B) Manually renew certificates before they expire
C) Create a new certificate for each subdomain
D) Use wildcard certificates to cover multiple subdomains