<a id="co-troubleshoot-networking"></a>

# Common Networking Issues

Resolve common networking issues in Confluent for Kubernetes using the following steps.

<a id="co-c3-mds-certificates"></a>

## Issue: Confluent Control Center (Legacy) can’t use auto-generated certificates for MDS or Confluent Cloud Schema Registry

When TLS is enabled, and when Confluent Control Center (Legacy) uses a different TLS certificate to
communicate with Metadata Service (MDS) or Confluent Cloud Schema Registry, Control Center (Legacy) can’t use an
auto-generated TLS certificate to connect to MDS or Confluent Cloud Schema Registry.

**Solution:** To encrypt Confluent Control Center (Legacy) traffic to MDS or Confluent Cloud Schema Registry, provide custom
TLS certificates:

1. Add to the Confluent Control Center (Legacy) TLS secret a custom truststore that includes the root CA to
   trust Confluent Cloud Schema Registry or MDS.
2. Use the preceding secret name in the Confluent Control Center (Legacy) custom resource (CR):
   ```yaml
   spec:
     dependencies:
       mds:
         tls:
           secretRef: <custom Root CA>
   ```
3. Disable auto-generated certs and provide the RootCA in Confluent Control Center (Legacy) custom resource:
   ```yaml
   spec:
     tls:
       autoGeneratedCerts: false
       secretRef: <custom Root CA>
   ```
4. Deploy or redeploy Confluent Control Center (Legacy).

## Issue: ksqlDB can’t use auto-generated certificates for Confluent Cloud

When ksqlDB communicates with Confluent Cloud, ksqlDB can’t use an auto-generated
TLS certificate.

**Solution:** To encrypt ksqlDB traffic to Confluent Cloud, provide custom TLS
certificates:

1. Provide a custom truststore that includes the Let’s Encrypt Root CA.
2. Disable auto-generated certs and provide the RootCA in ksqlDB custom
   resource:
   ```yaml
   spec:
     tls:
       autoGeneratedCerts: false
       secretRef: <custom Root CA>
   ```
3. Deploy or redeploy ksqlDB.

## Issue: Kafka listeners can’t share the same TLS secret reference

For a Kafka custom resource, two different listeners, such as internal
and external listeners, can’t share the same TLS secret reference.
Configuring this impacts the volume mount path, and the `statefulset`
fails.

**Workaround:** Use global TLS if you need to share TLS configuration,
as shown in the following example:

```yaml
spec:
  tls:
    secretRef: tls-shared-certs
  listeners:
    internal:
      tls:
        enabled: true
    external:
      tls:
        enabled: true
```

**Fixed Version:** Upgrade to CFK 2.0.2, which fixes this limitation.

## Issue: TLS-enabled ksqlDB fails to start with a crash loop

Currently, ksqlDB doesn’t support using different trust stores for the REST
client connections and the connections from ksqlDB to Kafka.

`spec.dependencies.kafka.tls.ignoreTrustStoreConfig` in the ksqlDB CR,
used for a dependency on a component that doesn’t decouple HTTPS and TLS
properties, doesn’t work if the ksqlDB REST endpoint has TLS enabled and
if the Kafka dependency uses TLS.

For example, a ksqlDB with TLS enabled, auto-generate certificates, and
`spec.dependencies.kafka.tls.ignoreTrustStoreConfig` set to `true`, fails
with a crash loop. The following error appears in the ksqlDB
log:

```text
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
```

**Workaround:** Set `spec.dependencies.kafka.tls.ignoreTrustStoreConfig: false`
in the ksqlDB CR and reapply the CR to re-start ksqlDB.