Camunda out of the box connector bundle failing with "Could not start Camunda Operate Client; PKIX path building failed"

Hi Team,
We have setup the Camunda platform in on prem Kubernetes using the Helm charts with the TLS enabled and the setup is working as expected. We deployed the out of the box Connector bundle using the image from docker hub “Docker” the pod is failing to connect to the Camunda operate (HTTPS) with the below error.

o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ‘’
INFO 1 — [ main] i.c.c.r.ConnectorRuntimeApplication : Started ConnectorRuntimeApplication in 5.758 seconds (JVM running for 6.183)
ERROR 1 — [pool-2-thread-1] o.s.s.s.TaskUtils$LoggingErrorHandler : Unexpected error occurred in scheduled task

java.lang.RuntimeException: Could not start Camunda Operate Client: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at io.camunda.connector.runtime.inbound.operate.OperateClientLifecycle.start(OperateClientLifecycle.java:65)
at io.camunda.connector.runtime.inbound.operate.OperateClientLifecycle.get(OperateClientLifecycle.java:89)
at io.camunda.connector.runtime.inbound.operate.OperateClientLifecycle.searchProcessDefinitions(OperateClientLifecycle.java:117)
at io.camunda.connector.runtime.inbound.importer.ProcessDefinitionImporter.scheduleImport(ProcessDefinitionImporter.java:67)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.springframework.scheduling.support.ScheduledMethodRunnable.run(ScheduledMethodRunnable.java:84)
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: io.camunda.operate.exception.OperateException: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at io.camunda.operate.auth.SelfManagedAuthentication.authenticate(SelfManagedAuthentication.java:93)
at io.camunda.operate.CamundaOperateClient$Builder.build(CamundaOperateClient.java:247)
at io.camunda.connector.runtime.inbound.operate.OperateClientFactory.camundaOperateClient(OperateClientFactory.java:160)
at io.camunda.connector.runtime.inbound.operate.OperateClientLifecycle.start(OperateClientLifecycle.java:63)
… 15 common frames omitted
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at java.base/sun.security.ssl.Alert.createSSLException(Unknown Source)
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
at java.base/sun.security.ssl.TransportContext.fatal(Unknown Source)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(Unknown Source)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(Unknown Source)
at java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(Unknown Source)
at java.base/sun.security.ssl.SSLHandshake.consume(Unknown Source)
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
at java.base/sun.security.ssl.HandshakeContext.dispatch(Unknown Source)
at java.base/sun.security.ssl.TransportContext.dispatch(Unknown Source)
at java.base/sun.security.ssl.SSLTransport.decode(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.decode(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(Unknown Source)
at java.base/sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source)
at io.camunda.operate.auth.SelfManagedAuthentication.authenticate(SelfManagedAuthentication.java:75)
… 18 common frames omitted

Please advise us on this. We tried adding the certificates in the Kubernetes but no luck with that.

Thank you!

Hello @Sagar023 ,

it looks like the keystore used does not contain a trusted CA which is part of the Operate Server certificate chain.

How do you enable TLS? Which certificates do you use?

Jonathan

Hi @jonathan.lukas ,

We created the TLS certificate and stored in the rancher, while installing the Camunda through HELM we passed those in values.yaml file.
Below were the values used
path: /operate
host: “”
tls:
enabled: true
secretName: “”

Thanks,
Sagar Adyanthaya

Hello @Sagar023 ,

is at least one CA (probably root) known to the client?

If not, please make it available by installing the public certificate to the keystore or adding it to the jvm keystore.

Jonathan

1 Like

I had to solve these issues with self-signed CAs in Kubernetes, read my post https://vdan.niceneasy.ch/camunda-8-oauth-for-zeebe-with-istio/

For all spring containers you can set the following variables:

JDK_JAVA_OPTIONS: Dlogging.level.root=info -Djavax.net.ssl.trustStore=/etc/ssl/camunda/trust-store.jks -Djavax.net.ssl.trustStorePassword=changeit

and mount the trust store as a configmap:

        volumeMounts:
        - name: config
          mountPath: /usr/local/operate/config/application.yml
          subPath: application.yml
        - name: keystore
          mountPath: /etc/ssl/camunda     
      volumes:
      - name: config
        configMap:
          name: camunda-operate
          defaultMode: 484
      - name: keystore
        configMap:
          name: keycloak-webserver-ssl

In this sample from operate you can see how to override the spring boot application.yml as well.

In order to create the trust store, it could look like:

kubectl get secret internal-camunda-gateway-credential -o jsonpath="{.data.ca\.crt"} | base64 -d > helix-ca.crt
kubectl get secret internal-camunda-gateway-credential -o jsonpath="{.data.tls\.crt"} | base64 -d > helix-gw.crt
keytool -import -alias camunda.tanzu.ch -keystore trust-store.jks -file helix-gw.crt -srcstorepass demodemo -deststorepass demodemo -noprompt
keytool -import -alias tanzu.ch.ca -keystore trust-store.jks -file helix-ca.crt -srcstorepass demodemo -deststorepass demodemo -noprompt
kubectl create configmap keycloak-webserver-ssl --from-file=./trust-store.jks
kubectl create configmap trusted-cas --from-file=./trusted.crt

With the same means you can also create a key-store.jks containing private keys for the webserver, if you want to enable TLS already on the container.

You should find some places in the values file of the helm chart to add configmap and volume mounts!

Hope it helps!

Daniele

PS: I plan to come up with a blog post on enabling TLS on the platform.

2 Likes

This Helped.

1 Like