Status

Current state: Under Discussion

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: here [Change the link from KAFKA-1 to your own ticket]

Motivation

Historically, Apache Kafka components communicating over mutual TLS (mTLS) have relied on multipurpose TLS certificates—specifically, certificates containing both serverAuth and clientAuth Extended Key Usages (EKU).

However, public Certificate Authorities (CAs) are actively deprecating and will soon stop providing these multipurpose certificates to comply with stricter security standards.

This presents a breaking operational challenge for Kafka environments relying on public CAs. Currently, several Kafka components utilize a single keystore for both inbound (server) and outbound (client) mTLS connections, natively expecting a multipurpose certificate:

  • Inter-broker mTLS: Brokers act as servers to accept connections, and as clients to connect to other brokers, requiring both auth EKUs.

  • Kafka Connect inter-worker mTLS: Workers communicate with each other requiring both client and server auth EKUs.

  • MirrorMaker 2 inter-worker mTLS: Similar to Kafka Connect, internal communication requires both EKUs.

This KIP proposes adding support for single-purpose TLS certificates in Kafka to ensure continued compatibility with public CA issuance policies.

Possible solutions

Solution 1: Separate Keystore Configurations

Introduce a completely new set of properties to allow users to define distinct keystores for client and server operations.

  • Mechanism: Add properties like ssl.client.keystore.location, ssl.server.keystore.location, and their associated password/type configurations. Kafka's SslEngineFactory would build entirely separate SSLContext objects based on whether the component is acting as a client or server.

  • Pros: Complete isolation of credentials; conceptually very clear to security administrators.

  • Cons: Creates a massive new configuration surface area. We would need to duplicate almost all existing ssl.keystore.* properties.

Solution 2: Custom KeyManager with Smart Key Selection

Use the existing single keystore configuration, but update Kafka's internal KeyManager to automatically select the correct certificate based on the connection context and the certificate's EKU.

  • Mechanism: Users place both the single-purpose server cert and the single-purpose client cert into the same keystore. We write a custom X509ExtendedKeyManager that inspects the requested SSL context (client mode vs. server mode) and dynamically selects the certificate with the matching EKU.

  • Pros: Zero new configurations required. Highly seamless for the end-user.

  • Cons: "Magic" behavior can be difficult to debug. If a user has multiple client or server certs in the keystore, the implicit selection logic could pick the wrong one, leading to hard-to-diagnose SSLHandshakeExceptions.

Solution 3: Separate Alias Properties for a Single Keystore

Keep the existing single keystore configuration, but introduce new properties that allow the user to explicitly define which alias to use for which purpose.

  • Mechanism: Users put both certs into the same keystore. We introduce two new properties: ssl.client.keystore.key.alias and ssl.server.keystore.key.alias. The SslEngineFactory uses these explicit aliases when building the respective contexts.

  • Pros: Strikes a balance between explicitness and configuration bloat. Only requires a few new properties while avoiding the unpredictability of automatic key selection.

  • Cons: Still requires users to manage a multi-certificate keystore, which some security tools handle poorly compared to single-certificate keystores.

Rejected Alternatives

  • Disabling EKU Validation: Modifying Kafka to ignore EKU checks altogether. Rejected because it compromises the security integrity of the TLS handshake.

  • Relying Exclusively on Private CAs: Forcing users to manage their own internal PKI to generate multipurpose certs. Rejected because it limits Kafka's usability and imposes significant operational overhead on users who prefer or mandate public CAs for internal routing.

  • No labels