Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Helm repositories with self signed certs doesn't work when used as umbrella charts #3693

Open
MohamedTalhaoui opened this issue Jun 2, 2020 · 8 comments
Labels
bug Something isn't working verify Solution needs verification

Comments

@MohamedTalhaoui
Copy link

Describe the bug

I have deployed chartmuseum and configured argocd to use it as a helm repository.
I have also added the self signed certificate
Helm Repository is correctly added and argocd can connect to it.

My chartmuseum hosts a base helm chart that I wish to use as a umbrella chart.
I have a git repo containing a child helm chart that depends on my base helm chart

Sync of the child helm chart fails with

x509: certificate signed by unknown authority

To Reproduce

Deploy a chartmuseum
Push a base hel chart to the chartmuseum
Register chartmuseum as a helm repository in argocd
Add the chartmuseum self-signed cert to argocd-tls-certs-cm
Create a git repo with a child helm chart depending on the base
Create an argocd application to sync the child helm chart
The sync fails with

x509: certificate signed by unknown authority

Expected behavior
The sync should be succesful

Screenshots

If applicable, add screenshots to help explain your problem.

Version

argocd: v1.5.4+36bade7
  BuildDate: 2020-05-05T19:02:56Z
  GitCommit: 36bade7a2d7b69d1c0b0c4d41191f792a847d61c
  GitTreeState: clean
  GoVersion: go1.14.1
  Compiler: gc
  Platform: darwin/amd64
argocd-server: v1.5.4+36bade7
  BuildDate: 2020-05-05T19:01:57Z
  GitCommit: 36bade7a2d7b69d1c0b0c4d41191f792a847d61c
  GitTreeState: clean
  GoVersion: go1.14.1
  Compiler: gc
  Platform: linux/amd64
  Ksonnet Version: v0.13.1
  Kustomize Version: {Version:kustomize/v3.5.4 GitCommit:3af514fa9f85430f0c1557c4a0291e62112ab026 BuildDate:2020-01-11T03:12:59Z GoOs:linux GoArch:amd64}
  Helm Version: version.BuildInfo{Version:"v3.2.0", GitCommit:"e11b7ce3b12db2941e90399e874513fbd24bcb71", GitTreeState:"clean", GoVersion:"go1.13.10"}
  Kubectl Version: v1.14.0

Logs

Paste any relevant application logs here.
@MohamedTalhaoui MohamedTalhaoui added the bug Something isn't working label Jun 2, 2020
@alexmt
Copy link
Collaborator

alexmt commented Jun 2, 2020

hello @MohamedTalhaoui ,

Try registering your repository using --insecure-skip-server-verification flag:

argocd repo add <url> --insecure-skip-server-verification --type helm --name <reponame>

Thanks,
Alex

@alexmt alexmt added the verify Solution needs verification label Jun 2, 2020
@MohamedTalhaoui
Copy link
Author

MohamedTalhaoui commented Jun 10, 2020

Hi,

I am using declarative setup and the helm repo definition looks like this

- name: chartmuseum-private
   type: helm
   insecure: true
   url: https://chartmuseum....

I still have the error.
Important to note that the helm repo is correctly added to my repositories with connection status showing successful. But synchronising an application using this repository fails with the certificate error.
Am I missing something ?

@MohamedTalhaoui
Copy link
Author

Any update ?

@MohamedTalhaoui
Copy link
Author

MohamedTalhaoui commented Jul 16, 2020

I can reproduce with latest argocd release 1.6.1
I have also tried removing the insecure flag and importing the server certs in the argocd-tls-certs-cm but that does not help.

Maybe related to #3539

@MohamedTalhaoui
Copy link
Author

I was able to workaround this issue by forcing the use of absolute path in the chartmuseum chart repo.
helm/chartmuseum#170

I was able to test with harbor (that uses chartmuseum underneath).
I was not able to test with Nexus that does not seem to have a configuration option for this.

Not sure if this issue is still in ArgoCD scope, so I let you guys decided it you want to keep it or close it.

@geowalrus4gh
Copy link

Almost 2 year old 'relevant' bug. Do you guys have any plan to fix it ?

@jgwest
Copy link
Member

jgwest commented Feb 8, 2024

Is this still reproducible after #6458?

@fuzolan
Copy link

fuzolan commented Aug 22, 2024

I use 2.12.1 and it is still broken

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working verify Solution needs verification
Projects
None yet
Development

No branches or pull requests

5 participants