Unable to run task when using custom TLS certificate

[l0rd]

Describe the bug

I have deployed Che on minikube. I am using a custom TLS certificate for Che endpoints.

That means that I have:

• created a Kubernets tls secret with the key and certificate
• updated CheCluster setting both spec/k8s/tlsSecretName and /spec/server/cheHostTLSSecret to point to that secret
• add the CA certificate in configmap properly labelled (as described here)

When trying to run a task I get the following error:

Error launching task 'maven build': Request runTask failed with message: Failed to execute Che command: unable to verify the first certificate 

Che version

nightly

Steps to reproduce

Deploy Che on minikube using chectl
Configure Che to use a custom certificate as described here
Start the Java maven sample
Try to start one of the 2 tasks provided

Expected behavior

The maven build should run successfully

Runtime

minikube

minikube version: v1.17.1
commit: 043bdca07e54ab6e4fc0457e3064048f34133d7e

Installation method

$  chectl update next && \
   chectl server:deploy \
       -p minikube

Environment

macOS

[azatsarynnyy]

I'm labeling it as area/plugins it's related to Task Plug-in.

[sunix]

I have managed to reproduce this issue.
My thoughts:

• Why it is working with the origininal self-signed certificate that is generated when installing Che?
• Why are we trying to use an 'external URL' ? when we are trying to reach machine exec which is local to the workspace pod: https://github.com/eclipse/che-theia/blob/9a76d18382e3b90858b1fd63e713eb908facbb70/plugins/task-plugin/src/che-workspace-client.ts#L112

[sunix]

Maybe different cert being used here: https://github.com/eclipse/che-machine-exec/blob/master/main.go#L87

[sleshchenko]

Why it is working with the origininal self-signed certificate that is generated when installing Che?

The difference I see:
https://che-incubator.github.io/2021/02/01/@mario.loriedo-using-mkcert-to-locally-trust-eclipse-che-tls-certificates-ffaafe76e5d0.html creates CA into custom-certs cert

While default certs Che operator generated, are propagated over

    spec:
      containers:
      - env:
        - name: CHE_SELF__SIGNED__CERT
          valueFrom:
            secretKeyRef:
              key: ca.crt
              name: self-signed-certificate
              optional: true
        - name: CHE_GIT_SELF__SIGNED__CERT
        - name: CHE_GIT_SELF__SIGNED__CERT__HOST

from secret self-signed-certificate
Custom certificates and Che Self-signed can be used on different ways.

[ericwill]

What's left to be done for this ticket, @sunix can we close it?

[sunix]

Yes closing. FYI, I created #19246 to clarify our docs on how things should be configured as a che admin. And how plugins/editors/applications should consume these certificate.

[l0rd]

@sunix Can you provide more details? In particular what's not clear is:

1. Have you been using a custom TLS certificate (not the auto generated one) and have Che working?
2. Are the steps to configure Che to use a custom certificate easy to follow for an admin?

[l0rd]

@sunix the custom certificate is trusted by the Che server (because it's able to communicate with Keycloak), by the plugin brokers (because they are able to communicate with the registries), by Theia (because it's able to communicate with the Che server). But somehow there is a process that probably looks in the bad (old/legacy) folder for trusted certificates and running tasks fail.

[sunix]

To test: remove the certificate generated by chectl from the browser and see if terminal is working or not.

[l0rd]

I have somehow missed that the issue had been solved by eclipse-che/che-theia#1019. I thought that the issue was closed in favor of a doc issue. I will verify the fix and if it works for me I will close the issue later today.

To test: remove the certificate generated by chectl from the browser and see if terminal is working or not.

I never install the certs generated by chectl anyway

[l0rd]

Closing as this issue as been solved. Although I am still not able to successfully run this scenario as I have found another bug 😡