Multi-user Che with IBM Cloud Private's OIDC server failing due to self-signed certs
See original GitHub issueDescription
I’m trying to get multi-user Che running on IBM Cloud Private (ICP) 3.1.2, using ICP’s own OIDC server as the OIDC provider. The server is running at https://<master-ip>:8443/oidc/endpoint/OP
. I’ve made sure to set the following values in the Che helm chart:
customOidcProvider: "https://<master-ip>:8443/oidc/endpoint/OP"
tls:
enabled: true
useCertManager: true
useStaging: false
secretName: che-tls
However, when I install Che, the following errors are shown in the Che pod’s logs:
1) Error injecting constructor, java.lang.RuntimeException: Exception while retrieving OpenId configuration from endpoint: https://<master-ip>:8443/oidc/endpoint/OP/.well-known/openid-configuration
at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.<init>(KeycloakSettings.java:70)
at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.class(KeycloakSettings.java:53)
while locating org.eclipse.che.multiuser.keycloak.server.KeycloakSettings
for the 1st parameter of org.eclipse.che.multiuser.keycloak.server.KeycloakProfileRetriever.<init>(KeycloakProfileRetriever.java:39)
at org.eclipse.che.multiuser.keycloak.server.KeycloakProfileRetriever.class(KeycloakProfileRetriever.java:32)
while locating org.eclipse.che.multiuser.keycloak.server.KeycloakProfileRetriever
for the 1st parameter of org.eclipse.che.multiuser.keycloak.server.dao.KeycloakProfileDao.<init>(KeycloakProfileDao.java:38)
while locating org.eclipse.che.multiuser.keycloak.server.dao.KeycloakProfileDao
while locating org.eclipse.che.api.user.server.spi.ProfileDao
for the 2nd parameter of org.eclipse.che.multiuser.keycloak.server.KeycloakUserManager.<init>(KeycloakUserManager.java:58)
at org.eclipse.che.multiuser.keycloak.server.KeycloakUserManager.class(KeycloakUserManager.java:58)
while locating org.eclipse.che.multiuser.keycloak.server.KeycloakUserManager
while locating org.eclipse.che.multiuser.api.account.personal.PersonalAccountUserManager
while locating org.eclipse.che.api.user.server.UserManager
Caused by: java.lang.RuntimeException: Exception while retrieving OpenId configuration from endpoint: https://<master-ip>:8443/oidc/endpoint/OP/.well-known/openid-configuration
at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings.<init>(KeycloakSettings.java:104)
at org.eclipse.che.multiuser.keycloak.server.KeycloakSettings$$FastClassByGuice$$e0d0786b.newInstance(<generated>)
at com.google.inject.internal.DefaultConstructionProxyFactory$FastClassProxy.newInstance(DefaultConstructionProxyFactory.java:89)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:114)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:42)
at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:65)
at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:113)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:91)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:306)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:168)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:39)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:62)
at com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:211)
at com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:182)
at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109)
at com.google.inject.Guice.createInjector(Guice.java:87)
at org.everrest.guice.servlet.EverrestGuiceContextListener.getInjector(EverrestGuiceContextListener.java:140)
at com.google.inject.servlet.GuiceServletContextListener.contextInitialized(GuiceServletContextListener.java:45)
at org.everrest.guice.servlet.EverrestGuiceContextListener.contextInitialized(EverrestGuiceContextListener.java:85)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:985)
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
The last error makes it seem like its failing on the self-signed cert that ICP uses for OIDC. So I guess I have two questions:
- Has anyone had luck integrating Che with ICP’s OIDC server? If so, how?
- Has anyone been able to run a multi-user Che with a self-signed certificate for TLS?
I’m wondering if I need to update the che-tls secret? Maybe have it contain the self-signed certs? I’m not sure.
Issue Analytics
- State:
- Created 5 years ago
- Comments:9 (6 by maintainers)
Top Results From Across the Web
401 self-signed certificate error returned when accessing ...
This issue occurs when the IBM Cloud Private console certificate is created automatically when IBM Cloud Private is installed. To verify this is...
Read more >Red Hat CodeReady Workspaces 2.15 Installation Guide
Understanding CodeReady Workspaces server advanced configuration ... When enabled, the certificate from che-git-self-signed-cert ConfigMap.
Read more >kubectl error when retrieving credentials from custom-process
4) Incase of TLS it throws the below Keycloak error and incase of Self-signed it says che-certificate-manager already exists even when the kubernetes...
Read more >OpenShift Articles - CertDepot
Advanced Cluster Security: A Brief Introduction to Red Hat Advanced Cluster Security for Kubernetes (27/05/2021),; Continuous Security for Cloud-native ...
Read more >Search Results - CVE
Versions of pgAdmin prior to 6.17 failed to properly secure this API, ... Server without direct access to the client certificate and related...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@davidwindell I believe so, that’s what I ended up needing to use to get it working.
@johnmcollier I’ve just tried to setup Gitlab as an OpenID connect provider for Che. I’m also seeing the same thing with ?code being added to the URL and an infinite redirect loop. Do I need wildcard support to be implemented to fix this do you think? https://gitlab.com/gitlab-org/gitlab-ce/issues/48707