create workspace failed when customize the hostname

[whafra]

refernce:
https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-che-hostname/

the enviroment (air-gap ):
OS :ubuntu 18.04.5 LTS
kubernetes version:v1.18.6
eclipse-che version: 7.19.0
install cmd:
chectl server:start --installer=operator --platform k8s --multiuser ....

I have deplyed the eclipse-che successfully (refer to https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-che-hostname/)
the patch file was :
spec:
server:
cheHost: XXXX
cheHostTLSSecret: che-tls

When i accessed https:// , the unsafe certificate message appreared .
if i ignore the warning and contine to go ahead , the login interface showed up. Everything seemed ok.
But when tried to create workspace ,the exception was thrown by che-plugin-metadate-broker-v3-4-0 , and the key information was just like :

Colud not connetct to endpoint 'wss:///api/websocket' ,due to error 'x509;certificate is valid for ingress.local,not '

could somebody give me some advice ?
thanks a lot.

[tolusha]

@whafra
I will check

[tolusha]

Minikube v1.14.0

What does work (Eclipse Che is deployed, workspace is created):

1. Eclise Che 7.19.2
   patch file:

spec:
  server:
    cheHost: my-new-ide.com
    cheHostTLSSecret: chehost

chehost secret is differ from che-tls secret. It is created to secure my-new-ide.com specifically.

2. Eclipse Che nightly
   It is not needed to specify tls secret for cheHost in this case

spec:
  server:
    cheHost: my-new-ide.192.168.99.100.nip.io

What doesn't work (regression)
3. Eclipse Che nightly

spec:
  server:
    cheHost: my-new-ide.com
    cheHostTLSSecret: chehost

[whafra]

@tolusha
As your advice , I tried the following method

spec:
server:
cheHost: xxx.com
cheHostTLSSecret: che-host-tls

and the che-host-tls was differ from the self-signed secret .It was created to secure xxx.com specifically.
And When i was creating workspace , I met with the error thrown by che-plugin-broker

Couldn't connect to endpoint 'wss://xxx.com/api/websocket', due to error 'x509: certificate signed by unknown authority'
And by the way , i upgrade the eclipse-che to 7.21.0.

Do you have some suggestion ?thank you .

[tolusha]

Probably it might happen if a different root CA was used to generate server certificate for chehost.
Could you confirm that use used the same root CA ?

[whafra]

@tolusha
thanks for your help
Could you give me more details about " the same rootCA "
the che-host-tls must use the same rootCA to the chehost secret ? In my scenario ,I created the self-signed centification before deploying the che . I am confused ....

Thank you .

[tolusha]

Initially I generate ca.crt then using this CA I generate private and public keys for che-tls and chehost secrets. [1]
Then I create all those secrets in a che namespace [2]

[1] https://gist.github.com/tolusha/3137568f330111a305da4f2dd28c6e33
[2] https://gist.github.com/tolusha/10998fa2d683c387a662d2ed3e6a3e05

[whafra]

@tolusha
thank you very much . The script you supported took effect . Everything is ok ...
And I have another two confusion .

1. I remembered that there is a documentation of "how to create the self-signed-centification " on the website https://www.eclipse.org/che/docs ,however ,i can not find it now .
2. In my origanization ,the domain name and the related cert is delivered by some certain department after application and review. And I will get the domain cert (a .pfx file ) . under these condition ,could i use the same rootCA to create the self-sign certification (as your script ,it is domain.crt) ? In other word , I have host.key , host.crt and ca.key ,ca.crt , could i use the existing ca.crt and ca.key to create the domain.crt?
   I am not familiar to the certification and hope that my description is clear enough .
   Thank you .

[mmorhun]

Hello @whafra. The idea here is to have the same root CA for both che-tls and chehost secrets.
In case of your own self-signed certificate, you generate self-signed root certificate and with its private key you create and sign both child certs: che-tls and chehost. Actually that's what @tolusha said.
If you department provides certificates with the domian then you can go two ways:

1. Ignore certificate from your department and use your own self-signed one. This approach makes you sort of independent, but it has limitations: to use Che, all users should trust the certificate generated by you. If it is only you who supposed to use Che then you have to add your certificate into your system trust store (or browser's one). If you want to give access to a friend of yours, then he/she should add your root CA certificate into their system (or browser).
2. Request certificate to cover all Che ingress domains from your department. This way no one should add something and it will work out of the box. However, you have to get parent(what we called root before) CA (actually chain of trust) and content of both che-tls and chehost from departments' system administrator.

[whafra]

@mmorhun ，thank you.
If i select the second way ，I have to get the rootCA ...
and should I have to change the install command ...
from
chectl server:start --installer=operator --platform k8s --multiuser --domain=masterip.nip.io
to
chectl server:start --installer=operator --platform k8s --multiuser --domain=xxx.com
......................................
I am not sure whether I understand it correctly.
Thanks for your help.

[mmorhun]

@whafra, I have a question first. When you deploy Eclipse Che, do you need a user provided domain for Che dashboard? Because in the issue description you seems used it, but in the comment above you don't. If you don't need it, then you can drop cheHost and cheHostTLSSecret fields and operator will assign Che dashboard URL automatically, so you don't need to do some extra config.
Now answering your question. The domain parameter should be adjusted with your Kubernetes cluster settings. Provided domain should lead a user into Kubernrtes cluster. And that's system admin responsibility to configure network and/or cluster right way. Also, the certificate from che-tls secret must match the domain (otherwise it will not work).

[skabashnyuk]

As far as I can see we didn't set Content-Security-Policy or x-frame-options headers for workspace-loader page. It might happen that at some point in time Chrome changed his internal policies of how to interpret these values if they are not set.

[tolusha]

@whafra
If you don't mind I will keep this issue opened as a reminder.
There is something we can improve here.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[tolusha]

I identified a new problem after switching from keycloak to OIDC identity provider while deploying Eclipse Che on minikube.
redirectUrl is not configured properly in dex configuration.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.