There is no need to add the self signed CA in single host mode

[l0rd]

Describe the bug

When I deploy Che with chectl in single-host mode and I am warned to add a certificate:

    ✔ ❗[MANUAL ACTION REQUIRED] Please add Che self-signed CA certificate into your browser: /Users/mariolet/cheCA.crt.
   Documentation how to add a CA certificate into a browser: https://www.eclipse.org/che/docs/che-7/overview/importing-certificates-to-browsers/

But that's not needed. Che workspaces work fine in my browser even if I do not import the certificate.

Che version

nightly

Steps to reproduce

On minikube deploy Che using chectl:

$ echo "spec:
   server:
    serverExposureStrategy: 'single-host'
   k8s:
    singleHostExposureType: 'native'" > ./patch.yaml
$ chectl server:start \
   -p minikube \
   --che-operator-cr-patch-yaml \
   ./patch.yaml
....
  ✔ Show important messages
    ✔ Eclipse Che admin credentials are: "admin:admin". You will be asked to change default Che admin password on the first login.
    ✔ Autogenerated Keycloak credentials are: "admin:bR1CmX698Ywc".
    ✔ ❗[MANUAL ACTION REQUIRED] Please add Che self-signed CA certificate into your browser: /Users/mariolet/cheCA.crt.
   Documentation how to add a CA certificate into a browser: https://www.eclipse.org/che/docs/che-7/overview/importing-certificates-to-browsers/
Command server:start has completed successfully.

Expected behavior

No warning, no message to add the CA cert into a browser.

Runtime

minikube version: v1.13.1
commit: 1fd1f67f338cbab4b3e5a6e4c71c551f522ca138

Screenshots

Environment

macOS

[PirateBread]

Is it the case that single host mode removes the requirement to add the cert to the browser? I'm interested in this issue as I'm trying to configure with a self-signed cert however due to client restrictions we can't add the certificate to the browser. Does this mean we're forced to create a trusted certificate?

[l0rd]

Is it the case that single host mode removes the requirement to add the cert to the browser?

@PirateBread correct

[l0rd]

@PirateBread to be precise you will still have a warning and you have to agree to accept the risk of accessing a website that uses an untrusted certificate but you don't need to perform actions that need admin rights (download the certificate and configure your browser/host sot that the certificate authority is added among the trusted ones).

[PirateBread]

@l0rd

Thanks for confirming. I don't think this is documented anywhere? I'm trying to access Eclipse using single host mode but can't get past this client side SSL check. Your post was the only thing I found on this topic.

The config map has the following:
CHE_INFRA_KUBERNETES_SERVER__STRATEGY: single-host

I'm not using chectl, but deploying with Helm, so wondering what the difference is between your install which doesn't need it.

[sleshchenko]

@PirateBread here you can find docs about it https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-workspace-exposure-strategies/
If you don't use chectl - you need to generate certificates by your own. Chectl does it with the following resources
https://github.com/eclipse/che/tree/master/deploy/cert-manager, https://github.com/che-incubator/chectl/blob/master/installers/cert-manager.yml

[PirateBread]

@sleshchenko Thanks for the comment. I have seen that particular documentation but not relating to the client SSL validation. This is the only resource I've seen which suggests that the adding the certificate to the browser is not required when deploying in single-host mode.

To clarify: my issue is deploying Che in single-host mode with an internal generated certificate which is not trusted by the end user devices. I am being blocked accessing the dashboard by the "self-signed" SSL check which is asking me to trust the certificate in the browser, which we can't do due to restrictions on the end user devices.

[l0rd]

I am being blocked accessing the dashboard by the "self-signed" SSL check which is asking me to trust the certificate in the browser, which we can't do due to restrictions on the end user devices.

@PirateBread now I understand your problem. I think that to overcome this problem I have opened https://<che-host>/swagger and accepted the warning / risks from the browser. Then I was able to use the dashboard. I actually think the problem may be related to the fact that if single-host is set for the che server only (using the config map) keycloak and che-server ingresses will use different hosts. The configuration should be done at the global values level for helm based installations or at the CheCluster level for operator based installations.

[mmorhun]

In general, it is still better to add the certificate as trusted in case if clients aren't in the trusted network. Otherwise, it might be unsafe.

[l0rd]

In general, it is still better to add the certificate as trusted in case if clients aren't in the trusted network. Otherwise, it might be unsafe.

@mmorhun asking users to add an untrusted CA certificate to their local truststore is not safe and it's worse than accepting one exception.

[mmorhun]

asking users to add an untrusted CA certificate to their local truststore is not safe and it's worse than accepting one exception.

Disagree on this. When users add self-signed certificate into their trust store it is possible to check its origin (he cert was given by admin or generated by Che installer). In case of just trusting unknown untrusted thing in is not possible to check at all.

[l0rd]

A couple of updates here:

• We agreed with the deploy team that, in single host mode, we are NOT going to suggest to the user to locally import Che CA certificate
• I have checked that, in single host mode, after the browser warns the user about the risk of using an untrusted cert and the user accept to open the website anyway, Che dashboard doesn't block the user and everything works as expected. No need to open https://<che-host>/swagger as I suggested above. @PirateBread your problem may be related to the fact that you set CHE_INFRA_KUBERNETES_SERVER__STRATEGY: single-host for the che server but that doesn't prevent keycloak ingress to use a different hostname (and a different untrusted certificate). To avoid that you should follow carefully helm or operator instructions.