AWS Certificate Manager for MCP Servers — TLS Provisioning, Validation, and Renewal

Request a public certificate

ACM public certificates are issued by Amazon Trust Services, a publicly trusted CA. Certificates are free for use with ACM-integrated AWS services. There is no charge per certificate, no charge per renewal, and no charge for wildcard certificates.

# Request a certificate for your MCP server's domain
aws acm request-certificate \
  --domain-name api.mcp-server.example.com \
  --validation-method DNS \
  --subject-alternative-names "*.mcp-server.example.com" "mcp-server.example.com" \
  --key-algorithm EC_prime256v1 \
  --tags Key=Service,Value=mcp-server Key=Environment,Value=production \
  --region us-east-1
# Output: { "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/abc-123..." }

# Retrieve the DNS validation records (CNAME name+value) you must add to your DNS
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --query 'Certificate.DomainValidationOptions[].ResourceRecord'
# Output: [{ "Name": "_abc123.mcp-server.example.com.", "Type": "CNAME", "Value": "_xyz789.acm-validations.aws." }]

Choose DNS validation over email validation: DNS validation is permanent (the CNAME record stays in DNS and ACM uses it for all future auto-renewals), while email validation requires a manual step on every renewal cycle. DNS validation is the only approach that supports fully automated certificate lifecycle management.

# If your domain is in Route 53 — add the validation CNAME automatically
# (requires the hosted zone ID for your domain)
HOSTED_ZONE_ID=$(aws route53 list-hosted-zones-by-name \
  --dns-name mcp-server.example.com \
  --query 'HostedZones[0].Id' --output text | sed 's|/hostedzone/||')

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

RECORD_NAME=$(echo $VALIDATION_RECORD | jq -r '.Name')
RECORD_VALUE=$(echo $VALIDATION_RECORD | jq -r '.Value')

aws route53 change-resource-record-sets \
  --hosted-zone-id $HOSTED_ZONE_ID \
  --change-batch "{
    \"Changes\": [{
      \"Action\": \"UPSERT\",
      \"ResourceRecordSet\": {
        \"Name\": \"$RECORD_NAME\",
        \"Type\": \"CNAME\",
        \"TTL\": 300,
        \"ResourceRecords\": [{\"Value\": \"$RECORD_VALUE\"}]
      }
    }]
  }"

# Wait for validation to complete (typically 2-5 minutes with Route 53)
aws acm wait certificate-validated \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123
echo "Certificate validated and issued"

Certificate validation methods compared

Key algorithm choices

ACM supports RSA 2048, RSA 4096, and ECDSA P-256 and P-384. For MCP server deployments the choice affects TLS handshake performance and compatibility:

ECDSA P-256 certificates (EC_prime256v1) are the modern choice: smaller size (smaller certificates fit in fewer TLS handshake packets), faster signing, and lower per-connection compute cost on ALBs under high concurrency. MCP clients using modern HTTP stacks all support ECDSA. The only reason to use RSA 2048 is compatibility with legacy clients that don't support ECDSA — for MCP server deployments where all clients are modern AI agents or developer SDKs, EC_prime256v1 is the better default.

# You cannot change the key algorithm after a certificate is issued.
# To migrate from RSA to ECDSA: request a new certificate, attach to ALB/CloudFront,
# then delete the old one. No downtime — ALB/CloudFront negotiates the new cert immediately.

# Request ECDSA P-256 certificate (recommended for new MCP server deployments)
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

# Check certificate details including key algorithm
aws acm describe-certificate \
  --certificate-arn arn:aws:acm:us-east-1:123456789012:certificate/abc-123 \
  --query 'Certificate.{Status:Status,Algorithm:KeyAlgorithm,Expiry:NotAfter,SANs:SubjectAlternativeNames}'

Certificate lifecycle and auto-renewal

ACM certificates are valid for 13 months (395 days). ACM attempts renewal starting 60 days before expiry. For DNS-validated certificates, renewal is fully automatic — ACM queries the validation CNAME record that is already in DNS. For email-validated certificates, ACM sends a new validation email that must be clicked within 72 hours.

# List all certificates with their expiry dates (useful for a monthly audit)
aws acm list-certificates \
  --certificate-statuses ISSUED \
  --query 'CertificateSummaryList[].{Arn:CertificateArn,Domain:DomainName}' \
  --output json | \
jq -r '.[] | .Arn' | \
while read ARN; do
  aws acm describe-certificate \
    --certificate-arn "$ARN" \
    --query 'Certificate.{Domain:DomainName,Expiry:NotAfter,Status:Status,RenewalStatus:RenewalSummary.RenewalStatus}' \
    --output json
done

# 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 values:
#   PENDING_AUTO_RENEWAL — ACM hasn't started the renewal attempt yet
#   PENDING_VALIDATION   — DNS/email validation in progress (DNS should resolve quickly)
#   SUCCESS              — renewed; new cert will be deployed at next attachment sync
#   FAILED               — validation failed; check DomainValidationOptions for reason

The most common cause of renewal failure is deleting the DNS validation CNAME record. This happens when DNS zones are migrated to a new provider, when TTL-zero records are cleaned up by automation, or when the record was never added to a subdomain's zone (common when the subdomain has a delegated zone that the base domain's CNAME doesn't cover). Never delete ACM validation CNAME records. They are harmless to leave permanently — ACM uses them only for validation queries.

# Monitor for certificates within 60 days of expiry using CloudWatch
# ACM emits a DaysToExpiry metric automatically — no setup needed
aws cloudwatch put-metric-alarm \
  --alarm-name ACMCertExpiry60Days \
  --alarm-description "ACM certificate expiring within 60 days — check 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

# EventBridge rule for ACM certificate expiry notifications (account-level)
# ACM sends events 45, 30, 15, 7, 3, and 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"
  }]'

ACM limits and multi-region deployments

ACM certificates are regional — a certificate issued in us-east-1 cannot be attached to an ALB in us-west-2. For multi-region MCP server deployments, request the same certificate in each region. DNS validation only requires the CNAME to be added once — subsequent requests for the same domain in different regions validate automatically against the existing CNAME.

# Request the same certificate in multiple regions for multi-region ALB deployment
# Region us-east-1 (primary)
aws acm request-certificate \
  --domain-name api.mcp.example.com \
  --validation-method DNS \
  --key-algorithm EC_prime256v1 \
  --region us-east-1

# Region us-west-2 (secondary)
aws acm request-certificate \
  --domain-name api.mcp.example.com \
  --validation-method DNS \
  --key-algorithm EC_prime256v1 \
  --region us-west-2

# DNS validation CNAME is the same for both requests —
# add it once and both certificates will validate.
# The CNAME value is deterministic per domain, not per certificate ARN.

Certificate expiry and MCP server uptime

An expired TLS certificate causes MCP clients to reject connections with a hard TLS error — no retry, no fallback, instant failure. For MCP servers in production, a certificate expiry is functionally identical to a server outage: all clients stop working simultaneously at the second the certificate expires.

ACM auto-renewal eliminates this risk for certificates attached to ALBs and CloudFront, but it does not protect against: DNS CNAME records being deleted (renewal fails), certificates used on EC2 instances managed by Let's Encrypt that miss a renewal cycle, or imported third-party certificates that ACM cannot auto-renew. AliveMCP monitors TLS certificate validity as part of its health checks — if your MCP server's TLS cert is within 14 days of expiry, AliveMCP fires an alert before your clients experience failures, giving you time to remediate regardless of how the certificate was provisioned.

Failure modes reference