Fix Hostname/IP Does Not Match Certificate Altnames

This error means the HTTPS client connected to a server that presented a certificate not valid for the hostname or IP address in the URL. The certificate may be trusted, current, and issued by a public certificate authority, but TLS validation still fails if its Subject Alternative Name (SAN) list does not contain the requested identity. The fix is to identify the hostname the client expects, inspect the certificate actually returned by the server, and correct the URL, certificate, DNS, SNI, or proxy routing that caused the mismatch.

Use this table to match the error message to the likely fault before changing certificate settings.

Symptom	Likely Cause	Safe Fix
The error says `Host: api.example.com` but the certificate lists another domain	Wrong certificate selected by a virtual host, load balancer, or proxy	Configure SNI and routing so `api.example.com` receives its own certificate
The URL uses `https://<IP_ADDRESS>`	The certificate has DNS names but no matching IP SAN	Use the DNS hostname, or issue a certificate with that exact IP address in an IP SAN
The request works in a browser but fails in Node.js, a container, or CI	Different DNS result, proxy, CA bundle, or SNI behavior in that runtime	Test from the failing environment and compare the presented certificate
The certificate lists the correct name in one environment but not another	A stale load balancer node, DNS record, CDN rule, or ingress configuration returns an old/default certificate	Correct the affected route and retest each endpoint
The application uses a self-signed or private-CA certificate	The client may not trust the issuer, and the hostname may also be wrong	Make the SAN match the URL, then configure the client to trust the private CA

What the Hostname/IP Certificate Error Means

TLS does more than encrypt traffic. Before sending an HTTP request, the client checks whether the server can prove its identity. For a request such as:

https://api.example.com/v1/status

the client expects a certificate whose SAN extension contains DNS:api.example.com.

A certificate can contain several identities, for example:

DNS:api.example.com
DNS:api.internal.example.com
DNS:*.services.example.com

If the server instead presents a certificate containing only DNS:source.example.com, Node.js rejects it when the request URL is https://target.example.com.

This is separate from certificate-chain validation:

A trusted certificate authority proves who issued the certificate.
Valid dates prove the certificate is currently usable.
A complete chain lets the client reach a trusted issuer.
The SAN list proves that the certificate belongs to the hostname or IP address requested.

All four checks can matter. A publicly trusted, unexpired certificate with a complete chain still fails if its SAN does not match the URL.

Modern clients use the SAN extension for hostname validation. The older Common Name field is not a reliable substitute, and a port does not belong in a certificate name. For example, a certificate should contain DNS:api.example.com, not DNS:api.example.com:8443.

How to Fix the Certificate Name Mismatch

Fix the mismatch by using the requested DNS hostname or deploying a certificate whose SAN matches the requested identity.

Step 1: Record the Exact Name the Client Is Validating

Find the URL used by the failing request.
Copy the hostname exactly, without the protocol, path, or port.
Note whether the URL uses a DNS name or a numeric IP address.
Check whether the failing request runs behind a proxy, in a container, or in a different network from your local test.

For this URL:

https://api.example.com:8443/orders

the identity being checked is api.example.com. The port is 8443, but it is not part of the certificate name.

For this URL:

https://203.0.113.10/orders

the identity being checked is the IP address 203.0.113.10. A SAN entry of DNS:api.example.com does not validate a direct connection to that IP.

I reproduce this kind of problem one request at a time in a clean container or virtual environment, because it removes machine-specific DNS and proxy noise.

Also record the error’s two important parts:

The Host: value is what the client expected.
The cert's altnames: value is what the server actually presented.

If the error says the host is target.domain.com but the certificate lists DNS:source.domain.com, do not assume the target certificate is broken. The request may have reached the wrong server, a default virtual host, or an intermediary that selected the source certificate.

Step 2: Inspect the Certificate Returned for the Requested Hostname

Run the test from the same machine, container, pod, or CI runner that fails. Replace api.example.com and 443 with the hostname and port from your application URL.

openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -ext subjectAltName

The important output is the X509v3 Subject Alternative Name section. Look for the exact requested identity:

X509v3 Subject Alternative Name:
    DNS:api.example.com

If the application connects by IP address, look for an IP SAN instead:

X509v3 Subject Alternative Name:
    IP Address:203.0.113.10

A DNS SAN and an IP SAN are different certificate identities. The text DNS:203.0.113.10 is not a valid replacement for IP Address:203.0.113.10.

Then run a hostname-verification test:

openssl s_client -connect api.example.com:443 -servername api.example.com -verify_hostname api.example.com </dev/null

A successful result ends with a verification result of 0 (ok). A mismatch confirms that the endpoint is returning the wrong certificate, the certificate lacks the requested SAN, or the request is reaching an unexpected destination.

The -servername argument sends Server Name Indication (SNI). On a server hosting multiple HTTPS sites on one IP address, SNI tells the server which certificate to return.

Step 3: Correct the URL or Endpoint Identity

Use the certificate’s SAN entries and the endpoint it returned to select the applicable repair.

If the Application Used an IP Address

Change the application URL to the service’s DNS hostname:

https://api.example.com

Do not use this as a production workaround:

https://203.0.113.10

When a TLS certificate does not list a service IP address as an alternative name, direct IP connections can fail validation and require a hostname.

If you genuinely need clients to connect by IP address, reissue the certificate with that exact address as an IP SAN. This is usually less flexible than using a stable DNS name, especially when the service sits behind a load balancer, CDN, ingress controller, or failover setup.

If the Certificate Is Missing a DNS Name

Issue and deploy a replacement certificate containing every hostname that clients use. For example, if users and applications reach both names, the SAN list needs both:

DNS:api.example.com
DNS:api.internal.example.com

A wildcard certificate such as *.example.com can cover one subdomain level, such as api.example.com, but it does not cover example.com itself or deeper names such as v1.api.example.com.

After issuing the certificate, attach it to the HTTPS listener, reverse proxy, load balancer, CDN distribution, or Kubernetes ingress that serves the hostname. Use openssl s_client with the requested hostname as -servername to confirm the endpoint presents the replacement certificate.

If the Server Returns Another Site’s Certificate

Fix certificate selection rather than reissuing an unrelated certificate. Common places to check are:

The default HTTPS virtual host in Nginx, Apache, Caddy, or another reverse proxy
A load balancer listener with the wrong certificate attached
A CDN origin or edge rule
A Kubernetes Ingress host rule and its TLS certificate reference
A proxy that connects upstream by IP instead of by the intended DNS hostname
A stale deployment instance that still has an old certificate

The requested hostname must be sent as SNI, and the proxy or server must map that name to the correct certificate.

For an SNI-enabled backend whose certificate does not contain its direct IP address, connect with its DNS hostname and send that hostname as SNI; direct-IP testing can select the wrong virtual host and also fail SAN validation.

Step 4: Deploy the Correct Route and Retest It

After changing the application URL, certificate, ingress, proxy, or load balancer configuration:

Reload or restart the component that terminates TLS.
Test the public hostname from the same failing environment.
Confirm the SAN list includes the hostname from the application URL.
Run the application request again with normal certificate verification enabled.
Remove temporary debugging overrides, alternate hosts files, and test proxy settings.

To test a specific backend IP while keeping the correct hostname, use curl --resolve. Replace the sample address with the backend’s actual address:

curl --resolve api.example.com:443:203.0.113.10 -vI https://api.example.com/

This connects to the chosen IP while preserving api.example.com in the URL, HTTP Host header, TLS hostname check, and SNI value. It is much more useful than browsing directly to https://203.0.113.10.

IP Addresses, SNI, and Reverse Proxies

Direct IP access is a common source of this error because it changes both certificate validation and virtual-host selection.

A request to:

https://api.example.com

normally does this:

DNS resolves api.example.com to an IP address.
The client connects to that IP.
The client sends api.example.com through SNI.
The server selects the certificate configured for api.example.com.
The client validates DNS:api.example.com in the certificate SAN list.

A request to:

https://203.0.113.10

changes the expected identity to the IP address. It may also omit useful SNI information, causing a shared endpoint to return its default certificate.

Setting only an HTTP Host header does not fix this. TLS negotiation happens before the HTTP request is sent, so the server must choose its certificate before it sees the HTTP headers.

This is particularly important for:

API gateways
CDN origins
Nginx and Apache name-based virtual hosts
Cloud load balancers
Kubernetes ingress controllers
Service meshes and TLS-terminating proxies
Private services reached through /etc/hosts overrides

If an upstream proxy connects to https://10.0.0.15 while expecting api.internal.example.com, configure it to use the DNS hostname for TLS or explicitly set the upstream TLS server name in that proxy’s supported configuration.

Node.js, Containers, and Kubernetes Cases

Node.js commonly reports this failure as ERR_TLS_CERT_ALTNAME_INVALID along with text similar to “Hostname/IP does not match certificate’s altnames.” The runtime is correctly preventing a client from sending credentials or API data to a server that cannot prove it owns the requested name.

A documented Got mismatch case used Node.js v16.19.0 and Got 11.8.2, but this error is usually caused by endpoint configuration rather than that version pair. Check the runtime that makes the HTTPS request:

node --version

Check the application’s installed Got package version:

npm ls got

The reported Got/Node case showed a request for one domain receiving a certificate containing another domain’s SAN, despite both domains having publicly signed certificates and complete chains. That pattern points to certificate selection, DNS, proxying, or routing, not automatically to a bad certificate chain.

Containers and CI Runners

A container can resolve a hostname differently from your laptop because it has different DNS servers, search domains, /etc/hosts entries, VPN access, proxy environment variables, or service-discovery rules.

From the failing container, check the resolved addresses:

getent ahosts api.example.com

Compare that result with the destination expected by your load balancer or ingress. If the container reaches an older address or internal endpoint, correct the container DNS configuration, service record, or routing rule rather than changing the client to ignore TLS errors.

Kubernetes Ingress and Service Routing

For a Kubernetes HTTPS ingress, verify that all three names align:

The client URL hostname
The Ingress spec.rules.host value
The hostname covered by the certificate referenced in spec.tls

The ingress controller must receive the SNI name and select the certificate for that host. A fallback or default certificate often appears when the hostname has no matching TLS rule, the secret is attached to the wrong ingress, or traffic reaches a different ingress controller than expected.

For internal service-to-service traffic, use a stable DNS name that appears in the upstream certificate. Do not replace that name with a ClusterIP, Pod IP, node IP, or load-balancer IP unless the certificate explicitly contains that IP as an IP SAN.

What Not to Disable

Do not solve this in production by disabling certificate verification. These examples suppress an important identity check:

process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0'

rejectUnauthorized: false

They may make a request appear to work, but they allow a client to accept a certificate for the wrong server. That defeats a key protection TLS provides against interception and misrouting.

A private CA or self-signed certificate needs two separate fixes when both conditions apply:

The certificate SAN must match the hostname in the URL.
The client must trust the private CA that issued the certificate.

Adding a certificate authority to a trust store fixes issuer trust. It does not make an unrelated hostname valid.

Confirm the Fix and Prevent a Repeat

Before closing the incident, confirm these points:

The application URL uses the intended DNS hostname.
The certificate returned with SNI contains that hostname in its SAN list.
The certificate chain is trusted by the application runtime.
DNS resolves to the intended endpoint from containers, CI, and production hosts.
The load balancer, proxy, or ingress selects the correct certificate for the hostname.
Certificate renewal automation preserves every required SAN.
No production code uses rejectUnauthorized: false or a global TLS-verification override.

For services with several public names, keep a small inventory of each hostname, its TLS termination point, and the certificate SANs it requires. That makes certificate renewal and routing changes much easier to verify before deployment.

Frequently Asked Questions

What Does a Hostname Mismatch Notification Mean?

A hostname mismatch notification means an app connected to a server whose TLS certificate does not identify the hostname or IP address in the app’s URL. The server may still be online, but the app cannot safely confirm it reached the intended service. Check the URL hostname and compare it with the certificate’s DNS: or IP Address: SAN entries.

Can I Use HTTPS With an IP Address Instead of a Domain Name?

Yes, but the certificate must contain that exact numeric address as an IP SAN, such as IP Address:203.0.113.10. A certificate that contains only DNS:api.example.com validates requests to https://api.example.com, not requests to https://203.0.113.10. Using the service hostname is usually the better choice for SNI-enabled or load-balanced services.

Does a Self-Signed Certificate Cause This Error?

A self-signed certificate can be involved in this error, but self-signed status and hostname mismatch are separate checks. A self-signed certificate for DNS:dev.example.test can work when the client trusts its issuing certificate and connects to https://dev.example.test. It still fails if the client connects to a different hostname or directly to an IP address not present as an IP SAN.

Why Does It Work in My Browser but Fail in Node.js or Docker?

The browser and Node.js process may use different DNS answers, proxy settings, certificate stores, or network routes. Test from the failing runtime with openssl s_client -connect api.example.com:443 -servername api.example.com -verify_hostname api.example.com </dev/null to see the certificate that runtime’s network path returns. Correct the differing route or trust configuration rather than turning off validation.

Does Adding a Port to the Certificate Name Fix It?

No. Certificates validate hostnames and IP addresses, not TCP ports. For https://api.example.com:8443, the certificate needs DNS:api.example.com; it should not contain api.example.com:8443.