Introduction

This question usually comes up during local development, when a Kafka client is connecting to a broker with a self-signed certificate or a certificate that does not match the broker hostname. The important detail is that Kafka exposes a supported way to disable hostname verification, but not a simple supported switch that blindly trusts every server certificate.

What Kafka Verifies During TLS Setup

When a Java Kafka client connects over SSL or SASL_SSL, two checks are commonly involved:

• The certificate chain must be trusted by the client's truststore.
• The certificate must match the server hostname.

Those are related but different checks. If your certificate is signed by an unknown CA, trust validation fails. If the certificate is trusted but the host name in the certificate does not match the broker address, hostname verification fails.

That distinction matters because the Kafka client configuration contains a property for the second case:

props.put("ssl.endpoint.identification.algorithm", "");

Setting that property to an empty string disables endpoint identification, which means hostname verification is turned off. It does not magically trust an unknown or invalid certificate chain.

The Supported Fix: Use a Truststore

The normal solution is to import the broker CA certificate into a truststore and point the client at it. That keeps TLS security intact and works in both development and production.

1import java.util.Properties;
2import org.apache.kafka.clients.producer.KafkaProducer;
3import org.apache.kafka.clients.producer.ProducerRecord;
4import org.apache.kafka.common.serialization.StringSerializer;
5
6public class SecureProducerExample {
7    public static void main(String[] args) {
8        Properties props = new Properties();
9        props.put("bootstrap.servers", "broker1.example.com:9093");
10        props.put("security.protocol", "SSL");
11        props.put("ssl.truststore.location", "/path/to/client.truststore.jks");
12        props.put("ssl.truststore.password", "changeit");
13        props.put("key.serializer", StringSerializer.class.getName());
14        props.put("value.serializer", StringSerializer.class.getName());
15
16        try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
17            producer.send(new ProducerRecord<>("orders", "id-1", "created"));
18            producer.flush();
19        }
20    }
21}

If the only problem is a host name mismatch in a non-production environment, you can add the endpoint identification setting while still using a real truststore:

props.put("ssl.endpoint.identification.algorithm", "");

That configuration says, in effect, "trust this CA, but do not verify the broker hostname." It is still weaker than full TLS verification and should be treated as a development-only workaround.

Can You Disable Trust Validation Entirely

Not through a simple built-in property intended for normal client use. The Java client uses the configured SSL engine and trust manager to validate certificates. In Kafka client configuration, the main extension point is ssl.engine.factory.class, which allows a custom SSL engine implementation. That means you could write unsafe custom code that trusts every certificate, but this is not the normal or recommended path.

In other words:

• Disabling hostname verification is supported through configuration.
• Disabling certificate trust verification entirely is not exposed as a simple safe switch.
• If you bypass trust checks with custom SSL code, you are stepping outside the normal security model.

This is why the best practical answer is usually to fix the truststore or regenerate certificates with the right subject alternative names.

Development Workflow That Avoids the Problem

For local environments, the cleanest setup is:

1. Create a local CA or use your platform's test certificate tooling.
2. Generate broker certificates that include the broker host names you actually connect to.
3. Import the CA certificate into the client truststore.
4. Keep hostname verification enabled unless you have a temporary reason not to.

That workflow takes a little more setup on day one, but it prevents a lot of wasted time later. Once certificates are generated correctly, the same client properties work consistently across environments.

Common Pitfalls

• Assuming ssl.endpoint.identification.algorithm disables all certificate checks when it only disables hostname verification.
• Trying to solve a missing CA trust problem by turning off the wrong setting.
• Shipping a development-only insecure SSL workaround into production.
• Using broker addresses that are not present in the certificate subject alternative names.
• Treating self-signed certificates as the problem when the real issue is an unconfigured truststore.

Summary

• Kafka Java clients support disabling hostname verification with ssl.endpoint.identification.algorithm="".
• That setting does not disable certificate trust validation.
• The supported and correct fix is usually to configure a truststore with the right CA certificate.
• Fully trusting all certificates would require unsafe custom SSL behavior, not a normal client property.
• For long-term reliability, generate proper broker certificates and keep full TLS verification enabled.