AWS Route53通配符子域名绑定ELB的SSL证书错误技术问询

Alright, let's figure out why you're hitting that SSL certificate error when accessing HTTPS—since HTTP works fine, we can narrow this down to a few key configuration issues with your ELB, certificate, or routing. Here's what to check step by step:

1. First, confirm your ACM certificate actually covers your target domain #

Your current certificate is issued for *.domain.com and domain.com, but here's a critical detail: SSL wildcard certificates only match direct subdomains of the base domain. That means *.domain.com works for testing.domain.com, but not for nested subdomains like app.testing.domain.com (which falls under *.testing.domain.com).

If you're accessing a URL like something.testing.domain.com, your browser will throw a certificate error because the certificate doesn't include that nested wildcard. Fix this by:

• Requesting a new ACM certificate that adds *.testing.domain.com to the list of covered domains, or
• If you only need specific subdomains under testing.domain.com, adding those explicitly (e.g., app.testing.domain.com) to the certificate.

2. Check your ELB's HTTPS listener setup #

Make sure your ELB's 443-port listener is using the correct ACM certificate:

• Head to the AWS Console, find your ELB, and navigate to the Listeners tab.
• For the 443 listener, verify the attached SSL certificate is the one with your intended domain coverage (including *.testing.domain.com if you updated it). It's easy to accidentally pick a default or old certificate here.
• Also, confirm the listener is set to terminate SSL at the ELB—this is the standard setup when using ACM with an ELB. If you're forwarding HTTPS traffic directly to Nginx (target port 443), Nginx would need its own matching certificate, which isn't your intended setup here.

3. Fix your ELB target group's forwarding port #

Since the ELB is handling SSL termination, it should forward traffic to Nginx's HTTP port (80), not HTTPS (443):

• Go to your ELB's target group settings. If the registered port is 443, your ELB is sending encrypted traffic to Nginx, which doesn't have the right certificate (you're relying on the ELB's cert). Switching the target group to use port 80 will eliminate this mismatch.

4. Test the certificate directly to rule out browser issues #

Sometimes browser cache can mask the real problem. Use openssl to check what certificate the ELB is presenting for your domain:

openssl s_client -connect your-elb-dns-name.elb.amazonaws.com:443 -servername your-specific-subdomain.testing.domain.com

Look at the Subject and Subject Alternative Name fields in the output. If these don't include your *.testing.domain.com subdomain, that confirms the certificate coverage is the issue.

5. Double-check your Route53 record #

It sounds obvious, but make sure your *.testing.domain.com Route53 record is pointing to the correct ELB. Accidentally pointing it to a different ELB (like a classic ELB instead of an application ELB) that doesn't have your ACM certificate attached will definitely cause this error.

Once you've worked through these steps, clear your browser cache and test HTTPS again. The most likely culprits are either the certificate not covering your nested subdomain, or a misconfigured ELB listener/target group.

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