TLS for MCP Servers on AWS: ACM Certificate Provisioning, ALB and CloudFront HTTPS Termination, and Private CA mTLS

Pattern 1 — Certificate Provisioning and Auto-Renewal

DNS validation: the one decision that makes everything else automatic

ACM certificates require domain ownership validation before issuance. The choice between DNS and email validation is irreversible per-certificate and determines whether you ever need to manually intervene in the certificate lifecycle again. DNS validation adds a CNAME record to your DNS zone once, and ACM queries that record for every subsequent renewal — you never touch it again. Email validation sends a confirmation email for every renewal cycle (every 13 months), requiring a human to click a link within 72 hours. For any MCP server with more than one certificate or more than one operator, email validation will eventually cause an outage when a renewal email is missed.

# Request a certificate with DNS validation and ECDSA P-256 key
aws acm request-certificate \
  --domain-name api.mcp.example.com \
  --subject-alternative-names "*.mcp.example.com" "mcp.example.com" \
  --validation-method DNS \
  --key-algorithm EC_prime256v1 \
  --tags Key=Service,Value=mcp-server Key=Environment,Value=production \
  --region us-east-1

# Retrieve the DNS validation CNAME to add to your DNS zone
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'
# Add this CNAME to your DNS zone permanently — never delete it

# Automate for Route 53 hosted zones
HOSTED_ZONE_ID=$(aws route53 list-hosted-zones-by-name \
  --dns-name mcp.example.com \
  --query 'HostedZones[0].Id' --output text | sed 's|/hostedzone/||')

RECORD=$(aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --query 'Certificate.DomainValidationOptions[0].ResourceRecord')

aws route53 change-resource-record-sets \
  --hosted-zone-id $HOSTED_ZONE_ID \
  --change-batch "{\"Changes\":[{\"Action\":\"UPSERT\",\"ResourceRecordSet\":{
    \"Name\":$(echo $RECORD | jq '.Name'),
    \"Type\":\"CNAME\",
    \"TTL\":300,
    \"ResourceRecords\":[{\"Value\":$(echo $RECORD | jq '.Value')}]
  }}]}"

aws acm wait certificate-validated \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123

One CNAME record validates both *.mcp.example.com and mcp.example.com — wildcard SANs share a validation record with their base domain. For multi-region deployments, request the same domain certificate in each region; the CNAME value is deterministic per domain (not per certificate ARN), so the validation record added for us-east-1 automatically validates certificates requested in us-west-2 and eu-west-1 for the same domain.

Key algorithm selection: EC_prime256v1 for all new deployments

The key algorithm affects every TLS handshake your MCP server initiates. For MCP servers under concurrent load — multiple AI agents calling tools simultaneously — the handshake cost compounds. ECDSA P-256 certificates are 10–20× faster to sign than RSA 2048 due to the underlying cryptographic operations, produce smaller certificate sizes (fewer bytes in the TLS ClientHello), and provide equivalent security for all current threat models. The only reason to choose RSA 2048 is compatibility with legacy TLS clients that predate ECDSA support — modern MCP clients (AI agent SDKs, developer HTTP libraries) all support ECDSA.

Key algorithm cannot be changed after issuance. To migrate from RSA to ECDSA on a running ALB: request a new ECDSA certificate, add it as an additional SNI certificate on the listener, set it as the new default, then remove the old certificate — no downtime, ALB negotiates the new certificate immediately for new connections.

Certificate expiry monitoring: don't rely on ACM auto-renewal alone

ACM auto-renewal is not a guarantee — it is a best-effort process that fails when the DNS validation CNAME has been deleted. The most common cause is a DNS provider migration where the operator migrates all "real" records and forgets about ACM validation CNAMEs because they look like noise. The certificate then enters PENDING_VALIDATION status 60 days before expiry, stays there, and expires without any console notification unless you have an alarm configured.

# CloudWatch alarm on DaysToExpiry metric — fires at 60 days to give time to fix
# The DaysToExpiry metric is published automatically by ACM with no setup required
aws cloudwatch put-metric-alarm \
  --alarm-name ACMCertExpiry60Days \
  --alarm-description "ACM certificate expiring within 60 days — verify renewal status" \
  --metric-name DaysToExpiry \
  --namespace AWS/CertificateManager \
  --dimensions Name=CertificateArn,Value=arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --statistic Minimum \
  --period 86400 \
  --evaluation-periods 1 \
  --threshold 60 \
  --comparison-operator LessThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:cert-expiry-alerts \
  --treat-missing-data breaching  # alarm if metric stops publishing

# EventBridge rule for ACM-native expiry events (45/30/15/7/3/1 days before expiry)
aws events put-rule \
  --name ACMCertExpiryNotification \
  --event-pattern '{
    "source": ["aws.acm"],
    "detail-type": ["ACM Certificate Approaching Expiration"]
  }' \
  --state ENABLED

aws events put-targets \
  --rule ACMCertExpiryNotification \
  --targets '[{
    "Id": "SendToSNS",
    "Arn": "arn:aws:sns:us-east-1:123456789012:cert-expiry-alerts"
  }]'

# Check renewal status for a specific certificate
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --query 'Certificate.RenewalSummary'
# RenewalStatus: PENDING_AUTO_RENEWAL / PENDING_VALIDATION / SUCCESS / FAILED

The CloudWatch DaysToExpiry alarm with treat-missing-data breaching is the most robust approach: if ACM stops publishing the metric (certificate deleted, region issue), the alarm fires rather than remaining OK. Pair it with the EventBridge rule to catch cases where ACM detects a renewal problem internally before the 60-day window. AliveMCP also monitors TLS certificate validity as part of MCP server health checks — if a certificate within 14 days of expiry is detected on any monitored endpoint, it fires an alert regardless of how the certificate was provisioned (ACM, Let's Encrypt, or custom CA).

Pattern 2 — Choosing Between ALB and CloudFront for TLS Termination

ALB: the standard choice for MCP server HTTPS

An Application Load Balancer with an ACM certificate is the right TLS termination layer for most MCP server deployments. The ALB terminates TLS, and backend containers receive plain HTTP inside the VPC — no TLS handling required in the MCP server code. ACM auto-renewal is transparent to the ALB: when ACM issues a renewed certificate, the ALB picks it up automatically without any listener modification or deployment.

# Create ALB with HTTPS listener and HTTP redirect
ALB_ARN=$(aws elbv2 create-load-balancer \
  --name mcp-server-alb \
  --subnets subnet-public-1a subnet-public-1b \
  --security-groups sg-alb-id \
  --scheme internet-facing \
  --type application \
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

# Enable deletion protection immediately
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn $ALB_ARN \
  --attributes Key=deletion_protection.enabled,Value=true

# Create HTTPS listener with the recommended TLS policy
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
  --default-actions Type=forward,TargetGroupArn=$TG_ARN

# Create HTTP redirect listener
aws elbv2 create-listener \
  --load-balancer-arn $ALB_ARN \
  --protocol HTTP \
  --port 80 \
  --default-actions '[{
    "Type": "redirect",
    "RedirectConfig": {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}
  }]'

# CRITICAL for SSE-based MCP servers: increase idle timeout beyond default 60s
# Default 60s terminates SSE connections with no data activity mid-session
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn $ALB_ARN \
  --attributes Key=idle_timeout.timeout_seconds,Value=300

The SSE idle timeout is the most commonly missed ALB configuration for MCP servers. An SSE connection that receives no data for 60 seconds is terminated by the ALB with no error visible to the client — the connection silently closes. For MCP tools that poll or wait between events (e.g., a tool waiting for an async operation to complete), 60 seconds is easy to exceed. Increase the ALB idle timeout to at least 300 seconds, or add periodic keepalive SSE comments (: keepalive\n\n) from the server side to reset the idle timer without requiring an actual data event.

CloudFront: when global edge and DDoS protection are worth the constraints

CloudFront adds a global edge network in front of your MCP server origin, reducing latency for clients connecting from regions far from the origin. It also includes AWS Shield Standard (basic DDoS protection) at no additional charge. The tradeoffs are the 60-second origin read timeout ceiling and the us-east-1 certificate requirement — both of which affect MCP server architecture in non-obvious ways.

# Request CloudFront certificate — MUST be in us-east-1
aws acm request-certificate \
  --domain-name mcp.example.com \
  --subject-alternative-names "*.mcp.example.com" \
  --validation-method DNS \
  --key-algorithm EC_prime256v1 \
  --region us-east-1    # Required — CloudFront ignores certs from all other regions

# Create CloudFront distribution with correct settings for MCP API
aws cloudfront create-distribution \
  --distribution-config '{
    "CallerReference": "mcp-server-cf",
    "Comment": "MCP server edge TLS",
    "DefaultCacheBehavior": {
      "TargetOriginId": "mcp-server-alb",
      "ViewerProtocolPolicy": "redirect-to-https",
      "AllowedMethods": {
        "Quantity": 7,
        "Items": ["GET","HEAD","OPTIONS","PUT","POST","PATCH","DELETE"],
        "CachedMethods": {"Quantity": 2, "Items": ["GET","HEAD"]}
      },
      "CachePolicyId": "4135ea2d-6df8-44a3-9df3-4b5a84be39ad",
      "OriginRequestPolicyId": "b689b0a8-53d0-40ab-baf2-68738e2966ac",
      "Compress": true
    },
    "Origins": {
      "Quantity": 1,
      "Items": [{
        "Id": "mcp-server-alb",
        "DomainName": "mcp-alb-123456.us-east-1.elb.amazonaws.com",
        "CustomOriginConfig": {
          "HTTPPort": 80,
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only",
          "OriginSSLProtocols": {"Quantity": 1, "Items": ["TLSv1.2"]},
          "OriginReadTimeout": 60
        }
      }]
    },
    "Aliases": {"Quantity": 1, "Items": ["mcp.example.com"]},
    "ViewerCertificate": {
      "ACMCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/abc-123",
      "SSLSupportMethod": "sni-only",
      "MinimumProtocolVersion": "TLSv1.2_2021",
      "CertificateSource": "acm"
    },
    "Enabled": true,
    "HttpVersion": "http2and3",
    "IsIPV6Enabled": true
  }'

The managed CachingDisabled policy (4135ea2d-6df8-44a3-9df3-4b5a84be39ad) sets TTL to zero for all cached responses — every request passes through to the MCP server origin. This is non-negotiable for MCP API endpoints: tool responses are per-session and per-request; caching a tool response and serving it to a different client is a data correctness bug, not just a performance issue. Use X-Cache: Miss from cloudfront in response headers to verify that no API responses are being cached.

Comparison: ALB vs CloudFront for MCP server TLS

Zero-downtime certificate rotation on ALB

Manual certificate rotation — when migrating from RSA to ECDSA, adding a new SAN, or updating a wildcard — follows a three-step pattern that keeps the ALB serving traffic continuously through the change:

# Step 1: Request and validate new certificate
NEW_CERT_ARN=$(aws acm request-certificate \
  --domain-name api.mcp.example.com \
  --subject-alternative-names "*.mcp.example.com" \
  --validation-method DNS \
  --key-algorithm EC_prime256v1 \
  --query 'CertificateArn' --output text)
aws acm wait certificate-validated --certificate-arn $NEW_CERT_ARN

# Step 2: Add new certificate as additional SNI (both old and new active)
LISTENER_ARN=$(aws elbv2 describe-listeners \
  --load-balancer-arn $ALB_ARN \
  --query 'Listeners[?Protocol==`HTTPS`].ListenerArn' --output text)

aws elbv2 add-listener-certificates \
  --listener-arn $LISTENER_ARN \
  --certificates CertificateArn=$NEW_CERT_ARN

# Step 3: Promote new certificate to default
aws elbv2 modify-listener \
  --listener-arn $LISTENER_ARN \
  --certificates CertificateArn=$NEW_CERT_ARN

# Step 4: Remove old certificate (after confirming no clients rejected new cert)
aws elbv2 remove-listener-certificates \
  --listener-arn $LISTENER_ARN \
  --certificates CertificateArn=arn:aws:acm:us-east-1:123456789012:certificate/old-cert

During steps 2 and 3, both certificates are active simultaneously — clients receiving the old certificate via an in-flight connection are not interrupted. ACM certificates are free to keep even after detaching from the ALB, so there is no urgency to delete the old certificate; wait at least 24 hours after the rotation before deleting to ensure any long-lived connections have fully transitioned.

Pattern 3 — Private CA for Internal mTLS

When to use Private CA instead of public ACM

ACM public certificates cover all external HTTPS traffic — any MCP client connecting over the internet gets a publicly trusted certificate at zero cost. Private CA adds cost ($400/month per active CA) and operational overhead (CA hierarchy management, certificate distribution to clients). The correct trigger for adding Private CA is a specific architectural requirement that public ACM cannot satisfy, not a general "more security is better" decision.

The most common valid use case for Private CA in MCP deployments is when an MCP gateway service must authenticate that incoming connections come specifically from authorized MCP orchestrators — not just any HTTPS client with a valid API key. Mutual TLS achieves this at the transport layer, before the application processes the request, and the ALB can enforce it without requiring any code change in the MCP server.

Building the CA hierarchy

A two-tier hierarchy (ROOT CA + SUBORDINATE CA) is the correct approach. The root CA signs only the subordinate CA certificate, then gets disabled — its private key is less exposed because it is inactive. The subordinate CA issues all end-entity certificates. If the subordinate CA is ever compromised, you create a new subordinate CA (still signed by the offline root) and revoke the old one, without rebuilding from scratch.

# Create root CA (RSA 4096 for the CA key; end-entity certs use EC P-256)
ROOT_CA_ARN=$(aws acm-pca create-certificate-authority \
  --certificate-authority-configuration '{
    "KeyAlgorithm": "RSA_4096",
    "SigningAlgorithm": "SHA512WITHRSA",
    "Subject": {
      "Country": "US",
      "Organization": "MCP Server Internal CA",
      "CommonName": "MCP Server Root CA"
    }
  }' \
  --certificate-authority-type ROOT \
  --query 'CertificateAuthorityArn' --output text)

# Self-sign the root CA certificate (10 year validity)
aws acm-pca get-certificate-authority-csr \
  --certificate-authority-arn $ROOT_CA_ARN \
  --output text > root_ca.csr

ROOT_CERT_ARN=$(aws acm-pca issue-certificate \
  --certificate-authority-arn $ROOT_CA_ARN \
  --csr fileb://root_ca.csr \
  --signing-algorithm SHA512WITHRSA \
  --template-arn arn:aws:acm-pca:::template/RootCACertificate/V1 \
  --validity Value=3650,Type=DAYS \
  --query 'CertificateArn' --output text)

aws acm-pca wait certificate-issued \
  --certificate-authority-arn $ROOT_CA_ARN \
  --certificate-arn $ROOT_CERT_ARN

aws acm-pca get-certificate \
  --certificate-authority-arn $ROOT_CA_ARN \
  --certificate-arn $ROOT_CERT_ARN \
  --query 'Certificate' --output text > root_cert.pem

aws acm-pca import-certificate-authority-certificate \
  --certificate-authority-arn $ROOT_CA_ARN \
  --certificate fileb://root_cert.pem

# Create subordinate CA (EC P-256; signed by root)
SUB_CA_ARN=$(aws acm-pca create-certificate-authority \
  --certificate-authority-configuration '{
    "KeyAlgorithm": "EC_prime256v1",
    "SigningAlgorithm": "SHA256WITHECDSA",
    "Subject": {
      "CommonName": "MCP Server Intermediate CA"
    }
  }' \
  --revocation-configuration '{
    "CrlConfiguration": {
      "Enabled": true, "ExpirationInDays": 7,
      "S3BucketName": "mcp-ca-crls-123456789012",
      "S3ObjectAcl": "BUCKET_OWNER_FULL_CONTROL"
    }
  }' \
  --certificate-authority-type SUBORDINATE \
  --query 'CertificateAuthorityArn' --output text)

# After subordinate CA is active, disable the root CA (saves $400/month)
aws acm-pca update-certificate-authority \
  --certificate-authority-arn $ROOT_CA_ARN \
  --status DISABLED

Short-lived certificates for ECS tasks: the sidecar pattern

For MCP server containers on ECS, the right pattern is a sidecar certificate provisioner that generates a fresh key pair and certificate at task startup. The certificate is valid for 4–24 hours — long enough for the task lifetime, short enough that revocation is moot (the cert expires before a CRL propagates). The private key never leaves the task; only the certificate signing request (CSR) goes to Private CA.

# ECS task definition with certificate provisioner sidecar
{
  "containerDefinitions": [
    {
      "name": "cert-provisioner",
      "image": "public.ecr.aws/amazonlinux/amazonlinux:2023",
      "essential": false,
      "command": ["/bin/bash", "-c",
        "openssl ecparam -name prime256v1 -genkey -noout -out /certs/service.key && \
         openssl req -new -key /certs/service.key \
           -subj \"/CN=${TASK_ARN}/O=MCPServer\" \
           -out /tmp/service.csr && \
         CERT_ARN=$(aws acm-pca issue-certificate \
           --certificate-authority-arn $CA_ARN \
           --csr fileb:///tmp/service.csr \
           --signing-algorithm SHA256WITHECDSA \
           --validity Value=4,Type=HOURS \
           --query CertificateArn --output text) && \
         aws acm-pca wait certificate-issued \
           --certificate-authority-arn $CA_ARN \
           --certificate-arn $CERT_ARN && \
         aws acm-pca get-certificate \
           --certificate-authority-arn $CA_ARN \
           --certificate-arn $CERT_ARN \
           --query Certificate --output text > /certs/service.crt"
      ],
      "mountPoints": [{"sourceVolume": "certs", "containerPath": "/certs"}],
      "environment": [{"name": "CA_ARN", "value": "$SUB_CA_ARN"}]
    },
    {
      "name": "mcp-server",
      "essential": true,
      "dependsOn": [{"containerName": "cert-provisioner", "condition": "SUCCESS"}],
      "mountPoints": [{"sourceVolume": "certs", "containerPath": "/certs", "readOnly": true}]
    }
  ],
  "volumes": [{"name": "certs"}]
}

Enabling mTLS on an ALB

With a Private CA hierarchy and client certificates issued to MCP orchestrators, the ALB can enforce mutual authentication at the network layer. Requests without a valid client certificate receive a 400 response from the ALB — the MCP server backend never sees unauthenticated connections. The client certificate's CN and issuer are forwarded to the backend in HTTP headers for fine-grained authorization.

# Create an ALB trust store containing the CA bundle
aws acm-pca get-certificate-authority-certificate \
  --certificate-authority-arn $SUB_CA_ARN \
  --query 'Certificate' --output text > sub_ca_cert.pem

cat root_cert.pem sub_ca_cert.pem > ca_bundle.pem
aws s3 cp ca_bundle.pem s3://mcp-alb-trust-store/ca-bundle.pem

TRUST_STORE_ARN=$(aws elbv2 create-trust-store \
  --name mcp-client-trust-store \
  --ca-certificates-bundle-s3-bucket mcp-alb-trust-store \
  --ca-certificates-bundle-s3-key ca-bundle.pem \
  --query 'TrustStores[0].TrustStoreArn' --output text)

# Enable mTLS verification on the HTTPS listener
aws elbv2 modify-listener \
  --listener-arn $LISTENER_ARN \
  --mutual-authentication \
    Mode=verify,TrustStoreArn=$TRUST_STORE_ARN,IgnoreClientCertificateExpiry=false

# The ALB now forwards client certificate details to the MCP server backend:
# X-Amzn-Mtls-Clientcert-Subject: "CN=mcp-orchestrator-prod,O=MCPServer"
# X-Amzn-Mtls-Clientcert-Issuer: "CN=MCP Server Intermediate CA"
# X-Amzn-Mtls-Clientcert-Serial: "01:23:45:67:89:ab"
# X-Amzn-Mtls-Clientcert-Validity: "NotBefore=...;NotAfter=..."
# Backend can implement per-CN authorization without any TLS handling code

Cost management: keeping Private CA affordable

At $400/month per active CA, Private CA can easily double the infrastructure cost for a small MCP deployment. The primary lever is the number of CAs in ACTIVE state. A CA in DISABLED state incurs no monthly charge — it cannot issue certificates, but certificates it has already issued remain valid.

For ECS fleets with frequent task restarts, the certificate issuance cost can exceed the CA fee. At $0.75/1,000 certificates, 10,000 issuances per month costs $7.50 — minor compared to the $400 CA cost. But at 1,000 issuances per day (a large ECS fleet with short task lifetimes and aggressive restarts), the monthly issuance cost reaches $22.50/month. Prefer longer certificate validity periods for stable long-running services; reserve 4-hour certificates for genuinely ephemeral workloads.

Consolidated failure modes reference