argo-cd: x509: certificate signed by unknown authority
If you are trying to resolve an environment-specific issue or have a one-off question about the edge case that does not require a feature then please consider asking a question in argocd slack channel.
Checklist:
- I’ve searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
- I’ve included steps to reproduce the bug.
- I’ve pasted the output of
argocd version.
Describe the bug
Whenever I try to connect to a helm repository I get an error: x509: certificate signed by unknown authority
for example:
rpc error: code = Unknown desc = Manifest generation error (cached): helm repo add stable https://charts.helm.sh/stable failed exit status 1: Error: looks like “https://charts.helm.sh/stable” is not a valid chart repository or cannot be reached: Get “https://charts.helm.sh/stable/index.yaml”: x509: certificate signed by unknown authority
I’m sure there’s something I’m doing wrong, but I’ve tried adding certificates, secrets etc. and nothing seems to work. I also don’t seem to be able to get any repositories to connect unless I add them via the GUI and set “Skip server verification”
To Reproduce
Set the repourl to be any helm chart
Expected behavior
The system is able to connect to helm repositories and download the charts.
Screenshots
Version
Paste the output from `argocd version` here.
Logs
Paste any relevant application logs here.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 26 (8 by maintainers)
Just to summarize what’s in https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/#self-signed-untrusted-tls-certificates:
Argo CD uses a kind of certificate pinning - that means, each certificate is pinned to the name of the repository server, and must be configured accordingly. The CN in the configured certificate is irrelevant, as long as it can be used to validate the server’s certificate (e.g. when you supply a CA certificate to validate TLS connections). What is relevant is the certificate supplied by the remote server - this needs to be properly set-up with a SAN that actually identifies the server (through SAN extension
DNS:<servername>, for example). One of the SAN entries must match the name of the server as being used to connect to it.If this is working now, can we close this issue then?