Deprecate `--self-signed-cert` flag

Is your task related to a problem? Please describe.

The goal of this task is to deprecate using --self-signed-cert since it causes a lot of failed deployments of Eclipse Che in case if use forgot to set it to true

[mmorhun]

Hello @sneely333

please let me know if this should be posted on a separate thread or location

Probably yes as this ticket is for new feature (which is in progress and any implementation discussion should happen here), so posting installation issue here mixes two different topics.

Can eclipse che use a wildcard cert for che-tls?

By default it is a requirement, because Che has its components on subdomains. Moreover, any user created endpoint (a server within a workspace for example) will create a new ingress/route (depending on your infrastructure) which, by default, creates new subdomain. However, there is a possibility to use single-host strategy installation which is under active development now. You may try it as well.

Does eclipse che require any ports originating from the internet in order to complete the installation?

Eclipse Che uses external route to reach Keycloak, so it could be the reason of your installation failure (and looking at the error from the provided log I see that Che server failed to query Keycloak). P.S. You may try to use external Keycloak, though. Please refer docs. But it is easier to set up network for Che to be able to reach default Keycloak.

Does eclipse che need to be able to modify the dns of a domain in order to run?

No it doesn’t need to chanage DNS records, but Eclipse Che creates new ingresses/routes for its endpoints. So all subdomains should point to the cluster (unless single host mode is used).

[mmorhun]

It would be good to autodetect whether self-signed certificate is used. However, because we use different approaches for Kubernetes and Openshift, solutions have to be different too.

• Openshift. We use router certificate to secure endpoints. So using or not self-signed certificate completely depends on the certificate type with which Openshift cluster is provisioned. Che admin just cannot control it with current approach. As Openshift clusters are often provisioned with self-signed certificates, it makes sense to turn the option by default. With such approach, in case of real certificate, we’ll be adding a CA which is already trusted. It shouldn’t do any harm.
• Kubernetes. For Kubernetes platform it is required to provide TLS certificate for Che. It is proposed to use the following algorithm:
  • If there is no che-tls and no self-signed-certificate secrets, treat it as self-signed certificate case and generate the secrets.
  • If both secrets present, consider the case as self-signed certificate option.
  • If che-tls present but self-signed-certificate missing, treat it as a real certificate use case.
  • If che-tls missing but self-signed-certificate present, treat it as invalid state, delete existing self-signed-certificate and generate the pair.