librdkafka 1.8.2 accepts certificate authorities as PEM strings

A Kafka client can now receive its certificate authority material as a configuration value instead of locating a file. The October 18 librdkafka 1.8.2 release adds ssl.ca.pem. It also repairs macOS handling of ssl.ca.location, which had reverted to automatic probing instead of retaining the supplied path. Both changes concern how the application tells the client which certificate authority to trust.

The distinction between loading trust material and checking a broker's identity remains important. The configuration reference at the release tag treats certificate verification and endpoint identification as separate settings. Supplying a CA string does not by itself describe every part of the server identity policy.

I prefer configuration whose meaning is visible at the application boundary. A file path can be appropriate, but it also depends on what is installed in the runtime environment. Accepting a string lets the application supply the intended trust material directly when that matches how its configuration is delivered.

Trust anchors and client identity use different properties

The new ssl.ca.pem property is a PEM certificate string used to verify the broker's key. It differs from ssl.certificate.pem, which supplies the client's public certificate for authentication, and ssl.key.pem, which supplies its private key. Those settings describe different identities and should not be exchanged merely because they all accept PEM data.

An application authenticating a broker needs trust material for that server's certificate chain. An application presenting its own certificate needs the corresponding client certificate and private key. A deployment can require both, but one configuration value cannot be assumed to perform both roles.

The string form changes delivery of the trust material. It does not change which authority issued a certificate or which broker name the certificate identifies. Configuration code still has to obtain the intended value and pass the complete PEM representation, rather than a filename where the property expects certificate contents.

This is useful when the application's surrounding configuration system already provides certificate text. It avoids inventing an intermediate file solely to communicate with the library. Where a deployment already mounts an appropriate CA file, the path-based property remains a separate documented option.

File discovery depends on the platform and linkage

The reference describes Windows using the root certificate store. On macOS, ssl.ca.location defaults to probe. With statically linked OpenSSL or explicit probing, the library searches a list of standard paths and uses the first location found. A dynamically linked OpenSSL can instead use the library's default path.

These are concrete reasons why the same configuration omission can behave differently across runtime environments. The installed certificate package and the linked OpenSSL affect discovery. An explicit CA value or path makes that dependency more deliberate, although the application still needs the right certificate material.

The tagged changelog records that 1.8.0 introduced the macOS regression preventing a configured path from taking effect. Version 1.8.2 repairs it. The release also ships macOS prebuilt binaries with statically linked OpenSSL 1.1.1l, replacing variation between earlier bundled versions.

That linkage change belongs in understanding certificate discovery. A native library's runtime behavior depends on the binary supplied to an application, not only the application's source-level client API. The release notes make the bundled dependency and the repaired path handling explicit. They also stop providing prebuilt binaries for macOS Sierra and older, a packaging boundary that applications using those artifacts need to recognize.

Hostname verification is an additional choice

The configuration reference defaults enable.ssl.certificate.verification to true. It separately lists ssl.endpoint.identification.algorithm with none as the default in this version. Selecting https enables broker hostname verification according to the documented HTTPS-style matching rules.

This excerpt states those verification choices explicitly, alongside the trust material supplied through the application's configuration API:

enable.ssl.certificate.verification=true
ssl.endpoint.identification.algorithm=https

The settings are a fragment, not a complete connection configuration. The application still selects its security protocol and supplies the appropriate CA material. Keeping the properties separate makes it possible to explain both trusting the issuing authority and checking the broker hostname.

I regard the explicit hostname setting as relevant to interpreting this release. A new way to load CA certificates should not be mistaken for a new default for every TLS check. The tagged reference establishes what this particular library version does.

The release also repairs prebuilt artifact architecture mistakes, including an x64 library packaged as Linux arm64. Those fixes reinforce that configuration and packaging both affect the actual client an application runs. For certificate handling, 1.8.2 gives applications a direct PEM input and restores the promised path selection on macOS, while the documented verification settings retain their separate roles.