🚨 Kafka Error Guide: 'No subject alternative names matching IP address found' Hostname Verification

Exact Error Message

This failure appears when the certificate is trusted and unexpired, but the name the client connected to does not appear in the certificate’s Subject Alternative Names:

[2026-06-29 15:40:09,712] ERROR [Producer clientId=ledger-producer] Connection to node
-1 (10.0.4.21:9093) failed authentication due to: SSL handshake failed
(org.apache.kafka.clients.NetworkClient)

org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: java.security.cert.CertificateException: No subject alternative names
matching IP address 10.0.4.21 found
    at sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:155)
    at sun.security.util.HostnameChecker.match(HostnameChecker.java:101)

The DNS variant reads almost identically:

java.security.cert.CertificateException: No subject alternative names matching DNS name
broker-01.kafka.internal found

Related variants include “No name matching … found” and “Hostname … not verified”, all driven by ssl.endpoint.identification.algorithm=https.

What the Error Means

This is a hostname (endpoint identification) verification failure. After the certificate chain is validated and confirmed unexpired, the client performs one more check: does the address it connected to match a name in the certificate? Kafka clients default ssl.endpoint.identification.algorithm=https, which enforces RFC 2818 hostname checking. If the client connected by IP 10.0.4.21 but the broker certificate’s SAN list only contains DNS names (or vice versa), verification fails.

Crucially, the certificate is perfectly valid and trusted — this is not PKIX path building failed (missing CA) or CertificateExpiredException (expired). It is purely a name-match problem. It commonly appears after switching clients from DNS names to raw IPs, after adding a new broker whose cert omits a SAN, or behind a load balancer whose address is not in any SAN.

Common Causes

• Connecting by IP while the cert only has DNS SANs (no IP Address: SAN entry). This is the classic case.
• Missing SAN entry for the specific broker hostname or advertised listener name.
• advertised.listeners returns a name (e.g. internal DNS) not present in the broker certificate.
• Load balancer / VIP address used by clients but absent from the broker cert SANs.
• CN-only certificate with no SAN at all — modern JDKs ignore CN for hostname matching and require SANs.
• Wildcard mismatch: a *.kafka.internal SAN does not match a multi-label host or a bare apex name.

How to Reproduce the Error

Connect by IP to a broker whose certificate only lists DNS SANs, with hostname verification on (the default):

cat > /tmp/ip-client.properties <<'EOF'
security.protocol=SSL
ssl.endpoint.identification.algorithm=https
ssl.truststore.location=/etc/kafka/ssl/truststore.jks
ssl.truststore.password=changeit
EOF

kafka-broker-api-versions.sh --bootstrap-server 10.0.4.21:9093 \
  --command-config /tmp/ip-client.properties

The chain validates, then fails with CertificateException: No subject alternative names matching IP address 10.0.4.21 found, because the cert has no IP Address: SAN.

Diagnostic Commands

All commands below are read-only.

# Dump the broker cert's SAN list — what names/IPs does it actually cover?
openssl s_client -connect broker-01.kafka.internal:9093 </dev/null 2>&1 | \
  openssl x509 -noout -text | grep -A1 'Subject Alternative Name'

# Show the subject/CN for context
openssl s_client -connect broker-01.kafka.internal:9093 </dev/null 2>&1 | \
  openssl x509 -noout -subject

# Inspect the SANs in the broker keystore certificate directly
keytool -list -v -keystore /etc/kafka/ssl/keystore.jks -storepass changeit | \
  grep -A3 'SubjectAlternativeName'

# What name/IP is the client actually connecting to, and is verification on?
grep -E 'bootstrap|ssl.endpoint.identification.algorithm' /tmp/ip-client.properties

# What does the broker advertise to clients? (must be in the SAN list)
grep -E 'advertised.listeners|listeners' /etc/kafka/server.properties

If the SAN list contains DNS:broker-01.kafka.internal but the client connects to 10.0.4.21, that mismatch is the entire problem.

Step-by-Step Resolution

1. Confirm it is hostname verification, not trust (PKIX) or expiry (CertificateExpiredException). The message names a specific IP or DNS name “not matching”.
2. List the cert SANs with openssl x509 -noout -text | grep -A1 'Subject Alternative Name'. Note exactly which DNS names and IPs it covers.
3. Compare to the connection target. If you connect by IP but only DNS SANs exist (or vice versa), that is the mismatch.
4. Prefer connecting by a name in the SAN. Point bootstrap.servers and advertised.listeners at a DNS name the certificate actually lists.
5. If clients must use IPs, the broker cert needs IP Address: SAN entries — reissue it with the correct SANs (operator/mutating step).
6. Behind a load balancer/VIP, ensure that address (DNS or IP) is in the SAN list.
7. Avoid disabling verification. Setting ssl.endpoint.identification.algorithm= (empty) turns off the check but removes MITM protection — use only as a temporary, documented stopgap.
8. Re-test with kafka-broker-api-versions.sh once names align.

Prevention and Best Practices

• Issue broker certificates with SANs covering every name and IP clients will use, including advertised listener names and any VIP.
• Standardize on connecting by DNS names that match the certificate, not raw IPs.
• Keep advertised.listeners consistent with the certificate SANs so client-side metadata never returns an unverifiable address.
• Never ship with ssl.endpoint.identification.algorithm disabled in production — it silently removes hostname protection.
• Add a synthetic probe that connects by the production name and asserts a clean handshake, catching SAN gaps when a broker is added. The free incident assistant can read the SAN list and the connect target to spot the mismatch.

Related Errors

• PKIX path building failed — the CA is untrusted; a different, earlier check.
• CertificateExpiredException — the cert is valid by name but past its dates.
• SSLHandshakeException: handshake_failure — protocol/cipher negotiation failure.
• SslAuthenticationException / SSL channel closed — abrupt close, often a listener/protocol mismatch.

Frequently Asked Questions

Why does connecting by IP fail but by hostname work? The certificate likely has only DNS SANs and no IP Address: SAN. Hostname verification requires the connected address to be in the SAN list.

My cert has the name in the CN. Why is it still rejected? Modern JDKs ignore the CN for hostname matching and require SANs. A cert with the name only in the CN and no SAN fails.

Can I just turn off the check? You can set ssl.endpoint.identification.algorithm= (empty), but it disables MITM protection. Treat it as a temporary stopgap, not a fix.

What about a load balancer in front of Kafka? The LB/VIP address (DNS or IP) must appear in the broker certificate SANs, otherwise clients connecting to it fail verification.

How do I see the SANs quickly? openssl s_client -connect host:9093 | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'.