Certificates FAQ
This page will guide you on all certificate-related issues that may occur when using Conduktor such as during Conduktor Login or while connecting to Kafka brokers, Kafka Connect, Schema Registry, ...


If your organization deploys Kafka services securely (with TLS) with non-trusted issuers or uses self-signed certificates
If your organization is using an internet proxy with SSL Inspection feature enabled such as
  • ZScaler
  • PaloAlto Networks
  • Symantec BlueCoat
you might run into problems at different stages of Conduktor:
  • During Conduktor Login phase
  • While connecting to your Kafka cluster
  • While connecting to your other Kafka services (Connect, Registry, ...)
Whatever your scenario, don't worry, this page will help you get everything sorted out in no time.
Certificate errors typically come with the following error message:
org.apache.kafka.common.errors.SslAuthenticationException: SSL handshake failed
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed:
unable to find valid certification path to requested target
To fix this, you have to let Conduktor know that your company's certificate is safe to use.
We have implemented a new feature to disable certificate validation in Conduktor in order to help you troubleshot certificate-related issues.
On the Cluster selection screen, navigate to Options > Network > Trusted Certificates
Check the box "Allow non-trusted certificates automatically"
Restart Conduktor and try again.
If your errors disappear, you can either leave the box checked or resolve your certificate issue properly by importing them.

Importing certificates in Conduktor

If you already have the certificates at your disposal, you can directly import them in the Trusted Certificates tab from above.
PEM certificates looks like this (generally .pem or .crt files)
If you don't have them, get in touch with your Administrator to help you.

Conduktor Certificate model

We are pleased to present to you our new Certificate model, intended to simplify your life as much as possible when your architecture involves non-trusted issuers.
The SSL Context is shared across all connections except ksqlDB
With this new model, you just need to import the certificates once in the Network tab and they will be picked up by all the components.
If you are using Windows and Mac, and your organization has pushed certificates into your machine using GPO, we will even load them!
This means that you don't need to define the trust store for each individual component anymore.
Unfortunately, we were not able to integrate ksqlDB in our new certificate model yet.
We remain fully compatible with the previous methods so if you have configured your Kafka clusters with .jks files, or if you still want to use this mechanism, everything will work as usual.

Additional properties (for Kafka brokers and Schema Registry)


JKS Manual Import (for Kafka Connect and ksqlDB)

The previous method is still available

Client Certificate Authentication

If you are using Client Certificate Authentication to connect to your Kafka Clusters, you have 2 possibilities to successfully connect to your Kafka Cluster

Keystore using JKS file


Inline Access Key and Access Certificate

Please note the trailing \ at the end of each line which signals a multiline content
ssl.keystore.key=-----BEGIN PRIVATE KEY----- \
Ip9QIvB7ef4xzUh3qGCoBsgqLubkgkEdauznHtn4EuDkhbKbWjUg37WMS4TjtUYt \
OHwT1aX5LrgKL1vYxzzOBAk46oUiboIv1PMbVS5LmO4ALtjR1N1rLL+OWVwuDCd/ \
1+T//b58rImpt5Ah2E1TYDK3 \
ssl.keystore.certificate.chain=-----BEGIN CERTIFICATE----- \
MIIEPzCCAqegAwIBAgIUX6T5U95harasueNwvjRgspnkJT0wDQYJKoZIhvcNAQEM \
6mpaK0/FlLZoV7WXcvgYLxHA6t249YI2cjTS+FXfBgFtXyF/gLsse26HCs/vpCB6 \
LsQbSqSb9md+ToDyp/wHCspeWkWJTYu4YZUmkR2dhFvDJbhANIXwICQc18dsVEDl \
vWv09PuooDhAdBZi0UsBa0XUwvzKFlZfaJ7csh20jvR7Vpg= \
Copy link
On this page
Identify a certificate-related issue (PKIX path building failed)
Importing certificates in Conduktor
Conduktor Certificate model
Client Certificate Authentication