<a id="kafka-ssl-authentication"></a>

<a id="tls-authentication"></a>

# Use TLS Authentication in Confluent Platform

## TLS authentication overview

TLS authentication is a two-way authentication process in which the server and
client verify each other’s certificates. Confluent Platform uses [OpenSSL](../../../_glossary.md#term-OpenSSL), an
open-source cryptography toolkit that implements the TLS and Secure Socket Layer
(SSL) protocols, to support [Transport Layer Security (TLS)](../../../_glossary.md#term-Transport-Layer-Security-TLS) encryption.

#### NOTE
You can learn more about securing your Kafka deployment in the free course,
[Apache Kafka Security](https://developer.confluent.io/learn-kafka/security/authentication-basics/).

Because TLS authentication requires TLS encryption, this page shows you how
to configure both at the same time and is a superset of configurations required
just for [TLS encryption](../../protect-data/encrypt-tls.md#kafka-ssl-encryption).

By default, Apache Kafka® communicates in `PLAINTEXT`, which means that all data is
sent in plain text (unencrypted). To encrypt communication, you should configure
all Confluent Platform components in your deployment to use TLS encryption.

Secure Sockets Layer (SSL) was the predecessor of Transport Layer Security (TLS),
and has been deprecated since June 2015. For `TLS` configurations, the properties
often still refer to `SSL`.

TLS provides both encryption and authentication. Although standard TLS
encryption inherently includes one-way authentication where the client
verifies the server, this topic uses the term “TLS authentication” to
refer to two-way (mutual) authentication, where the broker also verifies
the client’s certificate. You can choose to use TLS for encryption only
while using a separate mechanism for client identity, such as
[SASL](../overview.md#kafka-sasl-auth) or
[TLS client authentication](#kafka-ssl-authentication).

Enabling TLS might have a performance impact due to encryption overhead.

TLS uses private-key/certificate pairs, which are used during the TLS handshake
process.

* Each broker needs its own private-key/certificate pair, and the client uses
  the certificate to authenticate the broker.
* Each logical client needs a private-key/certificate pair if client
  authentication is enabled, and the broker uses the certificate to authenticate
  the client.

You can configure each broker and logical client with a truststore, which is used
to determine which certificates, broker or logical client identities, to authenticate. You can configure the truststore in many ways. Consider the
following two examples:

* The truststore contains one or many certificates: the broker or logical client
  trusts any certificate listed in the truststore.
* The truststore contains a Certificate Authority (CA): the broker or logical
  client trusts any certificate that was signed by the CA in the truststore.

Using the CA method is more convenient, because adding a new broker or client
doesn’t require a change to the truststore. The CA method is outlined in the
[CA trust store diagram](https://github.com/confluentinc/confluent-platform-security-tools/blob/master/single-trust-store-diagram.pdf).

However, with the CA method, Kafka does not conveniently support blocking
authentication for individual brokers or clients that were previously trusted using
this mechanism (certificate revocation is typically done using Certificate Revocation
Lists or the Online Certificate Status Protocol), so you would have to rely on
authorization to block access.

In contrast, if you use one or many certificates, blocking
authentication is achieved by removing the broker or client’s certificate from
the truststore.

#### SEE ALSO
For an example that shows how to set Docker environment variables for Confluent Platform running on KRaft, see the [Confluent Platform demo](../../../tutorials/cp-demo/index.md#cp-demo).
Refer to the demo’s [docker-compose.yml file](https://github.com/confluentinc/cp-demo/tree/latest/docker-compose.yml) for a configuration reference.

## Creating TLS keys and certificates

Refer to the [Enable Security for a KRaft-Based Cluster in Confluent Platform](../../security_tutorial.md#security-tutorial), which describes how to [create TLS keys and certificates](../../security_tutorial.md#generating-keys-certs).

## Brokers

Configure all brokers in the Kafka cluster to accept secure connections from clients. Any configuration changes made to the broker will require a [rolling restart](../../../kafka/post-deployment.md#rolling-restart).

Enable security for Kafka brokers as described in the section below. Additionally, if you are using Confluent Control Center or Auto Data Balancer, configure your brokers for:

* [Confluent Metrics Reporter](#authentication-ssl-metrics-reporter)

For details on all required and optional broker configuration properties, see [Kafka Broker and Controller Configuration Reference for Confluent Platform](../../../installation/configuration/broker-configs.md#cp-config-brokers).

1. Configure the truststore, keystore, and password in the `server.properties`
   file of every broker. Because this stores passwords directly in the broker
   configuration file, it is important to restrict access to these files using
   file system permissions.
   ```bash
   ssl.truststore.location=/var/private/ssl/kafka.server.truststore.jks
   ssl.truststore.password=test1234
   ssl.keystore.location=/var/private/ssl/kafka.server.keystore.jks
   ssl.keystore.password=test1234
   ssl.key.password=test1234
   ```

   Note that `ssl.truststore.password` is technically optional, but strongly
   recommended. If a password is not set, access to the truststore is still
   available, but integrity checking is disabled.
2. If you want to enable TLS for interbroker communication, add the following
   to the broker properties file, which defaults to `PLAINTEXT`:
   ```bash
   security.inter.broker.protocol=SSL
   ```
3. Configure the ports for the Apache Kafka® brokers to listen for client and interbroker
   TLS (`SSL`) connections. You should configure `listeners`, and optionally,
   `advertised.listeners` if the value is different from `listeners`.
   ```bash
   listeners=SSL://kafka1:9093
   advertised.listeners=SSL://localhost:9093
   ```
4. Configure both TLS (`SSL`) ports and `PLAINTEXT` ports if:
   * TLS is not enabled for interbroker communication
   * Some clients connecting to your Confluent Platform cluster do not use TLS

   ```bash
   listeners=PLAINTEXT://kafka1:9092,SSL://kafka1:9093
   advertised.listeners=PLAINTEXT://localhost:9092,SSL://localhost:9093
   ```

   Note that `advertised.host.name` and `advertised.port` configure a
   single `PLAINTEXT` port and are incompatible with secure protocols. Use
   `advertised.listeners` instead.
5. To enable the broker to authenticate clients (two-way authentication), you must
   configure all the brokers for client authentication. Configure
   this to use `required` rather than `requested` because misconfigured
   clients can still connect successfully and this provides a false sense of
   security.
   ```bash
   ssl.client.auth=required
   ```

   #### NOTE
   If you specify `ssl.client.auth=required`, client authentication
   fails if valid client certificates are not provided. SASL listeners can be
   enabled in parallel to mTLS if you have defined SASL listeners with the
   following listener prefix:
   ```bash
   listener.name.<saslListenerName>.ssl.client.auth
   ```

   For details, see [KIP-684](https://cwiki.apache.org/confluence/display/KAFKA/KIP-684+-+Support+mutual+TLS+authentication+on+SASL_SSL+listeners#KIP684SupportmutualTLSauthenticationonSASL_SSLlisteners-UseadifferentconfigurationoptionforenablingmTLSwithSASL_SSL).

### Optional broker TLS settings

`ssl.endpoint.identification.algorithm`
: The endpoint identification algorithm used by clients to validate server host
  name. The default value is `https`. Clients including client connections
  created by the broker for interbroker communication verify that the broker host
  name matches the host name in the broker’s certificate. Disable server host name
  verification by setting `ssl.endpoint.identification.algorithm` to an empty string.

* Type: string
* Default: https
* Importance: medium

`ssl.cipher.suites`
: A cipher suite is a named combination of authentication, encryption, MAC, and
  key exchange algorithm used to negotiate the security settings for a network
  connection (using the TLS network protocol).

* Type: list
* Default: null (by default, all supported cipher suites are enabled)
* Importance: medium

`ssl.enabled.protocols`
: The comma-separated list of protocols enabled for TLS connections. The default
  value is `TLSv1.2,TLSv1.3` when running with Java 11 or later, `TLSv1.2`
  otherwise. With the default value for Java 11 (`TLSv1.2,TLSv1.3`), Kafka
  clients and brokers prefer TLSv1.3 if both support it, and falls back to
  TLSv1.2 otherwise (assuming both support at least TLSv1.2).

* Type: list
* Default: `TLSv1.2, TLSv1.3`
* Importance: medium

`ssl.truststore.type`
: The file format of the truststore file.

* Type: string
* Default: JKS
* Importance: medium

Due to import regulations in some countries, the Oracle implementation limits
the strength of cryptographic algorithms available by default. If stronger
algorithms are needed (for example, AES with 256-bit keys), the
[JCE Unlimited Strength Jurisdiction Policy Files](http://www.oracle.com/technetwork/java/javase/downloads/index.html)
must be obtained and installed in the JDK/JRE. See the [JCA Providers Documentation](https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) for more information.

<a id="authentication-ssl-clients"></a>

## Clients

Configure Kafka clients to use TLS authentication when connecting to Confluent Server brokers.

#### IMPORTANT
If you are configuring this for Schema Registry or REST Proxy, you must prefix each parameter with
`confluent.license`. For example, `sasl.mechanism` becomes
`confluent.license.sasl.mechanism`. For additional information, see
[Configure license clients to authenticate to Kafka](../../../installation/license.md#kafka-rest-and-sasl-ssl-configs).

The new Producer and Consumer clients support security for Kafka versions 0.9.0 and higher.

If you are using the Kafka Streams API, you can read on how to configure equivalent
[SSL](/platform/current/clients/javadocs/javadoc/org/apache/kafka/common/config/SslConfigs.html) and
[SASL](/platform/current/clients/javadocs/javadoc/org/apache/kafka/common/config/SaslConfigs.html) parameters.

In the following example, client authentication is required by the broker.
Store the configuration in a `client-ssl.properties` file. Because this stores
passwords directly in the configuration file, it is important to restrict access
to these files using file system permissions.

```bash
bootstrap.servers=kafka1:9093
security.protocol=SSL
ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
ssl.truststore.password=test1234
ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
```

Note that `ssl.truststore.password` is technically optional, but strongly
recommended. If a password is not set, access to the truststore is still
available, but integrity checking is disabled.

The following examples use `kafka-console-producer` and `kafka-console-consumer`,
and pass in the `client-ssl.properties` defined earlier:

```bash
kafka-console-producer --bootstrap-server kafka1:9093 --topic test --producer.config client-ssl.properties
kafka-console-consumer --bootstrap-server kafka1:9093 --topic test --consumer.config client-ssl.properties --from-beginning
```

### Optional client TLS settings

`ssl.endpoint.identification.algorithm`
: The endpoint identification algorithm used by clients to validate server host
  name. The default value is `https`. Clients including client connections
  created by the broker for interbroker communication verify that the broker host
  name matches the host name in the broker’s certificate. Disable server host name
  verification by setting `ssl.endpoint.identification.algorithm` to an empty string.
  <br/>
  * Type: string
  * Default: https
  * Importance: medium

`ssl.provider`
: The name of the security provider used for TLS connections. Default value is the
  default security provider of the JVM.
  <br/>
  * Type: string
  * Default: null
  * Importance: medium

`ssl.cipher.suites`
: A cipher suite is a named combination of authentication, encryption, MAC, and
  key exchange algorithm used to negotiate the security settings for a network
  connection (using the TLS network protocol).
  <br/>
  * Type: list
  * Default: null (by default, all supported cipher suites are enabled)
  * Importance: medium

`ssl.enabled.protocols`
: The comma-separated list of protocols enabled for TLS connections. The default
  value is `TLSv1.2,TLSv1.3` when running with Java 11 or later, `TLSv1.2`
  otherwise. With the default value for Java 11 (`TLSv1.2,TLSv1.3`), Kafka
  clients and brokers prefer TLSv1.3 if both support it, and falls back to
  TLSv1.2 otherwise (assuming both support at least TLSv1.2).
  <br/>
  * Type: list
  * Default: `TLSv1.2,TLSv1.3`
  * Importance: medium

`ssl.truststore.type`
: The file format of the truststore file.
  <br/>
  * Type: string
  * Default: JKS
  * Importance: medium

<a id="authentication-ssl-connect"></a>

## Kafka Connect

This section describes how to enable security for Kafka Connect. Securing Kafka Connect requires that you configure security for:

1. Kafka Connect workers: part of the Kafka Connect API, a worker is really just an advanced client, underneath the covers
2. Kafka Connect connectors: connectors may have embedded producers or consumers, so you must override the default configurations for Connect producers used with source connectors and Connect consumers used with sink connectors
3. Kafka Connect REST: Kafka Connect exposes a REST API that can be configured to use TLS/SSL using [additional properties](../../protect-data/encrypt-tls.md#encryption-ssl-rest)

Configure security for Kafka Connect as described in the section below. Additionally, if you are using Confluent Control Center streams monitoring for Kafka Connect, configure security for:

* [Confluent Metrics Reporter](#authentication-ssl-metrics-reporter)

<a id="authentication-ssl-connect-workers"></a>

Configure the top-level settings in the Connect workers to use TLS by adding
these properties in `connect-distributed.properties`. These top-level settings
are used by the Connect worker for group coordination and to read and write to
the internal topics that are used to track the cluster’s state (for example,
configs and offsets). This configuration assumes the brokers require client
authentication.

```bash
bootstrap.servers=kafka1:9093
security.protocol=SSL
ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
ssl.truststore.password=test1234
ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
```

Connect workers manage the producers used by source connectors and the consumers
used by sink connectors. So, for the connectors to use security, you must also
override the default producer and consumer configuration that the worker uses.
This configuration assumes the brokers require client authentication.

* For source connectors: configure the same properties by adding the `producer` prefix.
  ```bash
  producer.bootstrap.servers=kafka1:9093
  producer.security.protocol=SSL
  producer.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
  producer.ssl.truststore.password=test1234
  producer.ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
  producer.ssl.keystore.password=test1234
  producer.ssl.key.password=test1234
  ```
* For sink connectors: configure the same properties by adding the `consumer` prefix.
  ```bash
  consumer.bootstrap.servers=kafka1:9093
  consumer.security.protocol=SSL
  consumer.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
  consumer.ssl.truststore.password=test1234
  consumer.ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
  consumer.ssl.keystore.password=test1234
  consumer.ssl.key.password=test1234
  ```

#### IMPORTANT
**Updating the certificate authority (CA)**

When you update the certificate authority (CA), the Connect workers must be
restarted.

You can pass the CA at the JVM level as shown here:

```none
KAFKA_OPTS="-Djavax.net.ssl.trustStore=${CERTS_PATH}/truststore.jks \
-Djavax.net.ssl.trustStorePassword=$TRUSTSTORE_PASSWORD \
-Djavax.net.ssl.keyStore=${CERTS_PATH}/keystore.jks \
-Djavax.net.ssl.keyStorePassword=$KEYSTOR
```

For more information, see [Kafka Connect Security Basics for Confluent Platform](../../../connect/security.md#connect-security).

<a id="authentication-ssl-replicator"></a>

## Confluent Replicator

Confluent Replicator is a type of Kafka source connector that replicates data from a source to destination Kafka cluster. An embedded consumer inside Replicator consumes data from the source cluster, and an embedded producer inside the Kafka Connect worker produces data to the destination cluster.

Replicator version 4.0 and earlier requires a connection to ZooKeeper in the origin and destination Kafka clusters. If ZooKeeper is configured for authentication, the client configures the ZooKeeper security credentials via the global JAAS configuration setting `-Djava.security.auth.login.config` on the Connect workers, and the ZooKeeper security credentials in the origin and destination clusters must be the same.

To configure Confluent Replicator security, you must configure the Replicator connector as shown below and additionally you must configure:

* [Kafka Connect](#authentication-ssl-connect)

To add TLS to the Confluent Replicator embedded consumer, modify the Replicator JSON
properties file.

This example is a subset of configuration properties to add for TLS encryption
and authentication. This configuration assumes the brokers require client
authentication.

```bash
{
  "name":"replicator",
    "config":{
      ....
      "src.kafka.ssl.truststore.location":"/etc/kafka/secrets/kafka.connect.truststore.jks",
      "src.kafka.ssl.truststore.password":"confluent",
      "src.kafka.ssl.keystore.location":"/etc/kafka/secrets/kafka.connect.keystore.jks",
      "src.kafka.ssl.keystore.password":"confluent",
      "src.kafka.ssl.key.password":"confluent",
      "src.kafka.security.protocol":"SSL"
      ....
    }
  }
}
```

#### SEE ALSO
To view an example Confluent Replicator configuration, see [TLS source authentication demo script](https://github.com/confluentinc/examples/tree/latest//replicator-security/scripts/submit_replicator_source_ssl_auth.sh). For demos of common security configurations, see [Replicator security demos](https://github.com/confluentinc/examples/tree/latest//replicator-security).

To configure Confluent Replicator for a destination cluster with TLS authentication, modify
the Replicator JSON configuration to include the following:

```bash
{
  "name":"replicator",
    "config":{
      ....
      "dest.kafka.ssl.truststore.location":"/etc/kafka/secrets/kafka.connect.truststore.jks",
      "dest.kafka.ssl.truststore.password":"confluent",
      "dest.kafka.ssl.keystore.location":"/etc/kafka/secrets/kafka.connect.keystore.jks",
      "dest.kafka.ssl.keystore.password":"confluent",
      "dest.kafka.ssl.key.password":"confluent",
      "dest.kafka.security.protocol":"SSL"
      ....
    }
  }
}
```

Additionally, the following properties are required in the Connect worker:

```bash
security.protocol=SSL
ssl.truststore.location=/etc/kafka/secrets/kafka.connect.truststore.jks
ssl.truststore.password=confluent
ssl.keystore.location=/etc/kafka/secrets/kafka.connect.keystore.jks
ssl.keystore.password=confluent
ssl.key.password=confluent
producer.security.protocol=SSL
producer.ssl.truststore.location=/etc/kafka/secrets/kafka.connect.truststore.jks
producer.ssl.truststore.password=confluent
producer.ssl.keystore.location=/etc/kafka/secrets/kafka.connect.keystore.jks
producer.ssl.keystore.password=confluent
producer.ssl.key.password=confluent
```

For more details, see [general security configuration for Connect workers](../../../connect/security.md#connect-security).

#### SEE ALSO
To view an example Confluent Replicator configuration, see [TLS destination authentication demo script](https://github.com/confluentinc/examples/tree/latest//replicator-security/scripts/submit_replicator_dest_ssl_auth.sh). For demos of common security configurations, see [Replicator security demos](https://github.com/confluentinc/examples/tree/latest//replicator-security).

<a id="authentication-ssl-c3"></a>

## Confluent Control Center

You can configure TLS for Control Center so access is secured through HTTPS.

In addition, Control Center uses Kafka Streams as a state store, so if all the Confluent Server brokers
in your Confluent Platform cluster backing Confluent Control Center are secured, then Confluent Control Center also needs to be secured.

Also, because the Control Center acts as a proxy server for other components,
you can configure TLS for Control Center to secure its communication with
other secured Confluent Platform components.

Enable TLS for Confluent Control Center in the `etc/confluent-control-center/control-center.properties` file.
This configuration assumes the brokers require client authentication.

For details on how to enable TLS for Control Center as a server
or a proxy server, see [Configure TLS for Control Center on Confluent Platform](/control-center/current/security/ssl.html).

<a id="authentication-ssl-metrics-reporter"></a>

## Confluent Metrics Reporter

Enable TLS encryption and authentication for Confluent Metrics Reporter, the metrics
component used by Confluent Control Center and Auto Data Balancer.

To add TLS for the Confluent Metrics Reporter, add the following to `server.properties` on
the brokers in the Confluent Platform cluster being monitored. This configuration assumes the
brokers require client authentication.

```bash
confluent.metrics.reporter.bootstrap.servers=kafka1:9093
confluent.metrics.reporter.security.protocol=SSL
confluent.metrics.reporter.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
confluent.metrics.reporter.ssl.truststore.password=test1234
confluent.metrics.reporter.ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
confluent.metrics.reporter.ssl.keystore.password=test1234
confluent.metrics.reporter.ssl.key.password=test1234
```

<a id="authentication-encryption-ssl-self-balancing"></a>

## Enable TLS in a Self-Balancing cluster

To enable TLS encryption in a Self-Balancing cluster, add the following to
the `server.properties` file on the brokers in your Confluent Platform cluster.

```bash
confluent.rebalancer.metrics.security.protocol=SSL
confluent.rebalancer.metrics.ssl.truststore.location=/etc/kafka/secrets/kafka.client.truststore.jks
confluent.rebalancer.metrics.ssl.truststore.password=confluent
confluent.rebalancer.metrics.ssl.keystore.location=/etc/kafka/secrets/kafka.client.keystore.jks
confluent.rebalancer.metrics.ssl.keystore.password=confluent
confluent.rebalancer.metrics.ssl.key.password=confluent
```

<a id="authentication-ssl-schema-registry"></a>

## Schema Registry

Schema Registry uses Kafka to persist schemas, and so it acts as a client to write data to the Kafka cluster. Therefore, if the Kafka brokers are configured for security, you should also configure Schema Registry to use security.  You may also refer to the complete list of [Schema Registry configuration options](../../../schema-registry/installation/config.md#schemaregistry-config).

The following is an example subset of `schema-registry.properties` configuration
parameters to add for TLS encryption and authentication. This configuration
assumes the brokers require client authentication.

```bash
kafkastore.bootstrap.servers=SSL://kafka1:9093
kafkastore.security.protocol=SSL
kafkastore.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
kafkastore.ssl.truststore.password=test1234
kafkastore.ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
kafkastore.ssl.keystore.password=test1234
kafkastore.ssl.key.password=test1234
```

<a id="authentication-ssl-rest-proxy"></a>

## REST Proxy

Securing Confluent REST Proxy with TLS encryption and authentication requires that you
configure security between:

1. REST clients and REST Proxy (HTTPS)
2. REST Proxy and the Confluent Platform cluster

Also, refer to the complete list of [REST Proxy configuration options](../../../kafka-rest/production-deployment/rest-proxy/security.md#kafkarest-security).

1. Configure HTTPS between REST clients and REST Proxy. The following is an
   example subset of `kafka-rest.properties` configuration parameters to configure HTTPS.
   ```bash
   ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
   ssl.truststore.password=test1234
   ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
   ssl.keystore.password=test1234
   ssl.key.password=test1234
   ```
2. Configure TLS encryption and authentication between REST Proxy and the Confluent Platform
   cluster. The following is an example subset of `kafka-rest.properties`
   configuration parameters to add for TLS encryption and authentication.
   This configuration assumes the brokers require client authentication.
   ```bash
   client.bootstrap.servers=kafka1:9093
   client.security.protocol=SSL
   client.ssl.truststore.location=/var/private/ssl/kafka.client.truststore.jks
   client.ssl.truststore.password=test1234
   client.ssl.keystore.location=/var/private/ssl/kafka.client.keystore.jks
   client.ssl.keystore.password=test1234
   client.ssl.key.password=test1234
   ```

## TLS Logging

Enable TLS debug logging at the JVM level by starting the Kafka broker and/or clients with the `javax.net.debug` system property. For example:

```bash
export KAFKA_OPTS=-Djavax.net.debug=all
kafka-server-start etc/kafka/server.properties
```

Once you start the broker you should be able to see in the `server.log`:

```bash
with addresses: PLAINTEXT -> EndPoint(192.168.64.1,9092,PLAINTEXT),SSL -> EndPoint(192.168.64.1,9093,SSL)
```

To verify if the server’s keystore and truststore are setup correctly you can run the following command:

```bash
openssl s_client -debug -connect localhost:9093 -tls1
```

Note: TLSv1 should be listed under `ssl.enabled.protocols`.

In the output of this command you should see the server’s certificate:

```bash
-----BEGIN CERTIFICATE-----
{variable sized random bytes}
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=Joe Smith
issuer=/C=US/ST=CA/L=Santa Clara/O=org/OU=org/CN=kafka/emailAddress=test@test.com
```

You can find more details on this in [the Oracle documentation](http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ReadDebug.html) on [debugging SSL/TLS connections](http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/ReadDebug.html).

If the certificate does not show up with the `openssl` command, or if there are any other error messages, then your keys or certificates are not setup correctly. Review your configurations.