Can anyone please provide the helm chart for installing Camunda 8.5 Identity component that uses OIDC Provider without relying on keycloak.
Please refer the following document link: Connect to an OpenID Connect provider | Camunda 8 Docs
Thanks for responding. I followed the document and updated my helm chart by using our internal OIDC provider. But identity and other components like operate, tasklist are not coming up. The below error is appearing
at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:53) [operate-webapp-8.5.0-exec.jar:8.5.0]
at org.springframework.boot.loader.launch.JarLauncher.main(JarLauncher.java:58) [operate-webapp-8.5.0-exec.jar:8.5.0]
Caused by: java.util.concurrent.ExecutionException: io.grpc.StatusRuntimeException: CANCELLED
at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:396) ~[?:?]
at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2073) ~[?:?]
at io.camunda.zeebe.client.impl.ZeebeClientFutureImpl.join(ZeebeClientFutureImpl.java:52) ~[zeebe-client-java-8.5.0.jar!/:8.5.0]
… 36 more
Caused by: io.grpc.StatusRuntimeException: CANCELLED
at io.grpc.Status.asRuntimeException(Status.java:533) ~[grpc-api-1.62.2.jar!/:1.62.2]
at io.grpc.stub.ClientCalls$StreamObserverToCallListenerAdapter.onClose(ClientCalls.java:481) ~[grpc-stub-1.62.2.jar!/:1.62.2]
at io.grpc.internal.ClientCallImpl.closeObserver(ClientCallImpl.java:574) ~[grpc-core-1.62.2.jar!/:1.62.2]
at io.grpc.internal.ClientCallImpl.access$300(ClientCallImpl.java:72) ~[grpc-core-1.62.2.jar!/:1.62.2]
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInternal(ClientCallImpl.java:742) ~[grpc-core-1.62.2.jar!/:1.62.2]
at io.grpc.internal.ClientCallImpl$ClientStreamListenerImpl$1StreamClosed.runInContext(ClientCallImpl.java:723) ~[grpc-core-1.62.2.jar!/:1.62.2]
at io.grpc.internal.ContextRunnable.run(ContextRunnable.java:37) ~[grpc-core-1.62.2.jar!/:1.62.2]
at io.grpc.internal.SerializingExecutor.run(SerializingExecutor.java:133) ~[grpc-core-1.62.2.jar!/:1.62.2]
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.base/java.lang.Thread.run(Thread.java:840) ~[?:?]
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
would you please share oidc?
We use our organization internal OIDC provider. Are you looking for any specific information on OIDC configuration ?
This usually means that the URL you are trying to connect to has a self-signed certificate. You need to establish a trust chain, which often involves updating your Java Keyring, which is really outside the scope of this forum.
If possible try having your internal OIDC upgrade to a commercial certificate, which will have a trust chain from the default Java Keyring.
If you must stay with a Self-Signed Certificate, you need to update the keyrings within the images that Helm is installing.
@GotnOGuts Thanks for the response. The images the Helm is installing are the Camunda images added to a private repository of our organization. So, do you mean that the helm chart should be updated to use public key of our OIDC provider ? If that is the idea for trying out, can you please suggest what kind of changes required in Helm chart. I am beginner in Kubernetes and trying to setup Self-Managed host for my team.
First question is:
Does your OIDC provider use a self-signed certificate or a commercial one?
If we do establish that you have a self-signed cert and you cannot apply a commercial cert (how are the clients going to trust your OIDC provider then?), then dig into the trust path.
I don’t yet have a C8 cluster running, so can’t really guide you on how to inject your public keys into the image.
Our OIDC provider is using commercial certificate already. I got it verified. In fact, the commercial certificate authority in this case is again owned by our organization. The applications we use are internal applications.
That’s usually the definition of Self-Signed.
Is your Root-CA cert included in the default Windows OS install?
Is your Root-CA cert included in the default Java install?
If you answered no to EITHER of those questions, then you have a self-signed setup, and you need to inject a certificate into the image.
Another possibility is that you have just the OIDC cert loaded, not the chain (which I’ve seen on a number of servers), so there’s no way to go from WebServer → Intermediary → Regional → Root-CA . At the end of the day, that’s what the PKIX error means.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.