On Kubernetes we generate an untrusted SSL cert even when the default is a valid one

[l0rd]

Describe the bug

I have setup my Kubernetes Ingress controller to use a certificate signed by a trusted CA (at least my browser trust it).

When I deploy Che on that cluster I figure out that the dashboard is using an untrusted certificate (my browser don't trust it). And then I need to locally install the certificate or I won't be able to use Che at all.

Che version

nightly

Steps to reproduce

On minikube:

• Generate a valid certificate for you minikube applications (I have used mkcert)
• Configure nginx controller to use the new certificate (instructions here)
• Deploy Che using chectl

Expected behavior

Che should use the default SSL certificate instead of generating a new one

Runtime

minikube version: v1.13.1

Screenshots

Installation method

chectl server:start -p minikube -n workspaces-server

Environment

macOS

[mmorhun]

Hello @l0rd. I don't completely understand the DoD of this issue:

Generate a valid certificate for you minikube applications (I have used mkcert)

This certificate created by mkcert has the same level of validity (it is not possible to generate commonly trusted certificate for Minikube) as the certificate generated by our operator. mkcert adds it into users system and/or browser trust store. Just a bit more automations on user's system level.

Che should use the default SSL certificate instead of generating a new one

The problem is that trust is a sort of a bit subjective thing. A certificate might be trusted by one organisation and doesn't by another...
Also, sometimes, Google Chrome (at least) doesn't display 'accept the risk and continue' link. I don't know exact reasons why and when it happens, but I faced that.

Could you elaborate more on how you see the solution?

[l0rd]

@mmorhun the problem is that we always generate a certificate. If the user wants Che to use the default nginx certificate there is no option for that.

This certificate created by mkcert has the same level of validity (it is not possible to generate commonly trusted certificate for Minikube) as the certificate generated by our operator. mkcert adds it into users system and/or browser trust store. Just a bit more automations on user's system level.

Agree. mkcert just helped me to reproduce the problem locally: I have a trusted certificate and I have configured minikube to use it, but Che uses its own auto-generated certificate that I need to install locally (and repeat the install of the Che certificate every time I redeploy Che).

[tolusha]

For the time being we can deploy Eclipse Che without generating an untrusted SSL cert in the following way:

1. helm

cat >/tmp/che-cr-patch.yaml <<EOL
global:
  tls:
    secretName: ''
EOL

chectl server:deploy --installer helm ... --helm-patch-yaml /tmp/che-cr-patch.yaml

2. operator

cat >/tmp/che-cr-patch.yaml <<EOL
spec:
  k8s:
    tlsSecretName: ''
EOL

chectl server:deploy --installer operator ... --che-operator-cr-patch-yaml /tmp/che-cr-patch.yaml