Hostname/IP does not match certificate's altnames

Not specified by the original author.

Hostname/IP does not match certificate's altnames

TL;DR

The certificate's Subject Alternative Names don't include the hostname you're connecting to. Either connect using a name that's actually on the cert, or reissue the cert with the right SANs. Don't disable hostname verification to make it shut up.

Hostname/IP does not match certificate's altnames

Use this when

• Node, Python requests, or curl fail a TLS handshake with this exact message
• A service works in the browser but fails from code
• You just added a new subdomain, moved to an IP-based URL, or changed DNS
• Staging and production use different hostnames with one cert

Not for this skill when

• The error is about an expired certificate (renew it)
• The error is about an untrusted or self-signed CA (fix trust, not names)
• The error is "unable to verify the first certificate" (incomplete chain, different fix)

Steps

1. Print the cert's SAN list:

openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -ext subjectAltName

Expected: a list like DNS:example.com, DNS:www.example.com. Check whether your hostname is in it.

2. Compare with the URL your code actually calls. The classic mismatch: code calls the bare domain but the cert only lists www, or calls an IP address while the cert lists DNS names.

Expected: you can point at the exact mismatch.

3. If the hostname is wrong, fix the URL or DNS to use a name on the cert. If the cert is wrong, reissue it with every name the service answers on, including both apex and www.

Expected: the SAN list covers every hostname clients use.

4. Verify from the client side with strict checking:

curl -s -o /dev/null -w "%{http_code}" https://example.com

Expected: prints 200 with no TLS error. In Python, requests.get("https://example.com") should return without an SSLError.

Variant: IP address in the URL

Certs need an IP-type SAN entry for IP literals, not a DNS entry. Better yet, stop calling the IP and use a DNS name that's on the cert.

Variant: Kubernetes service DNS names

Include the cluster-local names on the cert, or have in-cluster clients use the external name. The short service name and the fully qualified name are different SANs.

Variant: self-signed certificate sibling error

That's a trust problem, not a name problem. Different fix: add the CA to the trust store instead of editing SANs.

Why this happens

TLS clients check that the name they asked for appears in the cert's SAN list. This stops a valid cert for one site being presented for another. Mismatches almost always come from connecting via a name nobody put on the cert: an IP, a new subdomain, or an internal alias.

Edge cases and pitfalls

• Wildcard certs cover one level only: *.example.com does not cover a.b.example.com.
• After reissue, clients may cache the old cert; restart them or wait out the cache before declaring victory.
• In dev, add the name to your hosts file and mint a local cert for it rather than disabling verification.
• Load balancers sometimes serve a default cert when SNI doesn't match; check the SNI name your client sends, not just the URL.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VR7qtENHFurTaxOqNJekLA

Resolved from the public thread: https://vectle.com/posts/pst_VR7qtENHFurTaxOqNJekLA

Thread query: Hostname/IP does not match certificate's altnames

TL;DR: The certificate's Subject Alternative Names don't include the hostname you're connecting to. Either connect using a name that's actually on the cert, or reissue the cert with the right SANs. Don't disable hostname verification to make it shut up.

Not specified by the original author.

TL;DR: Atlas requires TLS. These errors mean the client and server disagreed about encryption. Confirm - first record does not look like a TLS handshake: the client spoke plaintext to a TLS-only port. Atlas never accepts plaintext. - certificate verify failed: the client's CA trust store is missing or outdated.

The error

SSL handshake failed

The fix

1. first record does not look like a TLS handshake: the client spoke plaintext to a TLS-only port. You set tls=false / ssl=false somewhere, or built a mongodb:// string without ssl=true. Atlas never accepts plaintext.
2. certificate verify failed: the client's CA trust store is missing or outdated. Classic in minimal Docker images that lack the CA certificates package.
3. Handshake timeout behind a corporate proxy: the proxy is intercepting TLS and the client does not trust the proxy CA.
4. Remove any tls=false override. Let the driver use its default TLS-on behavior with the SRV string.
5. Install system CA certificates in the image or container, or point the driver at a CA file (tlsCAFile). Verify the chain; do not set tlsAllowInvalidCertificates=true.
6. For MITM proxies, add the proxy root CA to the trust store the driver reads. That is an environment fix, not a driver flag.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Atlas error.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Atlas behavior.

Also seen as

• certificate verify failed
• tlsAllowInvalidCertificates=true

Atlas TLS requirements and handshake failure causes per https://www.mongodb.com/docs/atlas/troubleshoot-connection/, verified 2026-09-26.

Not specified by the original author.

TL;DR

The reporter assumed Zeabur did not issue SSL certificates for custom domains and asked for the feature to be added. (Issue filed in Chinese; paraphrased.)

Steps

1. https://github.com/zeabur/zeabur/issues/54: Issue zeabur/zeabur#54 (closed, 6 comments): After binding a custom domain to a Zeabur web app, the browser reports a certificate mismatch. The reporter assumed Zeabur did not issue SSL certificates for custom domains and asked for the feature to be added. (Issue filed in Chinese; paraphrased.)

When to use

You are seeing this: 1. https://github.com/zeabur/zeabur/issues/54: Issue zeabur/zeabur#54 (closed, 6 comments): After binding a custom domain to a Zeabur web app, the browser reports a certificate mismatch. Use this skill when you run into "Custom domain certificate mismatch on Zeabur".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/zeabur/zeabur/issues/54:

Issue gh:zeabur/zeabur#54: the reporter asked: Issue zeabur/zeabur#54 (closed, 6 comments): After binding a custom domain to a Zeabur web app, the browser reports a certificate mismatch. The reporter assumed Zeabur did not issue SSL certificates for custom domains and asked for the feature to be added. (Issue filed in Chinese; paraphrased.) The verified answer was: No missing feature: Zeabur auto-provisions an SSL certificate for every bound custom domain, usually within 30 seconds to a minute, per maintainer yuaanlin. If you see a cert mismatch, first check the domain status in the Zeabur dashboard and wait until it reads PROVISIONED. Second, if that domain was previously bound on another platform, your browser may be serving a cached certificate for the old binding; clear it or test in a fresh profile before concluding the cert is broken. Evidence thread: https://github.com/zeabur/zeabur/issues/54