Self-signed-cert issues in new versions of Che prevent Codewind from supporting newer versions

[johnmcollier]

Opening an issue here for tracking on our side of the TLS issues we're hitting in Che, there isn't anything really for us to "do" for this.

Back in the fall, changes in Theia were delivered that required HTTPS for webviews to properly function (eclipse-theia/theia#6465 (comment)). Che (and Che Theia) 7.6.0 was the first version of Che to pull this change in (eclipse-che/che#15616). This means that Codewind on Che 7.6.0 (or higher) requires Che to be installed with TLS enabled, or else the webview CSS will be broken.

When Che is deployed on a cluster using publicly signed certificates (such as on IBM Cloud), this is perfectly fine, and Codewind and Che work great with TLS enabled. However, on clusters with self-signed-certificates (like on our dev OCP4 clusters on Fyre), Che by default rejects all of the ingresses/routes with self-signed certificates. To work around that, the user has to:

1. Run oc get routes / kubectl get ingress and manually whitelist all of the routes/ingresses installed with Che in their browser:

   che-che.apps.some.url.com
   devfile-registry-che.apps.some.url.com
   keycloak-che.apps.some.url.com
   plugin-registry-che.apps.some.url.com
   

   If the user misses a URL here, Che does not prevent them with any errors or tells them what to do

2. Once they've created a workspace, they have to Run oc get routes / kubectl get ingress and manually whitelist the workspace-specific routes/ingresses in their browser as well:

    route0nzv85h8-che.apps.some.url.com
    route28decx1k-che.apps.some.url.com
    route4bv4ufz4-che.apps.some.url.com
    routea19gynas-che.apps.some.url.com
    routefotdpb5q-che.apps.some.url.com
    routerm5stq1e-che.apps.some.url.com
   

   Again, if the user misses a URL here, they're not presented with any errors. And each user will need to repeat this step for each Che workspace they create/access.

The current alternative to all of this, is to have the user generate their own certificate, replace the OpenShift router's default certificates with that certificate, and have each user add the root CA certificate into browser's whitelist. However, that's not an option that would be possible or acceptable for many.

I voiced my frustration in eclipse-che/che#15658, if anyone wants more details.

Now, there is some work being done in Che to mitigate this:

1. TLS by default eclipse-che/che#14742
2. Dashboard messages should be more accurate when self-signed cert issue happens eclipse-che/che#15298
3. https://www.eclipse.org/lists/che-dev/msg03566.html (and its children)

But until then, we're unable to move up Che versions that Codewind supports.

[johnmcollier]

eclipse-che/che#16052 is the issue to keep an eye on from Che's side.

Once it's delivered, we should have no issues verifying Codewind on newer Che versions with self-signed certs

[johnmcollier]

Adding tech-topic label as a potential workaround has been identified:

1. Download the cluster's router certificate from your browser
2. Add the certificate to your system
3. Set the certificate's trust to Always trust

Do we want to update our docs to tell the user to do that so that we can move up to supporting newer Che versions, or do we want until the improvements in the Che operator are in so that the above steps aren't needed?

[jopit]

JohnC to investigate the answers to the following:

• How easy is this on Windows/Linux?
• Will there be problems when using FireFox?

[johnmcollier]

Still need to investigate Windows/Linux, but for Firefox:

• Firefox 71 and up has a newer certificate view/manager and it allows you to import the ingress-operator certificate in the browser and everything works
• Firefox 70 and older don't work, and do not allow you to download the ingress-operator