Hostname/IP Does Not Match Certificate's Altnames (ERR_TLS_CERT_ALTNAME_INVALID)

Node.js raises ERR_TLS_CERT_ALTNAME_INVALID from tls.checkServerIdentity(), after the chain has already been verified. The message format is fixed in the Node.js source (lib/tls.js, lib/internal/errors.js):

• Hostname/IP does not match certificate's altnames: Host: api.example.com. is not in the cert's altnames: DNS:www.example.com, DNS:example.com
• Hostname/IP does not match certificate's altnames: IP: 203.0.113.10 is not in the cert's list: — you connected by IP and the certificate has no matching IP-address entry (an empty list means none at all).
• Host: api.example.com. is not cert's CN: ... — the certificate has no DNS names in subjectAltName, so Node fell back to the Common Name, and that did not match either.
• Cert does not contain a DNS name — there is nothing to compare against.

The dot after the host name in the message is part of Node's format, not a typo in your URL. The error object also carries reason, host and cert properties, so you can log exactly which names the server presented.

Node's matcher follows RFC 6125 strictly. It compares label by label, allows one * only in the left-most label, rejects patterns with two labels or fewer (no *.com), and does not expand a wildcard inside a punycode (xn--) label. The Common Name is consulted only when the certificate has no DNS names at all, which is rare for public certificates today.

Node checks the name in servername if you set it, otherwise host (lib/internal/tls/wrap.js). That is why connecting to an IP address while the certificate is issued for a name always fails unless you pass the name separately.

node -e "
const tls = require('tls');
const s = tls.connect({host: 'api.example.com', port: 443, servername: 'api.example.com'}, () => {
  console.log(s.getPeerCertificate().subjectaltname); s.end();
});
s.on('error', e => console.log(e.code, e.reason));"

The same check from the shell, with the same SNI:

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

If the names printed are for a different site, the request reached the wrong server: compare dig +short api.example.com with the address your code uses, and check whether a proxy or load balancer default certificate is answering.

1. Use a host name the certificate lists. Replace IPs and internal aliases in configuration with the public name, or add an internal DNS record for that name.
2. Must connect to a specific IP? Keep the name for SNI and the identity check by passing it as servername:

   https.get({host: '203.0.113.10', servername: 'api.example.com',
              headers: {Host: 'api.example.com'}, path: '/health'}, res => {
     console.log(res.statusCode);
   });

3. Service-to-service inside a cluster: issue the internal certificate with the names clients actually use (for example the service DNS name) in subjectAltName, from your internal CA.
4. Bare domain or deeper subdomain: add example.com or a.b.example.com explicitly next to *.example.com when you reissue.
5. Do not override checkServerIdentity with a function that returns undefined, and do not set rejectUnauthorized: false. Both accept a certificate for any other domain signed by any trusted CA.

node -e "require('https').get('https://api.example.com/', r => console.log(r.statusCode)).on('error', e => console.log(e.code, e.reason))"
# 200
openssl s_client -connect api.example.com:443 -servername api.example.com -verify_hostname api.example.com </dev/null 2>/dev/null | grep 'Verify return code'
# Verify return code: 0 (ok)

The SSL/TLS checker lists the names on the certificate your server presents, so you can see whether the host you call is covered before you change code.

• NET::ERR_CERT_COMMON_NAME_INVALID — the same mismatch in Chrome
• SSL_ERROR_BAD_CERT_DOMAIN — the same mismatch in Firefox
• SSLPeerUnverifiedException — Java's host name failure
• unable to verify the first certificate — chain problem, checked before the name
• Certificate name mismatch — background and fixes