What is the difference between CONCOURSE_VAULT_CA_CERT and CONCOURSE_VAULT_CA_PATH

I deploy concourse and vault to kubernetes via helm and using authBackend: "cert" vault auth enable cert

What is the difference between the following two concourse environment vars / configuration:

## Path to a directory of PEMEncoded CA cert files to verify the vault server SSL cert.

concourse.web.vault.caPath: (env var CONCOURSE_VAULT_CA_PATH)


secrets.vaultCaCert (env var CONCOURSE_VAULT_CA_CERT)

aren’t they the same thing?? (pointing to the same vault cert?)

‘CA path’ means a filesystem path to a certificate file - values like /path/to/ca.crt, but ‘CA cert’ means the literal value of the cert - values like


so it is just a “configuration flavour”?

you can use the one OR the other env var to point to the (one and only) vault login cacert.

There is no case where these two would point to a different cert, right?

(if so, would be worth a mention in the docs, as it gave me some head-scratching)

I’m sorry, I said quite the wrong thing! Right there in the comment it explains that concourse.web.vault.caPath should actually be a path to a directory that could potentially contain many trusted certificates (like /etc/ssl/certs).

When it comes to how to trust the vault server’s CA cert in particular, Concourse’s vault API client delegates to hashicorp/go-rootcerts:

and doc comment in that library explains the precedence:

What this means for your helm chart case is that when concourse.web.vault.useCaCert is true, secrets.vaultCaCert will override concourse.web.vault.caPath. Maybe an explanatory comment in the helm chart, would help, or better we could improve the CLI helptext:

It seems unlikely that you’d set both, but I could imagine some kind of setup where an IT group at your company maintains a list of internal trusted certificates which gets automagically mounted at a fixed path in all your k8s pods. Then a sensible policy might be to set concourse.web.vault.caPath to point to this directory.

If we further suppose that you’re running some kind of “dev” Vault with a self-signed cert and you want to deploy a “dev” concourse on the same company infrastructure to integrate with it, you might also set secrets.vaultCaCert in the same deployment as a kind of “override”.

ah, ok, that explains it, thanx for doing these investigations … and I’d suggest to enhance the docs by saying:

CAPath     string `long:"ca-path"              description:"Path to a directory of (potentially many) PEM-encoded CA cert files to verify the vault server SSL cert, if not already configured by CACertFile."`

also heaving these comments in the values.yaml would be handy.

…as to be honest, it completely slipped my attention, that CAPath points to a directory (even if that was stated very clearly), as my mind was just obsessed to assign my generated certificates to the correct config variable :slight_smile: