Che: TLS with CRC does not work in Chrome/Chromium

Created on 4 Jun 2020  路  11Comments  路  Source: eclipse/che

Describe the bug

The process described to work with self-signed certificates in Che does not work on the combination of CRC 1.11.0, Che nightly and Chrome/Chromium

Che version

  • [ ] latest
  • [x] nightly
  • [ ] other: please specify

Steps to reproduce

  1. Install Che on crc as described
  2. go to https://che-che.apps-crc.testing/ with the browser
  3. Observe: you get an error page mentioning NET::ERR_CERT_AUTHORITY_INVALID
  4. Run chectl cacert:export -p crc
  5. In the browser, go to settings->privacy and security->manage certificates
  6. On the "trusted root certification authorities" tab, press "import"
  7. Import the file ~/cheCA.crt
  8. Observe: Chrome warns you about importing a root cert for *.apps-crc.testing
  9. Import the cert anyway
  10. Observe: the "trusted root certification authorities" tab does not show a cert for *.apps-crc.testing
  11. Restart the browser
  12. go to https://che-che.apps-crc.testing/
    13: observe: you still get the error NET::ERR_CERT_AUTHORITY_INVALID

Expected behavior

Ideally, just having to accept the certificate in the browser page, instead of importing a root cert authority
Failing that, I would like the import to work.

Runtime

  • [ ] other: crc 1.11.0

Screenshots

Installation method

chectl -a operator -p crc

Environment

  • [ ] my computer

    • [x] Windows

    • [ ] Linux

    • [ ] macOS

aredev-experience areinstall kinbug severitP1

All 11 comments

Ideally, just having to accept the certificate in the browser page, instead of importing a root cert authority

That's currently possible if we deploy Che in single-host mode. Single-host mode currently works on k8s but not on openshift. Platform team is working to support single-host on OpenShift too. Once it's supported on both platforms we should make it the default.

@l0rd this is blocking dogfooding for me: in the past, I used minishift, but was instructed to move to crc, since minishift is legacy.
Having some folks develop in crc is desirable, since OpenShift is generally more restrictive than Kubernetes.

Also, do we know I have no way to test this, but we should analyze if this bug affects OpenShift 4 in general, not just crc.

@tsmaeder agreed. That's a critical usabiliy issue. I just wanted to share some info about the work that is in progress to remove the need to locally install a certificate at all.

@l0rd @tsmaeder is

oc get secret router-ca -n openshift-ingress-operator -o 'go-template={{index .data "tls.crt"|base64decode}}' > ca.crt

working for you?
This is what we would tell anyone who have installed Che through the openshift4 operator hub to do to retrieve the certificate. These people may not have chectl installed.

@sunix that does not even run on Windows (no base64decode).

@l0rd this is not a usability issue, it's blocking me from working on any che-theia stuff, since openshift.io is not a workable platform for self-hosting. I have no workaround right now.

@tsmaeder you can remove the base64 decode and decode it online: https://www.base64decode.org/
If this can help to for your self-hosting.

@sunix not sure how that would work: I don't understand what this syntax does: "-o 'go-template={{index .data "tls.crt"|base64decode}}'"

After reading up on go template syntax, I've been able to create a certificate file via @sunix's instructions. Importing that certificate file works. However, reexporting a certificate via chectl cacert:export and importing that file leads to the problem described in this bug.
As I have a workaround, I'm stopping investigation on this bug.

The exact incantation on Windows is:

oc get secret router-ca -n openshift-ingress-operator -o "go-template={{index .data \"tls.crt\"}}" > ca.crt

You then have to base-64 decode the contents of the resulting file and then can import the certificate.

Was this page helpful?
0 / 5 - 0 ratings