11.3 Encryption in Transit with AWS Certificate Manager (ACM)

11.3 Encryption in Transit with AWS Certificate Manager (ACM)

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your ability to protect network communications across AWS infrastructure. You must master AWS Certificate Manager (ACM) certificate lifecycles, configure automated DNS validation and renewal workflows, establish expiration monitoring using CloudWatch and AWS Config, deploy private PKI using AWS Private CA, and enforce modern TLS security policies and HTTP-to-HTTPS redirects on Application Load Balancers.

AWS Certificate Manager (ACM) Architecture & Integrated Services

Protecting data in transit across public and private networks requires Transport Layer Security (TLS/SSL). AWS Certificate Manager (ACM) simplifies the complex, error-prone operational lifecycle of SSL/TLS certificates by automating certificate provisioning, validation, deployment, and renewal.

Native Integrated AWS Services

Public ACM certificates bind directly to AWS network termination endpoints:

• Elastic Load Balancing: Application Load Balancers (ALB) and Network Load Balancers (NLB with TLS listeners).
• Amazon CloudFront Distributions: Global content delivery network distributions. Exam Critical: CloudFront is a global edge service; all ACM certificates used by CloudFront must be requested or imported strictly in the us-east-1 (N. Virginia) Region.
• Amazon API Gateway: Custom domain names for Regional and Edge-optimized REST and HTTP APIs.
• AWS Elastic Beanstalk & AWS App Runner: Managed web application hosting environments.

The Non-Exportable Private Key Security Constraint

A fundamental architectural principle of public ACM certificates is that private keys cannot be exported or downloaded. ACM manages the private key within its secure HSM boundary. Consequently, you cannot use a public ACM certificate directly on a bare Amazon EC2 instance running Nginx or Apache, nor can you export it to an on-premises physical server. Public ACM certificates must terminate on an integrated AWS managed service (such as an ALB or CloudFront), which handles TLS termination and forwards decrypted traffic to backend compute instances over private VPC subnets.

---

Certificate Validation Mechanisms: DNS vs. Email Validation

Before ACM issues a public certificate, the applicant must prove ownership of the requested domain name. ACM provides two validation mechanisms with starkly different operational characteristics:

DNS Validation Mechanics

When you request a certificate using DNS validation, ACM generates a unique, domain-specific CNAME record containing an MD5/SHA-256 hash:

• Name: _a79865eb4b9f365.example.com.
• Value: _x2.acm-validations.aws.

Once added to the DNS zone, ACM queries public DNS servers. Upon verification, the certificate state transitions from Pending validation to Issued. Crucially, DNS validation handles renewals forever. As long as the CNAME record remains in place and the certificate remains actively bound to an AWS resource, ACM automatically issues and deploys renewed certificates 60 days prior to expiration with zero human intervention.

---

Certificate Expiration Monitoring & Observability

While DNS-validated ACM certificates renew automatically, operational blind spots can still cause production failures (e.g., if a developer deletes a CNAME record, an imported third-party certificate nears expiry, or a certificate is unused and thus excluded from auto-renewal). CloudOps teams establish proactive observability using two AWS monitoring mechanisms:

1. Amazon CloudWatch Metric: DaysToExpiry

ACM publishes the metric DaysToExpiry in the AWS/CertificateManager namespace for each active certificate:

• CloudOps engineers configure a CloudWatch Alarm triggered when DaysToExpiry <= 30 (Warning) or DaysToExpiry <= 14 (Critical).
• The alarm notifies an Amazon SNS topic linked to the on-call PagerDuty or Slack engineering channel, prompting immediate investigation.

2. AWS Config Managed Rule: acm-certificate-expiration-check

For centralized multi-account governance, AWS Config provides a pre-built managed rule:

• Rule Identifier: acm-certificate-expiration-check
• Parameters: daysToExpiration (e.g., set to 14 or 30).
• When AWS Config detects an ACM certificate expiring within the designated threshold, it marks the resource as NON_COMPLIANT and emits a compliance state-change event to Amazon EventBridge, triggering automated ticket creation or executive alerting.

---

AWS Private Certificate Authority (AWS Private CA)

Public SSL/TLS certificates cannot be issued for internal domains (e.g., api.internal.corp) and cannot be exported to internal compute resources. For enterprise internal security, AWS provides AWS Private Certificate Authority (AWS Private CA):

• Managed Enterprise PKI: Allows organizations to create a complete private CA hierarchy (Root CA and Subordinate/Issuing CAs) without operating complex on-premises OpenSSL or Microsoft CA infrastructure.
• Internal Microservices & mTLS: Issues internal certificates for service-to-service mutual TLS (mTLS) in Amazon EKS, ECS, and service meshes (AWS App Mesh / Istio).
• Exportable Private Keys: Unlike public ACM certificates, private certificates issued by AWS Private CA can have their private keys and certificates exported via the AWS CLI or API (acm:ExportCertificate), allowing secure installation directly onto backend EC2 instances, on-premises virtual machines, and IoT microcontrollers.

---

Enforcing In-Transit Security: ALB Policies & HTTP Redirection

Terminating TLS on an Application Load Balancer requires strict operational hygiene to eliminate deprecated cryptographic standards and ensure all traffic is encrypted.

Enforcing TLS Security Policies

ALB HTTPS listeners use predefined TLS Security Policies that define supported TLS protocol versions and cryptographic cipher suites. Legacy policies often permit insecure protocols (TLS 1.0, TLS 1.1) and vulnerable CBC-mode ciphers susceptible to exploits like POODLE and BEAST.

CloudOps engineers must replace default policies with modern policies like ELBSecurityPolicy-TLS13-1-2-2021-06 on all production HTTPS listeners.

HTTP to HTTPS Listener Redirection

To prevent users from inadvertently transmitting plaintext data, ALBs natively support HTTP-to-HTTPS Redirection at the listener level without requiring backend web server rewrites:

{
  "Type": "redirect",
  "RedirectConfig": {
    "Protocol": "HTTPS",
    "Port": "443",
    "Host": "#{host}",
    "Path": "/#{path}",
    "Query": "#{query}",
    "StatusCode": "HTTP_301"
  }
}

Configuring this redirect rule on the port 80 (HTTP) listener causes the ALB to return an immediate HTTP 301 Moved Permanently response, seamlessly upgrading client browsers to encrypted port 443 sessions.