Introduction

A valid certificate still produces hostname mismatch errors if the load balancer presents the wrong one. This commonly happens after adding another site to the same listener, rotating certificates without updating the listener attachment, or relying on SNI while the wrong default certificate remains first in the selection order.

Symptoms

  • Browsers report a certificate mismatch even though the target certificate exists in the account
  • One host name works while another on the same listener shows the wrong certificate
  • The issue started after attaching an additional domain or rotating certificates
  • Direct origin access may present the correct certificate while the load balancer does not

Common Causes

  • The listener is attached to the wrong certificate
  • SNI certificate selection does not include the requested host name
  • The new certificate does not actually contain the required SAN entry
  • The wrong default certificate is served to clients that do not negotiate as expected

Step-by-Step Fix

  1. 1.Inspect the certificate actually presented by the public endpoint
  2. 2.Test the live listener instead of assuming the dashboard attachment is correct.
bash
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -subject -issuer -ext subjectAltName
  1. 1.Check which certificate is attached to the load balancer listener
  2. 2.Compare the listener attachment with the certificate ARN you intended to serve.
bash
aws elbv2 describe-listeners --load-balancer-arn <alb-arn>
aws elbv2 describe-listener-certificates --listener-arn <listener-arn>
  1. 1.Attach the correct certificate and keep SNI ordering clean
  2. 2.Make sure the requested host name is covered by the certificate attached to the listener.
bash
aws elbv2 add-listener-certificates --listener-arn <listener-arn> --certificates CertificateArn=<correct-cert-arn>
  1. 1.Retest the exact host name after the listener update
  2. 2.Re-run the live handshake check and confirm the SAN list now includes the requested name.
bash
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -ext subjectAltName

Prevention

  • Verify listener certificate attachments after every certificate rotation
  • Use SAN coverage reviews when consolidating many domains on one listener
  • Test each public host name with SNI-aware tools after load balancer changes
  • Document which listener certificate is default and which are SNI attachments

Verification

After applying the fix, verify the exact symptom that made the incident visible instead of relying on one green log line. Re-run the command, request, deployment, or browser path that failed before the change and capture the new output for the incident record.

  • Confirm the original error message no longer appears in application, platform, or edge logs.
  • Check the affected dependency path from the client side and from the server side when both are available.
  • Watch the next scheduled job, deploy, cache refresh, or certificate renewal cycle so the fix survives the normal operating path.
  • Record the final configuration value, command output, and timestamp in the runbook for SSL SAN Mismatch Because the Load Balancer Is Serving the Wrong Certificate.

Rollback

If the fix changes routing, credentials, certificates, state, cache behavior, or runtime configuration, keep a rollback path ready before applying it to production. Save the previous configuration, identify the owner of the affected service, and define the signal that will trigger rollback.

  1. 1.Restore the last known-good configuration or state reference if validation shows a wider blast radius.
  2. 2.Re-run the same diagnostic checks from the fix section to confirm the rollback returned the system to the previous behavior.
  3. 3.Leave a short note explaining why the attempted fix was reverted so the next responder does not repeat the same change.

Operational Notes

Use this guide as an incident workflow, not as a blind checklist. The safest order is to collect the current state, confirm the narrowest failing component, apply one focused change, and then re-test the same path that failed. Avoid combining unrelated fixes during SSL SAN Mismatch Because the Load Balancer Is Serving the Wrong Certificate; otherwise the team will not know which change restored service or which change caused a later regression.

For production systems, capture command output before and after each change. Include timestamps, hostnames, environment names, account IDs, namespaces, certificate names, or configuration keys when they are relevant. These details make the guide useful during a future incident and help separate a real recurrence from a similar-looking but unrelated failure.

Escalate when the failing path crosses a boundary your team does not own, such as a managed cloud control plane, identity provider, external DNS service, payment gateway, or shared network appliance. Share the exact failing request, correlation ID, command output, and change window with the owning team. Keep customer-facing mitigation separate from root-cause repair: it is often safer to route around the broken dependency first, then schedule the permanent cleanup after traffic is stable.

  • [SSL certificate troubleshooting: Fix Certificate And Private Key Do Not Match Issue](certificate-and-private-key-do-not-match)
  • [Fix Fix Acme Account Still Using Old DNS Provider Credentials After Migration Issue in SSL](fix-acme-account-still-using-old-dns-provider-credentials-after-migration)
  • [Fix Fix Acme Challenge Returning 404 Issue in SSL](fix-acme-challenge-returning-404)
  • [Fix Fix Acme Http 01 Challenge Failing Due To Redirect Issue in SSL](fix-acme-http-01-challenge-failing-due-to-redirect)
  • [Fix Fix Apache Too Many Redirects After SSL Issue in SSL](fix-apache-too-many-redirects-after-ssl)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "SSL SAN Mismatch Because the Load Balancer Is Serving the Wrong Certificate", "description": "Resolve SSL SAN mismatch errors by checking SNI certificate selection, listener rules, and the exact host name attached to the load balancer certificate.", "url": "https://www.fixwikihub.com/ssl-san-mismatch-load-balancer-serving-wrong-certificate", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2026-04-10T04:45:00.000Z", "dateModified": "2026-04-10T04:45:00.000Z" } </script>