Use ssl.client.auth=required if you want mutual TLS on Kafka. The Kafka documentation discourages requested because clients without certificates can still connect, which gives a false sense of security. Keep hostname verification on as well. Turning it off is a shortcut that removes the main man-in-the-middle check.
The three client auth values
On the broker, ssl.client.auth can be none, requested or required. The Kafka documentation describes them this way: required means client authentication is required, requested means it is asked for but a client without a certificate can still connect, and none means it is not asked for.
The docs also say the use of requested is discouraged, because it gives a false sense of security and misconfigured clients will still connect successfully.
That last point is the practical one. With requested, a client whose certificate is missing or broken does not fail. It just connects without an identity. You then find out only when an ACL denies it, or worse, when none does.
What TLS without client auth gives you
With none, TLS encrypts the traffic and the client verifies the broker. You get confidentiality and server authentication. You do not get client identity from the certificate, so you need SASL to identify callers. That is a perfectly valid design, covered in the comparison of SASL mechanisms.
If you want identity from certificates, use required, then map certificate names into principals. The principal defaults to a full distinguished name string, and a mapping rule can shorten it, as described in the guide to SSL principal mapping.
Truststores on the broker
One detail trips people up. If you set client auth to requested or required, the broker needs a truststore containing the certificate authorities that signed the client keys. Without it, valid clients are rejected.
Hostname verification
Hostname verification checks the certificate a server presents against the actual hostname or address of that server. The documentation says its main purpose is to prevent man-in-the-middle attacks.
Kafka had this disabled by default for a long time. From version 2.0.0, server host name verification is enabled by default for client connections and for inter-broker connections. You can disable it by setting ssl.endpoint.identification.algorithm to an empty string.
The documentation is blunt about this: there is normally no good reason to turn it off apart from getting something working quickly with a promise to fix it later. It also says it is easier to get right at the start than after the cluster is running.
Practical steps
- Put DNS or IP names in the subject alternative name field of broker certificates. The docs note that common name based verification has been deprecated for a long time and SAN is more flexible.
- Set ssl.client.auth to required if you rely on certificates for identity.
- Leave ssl.endpoint.identification.algorithm at its default.
- Enable TLS for inter-broker traffic too, by setting security.inter.broker.protocol, since the default is plaintext.
- Test with a client that has no certificate and confirm it is refused.
Quick check
Does TLS on Kafka slow it down?
The Kafka security overview notes a performance degradation when SSL is enabled, and says its size depends on the CPU type and the JVM implementation. Measure on your own hardware.
Is inter-broker traffic encrypted by default?
No. The documentation says the inter-broker protocol defaults to PLAINTEXT, so you need to set it.
Sources
- Apache Kafka documentation: Encryption and authentication using SSL
- Apache Kafka documentation: Security overview
Last reviewed: 19 October 2026.
