jx: x509: certificate signed by unknown authority' error on controllerteam pod
Summary
The controllerteam pod cannot successful start due to x509: certificate signed by unknown authority’ error during installation.
Steps to reproduce the behavior
Perform a jx installation on a network that employs self signed root ca.
Expected behavior
Installations succeeds without error
Actual behavior
The controllerteam pod contains the follow error in the log
error: failed to initialise helm: failed to run 'helm init --client-only' command in directory '', output: 'Creating /root/.helm
Creating /root/.helm/repository
Creating /root/.helm/repository/cache
Creating /root/.helm/repository/local
Creating /root/.helm/plugins
Creating /root/.helm/starters
Creating /root/.helm/cache/archive
Creating /root/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Error: error initializing: Looks like "https://kubernetes-charts.storage.googleapis.com" is not a valid chart repository or cannot be reached: Get https://kubernetes-charts.storage.googleapis.com/index.yaml: x509: certificate signed by unknown authority'
Jx version
The output of jx version is:
jx 2.0.775
jenkins x platform 2.0.1287
Kubernetes cluster v1.14.1
kubectl v1.14.1
helm client Client: v2.14.3+g0e7f3b6
git 2.18.0
Operating System CentOS Linux release 7.6.1810 (Core)
verifying packages
Jenkins type
- [ X] Serverless Jenkins X Pipelines (Tekton + Prow)
- Classic Jenkins
Kubernetes cluster
v1.14.1 K8S Cluster on VMWare VMs created by kubespray
Operating system / Environment
CentOS 7.6
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 20 (11 by maintainers)
Would also be interested in the outcome of this. Blocking self-signed certificates outright on the assumiption that everyone is using github.com for helm repos and webhooks seems somewhat short-sighted. Particularly in my case, trying to set up a proof-of-concept install on a development kubernetes cluster and using a development gitlab install (all with company-signed certs) and no external access allowed - it makes running jx boot needlessly painful.
I have no problem with requring properly-signed certs being the default, but it should be configurable or this product becomes effectively useless for a significant number of potential enterprise customers.
@garethjevans I am currently trying to evaluate Jenkins X on-prem behind my company’s firewall which directs all traffic through their proxy which is terminated with a self-signed cert. We have to configure most software to trust the company’s custom root ca for them to work properly. What I was hoping for in Jenkins X was the ability for me to configure it to use the OS’s cert bundle (which has the company’s root ca already trusted) or a root ca cert that I provide for the Jenkins X images to trust.