Connecting IBM QRadar

Complete the subscription steps in Connecting a Kafka consumer and retrieve your issued credentials. This guide uses OpenSSL and Java keytool on a secure workstation to prepare JKS files for QRadar's Apache Kafka protocol. IBM documents both JKS and PKCS12 support in its Kafka protocol configuration reference.

Use the private key corresponding to your submitted CSR. In the commands below, siem-primary.key is an example local filename; replace it with your key's path. Copy your subscription's client-fullchain.crt and the root-level cnx_ca.crt and cnx_ica_service.crt into a private working directory. Restrict access to that directory and the generated keystores using your operating system's file permissions. The commands below work in PowerShell and Unix shells with OpenSSL and keytool available on your command path.

1. Build the client keystore

Package your private key and the full issued client chain:

openssl pkcs12 -export -inkey siem-primary.key -in client-fullchain.crt -name cnx-telemetry -out kafka.client.p12

OpenSSL prompts for an export password. Import that entry into a new JKS keystore:

keytool -importkeystore -srckeystore kafka.client.p12 -srcstoretype PKCS12 -srcalias cnx-telemetry -destkeystore kafka.client.keystore.jks -deststoretype JKS -destalias cnx-telemetry

Enter the source export password and a destination keystore password when prompted. With this command, the imported private-key entry retains the source entry password. Record it for QRadar's Private Key Password field; the destination password goes in Key Store Password.

Check the imported entry:

keytool -list -v -keystore kafka.client.keystore.jks -alias cnx-telemetry

Confirm that it is a PrivateKeyEntry, with your client certificate and the issuing intermediate in its certificate chain. OpenSSL's PKCS12 reference and Java's keytool reference describe the conversion options.

2. Build the broker truststore

Use the root-level cnx_ca.crt and cnx_ica_service.crt for broker trust. Inspect their subjects, issuers, and SHA-256 fingerprints:

keytool -printcert -file cnx_ca.crt
keytool -printcert -file cnx_ica_service.crt

Import both certificates as separate trusted entries into a new truststore:

keytool -importcert -storetype JKS -keystore kafka.client.truststore.jks -alias cnx-root-ca -file cnx_ca.crt
keytool -importcert -storetype JKS -keystore kafka.client.truststore.jks -alias cnx-service-ica -file cnx_ica_service.crt

Use the same truststore password for each import and review the certificate before accepting the prompt. List the result:

keytool -list -v -keystore kafka.client.truststore.jks

The entries should be trustedCertEntry records. The client keystore contains your identity and private key; this truststore contains the CAs used to validate CNX brokers.

cnx_ica_external_client.crt issues your client certificate and is already included in client-fullchain.crt. It is not needed in this broker truststore.

3. Install the stores on QRadar

Copy both .jks files securely to /opt/qradar/conf/trusted_certificates/kafka/ on every QRadar collection host assigned to this log source. Keep the keystore readable by the collector and restrict access to its private-key material. IBM specifies this location in its client-authentication setup.

The temporary .p12 also contains your private key. Manage it under the same secret-storage policy as the key and the JKS keystore.

4. Configure the Apache Kafka log source

Create a log source using the Apache Kafka protocol. Set the following fields; names can vary with your installed protocol version:

Select a TLS version supported by the CNX endpoint and your QRadar version. IBM documents TLS 1.3 support from QRadar 7.5.0 UP5. Keep hostname verification enabled and allow connectivity to all brokers advertised in Kafka metadata. Enter secrets in the password fields, rather than consumer-property overrides.

CNX Kafka values contain a complete JSON record. Preserve that payload for parsing; configure the log source type and JSON properties using Ingesting into a SIEM. Transport configuration alone does not supply a CNX-specific DSM or event mappings.

5. Validate and maintain collection

Confirm that the collector authenticates, joins its assigned group, and imports records from the selected topics. Check event-time parsing and retain the feed's original event-time value at its supplied precision. See Time provenance.

Monitor lag against the two-hour topic retention window. Size collection capacity and the EPS throttle to keep pace with the selected feeds. If collection fails, check broker reachability, certificate validity, passwords, and store entry types before changing consumer properties.

When CNX publishes a renewed client certificate, rebuild the client keystore with its corresponding private key, install it on the collection hosts, and reload the log source using your QRadar deployment procedure. Rebuild the truststore when the delivered broker trust chain changes.