incubator/crd.yaml tlsSupport:true by default breaks server:start in minikube

[gattytto]

changes introduced in latest versions of chectl the file:
/usr/local/lib/chectl/templates/che-operator/crds/org_v1_che_cr.yaml
set the following default:

tlsSupport: true
selfSignedCert: false

while the comment above tlsSupport instates:

# TLS mode for Che. Make sure you either have public cert, or set selfSignedCert to true

after issuing "chectl server:start -m -p minikube" to start a new che, che-server breaks on startup because of:

Caused` by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching keycloak-che.10.0.2.33.nip.io found.

[mmorhun]

@gattytto could you please provide step by step flow how you tried to deploy Che. Also full logs attached increases chances of problem understanding.

[tolusha]

Duplicates
#16396 ?

[gattytto]

@gattytto could you please provide step by step flow how you tried to deploy Che. Also full logs attached increases chances of problem understanding.

just emptied out /usr/local/lib/chectl and deleted /usr/local/bin/chectl
went to incubator/chectl git page and ran the :next "bash" install method pointed out there.

then it downloads all the yamls again and puts the chectl binary in place, then run it using:
"chectl server:start -m -p minikube".

as mentioned, those 2 settings come by default in the crd.yaml file downloaded by the script. Switching tlsSupport back to "false" allowed me to deploy che normally.

[tolusha]

@gattytto
We are working on providing clearer steps how to use tls

[gattytto]

@tolusha tlsSupport is still enabled by default along with selfSigned set to false, meaning chectl+che-operator+kube will try tls without expecting self signed (I'm guessing self signed will still be used by default) so this will break?

[tolusha]

@gattytto
You are right.
We are working on deprecating selfSignedCert or setting it to true at least .