When Che server attempts to send an HTTPS request to an external service as Keycloak, a proxy or a git server, the connection fails if Che does not trust the TLS certificate used by the external service.

To fix this problem, configure Che to authorize HTTPS communication with external services, such as identity and Git servers, by adding information about the TLS certificates to the Che configuration.

Prerequisites
  • The kubectl tool is available.

Procedure
  1. Save the external services certificates to a local file system.

  2. Create a new configMap with the required TLS certificates:

    $ kubectl create configmap <configMap-name> --from-file=<certificate-file-path> -n=<che-namespace-name>

    To apply more than one certificate, add another --from-file=<certificate-file-path> option to the above command.

  3. Update the existing Che server configuration

    Use these steps with existing instances of Che. To install a new instance of Che with self-signed TLS certificates, create a new CheCluster Custom Resource or Helm Chart property, based on the installation method selected, instead of updating the existing configuration.
    • For a Che Operators deployment:

      • Define a name for the newly created configMap by editing the spec.server.ServerTrustStoreConfigMapName CheCluster Custom Resource property to match the previously created configMap:

        $ kubectl patch checluster eclipse-che -n che --type=json -p '[{"op": "replace", "path": "/spec/server/serverTrustStoreConfigMapName", "value": "<config-map-name>"}]'
    • For a Che Helm Chart deployment:

      1. Clone the che project.

      2. Go to the deploy/kubernetes/helm/che directory.

      3. Define a name for the newly created configMap by editing the global.tls.serverTrustStoreConfigMapName Helm Chart property to match the previously created configMap:

        $ helm upgrade che -n che --set global.tls.serverTrustStoreConfigMapName=<config-map name> \
           --set global.ingressDomain=<kubernetes-cluster-domain> .

        When using Minikube to run Che, substitute <kubernetes-cluster-domain> with $(minikube ip).nip.io.

Verification

If the certificates have been added correctly, the Che server starts and obtains Keycloak configuration over HTTPS. Otherwise here is a list of things to verify:

  • CheCluster attribute serverTrustStoreConfigMapName value matches the name of the ConfigMap. Get the value using the following command :

    $ kubectl get -o json checluster/eclipse-che -n che | jq .spec.server.serverTrustStoreConfigMapName
  • Che Pod Volumes list contains one Volume that uses the ConfigMap as data-source. To get the list of Volumes of the Che Pod:

    $ kubectl get po -o json <che-pod-name> -n che | jq .spec.volumes
  • Certificates are mounted in folder /public-certs/ of the Che server container. This command returns the list of files in that folder:

    $ kubectl exec -t <che-pod-name> -n che -- ls /public-certs/
  • In the Che server logs there is a line for every certificate added to the Java truststore, including Che self signed certificate.

    $ kubectl logs <che-pod-name> -n che
    (...)
    Found a custom cert. Adding it to java trust store based on /usr/lib/jvm/java-1.8.0/jre/lib/security/cacerts
    (...)
  • $Che server Java trustore contains the certificates. The certificates SHA1 fingerpints are among the list of the SHA1 of the certificates included in the trustore returned by the following command:

    $ kubectl exec -t <che-pod-name> -n che -- keytool -list -keystore /home/che/cacerts
    Your keystore contains 141 entries
    
    (...)

    To get the SHA1 hash of a certificate on the local filesystem:

    $ openssl x509 -in <certificate-file-path> -fingerprint -noout
    SHA1 Fingerprint=3F:DA:BF:E7:A7:A7:90:62:CA:CF:C7:55:0E:1D:7D:05:16:7D:45:60
Tags: