Implementing Zero-Maintenance HTTPS with AWS ACM Wildcard Certificates in Kubernetes

Setting up HTTPS for your Kubernetes applications on AWS can be complex, but using AWS Certificate Manager (ACM) with wildcard certificates makes it incredibly scalable and maintainable. This comprehensive guide walks you through creating and configuring a wildcard SSL certificate for your AWS ALB Ingress Controller.

Why Choose AWS ACM Wildcard Certificates?

Before diving into the setup, let's understand why this approach is ideal for production environments:

✔︎ Zero Maintenance: AWS automatically renews certificates
✔︎ Cost-Effective: Free public certificates
✔︎ Scalable: One certificate covers unlimited subdomains
✔︎ Production-Ready: Trusted by all browsers immediately
✔︎ Native Integration: Seamless with AWS Load Balancer Controller

Prerequisites

• AWS EKS cluster with ALB Ingress Controller installed

• Domain registered (we'll use mycompany.com as example)

• AWS CLI configured with appropriate permissions

• Access to your domain's DNS management (GoDaddy, Route53, etc.)

Step 1: Request the ACM Wildcard Certificate

Create a wildcard certificate that covers all subdomains of your domain:

aws acm request-certificate \
    --domain-name "*.mycompany.com" \
    --subject-alternative-names "mycompany.com" \
    --validation-method DNS \
    --region us-west-2

Output:

{
    "CertificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
}

Key Points:

• Replace us-west-2 with your AWS region

• The wildcard *.mycompany.com covers all first-level subdomains

• Including mycompany.com as SAN covers the apex domain

• Note down the CertificateArn for later use

Step 2: Verify ACM Certificate Status

Check the initial certificate status:

aws acm list-certificates --region us-west-2

Expected Output:

{
    "CertificateSummaryList": [
        {
            "CertificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012",
            "DomainName": "*.mycompany.com",
            "Status": "PENDING_VALIDATION",
            "Type": "AMAZON_ISSUED"
        }
    ]
}

The certificate will be in PENDING_VALIDATION status until DNS validation is completed.

Step 3: Get DNS Validation Records for ACM

Retrieve the DNS records needed for validation:

aws acm describe-certificate \
    --certificate-arn "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012" \
    --region us-west-2 \
    --query 'Certificate.DomainValidationOptions[*].ResourceRecord'

Output:

[
    {
        "Name": "_abc123def456.mycompany.com.",
        "Type": "CNAME",
        "Value": "_xyz789uvw012.acm-validations.aws."
    },
    {
        "Name": "_abc123def456.mycompany.com.",
        "Type": "CNAME", 
        "Value": "_xyz789uvw012.acm-validations.aws."
    }
]

Important: You'll see duplicate records because both *.mycompany.com and mycompany.com use the same validation record for wildcard certificates.

Step 4: Add DNS Validation Record

Add the CNAME record to your DNS provider (GoDaddy, Route53, etc.):

For GoDaddy:

• Type: CNAME

• Name: _abc123def456 (without .mycompany.com)

• Value: _xyz789uvw012.acm-validations.aws (without trailing dot)

• TTL: 600 seconds

Important Notes:

• Don't include .mycompany.com in the Name field - your DNS provider adds it automatically

• Remove the trailing dot from the Value field

• Only add one CNAME record, even though you see duplicates in the output

Step 5: Wait for ACM Certificate Validation

Monitor the validation status:

# Check validation status every few minutes
aws acm describe-certificate \
    --certificate-arn "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012" \
    --region us-west-2 \
    --query 'Certificate.Status'

Timeline:

• DNS propagation: 5-10 minutes

• AWS validation: 5-30 minutes after DNS propagation

• Total time: Usually 10-40 minutes

Success Output:

"ISSUED"

Step 6: Verify Issued ACM Certificate

Once issued, verify the certificate details:

aws acm list-certificates --region us-west-2

Successful Output:

{
    "CertificateSummaryList": [
        {
            "CertificateArn": "arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012",
            "DomainName": "*.mycompany.com",
            "Status": "ISSUED",
            "Type": "AMAZON_ISSUED",
            "NotBefore": "2025-09-05T00:00:00+00:00",
            "NotAfter": "2026-10-05T23:59:59+00:00"
        }
    ]
}

Step 7: Configure Kubernetes ALB Ingress with ACM Wildcard Certificate

Update your existing ingress to use HTTPS with the ACM certificate:

textapiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    
    # SSL/TLS Configuration with ACM
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:123456789012:certificate/12345678-1234-1234-1234-123456789012
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2-2017-01
    
    alb.ingress.kubernetes.io/group.name: production-alb
spec:
  rules:
  - host: api.mycompany.com
    http:
      paths:
      - path: /v1/*
        pathType: ImplementationSpecific
        backend:
          service:
            name: api-service
            port:
              number: 80
  - host: dashboard.mycompany.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: dashboard-service
            port:
              number: 3000
  - host: docs.mycompany.com
    http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: docs-service
            port:
              number: 80

Key Annotations Explained:

• certificate-arn: Your specific ACM certificate ARN (alternatively, use auto-discovery)

• listen-ports: Enables both HTTP and HTTPS listeners

• ssl-redirect: Automatically redirects HTTP to HTTPS

• ssl-policy: Uses secure TLS 1.2+ encryption policy

Step 8: Apply and Verify ALB Ingress

Deploy the updated ingress:

kubectl apply -f your-ingress-file.yaml

Wait 2-3 minutes for ALB to update, then test your endpoints:

# Test HTTPS endpoints
curl -I https://api.mycompany.com/v1/health
curl -I https://dashboard.mycompany.com/
curl -I https://docs.mycompany.com/

# Test HTTP redirect (should return 301/302)
curl -I http://api.mycompany.com/v1/health

Expected Results:

• HTTPS endpoints: HTTP/2 200 or appropriate status code

• HTTP endpoints: HTTP/1.1 301 Moved Permanently (redirect to HTTPS)

Scaling: Adding New Services with ACM Wildcard

The beauty of wildcard certificates is effortless scaling. To add new services:

Adding New Subdomains

Simply add new rules to your ingress - no certificate work needed:

spec:
  rules:
  # Existing rules...
  
  # New service - automatically covered by *.mycompany.com certificate
  - host: monitoring.mycompany.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: monitoring-service
            port:
              number: 3000

Steps:

1. Add the ingress rule

2. Add DNS A record: monitoring.mycompany.com → ALB IP

3. Apply ingress: kubectl apply -f ingress.yaml

4. Done! HTTPS works automatically

Troubleshooting Common ACM & ALB Issues

DNS Validation Stuck

Solutions:

• Verify CNAME record is added correctly (without domain suffix and trailing dot)

• Check DNS propagation: nslookup _validation-hash.yourdomain.com

• Wait longer - validation can take up to 30 minutes

Best Practices for ACM Wildcard Certificates

Security

• Use ELBSecurityPolicy-TLS-1-2-2017-01 or newer SSL policy

• Enable SSL redirect to enforce HTTPS

• Consider adding security headers through ingress annotations

Operational

• Document your certificate ARN for team reference

• Set up monitoring for certificate expiration (though ACM auto-renews)

• Use explicit certificate ARN in production for predictability

Cost Optimization

• Use wildcard certificates to minimize certificate count

• Leverage ALB target groups efficiently with ingress groups

Advanced ACM Configuration

Multiple Domain Levels

For complex domain structures, create multiple wildcard certificates:

bash# Main domain wildcard
aws acm request-certificate \
    --domain-name "*.mycompany.com" \
    --subject-alternative-names "mycompany.com" \
    --validation-method DNS \
    --region us-west-2

# Subdomain wildcard  
aws acm request-certificate \
    --domain-name "*.api.mycompany.com" \
    --subject-alternative-names "api.mycompany.com" \
    --validation-method DNS \
    --region us-west-2

Use multiple certificate ARNs in ingress:

textalb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:region:account:certificate/cert1,arn:aws:acm:region:account:certificate/cert2

Conclusion

AWS ACM wildcard certificates provide a robust, scalable, and zero-maintenance solution for HTTPS in Kubernetes environments. This setup gives you:

• Unlimited subdomain coverage with a single certificate

• Automatic renewal handled by AWS

• Production-grade security with modern TLS policies

• Effortless scaling for new services

The initial setup takes 30-60 minutes, but once configured, adding new HTTPS-enabled services requires only ingress rule updates and DNS records. This approach scales perfectly from small applications to enterprise-grade platforms.

For teams running production workloads on AWS EKS, this combination of ACM wildcard certificates and ALB Ingress Controller provides the ideal balance of security, maintainability, and operational simplicity.