No subject alternative names matching IP address … found

Where you see it

In Java programs that connect over TLS to an IP address: JDBC URLs, Kafka bootstrap servers, Elasticsearch and other cluster clients, health checks and scripts. Java’s hostname check throws a CertificateException, which reaches you inside an SSLHandshakeException:

javax.net.ssl.SSLHandshakeException: No subject alternative names matching IP address 10.0.0.5 found
	...
Caused by: java.security.cert.CertificateException: No subject alternative names matching IP address 10.0.0.5 found

Newer Java releases (JDK 23 and later, 21.0.9 and later, 17.0.19 and later) put the TLS alert in front of the outer message: (certificate_unknown) No subject alternative names matching IP address 10.0.0.5 found. The same check, in OpenJDK’s HostnameChecker, reports three related variants:

java.security.cert.CertificateException: No subject alternative DNS name matching api.internal.example.com found.
java.security.cert.CertificateException: No subject alternative names present
java.security.cert.CertificateException: No name matching api.internal.example.com found

What it means

A certificate lists the names and addresses it is valid for in its Subject Alternative Name (SAN) extension. Java checks an IP address only against IP Address entries, never against DNS names and never against the Common Name. The certificate was trusted, but it does not contain the IP address you connected to, so Java refuses it.

Likely causes

You connect by IP address, and the certificate only has DNS names

The most common case. Look at what the certificate contains:

openssl s_client -connect 10.0.0.5:443 -servername db.internal.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

subject=CN=db.internal.example.com
X509v3 Subject Alternative Name: 
    DNS:db.internal.example.com

Fix 1 (preferred): connect by the DNS name in the certificate, for example jdbc:postgresql://db.internal.example.com:5432/app instead of jdbc:postgresql://10.0.0.5:5432/app. If there is no DNS record, ask for one; names survive IP changes, addresses do not.

Fix 2: if clients must use the address, reissue the certificate with an IP entry. With a private CA:

openssl req -new -key server.key -subj "/CN=db.internal.example.com" \
  -addext "subjectAltName=DNS:db.internal.example.com,IP:10.0.0.5" -out server.csr

Check that your CA copies the requested SANs into the certificate. Public CAs do not issue certificates for private (reserved) IP addresses.

A cluster hands out IP addresses

Your configuration uses a name, but the error still shows an IP. Clustered systems often tell clients where to connect next: Kafka through advertised.listeners, Elasticsearch through its publish address, service discovery through IP-based endpoints. Configure those to advertise DNS names that are in the certificates, or issue node certificates that include their IP addresses.

The DNS name is not in the certificate

For No subject alternative DNS name matching … found., the name you use is missing from the SAN list. Compare with the openssl x509 -ext subjectAltName output above; connect with a listed name or reissue the certificate with every name clients use. Remember that *.example.com covers exactly one label, not example.com and not a.b.example.com.

The certificate has no SAN at all

No subject alternative names present means you connected by IP address and the certificate has no SAN extension at all. No name matching … found means you connected by name, the certificate has no DNS entries in its SAN, and Java’s fallback to the Common Name did not match either. Old internal certificates often look like this. Reissue them with a SAN list; browsers and Go do not accept a name that is only in the Common Name.

The server sends another certificate than you expect

A server or load balancer with several certificates chooses one by the name in SNI. When you connect by IP address, Java sends no SNI, and you may get a default certificate. Connect by name, or check what each name returns with openssl s_client -servername.

Check yours

Try it: Hostname matcherOpen the full tool

Runs in your browser. Nothing you paste is sent anywhere.

What do you have?

A certificateA list of names

Paste the server's certificate

Try a sampleChoose a sample…A wildcard certificate (*.example.com)A website certificate (www.example.com)A certificate with a Common Name but no SAN

-----BEGIN CERTIFICATE----- MIIC1zCCAnygAwIBAgIQWTTOzqWiPshGdQhNb6kmNjAKBggqhkjOPQQDAjB+MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQUEtJIFplcm8gdG8gSGVybzEnMCUGA1UECxMe U2FtcGxlcyAtIG5vdCBwdWJsaWNseSB0cnVzdGVkMSswKQYDVQQDEyJQS0kgWmVy byB0byBIZXJvIFNhbXBsZSBJc3N1aW5nIENBMB4XDTI2MTAwMTAwMDAwMFoXDTM2 MTAwMTAwMDAwMFowGjEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMFkwEwYHKoZI zj0CAQYIKoZIzj0DAQcDQgAEw4og6Y/SOr+WrqSv+ng7tOBEsc5N3A3yZRk+9hsR XzPQvB9672aHZHTYFNlSY93RWVcTRieE+8XnIbWIYfwxIqOCAT4wggE6MAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMBMGA1UdJQQMMAoGCCsGAQUFBwMBMCcG A1UdEQQgMB6CD3d3dy5leGFtcGxlLmNvbYILZXhhbXBsZS5jb20wHQYDVR0OBBYE FALMipe4vcXJTpwO926S15Y/bobzMB8GA1UdIwQYMBaAFN+ph37v40SN23r6Fg/z OvSNjJqeMEgGCCsGAQUFBwEBBDwwOjA4BggrBgEFBQcwAoYsaHR0cDovL3BraS5l eGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcnQwPQYDVR0fBDYwNDAyoDCg LoYsaHR0cDovL3BraS5leGFtcGxlLmNvbS9zYW1wbGUtaXNzdWluZy1jYS5jcmww EwYDVR0gBAwwCjAIBgZngQwBAgEwCgYIKoZIzj0EAwIDSQAwRgIhAM5dJUPhL+qV artvWtQinfnykhVflJTjMXe8M6PnqQfaAiEAhOLGj1hSEkNxQoMrYNXRaIe69nq6 2unibVFSVw1AC80= -----END CERTIFICATE-----

Choose a file

Host name you connect to

Paste the server’s certificate and type the IP address or name you connect to. The matcher shows the SAN entries and why an address does not match a DNS name.

Learn why

• Names and jobs: SANs, wildcards, key usage and the CA flag
• The TLS 1.3 handshake: SNI and default certificates.
• Related: PKIX path building failed (the trust problem in Java), Hostname mismatch in Python.

In the gameLevel 9: Names and jobsName Registry, Keystone. In development