SVT:Error: Internal Server Error - self signed certificate in certificate chain

[jagraj]

Codewind version: Codewind 0.14.0
OS: WIndows

Che version:
IDE extension version: 0.14.0
IDE version: Eclipse 2020-03
Kubernetes cluster:

Description:
I configured accessing secured templates from Codewind and I got into following failure.

One or more template source updates failed.
An error occurred trying to add template source: https://kabanero-index-kabanero.apps.jagraj4.4.4.purple-mystic-butterfly.com/kabanero-index.json
Error: Internal Server Error - self signed certificate in certificate chain

Steps to reproduce:

1. Install Codewind 0.14.0
2. Configure secure templates.
3. Then you get this failure while adding secure repo.

Workaround:

[jagraj]

/priority stopship

[tetchel]

cwctl needs to be able to disable ssl cert checking for template repos. The --insecure flag could be interpreted to do that.

[hhellyer]

I tried this locally, the error is coming from the codewind container itself, not the installer:

[17/06/20 08:36:27 /portal/routes/templates.route.js] [ERROR] { Error: self signed certificate in certificate chain
    at TLSSocket.onConnectSecure (_tls_wrap.js:1058:34)
    at TLSSocket.emit (events.js:198:13)
    at TLSSocket._finishInit (_tls_wrap.js:636:8) code: 'SELF_SIGNED_CERT_IN_CHAIN' }

[hhellyer]

There are 3 ways to fix this:

1. We can disable certificate checking for template repositories.
2. We could add a flag to template repositories to indicate certificate checking should be disabled.
3. We could not make a change and require that template repositories have a valid certificate.

Of those:

1. is trivia. I've tried it on a branch here: https://github.com/hhellyer/codewind/tree/template_certificate_checking and it seems to work (apart from not knowing @jagraj's password!).
   However we discussed it and don't think it's a good idea. It would allow someone to potentially spoof a repository (e.g. github) and we wouldn't notice, given that Codewind is essentially a tool for injecting code onto your machine or Kube cluster this isn't a good idea.

2. Would be an additional feature and require work in PFE, the installer and the UI plugins. We would need to see if we could contain it in the next release.

3. This is the current situation, we might want to document this.

[tobespc]

@jagraj @jopit @malincoln so our options really are 2 and 3 from above. If this is something we need for 0.14 then with a week left to go to dcut, do we have the resources ?

[jopit]

Is there no way for the user to import the self-signed cert into the user's trust store?

[hhellyer]

The error isn't coming from cwctl running on the users machine it's coming from the PFE container. We would need to import their certificate into the container and it would be lost on restart.
In Kube we might be able to do something like mount the certificate but we'd still have to import it into the right place on the system.

@markcor11 - Do you have any ideas on how we'd import a certificate into the codewind container when it starts up? (I think you've done similar things for the operator and keycloak.)

[jagraj]

I just updated my box note with the instructions how user can make client call to secure template repo with curl command. We need beaver token and also self signed certificate to make a call to secure template repo.

[markcor11]

The CA certificate is required in order for the client side code to validate the authenticity of the server certificate which is being connected to. The CA cert does not need to be protected in the same way a private key would be, in fact the more people who have the CA issuer certificate the better.

The CA certificate needs to be available before connecting to the server because if you are thinking of pulling the certificate down and accepting it on the fly during initial contact then you might just as well pass the --insecure option to CWCTL which does a blanket "we don't care on the certificate origin of this server".

By having the certificate available BEFORE use, makes for a more robust validation check since you are saying I only want to trust this server certificate if it was issued by CA's I know about.

In terms of the operator, we store Certificates and keys in Kubernetes secrets mounted into the file system of the container. There they survive restarts and are remounted on pod startup where they appear as a pem files in the container.

Having the secret available isn't the end of the story though, they still need to be utilised by the client code and should be provided to it alongside each HTTPs request it makes, or by adding it to a default Root Certificate store.

Here's a list of where GO currently scans for certificate files on Linux:

https://golang.org/src/crypto/x509/root_linux.go

[markcor11]

GoLang example supplying CA certificates from PEM from files outside of the default paths:
https://golang.org/src/crypto/tls/example_test.go