How certificate trust works

The Kafka connection uses mutual TLS (mTLS): QRadar validates the CNX Kafka broker, and the broker validates the subscriber certificate presented by QRadar. These are two related but separate certificate paths under the CNX root CA.

CNX Root CA
├── CNX Service ICA
│   └── kafka.cnx.net.kh server certificate
└── CNX External Client ICA
    └── subscriber client certificate

The root CA signs the intermediate certificate authorities (ICAs). Each ICA has a distinct purpose: the service ICA issues certificates for CNX services, while the external-client ICA issues certificates to subscriber systems.

What QRadar validates

When QRadar connects, the Kafka broker presents its server certificate. QRadar validates that certificate against its broker truststore:

kafka.cnx.net.kh -> cnx_ica_service.crt -> cnx_ca.crt

The truststore therefore contains cnx_ica_service.crt and cnx_ca.crt as trusted certificate entries. QRadar must also verify that the certificate is valid for the broker hostname; a valid signature chain does not replace hostname verification.

What CNX Kafka validates

QRadar presents the subscriber client certificate from its client keystore:

client.crt -> cnx_ica_external_client.crt -> cnx_ca.crt

The client keystore contains that certificate path and the subscriber's matching private key. The private key is generated and retained by the subscriber; CNX does not deliver or store it in the credentials repository.

CNX Kafka validates the presented client identity against the external-client certificate path. It then applies the Kafka permissions assigned to that subscription. Trusting the issuing ICA authenticates a certificate path; it does not by itself grant access to topics or consumer groups.

Files and responsibilities

File	Role	Used by QRadar in
`client.crt`	Subscriber leaf certificate presented to Kafka	Client keystore
Subscriber private key	Proof of control for `client.crt`; never supplied by CNX	Client keystore
`cnx_ica_external_client.crt`	Issues subscriber client certificates	Client certificate chain
`cnx_ica_service.crt`	Issues CNX service certificates, including the Kafka broker	Broker truststore
`cnx_ca.crt`	Root of both certificate paths	Client chain and broker truststore

client-fullchain.crt is the delivered convenience bundle containing client.crt and cnx_ica_external_client.crt. The QRadar conversion procedure adds cnx_ca.crt when packaging the private-key entry.

Trust, revocation, and authorization are separate checks

A complete mTLS decision has more than one layer:

Certificate path: each certificate is signed through the expected ICA to the CNX root, is within its validity period, and has the required TLS purpose.
Endpoint identity: QRadar verifies the Kafka broker hostname, and CNX maps the subscriber certificate identity to the issued subscription.
Revocation status: the TLS implementation checks whether a certificate has been revoked. CNX publishes CRLs at crl.cnx.net.kh; Java and QRadar may require explicit revocation-checking configuration.
Kafka authorization: CNX permits only the assigned topics and consumer group after authentication succeeds.

A certificate that builds a valid chain is not necessarily unrevoked or authorized. Likewise, repository SSO controls access to subscription files; it is separate from Kafka mTLS authentication.

For the concrete Java store commands, follow Connecting IBM QRadar. For the delivered repository layout and certificate lifecycle, see Subscription configuration.