librdkafka 2.8 sends the client certificate chain
The native Kafka client's maintenance release repairs certificate-chain handling, optional client authentication, and socket configuration timing.
A broker can trust the root authority for a client certificate and still reject the client if the intermediate certificates never arrive. librdkafka 2.8.0 repairs that missing-chain problem for several credential configuration paths. The change removes a broker-side workaround that could make the same credentials appear valid with one client and unusable with another.
The January 7 release identifies ssl.certificate.pem, the ssl_certificate interface, and ssl.keystore.location as affected paths. Previously, the broker needed intermediate certification authorities explicitly added to its truststore to accept the client's certificate in those cases.
I value Kafka's durable log and the ability to replay it through independent consumers. Those properties only help a consumer that can establish its connection. Certificate transport is worth understanding because an authentication failure can otherwise be misdiagnosed as a disagreement about which root authority the broker trusts.
The credential includes more than the leaf certificate
The certificate-chain patch changes how the client retains and supplies the accompanying certificates. Its credential object gains a chain, and PKCS#12 parsing retrieves the additional certificates instead of discarding them. The PEM handling also reads certificates following the initial one.
That is a change to what the client sends. It does not require the broker to stop checking the client's identity. The broker receives more of the chain needed to validate that identity against its configured trust.
This distinction explains why adding intermediates to the broker could work around the defect. The broker then had information that the client should have supplied. The repair places the information on the credential path where it belongs, reducing a dependency on every broker carrying the same extra intermediate certificates.
The release notes trace the issue back to the 1.x series. It is therefore a maintenance correction to a long-existing configuration behavior. It does not announce a new Kafka authentication mechanism or a replacement for TLS.
For applications supplying credentials programmatically, the affected configuration path matters. A certificate loaded into one interface is not evidence that every other supported interface handled its chain identically. The release explicitly identifies several paths whose behavior now becomes consistent.
An unwanted certificate can prevent another authentication method
A related certificate-selection patch handles a different problem. The client avoids sending a certificate whose chain does not match the broker's advertised trusted certificate authorities. That decision matters when the broker requests a certificate without requiring one.
The patch describes a broker with ssl.client.auth=requested. Sending a certificate that the broker rejects can prevent a connection that could otherwise continue to SASL authentication over TLS. In that arrangement, sending no matching client certificate and sending an untrusted one have different consequences.
The new callback examines the server's accepted authority list and compares it with issuers in the client certificate and its chain. If no matching issuer is found, it clears the client certificates for that connection and emits a warning. The purpose is to avoid supplying a certificate that would almost certainly be rejected.
The implementation also handles an absent authority list. In that case it lets the certificate be sent and leaves validation to the server. The selection behavior is therefore conditional on the information the peer provides.
This is an interoperability fix with a specific policy boundary. It does not make an untrusted certificate trusted. When client certificate authentication is mandatory, withholding an unmatched certificate does not create a valid identity. The useful case described by the patch involves optional certificate authentication followed by another permitted authentication method.
Socket options move before connection establishment
The socket configuration patch moves configured socket options before connection. The release notes connect that timing to send and receive buffer settings taking effect as documented. They trace the earlier ordering to version 0.9.0.
A configuration value can be syntactically accepted and still fail to produce the intended operating system behavior if it is applied at the wrong stage. This patch changes the stage. It does not claim a particular throughput increase for every application using the library.
That is a useful limit on the interpretation. The release repairs the conditions under which configured buffers can take effect. Any application-specific performance result would require evidence about the network and workload, which the release does not supply.
My concern with Kafka clients is predictability at these boundaries. A durable partition log does not remove the client's dependence on TLS and socket semantics. Making those configuration paths behave as documented reduces the number of unrelated broker changes needed to investigate a connection.
Leader changes also receive a maintenance correction
The release includes consumer fixes for moving partitions to leaders with unchanged or null leader epochs. It explains that null epochs can occur during a rolling upgrade to a broker version supporting KIP-320. Unchanged epochs can arise during a temporary internal-broker transition or with broker implementations that do not increment them.
Those cases concern whether the client accepts updated leadership information. They should not be interpreted as changes to Kafka's partition ordering guarantee. The client needs to move its connection to the available leader before it can continue consuming the log.
Taken together, the maintenance changes address the surrounding connection state. The client sends the chain belonging to its credentials, avoids an inappropriate optional certificate, and applies socket settings before connecting. The consumer fixes then permit leadership transitions in the specific epoch cases the release documents.