从Let's Encrypt迁移至AWS Certificate Manager的技术问题咨询

Hey there, let’s break down the most common issues and fixes for your setup—since you’ve migrated from a single Ubuntu/Apache server with Let’s Encrypt to an ELB using an ACM wildcard cert, here’s what to check step by step:

1. Resolve Route53 Record Conflicts & Propagation #

• First, delete the original A record for abc.xyz.com pointing to your old Ubuntu server. Route53 doesn’t allow overlapping A and CNAME records for the same subdomain—if both exist, DNS might still resolve to your old server instead of the ELB.
• Verify DNS propagation with command-line tools:
  • Run dig abc.xyz.com or nslookup abc.xyz.com locally to confirm the response shows your ELB’s domain name.
  • Flush your local DNS cache to avoid cached old records:
    • Linux: sudo systemd-resolve --flush-caches
    • Windows: ipconfig /flushdns
    • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

2. Validate ELB Listener Configuration #

• Ensure your ELB has an HTTPS listener (port 443) configured to use your ACM *.xyz.com wildcard certificate. Double-check that it maps to the correct backend port (usually 80 or 443, depending on your instances’ setup).
• Confirm your ELB’s security group allows inbound traffic on port 443 from your desired IP ranges (e.g., 0.0.0.0/0 for public access). Also, make sure your instances’ security groups accept traffic from the ELB’s security group on the backend port.
• If you’re still using HTTP (port 80), set up a listener rule to redirect all HTTP traffic to HTTPS to avoid mixed-content errors.

3. Confirm ACM Certificate Validity & Coverage #

• Verify your *.xyz.com wildcard certificate fully covers abc.xyz.com (wildcards apply to immediate subdomains, which this is—no issues here for your setup).
• Check the ACM console to ensure the certificate is successfully validated. Since you’re using Route53 with the same AWS account, validation should have auto-completed via a temporary CNAME record ACM creates. If validation failed, re-initiate it and ensure the Route53 record isn’t deleted prematurely.

4. Rule Out Old Server Interference #

• Temporarily stop the Apache service on your old Ubuntu server with sudo systemctl stop apache2. This eliminates the chance that lingering DNS propagation is sending traffic to the old server with the Let’s Encrypt cert.
• If you still see issues after stopping Apache, you can be confident traffic is reaching the ELB, not the old server.

5. Check ELB Health Checks #

• Confirm your ELB’s health checks are passing for both instances. If health checks fail, the ELB won’t route traffic to the instances, leading to errors even if your certificate is correct.
• Verify the health check path (e.g., /) returns a 200 OK response from your instances. Adjust the path or instance configuration if needed to fix failing checks.

6. Diagnose SSL/TLS Handshakes #

• Use openssl s_client -connect abc.xyz.com:443 to inspect the SSL handshake. Look for the certificate details—they should match your ACM wildcard cert, not the old Let’s Encrypt one.
• If you see "certificate name mismatch" errors, double-check that the ELB listener is assigned the correct ACM certificate (not an older, unused cert in your ACM account).

内容的提问来源于stack exchange，提问作者Hussain K