skip to content

What does ssl.endpoint.identification.algorithm control, and why is disabling it dangerous?

level: seniorimportance: must knowfreq 55%

answer

  1. default = https (verify SAN)
  2. empty string = OFF = MITM risk
  3. SAN, not CN, is matched
  4. fix = add SANs for advertised.listeners hosts
  5. trust-chain valid != identity valid

basics

~20 s

It controls TLS hostname verification — whether the client checks that the broker's certificate actually matches the hostname it connected to. The default is https (enabled). Setting it to empty disables that check, which lets an attacker with any valid-looking cert impersonate the broker (man-in-the-middle).

solid answer

~40 s

ssl.endpoint.identification.algorithm tells the client how to verify the broker's identity beyond just 'is the cert signed by a trusted CA'. With the default value https, the client checks that the hostname it connected to matches the certificate's SAN (Subject Alternative Name) entries. This stops an attacker who holds a different but CA-valid certificate from impersonating your broker. Setting it to an empty string disables hostname verification, so the client trusts ANY cert chaining to a trusted CA regardless of hostname — a textbook man-in-the-middle hole. People disable it to 'fix' handshake errors, but the real fix is to issue broker certs with SANs covering the advertised.listeners hostnames (and to make sure clients connect via those names). Never disable it in production; if you must in a test, document it as a known risk.

go deeper

for a junior

Knows the property turns on/off checking that the cert matches the broker hostname; default is on.

for a middle

Can explain SAN matching and that blanking it disables verification.

for a senior

Articulates the trust-vs-identity distinction, the MITM risk, and fixes it by adding SANs rather than disabling.

for a principal

Sets PKI/SAN issuance policy fleet-wide, covers inter-broker identity, and bans disabling verification in prod via guardrails.

## Two separate checks during a TLS handshake Validating a server in TLS is two steps: 1. **Chain/trust validation** — is the broker's certificate signed (directly or via intermediates) by a CA in my truststore, and is it unexpired/unrevoked? 2. **Identity (hostname) validation** — does the certificate actually belong to the host I *intended* to reach? Step 1 alone is not enough. A CA may have issued a perfectly valid certificate to *someone else*. If an attacker can route your traffic to their server and present that other valid cert, step 1 passes. **Hostname verification (step 2) is what binds the cert to the host you dialed.** ## The property `ssl.endpoint.identification.algorithm`: - Default: `https`. This applies RFC 2818 / RFC 6125 HTTPS-style endpoint identification: the connected hostname must match one of the certificate's **Subject Alternative Name (SAN)** DNS entries (modern certs ignore the legacy CN field). Wildcards like `*.kafka.example.com` are honored per the rules. - Empty string (`ssl.endpoint.identification.algorithm=`): **disables** hostname verification. Only step 1 runs. ## Why disabling is dangerous With verification off, the client accepts any certificate that chains to a trusted CA, **for any hostname**. In a corporate PKI where one internal CA signs many services, that means *any* service's cert (or any cert an attacker can get from that CA) is accepted as your broker — a man-in-the-middle can intercept and decrypt all traffic. The TLS still 'works' and is encrypted, but you've lost the authentication that made the encryption meaningful. ## Why people hit this and the correct fix The common trigger: a handshake error like `No subject alternative names matching IP address ... found` or `Certificate for <broker> doesn't match`. The wrong fix is to blank out the property. The **right** fixes: - Issue broker certificates whose SAN list covers every hostname clients use — i.e. the names in `advertised.listeners`. Include both DNS names and, if clients connect by IP, IP SANs. - Ensure clients connect using a name present in the SAN, not a raw IP or an internal alias the cert doesn't list. - For inter-broker traffic, the same applies: the advertised inter-broker host must be in the SAN. ## Inter-broker note The broker acts as a *client* to other brokers for replication/controller traffic. Hostname verification applies there too, gated by the same algorithm semantics; misconfigured advertised inter-broker hostnames produce the same failure between brokers. ## Quick mental model - Trust check = 'is this a real ID card from an authority I trust?' - Hostname check = 'is this ID card actually *for the person standing in front of me*?' Skipping it means accepting any genuine ID card from anyone.

  • A team disabled hostname verification to fix a 'No subject alternative names' error. What should they have done instead?
    Re-issue the broker certificate with SAN entries covering the hostnames (and IPs) clients use — i.e. the advertised.listeners names — and ensure clients connect via those names. Disabling verification opens a MITM hole.
  • Which certificate field does modern hostname verification check?
    The Subject Alternative Name (SAN) DNS/IP entries. The legacy Common Name (CN) is ignored by modern verifiers per RFC 6125.
  • Does hostname verification also apply to inter-broker connections?
    Yes — a broker is a TLS client when talking to other brokers, so the advertised inter-broker hostname must appear in the peer broker's SAN, governed by the same algorithm setting.

saying these in an interview costs you the question

  • Saying disabling it is fine because traffic is still encrypted — encryption without identity verification is MITM-able.
  • Claiming hostname verification matches the certificate CN — modern verification uses SAN.
  • Thinking a CA-valid cert is sufficient identity proof on its own.
  • Treating the empty-string value as 'use a secure default' — it means OFF.

context

resolving links…