Deprecate --self-signed-cert flag

[tolusha]

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]

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.

[sujen1412]

Hi @mmorhun,

For Kubernetes deployment, you mentioned it is a proposed algorithm, so that means currently it is required to provide TLS certificate with the self-signed-cert option.

Because, we tried option 3

If che-tls present but self-signed-certificate missing, treat it as a real certificate use case.

by providing a real wildcard certificate, but that did not work.

The only way we were able to make the deployment work was providing a self signed certificate and importing that into our browsers, which is not ideal for production.

cc @sneely333

[mmorhun]

Hello @sujen1412,
My comment above is a proposal how to resolve this issue.
However, the way to deploy Che with real certificate shouldn't be different.
To use real certificate, create che-tls secret (should have tls.key and tls.crt fields under data) in Che namespace (precreate it manually). Then deploy Che with followig command (add other options if needed):

chectl server:start -n <namespace> --domain=<your-public-domain> --platform=k8s --installer=operator

[mmorhun]

We tried to use approach described above, but it doesn't work correctly for Openshift infrastructure. Despite deployment process finishes ok, some components doesn't work properly if commonly trusted certificate is given as self-signed one.

Actually router TLS certificate chain could be:

• self-signed.
• signed by commonly trusted authority.
• signed by self-signed certificate.

We can determine whether router TLS certificate is self-signed by analyzing the chain. But it is much harder if chain has reference to parent CA which is not included. To my mind, reasonable algorithm should be: check if we are dealing with self-signed one. If so, just propagate it to Che components as we usually do. If it is not the case, consider that the certificate is commonly trusted. I believe that such approach will cover most of the use cases. In case if Openshift cluster is configured with CA certificate which is signed by some self-signed one (or chain), administrator should take care about that and add the parent certificate into additional certificates to trust (actually add it into config map).

@l0rd @tolusha @sleshchenko @skabashnyuk WDYT?

[sneely333]

@mmorhun thank you for your help. Working with @sujen1412, I have tried your suggestion but eclipse che fails to install.
We have a domain name and a valid wildcard for it (i.e. my system is something like node.mydomain.org and I have a wildcard for *.mydomain.org). We are on a network that allows all traffic out but no externally originating traffic in from the Internet.

So my question to you or anyone else is:

1. Can eclipse che use a wildcard cert for che-tls?
2. Does eclipse che require any ports originating from the internet in order to complete the installation?
3. Does eclipse che need to be able to modify the dns of a domain in order to run? I have a hostname but the domain is owned by the parent organization, not the group using eclipse che. Currently I have keycloak-che.mydomain.org, che-che.mydomain.org, devfile-registry-che.mydomain.org and plugin-registry-che.mydomain.org all pointing to the same host. Do I need to own the subdomain, provide nameservice for it where eclipse che can edit it and use the Let's encrypt cert issuer service to issue certs for it?

My failure messages are below:

Thanks and please let me know if this should be posted on a separate thread or location.
Susan

events.log ends with:
0s Normal Created pod/che-5f69f6d96b-kb4k5 Created container che
0s Normal Started pod/che-5f69f6d96b-kb4k5 Started container che
0s Normal UPDATE ingress/plugin-registry Ingress che/plugin-registry
0s Normal UPDATE ingress/devfile-registry Ingress che/devfile-registry
0s Warning Unhealthy pod/che-5f69f6d96b-kb4k5 Readiness probe failed: Get "http://10.1.64.10:8080/api/system/state": context d
eadline exceeded (Client.Timeout exceeded while awaiting headers)
0s Warning Unhealthy pod/che-5f69f6d96b-kb4k5 Readiness probe failed: HTTP probe failed with statuscode: 500
0s Warning Unhealthy pod/che-5f69f6d96b-kb4k5 Readiness probe failed: HTTP probe failed with statuscode: 500
0s Warning Unhealthy pod/che-5f69f6d96b-kb4k5 Readiness probe failed: HTTP probe failed with statuscode: 500

che.log has a significant amount of java exceptions all starting with:
while locating org.eclipse.che.api.workspace.server.WorkspaceManager
Caused by: java.lang.RuntimeException: Exception while retrieving OpenId configuration from endpoint: https://keycloak-che.mydomain.org/auth/realms/che/.well-known/ope
nid-configuration

keycloak.log does not contain errors but does include this warning:
20:11:57,019 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /opt/jboss/keycloak/standalone/configuration/applicat
ion.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost

[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).

[nickboldt]

is this being backported to 7.14.x (CRW 2.2), or only to be fixed in 7.15?

[mmorhun]

I think we should backport this feature into Che 7.14.x branch.

[l0rd]

@mmorhun yes please

[mmorhun]

Done