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

Raft join from CLI seems to be ignoring -tls-skip-verify #7269

Closed
SK360 opened this issue Aug 7, 2019 · 5 comments
Closed

Raft join from CLI seems to be ignoring -tls-skip-verify #7269

SK360 opened this issue Aug 7, 2019 · 5 comments
Labels
bug Used to indicate a potential bug

Comments

@SK360
Copy link

SK360 commented Aug 7, 2019

Describe the bug
When we have TLS enabled on a listener with a self signed cert, we are unable to join raft node due to cert signed by unknown authority error. It seems to be ignoring the -skip-tls-verify flag.

To Reproduce
[vault@Vault-002 ~]$ vault operator raft join -tls-skip-verify https://10.255.12.209:8200
Error joining the node to the raft cluster: Error making API request.

URL: POST https://127.0.0.1:8200/v1/sys/storage/raft/join
Code: 500. Errors:

Expected behavior
I expect it to trust the unknown authority and join the cluster

Environment:

  • Vault Server Version (retrieve with vault status): 1.2.0
  • Vault CLI Version (retrieve with vault version): 1.2.0
  • Server Operating System/Architecture: CentOS7

Vault server configuration file(s):

storage "raft" {
  path    = "/var/vault/raft"
  node_id = "Vault-001"
}

cluster_addr = "https://10.255.12.209:8201"
api_addr = "https://10.255.12.209:8200"

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_cert_file = "/etc/vault/tls/vault-cert.pem"
  tls_key_file = "/etc/vault/tls/vault-key.pem"
}

Additional Info
I also tried setting VAULT_SKIP_VERIFY env variable with no luck

@chrishoffman chrishoffman added the bug Used to indicate a potential bug label Aug 9, 2019
@leventyalcin
Copy link

leventyalcin commented Aug 19, 2019

I have the very same issue but not limited with that.

The cluster is using the very same certificate on all the nodes. So that, I've tried to set VAULT_CACERT with the correct CA file but didn't help.

When I checked what options I have with join command, I've noticed -leader-ca-cert, -leader-client-cert and -leader-client-key. While I'm giving the correct certs and the key, I've got following error.

* tls: failed to find any PEM data in certificate input

I've also added -client-cert, -client-key and -ca-cert, but the result is the same.

I also added the CA to the trusted chain. While curl-ing the API is OK without -k or giving the CA cert, RAFT isn't working.

@krabradosty
Copy link

krabradosty commented Sep 7, 2019

I've got the same error. But I use not a self-signed certificate. Instead, I configure Vault nodes with a certificates chain (server certificate + root CA certificate).
And, as I understand, -tls-skip-verify is used for client-server communication, but the problem is in establishing server-server tls communication.
Error still occurs after I added the root CA certificate to the host's trusted certificates store.

@krabradosty
Copy link

@leventyalcin
Copy link

Whoa! Nice catch @krabradosty and thanks for the ping. On the PR, it seems tagged for the release 1.2.3 but still not in the CHANGELOG unfortunately. I'm pretty sure will be released with the new version 🤞

ribbybibby added a commit to utilitywarehouse/vault-manifests that referenced this issue Sep 13, 2019
* Add the ca cert to the root bundle with an initcontainer
    * this works around this issue: hashicorp/vault#7269
    * it also makes initial setup a little simpler because you don't need to pass the ca cert
* Provide the config as an environment variable; this seems cleaner to me than sed
* Run vault with dumb-init to catch zombies
* Add a sidecar to unseal vault
    * if there's no key provided, assume this is the first run and block
    * rather than adding logic to confirm if the server is up and sealed,
      wait a reasonable amount of time and then unseal; if it fails then rely
      on kube's retry logic rather than adding our own
@michelvocks
Copy link
Contributor

Closing this since #7393 has been merged.

ribbybibby added a commit to utilitywarehouse/vault-manifests that referenced this issue Feb 18, 2020
We were adding the vault ca cert to the root ca bundle for two reasons:
- To workaround this issue with raft join: hashicorp/vault#7269
- To make things simpler when manually bootstrapping vault by removing the need to specify the path to the
  ca cert on the command line

Now that we're automatically bootstrapping the cluster and the issue is fixed, we can get rid of it.
ribbybibby added a commit to utilitywarehouse/vault-manifests that referenced this issue Feb 18, 2020
We were adding the vault ca cert to the root ca bundle for two reasons:
- To workaround this issue with raft join: hashicorp/vault#7269
- To make things simpler when manually bootstrapping vault by removing the need to specify the path to the
  ca cert on the command line

Now that we're automatically bootstrapping the cluster and the issue is fixed, we can get rid of it.
ribbybibby added a commit to utilitywarehouse/vault-manifests that referenced this issue Feb 18, 2020
We were adding the vault ca cert to the root ca bundle for two reasons:
- To workaround this issue with raft join: hashicorp/vault#7269
- To make things simpler when manually bootstrapping vault by removing the need to specify the path to the
  ca cert on the command line

Now that we're automatically bootstrapping the cluster and the issue is fixed, we can get rid of it.
ribbybibby added a commit to utilitywarehouse/vault-manifests that referenced this issue Feb 18, 2020
We were adding the vault ca cert to the root ca bundle for two reasons:
- To workaround this issue with raft join: hashicorp/vault#7269
- To make things simpler when manually bootstrapping vault by removing the need to specify the path to the
  ca cert on the command line

Now that we're automatically bootstrapping the cluster and the issue is fixed, we can get rid of it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Used to indicate a potential bug
Projects
None yet
Development

No branches or pull requests

5 participants