An AWS Application Load Balancer HTTPS listener serves several domains, each with its own ACM certificate attached to the listener. Most clients work fine, but one older client always receives the certificate for a different domain and fails hostname verification. What is happening, and how do you fix it?

## How an ALB chooses a certificate A TLS handshake begins with the client's ClientHello. Server Name Indication is an optional extension in that message carrying the hostname the client intends to reach - it exists precisely because the server must choose a certificate *before* any HTTP request (and therefore before any `Host` header) has been sent. An ALB HTTPS listener holds one certificate marked as the default and a list of additional certificates. On each handshake the load balancer looks at the SNI value and selects the certificate whose subject or subject alternative names cover it. When two certificates could serve the name, the ALB prefers the better match and, among equals, the stronger key algorithm. When there is no SNI at all, there is nothing to match on and the listener falls back to its default certificate. That is the whole mechanism, and it explains the symptom exactly: an SNI-less client always sees the default certificate no matter which domain it dialled. ## Confirming it rather than guessing Reproduce both sides of the handshake from a shell: ```bash # with SNI - should show the certificate for the requested host openssl s_client -connect alb.example.com:443 -servername shop.example.com </dev/null 2>/dev/null \ | openssl x509 -noout -subject -ext subjectAltName # without SNI - shows the listener's default certificate openssl s_client -connect alb.example.com:443 </dev/null 2>/dev/null \ | openssl x509 -noout -subject ``` If the second command prints a different subject from the first, you have proven the fallback. On the AWS side, `aws elbv2 describe-listener-certificates --listener-arn ...` shows which entry carries `IsDefault: true`. ## The fixes, and what each costs **Make the client send SNI.** This is the correct fix. Nearly every current TLS stack sends it by default; a client that does not is usually an ancient runtime or a library configured to connect to a literal IP address, in which case there is no name to send. Upgrading or reconfiguring the caller solves the problem permanently and costs nothing on the AWS side. **Cover the name on the default certificate.** ACM can issue a certificate with multiple subject alternative names, including wildcards. If the default certificate lists every domain the listener serves, the fallback path stops mattering. The trade-off is one certificate shared by unrelated domains - the whole name list is visible to anyone who connects, which leaks the fact that those domains are related, and every renewal touches all of them. **Give the stubborn domain its own listener or load balancer.** Two ALBs, or one ALB and a second HTTPS listener on a different port, each with the right default certificate. This costs money and DNS complexity but is unavoidable when several SNI-less clients need different names. ## The adjacent things that break at the same time **Region.** An ACM certificate must be issued or imported in the **same Region** as the load balancer. A certificate created in `us-east-1` simply will not appear when you attach it to an ALB in `eu-west-1` - that Region rule is the one CloudFront imposes, not this one. **Security policy.** The listener's security policy - names look like `ELBSecurityPolicy-TLS13-1-2-2021-06` - fixes the TLS protocol versions and cipher suites the ALB will negotiate. A client too old to send SNI is often also too old for the policy's cipher list, and that failure looks different: the handshake fails outright with a protocol or cipher alert rather than a certificate-name error. Tightening the policy to drop TLS 1.0/1.1 is the right long-term move, but do it knowing which clients you are cutting off, and use the load balancer's TLS-version metrics to find them before you flip it. **Renewal.** ACM-issued certificates validated by DNS renew themselves as long as the validation CNAME stays in the zone and the certificate is in use. Imported certificates do not renew - you must replace them yourself before expiry, and forgetting is a classic self-inflicted outage. **Quotas.** The number of additional certificates you can attach to one ALB is a service quota - as of 2025 the default is 25 beyond the default certificate, and it is adjustable. It is a real constraint on the "one shared ALB for every tenant domain" design, and worth checking in Service Quotas before you commit to that architecture.